11–20 of 24 posts
Not a great codebase, if you are trying to learn the industry's best practices. For instance, I recommend naming your RTL signals based on which pipeline stage they belong to. Assuming this thing even has a pipeline.
Not a great codebase, if you are trying to learn the industry's best practices. For instance, I recommend naming your RTL signals based on which pipeline stage they belong to. Assuming this thing even has a pipeline.
So, where is a great codebase for somebody who wants to learn?
Then we complain to them when it misbehaves anyway. A quick google will you find some guides.
https://www.doulos.com/knowhow/vhdl_designers_guide/rtl_codi...
On top of that we had company specific style guides. Having jumped from company to company, each one is different here and there.
To be honest, I think we tended to avoid looking at other people's code when we could! Its like having to wipe someone else's butt. It all looks terrible. Everyone can pick on someone else's stuff.
Having said all that, the basic principles of engineering apply:
- Nice separation between the design and the test bench.
- modularity within the design itself.
- A convention of signal naming that will assist the verification process. Eventually they get thrown a waveform when something has gone wrong. They need to look at signal names that aren't some random alphabet jumble.
- Parameterize variables so they can be reconfigured easily.
etc.
Earlier quoted context omitted.
The Terasic DE0-nano ( http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=E... ) is a great board for soft CPU's. It's cheap, has a decent size FPGA and external SDRAM. The Altera tools are free and run under Windows/OSX/Linux. I've used this board for my own soft CPU ( http://jamieiles.github.io/oldland-cpu/ ) and it's a rewarding project!
Happy to provide some quick feedback on your coding style: Please don't use initial blocks to initialize values, use an always block with reset. That will also solve the issue of having multiple drivers per signal (bad). Also, don't load memories from the RTL, do that from the test bench (using hierarchical references). initial begin $readmemh({`OLDLAND_ROM_PATH, "decode.hex"}, microcode, 0, 127); rd_sel = 4'b0; upda…
There are a lot more "news" esk hardware design places as well but I'm assuming you're looking closer to stack overflow/github of HDL rather than the slashdot/reddit of HDL?
If you want HDL best practices any of the resources you can get your hands on from http://www.sutherland-hdl.com/papers.html and I would highly recommend this book: http://www.amazon.com/SystemVerilog-Verification-Learning-Te...
Earlier quoted context omitted.
The Terasic DE0-nano ( http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=E... ) is a great board for soft CPU's. It's cheap, has a decent size FPGA and external SDRAM. The Altera tools are free and run under Windows/OSX/Linux. I've used this board for my own soft CPU ( http://jamieiles.github.io/oldland-cpu/ ) and it's a rewarding project!
Happy to provide some quick feedback on your coding style: Please don't use initial blocks to initialize values, use an always block with reset. That will also solve the issue of having multiple drivers per signal (bad). Also, don't load memories from the RTL, do that from the test bench (using hierarchical references). initial begin $readmemh({`OLDLAND_ROM_PATH, "decode.hex"}, microcode, 0, 127); rd_sel = 4'b0; upda…
For the memory loading, I don't know how you'd infer a ROM another way - aren't hierarchical references only supported in simulation/test benches?
Earlier quoted context omitted.
Happy to provide some quick feedback on your coding style: Please don't use initial blocks to initialize values, use an always block with reset. That will also solve the issue of having multiple drivers per signal (bad). Also, don't load memories from the RTL, do that from the test bench (using hierarchical references). initial begin $readmemh({`OLDLAND_ROM_PATH, "decode.hex"}, microcode, 0, 127); rd_sel = 4'b0; upda…
Thanks for the feedback. With regards to initial blocks, the advantage of using them on an FPGA design is that it's just the initialization value of the registers in the bitstream so doesn't have any real cost, but doing it with a reset would take logic, no? Does that really qualify as multiple drivers? For the memory loading, I don't know how you'd infer a ROM another way - aren't hierarchical references only suppor…
If your target wasn't an FPGA (but an ASIC), the initial block would be completely ignored, so who knows in what state your design would start. FPGAs are nice, they let you specify initial values. Real chips don't. Just put all initial values in your reset clause, in the same always block you assign those registers. Let the FPGA compiler optimize the logic if it can, or infer a mux if it must.
Would anyone familiar with the various qualities of FPGA boards care to weigh in on how to pick a good development board for this project? I personally know nothing about FPGA specs. Additionally, the first blog post in this series can be found at http://labs.domipheus.com/blog/designing-a-cpu-in-vhdl-part-...
The Terasic DE0-nano ( http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=E... ) is a great board for soft CPU's. It's cheap, has a decent size FPGA and external SDRAM. The Altera tools are free and run under Windows/OSX/Linux. I've used this board for my own soft CPU ( http://jamieiles.github.io/oldland-cpu/ ) and it's a rewarding project!
https://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=...
Would anyone familiar with the various qualities of FPGA boards care to weigh in on how to pick a good development board for this project? I personally know nothing about FPGA specs. Additionally, the first blog post in this series can be found at http://labs.domipheus.com/blog/designing-a-cpu-in-vhdl-part-...
The Terasic DE0-nano ( http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=E... ) is a great board for soft CPU's. It's cheap, has a decent size FPGA and external SDRAM. The Altera tools are free and run under Windows/OSX/Linux. I've used this board for my own soft CPU ( http://jamieiles.github.io/oldland-cpu/ ) and it's a rewarding project!
Would anyone familiar with the various qualities of FPGA boards care to weigh in on how to pick a good development board for this project? I personally know nothing about FPGA specs. Additionally, the first blog post in this series can be found at http://labs.domipheus.com/blog/designing-a-cpu-in-vhdl-part-...
http://www.digilentinc.com/Products/Catalog.cfm?NavPath=2,40...
The DE0-Nano-SoC, which has an FPGA and a dual-core Cortex A9 might be a good option if you wanted to get started with Altera parts:
https://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=...
The analogous Xilinx board is probably the Zedboard:
Finally, you might consider the Lattice Semiconductor iCE40. There are two dev boards (small and large, both very cheap):
http://latticesemi.com/iCEstick
http://www.latticesemi.com/en/Products/DevelopmentBoardsAndK...
They are especially attractive since they have the only fully open source toolchain:
https://github.com/cseed/arachne-pnr
Have fun!
Earlier quoted context omitted.
So, where is a great codebase for somebody who wants to learn?
Tools vendors each have coding guidelines that their stuff likes. At the RTL level, industry guys like myself just follow them like puppies due to fear of something in the tool chain breaking. Then we complain to them when it misbehaves anyway. A quick google will you find some guides. https://www.doulos.com/knowhow/vhdl_designers_guide/rtl_codi... On top of that we had company specific style guides. Having jumped fr…
There's also value to a consistently styled codebase.
Not a great codebase, if you are trying to learn the industry's best practices. For instance, I recommend naming your RTL signals based on which pipeline stage they belong to. Assuming this thing even has a pipeline.
Not a great codebase. That's putting it lightly. It does have a pipeline BTW. Industry is so different I don't know where to start complaining. Xilinx tools are not used for simulation usually because they suck and we generally pay those other tool vendors for their stuff so we might as well use them. Given that newbies don't want to pay, maybe Xilinx is the best. I don't know much about the free stuff. Looking at pr…
You know how in software you always say, "We don't have time for that"? Well, it's a lot harder to get away with skipping it in HDL.