Live data from Hacker News

Designing a CPU in VHDL, Part 1: Rationale, Tools, Method

labs.domipheus.com

31–40 of 45 posts

Re: Designing a CPU in VHDL, Part 1: Rationale, Tools, Method

#31
We did similar projects as part of our ECE degree. In general we would start with boolean algebra and logic design, then proceed to computer organization and last to computer architecture (one semester each).

Your project would be at the computer organization level. IIRC adding a pipeline would move it to computer architecture level.

I understand that reading outside a class may be a bit boring, but these courses gave us a much better understanding of key concepts and issues; from basic boolean operations (i.e how to do them right, how to optimize them), to basic concepts (e.g. 2's complement, base-2 arithmetic, FSMs, flip-flops), to more advanced concepts (e.g complex logical components, datapath, control), to various issues (e.g hazards, async / sync design), etc (i.e all these you probably won't implement as cache, OoO execution, virtual memory).

Knowing —to a certain degree— all these made the project easier and much more fun since we could actually have crazy ideas and try to implement them.

I don't know the current state of literature, but when I took the courses (12 years ago) the Patterson and Hennessy books (Computer Organization and Design, Computer Architecture) were terrific.

Re: Designing a CPU in VHDL, Part 1: Rationale, Tools, Method

#32
For those who really want to get into HDL stuff but are put off by the weird syntax, I highly suggesting taking a look at MyHDL[0]. It's a very nice Python lib with good docs and active development. I actually implemented a CPU in it. It can output to VHDL and Verilog and can even generate simple structures for you.

[0] http://www.myhdl.org/

Re: Designing a CPU in VHDL, Part 1: Rationale, Tools, Method

#33

Please 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.

Forgive my ignorance, for I'm just starting out with VHDL and digital hardware design in general. Building a CPU is what I eventually intend to do and I am curious how would you benchmark a hardware design? What metrics would someone use for judging the effectiveness of a CPU arch? My current understanding is gate count, area occupied by the design, clocks per instruction (CPI) and maximum frequency the design can be…

A common metric in embedded is DMIPS/MHz. This is considered a bit antiquated (first written for the VAX!), but the Dhrystone benchmark is free and simple to implement. The important part is that its (supposedly) independent of clock speed to show the efficiency of your CPU design, and so is normally run from cache to get zero wait-states. CoreMark[1] is a new replacement, and is becoming increasingly popular.

Once you implement/simulate your design in silicon, power usage becomes a good comparison metric. As the depends on clock frequency, DMIPS/mW is another common comparison benchmark. Since a lot of embedded applications spend most of there time in very low power states with the core stopped, sleep current and wake/sleep time are now becoming very important. This is more of a whole chip benchmark, and is a very popular area for microcontroller manufacturers to fight over right now, as results can vary wildly depending on the application. The makers of CoreMark have tried to come out with a benchmark[2], but it doesn't cover peripherals yet and isn't quite as popular.

1. https://www.eembc.org/coremark/ 2. http://www.eembc.org/ulpbench/

Re: Designing a CPU in VHDL, Part 1: Rationale, Tools, Method

#34
I'm also an (ex?) compiler engineer and I've played a little with FPGAs and computer architecture. In addition to the obligatory processor design, I recently created a open-source place and route tool for iCE40 FPGAs:

https://github.com/cseed/arachne-pnr

Together with Yosys (a Verilog synthesis tool):

http://www.clifford.at/yosys/

and the IceStorm bitstream creation tools:

http://www.clifford.at/icestorm/

it provides a full Verilog-to-bitstream open source toolchain for the iCE40 FPGAs. There is also a low-cost (~$21) USB development board:

http://www.latticesemi.com/icestick

Unfortunately, this toolchain doesn't support VHDL, so I can't try out the OP's TPU.

Re: Designing a CPU in VHDL, Part 1: Rationale, Tools, Method

#35
I've been working on a similar project for a couple of years now (http://jamieiles.github.io/oldland-cpu/) and these are very rewarding projects - there's a great mix of hardware and software so there's always something interesting to work on.

One of the most valuable lessons that I've learnt from this is to treat the FPGA as a validation target, and the FPGA tools purely as a way to produce that image - they're entirely unfriendly to develop in. If you use verilog then verilator gives lightening fast simulations and you can use it to verify the hardware against.

Re: Designing a CPU in VHDL, Part 1: Rationale, Tools, Method

#36

We did similar projects as part of our ECE degree. In general we would start with boolean algebra and logic design, then proceed to computer organization and last to computer architecture (one semester each). Your project would be at the computer organization level. IIRC adding a pipeline would move it to computer architecture level. I understand that reading outside a class may be a bit boring, but these courses gav…

What is the difference between Computer Organization and Computer Architecture?

Re: Designing a CPU in VHDL, Part 1: Rationale, Tools, Method

#37

We did similar projects as part of our ECE degree. In general we would start with boolean algebra and logic design, then proceed to computer organization and last to computer architecture (one semester each). Your project would be at the computer organization level. IIRC adding a pipeline would move it to computer architecture level. I understand that reading outside a class may be a bit boring, but these courses gav…

As of 2007-2011, Patterson and Hennessy books were in use in courses I took as well. Great stuff, but the treatment on GPUs was a little out of date even a year or two after being published (GPGPU was just getting started and evolving rapidly).

Re: Designing a CPU in VHDL, Part 1: Rationale, Tools, Method

#38
post #37

We did similar projects as part of our ECE degree. In general we would start with boolean algebra and logic design, then proceed to computer organization and last to computer architecture (one semester each). Your project would be at the computer organization level. IIRC adding a pipeline would move it to computer architecture level. I understand that reading outside a class may be a bit boring, but these courses gav…

As of 2007-2011, Patterson and Hennessy books were in use in courses I took as well. Great stuff, but the treatment on GPUs was a little out of date even a year or two after being published (GPGPU was just getting started and evolving rapidly).

Their Computer Organization and Design, had a new edition in 2013, that may cover GPU stuff better, havn't read it myself thou.

Still havn't seen a book that covers SIMD very well?

Re: Designing a CPU in VHDL, Part 1: Rationale, Tools, Method

#39

Please 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.

Having programmed in both, I prefer VHDL--the two take different paths, analogous to functional vs imperative programming. The type checking that makes VHDL so annoying is also the same type checking that's saved me. Coming from Haskell, VHDL was a much easier language to learn than Verilog.

For those not familiar with these languages, saying that VHDL is functional programming and Verilog is imperative programming is misleading. Both use essentially the same style of modeling digital hardware (which is really neither of those): encapsulated modules with ports, clocked processes, and combinatorial logic.

Where they differ is mainly in typing. VHDL requires you (unlike haskell, actually) to (very verbosely) spell out the type of everything. Verilog's type system is more like C's. You declare basic types and it's fairly loosey goosey about them. VHDL's syntax is based on Ada and Verilog's is more C like (but uses begin-end instead of curly braces).

Post reply on HN