Designing a CPU in VHDL, Part 1: Rationale, Tools, Method
11–20 of 45 posts
Re: Designing a CPU in VHDL, Part 1: Rationale, Tools, Method
#12Earlier quoted context omitted.
+1 for Verilog. SystemVerilog is the way to go.
I like VHDL. Verilog and non-blocking vs blocking assignments can trip you up so easily. As for verbose code, you spend way more time debugging and thinking about how to structure a program than you do writing text on the screen.
Re: Designing a CPU in VHDL, Part 1: Rationale, Tools, Method
#13https://www.digilentinc.com/Products/Catalog.cfm?NavPath=2,4...
Re: Designing a CPU in VHDL, Part 1: Rationale, Tools, Method
#14For those interested in other FPGA boards, Digilent makes a whole series of affordable ones. https://www.digilentinc.com/Products/Catalog.cfm?NavPath=2,4...
It's pretty cheap, but it has a whole bunch of nice things built onto it, and a simple flasher script that actually works on Linux!
Re: Designing a CPU in VHDL, Part 1: Rationale, Tools, Method
#15Please do yourself a favor and use Verilog instead. I understand that VHDL forces you to write cleaner code, but it's also frustrating for no good reason. Also, start looking into pipelining ASAP. Implement one micro-arch, benchmark it, then try to do better. It's a great way to learn.
+1 for Verilog. SystemVerilog is the way to go.
Re: Designing a CPU in VHDL, Part 1: Rationale, Tools, Method
#16For those interested in other FPGA boards, Digilent makes a whole series of affordable ones. https://www.digilentinc.com/Products/Catalog.cfm?NavPath=2,4...
Re: Designing a CPU in VHDL, Part 1: Rationale, Tools, Method
#17>bonus points goes to the people who realise there is an odd thing about the form of the baz (branch if Ra is zero) instruction. Is this because the second argument is another register (presumably containing an address to branch to) instead of a label?
Prehaps this is so the assembler/linker/loader doesn't need to resolve what address the label ends up having
Re: Designing a CPU in VHDL, Part 1: Rationale, Tools, Method
#18My best advice: synthesize early and often, and spend the time to poke around in the synthesis schematic viewer - Webpack still includes this I believe. It's a great way to compare what you wrote in code to the logic you intended to implement in your mind's eye (or better yet, your notebook).
Xilinx is happy to not reset registers, Altera will generate a bigger design if reset is not stated in the code.
Re: Designing a CPU in VHDL, Part 1: Rationale, Tools, Method
#19(never mind it being multicycle, it was done this way for a reason, and dropping in a RISC design should be fairly trivial.)
Re: Designing a CPU in VHDL, Part 1: Rationale, Tools, Method
#20Please do yourself a favor and use Verilog instead. I understand that VHDL forces you to write cleaner code, but it's also frustrating for no good reason. Also, start looking into pipelining ASAP. Implement one micro-arch, benchmark it, then try to do better. It's a great way to learn.
It's not perfect either, but reading it is vastly more pleasant than plodding through a design in one of the Vs.