News for hackers. Stuff that matters.
Re:Designing a CPU in VHDL, Part 1: Rationale, Tools, Method by alain94040 on Thursday June 18, 2015 @09:18PM (#9742573)
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.

Re:Designing a CPU in VHDL, Part 1: Rationale, Tools, Method by cyanoacry on Thursday June 18, 2015 @10:13PM (#9742690)
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.

Re:Designing a CPU in VHDL, Part 1: Rationale, Tools, Method by krupan on Friday June 19, 2015 @10:50AM (#9745128)
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).

Re:Designing a CPU in VHDL, Part 1: Rationale, Tools, Method by bisrig on Thursday June 18, 2015 @10:26PM (#9742716)
I will never forgive the Verilog powers that be for allowing the 'reg' keyword to describe "things that are not registers". But joking aside, the differences between VHDL and Verilog are minor in this context. And one person's frustration is another's saving grace due to strictness etc.
Re:Designing a CPU in VHDL, Part 1: Rationale, Tools, Method by jevinskie on Thursday June 18, 2015 @10:14PM (#9742691)
Yikes, I find Verilog to be much too C like while VHDL is almost Python like. I enjoy the strictness. VHDL 2008 (should be supported by tools now) fixes a lot of VHDL's warts. Also, I love the two process design methodology that you can use with VHDL. It lets you single-step through your VHDL code in the simulator as if it were plain procedural code!

http://www.gaisler.com/doc/vhdl2proc.pdf

Re:Designing a CPU in VHDL, Part 1: Rationale, Tools, Method by sigterm on Friday June 19, 2015 @02:13AM (#9743263)
One can do the "two process design methodology" in Verilog too. It's not unique to VHDL.
Re:Designing a CPU in VHDL, Part 1: Rationale, Tools, Method by gshrikant on Friday June 19, 2015 @04:55AM (#9743668)
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 clocked at.

Re:Designing a CPU in VHDL, Part 1: Rationale, Tools, Method by snops on Friday June 19, 2015 @08:20AM (#9744202)
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 by ajross on Friday June 19, 2015 @01:13AM (#9743114)
Verilog is C to VHDL's Pascal, maybe. Better but really not that much different. Check out the RISC-V folks' work in Chisel (a Scala-based DSL) for some great examples of what HDL code should be like.

It's not perfect either, but reading it is vastly more pleasant than plodding through a design in one of the Vs.

Re:Designing a CPU in VHDL, Part 1: Rationale, Tools, Method by domipheus on Friday June 19, 2015 @04:22AM (#9743569)
Cheers for the tips. I'll eventually move to Verilog, but as others point out, I think it's good to walk before I run. Regarding pipelining, I'm getting right on it - and the iterative benchmarking is something I plan to do. Thanks again :)
Re:Designing a CPU in VHDL, Part 1: Rationale, Tools, Method by alain94040 on Friday June 19, 2015 @11:48AM (#9745557)
Also, feel free to contribute to the Verilog tutorial I started for software engineers, it's on WikiBooks at https://en.wikibooks.org/wiki/Programmable_Logic/Verilog_for...

VHDL is dead in the industry(). While VHDL is slightly better for teaching, why not learn directly what everyone else uses? Also, because VHDL is such a pain to support for CAD tools, more tools support Verilog only, or support VHDL as a second-class citizen.

() my european friends hate me each time I say that, but it's true.

Re:Designing a CPU in VHDL, Part 1: Rationale, Tools, Method by hobolord on Friday June 19, 2015 @03:12PM (#9746984)
Yeah I was taught in VHDL but my prof acknowledged that it's mainly because it's better as an educational tool. He argued that it's easier to go from VHDL to Verilog after learning the strict practices, and that it leads to just better programming practices in the industry
Re:Designing a CPU in VHDL, Part 1: Rationale, Tools, Method by p1esk on Thursday June 18, 2015 @09:48PM (#9742643)
+1 for Verilog. SystemVerilog is the way to go.
Re:Designing a CPU in VHDL, Part 1: Rationale, Tools, Method by krapht on Thursday June 18, 2015 @09:52PM (#9742657)
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 by blackguardx on Thursday June 18, 2015 @11:00PM (#9742789)
I prefer Verilog but what you say is true or at least should be true if you want to end up with a good, easily debuggable result.
Re:Designing a CPU in VHDL, Part 1: Rationale, Tools, Method by mng2 on Thursday June 18, 2015 @11:42PM (#9742905)
I like VHDL, but SystemVerilog does have some very nice features.