I noticed that this uart in orpsocv2 is different than the original checked into the repository. Does anyone know why these changes were made and if they should be pushed back into the original?


John Eaton

Hi John

I think it's mostly formatting changes, although I believe I did add a define to allow hardening of the divisor so it needn't be set up by software. I'm not sure how useful this is.

Other than that, it was really only cosmetic changes. Regarding the multiple copies of cores around the place - this is something we're hoping to address with the next incarnation of ORSPoC, as you might have seen.

Thanks,

Julius

Presetting the divisor is really useful. This is especially true in embedded systems where you have a good understanding of your clocks and baud rate needs. Anything that you can remove from the initialization requirements is one less thing to go wrong during chip turnon.

I did notice that the rtl code had a switch for big/little endian but that this wasn't set in the defines.v file. This would have put any 32 bit uart always in big endian mode which I suspect may be the reason that it is configured in 8 bit mode.

I am doing a new wishbone interface for that module that will give us 8/16/32 bit operation in big or little endian. It will also fix the data hold problem on transmit and replaces `defines with parameters. If I get ambitious I may even parameterize the fifo sizes.

John Eaton

Hi John

Good to hear that the cores are getting a little TLC. Are you planning to step in as co-maintainer and change the upstream version, or was your idea to do the changes in the ORPSoC copy?

As you might know, there has been a move to unify code bases between ORPSoC and upstream lately, so I would prefer that you took over maintainership of the core if there aren't active maintainers already

I have not asked to be a co-maintainer simply because I do no want to deal with making changes that might break something that someone has in an existing design. It is cleaner to simply branch a project in a new database and make the improvements there so that existing users are not affected and sending you hate mail.

I would be willing ( and it is probably a good idea) to put all improvement back into the original project. I would take over maintenance of a existing project with the understanding that:

1) I would add a full test suite using my toolset ( icarus/covered/verilator) to the project

2) I would add my toolset from the socgen project to build the rtl code using an ip-xact enabled tool flow.

3) Any code changes that pass the test suite are allowed.


This would require that users update their systems with the correct libraries and tools to support my tool set. I would publish instructions for the distro's that I use ( Ubuntu,fedora) but any others will have to do their own system administration.

If this is acceptable or if you have concerns then lets talk.

z3qmtr45 @gmail .com


John Eaton

I have no mandate to decide what is acceptable changes to a core that someone else maintains, and that I have hardly looked at. My instinct however says that if the changes would make the core unusable without socgen, I would suggest branching or creating a new project. If socgen can just wrap around the existing core, then I see no problem with integrating a socgen environment. It certainly sounds good to have regression tests for the simulators that you mention

There's also an option for users to not use the latest version if there are changes that might break their designs. This might be a bit problematic in the long run though

If you are interested in co-maintainership, you should try to contact the existing maintainers, and if that doesn't succeed, contact the opencores admins.