Hacker News Reader

Comment by InitialLastName | Hacker News Reader

I would suggest that you be VERY careful with that expressiveness if you want to do anything in an actual hardware context. Verilog makes it very easy (IME much easier than VHDL) to create structures that, while technically possible to synthesize, take enormous amounts of logic resources.

View on HN

The course focuses on synthesizable Verilog for FPGAs, so our instructor has made sure to clarify the upsides and downsides to using different logic for common tasks.

Some interesting ones:

* Never use asynchronous resets [on FPGAs]

* if-else if-else chaining leads to unnecessary delays (priority encoders)

* Avoid latches by making sure to assign default values

* Never assume default values and/or states

Your professor seems great so far but pretty silly of him to teach you verilog instead of VHDL. As an EE myself I haven't seen a job description that says verilog over vhdl in a long time. Might want to familiarize yourself with both if you plan to pursue hardware design further.

Depends on where you're located. Counter anecdata: I've seen much more EE jobs asking for Verilog than VHDL :).

From what I read, this is very different between the US and Europe.

VHDL is popular in Europe and the US East Coast. Verilog is king on the West Coast.

An an EE who was schooled in VHDL, gave VHDL classes to new hires and was conditioned to look down on Verilog: after moving from Europe to the East Coast and then the West Coast, I eventually saw the error of my ways and I'm very happy to not have to deal with VHDL anymore.

And for the open source crowd: there is a much large body of decent quality open source Verilog tools than there is for VHDL. So as a hobbyist, it's really a nobrainer.

I always got more of a VHDL for FPGAs and Verilog for chips kind of vibe. Not that there's anything intrinsic in those languages, just the kinds of industries that ship FPGAs seem to gravitate to a DoD specified language.

And can you elaborate on what you like about Verilog?

That is very strange. Verilog and SystemVerilog totally dominates VHDL across the globe in terms of market share. Including Europe. Esp if you are designing ASICs, but also for FPGAs.

If you are desinging ASICs and use VHDL you will quite likely end up having mixed language RTL design. And after synthesis the netlist will be in Verilog. So any co-simulation between RTL and netlist must support both languages. Which costs extra in licenses.

Other reasons for choosing Verilog is that the tool developers (being mainly in the US) knows Verilog best. If you look at the adaption rate of new language features, Verilog (SystemVerilog) gets much more attention.

VHDL is for some reason considered a good school language. I don't see the point of it. It's a bit like teaching the ISO stack. The industry has chosen another stack, the pedagogical value if ISO vs TCP/IP is slim to none. The same can (imho) be said for VHDL.

I know Intel uses Verilog.

The majority of Intel's newly developed HDL is systemVerilog on the design and verification side, but honestly there is still a mix of everything going on there.

Some chip designs make use of purchased IP which is at times VHDL. Heck some unit owners and architects even experimented with HLS (High Level Synthesis) using SystemC for part of the graphics hardware and a few units still have state machines which automatically translate from a DSL or word macros.

I do think both of the trends people are identifying hold true though. US is more verilog than not, Europe I see more VHDL than verilog. US exceptions are typically FPGA developers and defense contractors (but definitely not universally).

In my opinion I find systemVerilog to be much easier to design in with less verbose syntax, better tooling and some nice constructs that make realizing design intent easier. systemVerilog always blows away VHDL in testbench design and general verification environment support. I would never wish designing an elaborate testbench in VHDL on an engineering team. VHDL does have some advantages if you have requirements to do a lot of formal property verification though.

* Never use asynchronous resets [on FPGAs]

It makes no difference for most FPGAs. Most have dedicated resources dedicated to resets and consume equal resources for async and sync resets.

For ASIC, sync resets these days are considered safer against glitches because they only have an impact during a rising edge of the clock instead of all the time.

But it's not something to be super religious about.

From my understanding, many FPGAs do not have a dedicated reset distribution network. Instead, P&R consumes a ton of resources to propagate resets across the chip.

My information could be out of date though!

Sometimes if-else-chaining is what you need. But if you are doing one of n-select, a switch is what you should use.

If you are using Verilog 2001 or later, you can use always @* to implicitly declare all variables a combinational process depends on. It used to be a huge source of latches.

I would also highly advice against mixing blocking (i.e a = x) and non-blocking (i.e. a <= x) assignments in one process. I usually write a single clocked process with all registers and then only have a few extra combinational processes for the logic.

I also recommend separating data path logic (the processing you do) with the control path (the FSM that keep track of what is happening inside your machine).

Never assume values or states is really good. I usually assign default states at the top of processes. Then for other state you only have to define that. It is really helpful in FSMs.

Not claiming to having a great coding style, but if you want some examples on RTL code and testbenches here are my cores for AES, SHA256 and many others:

https://github.com/secworks

Thanks for the pointers!

Actually, the first thing our professor taught us is when exactly to use blocking and non-blocking and that they should never be mixed.

By the way, I ran across some of your code on GH about a year back and have been following you ever since. Nice coincidence haha :)

Reply on news.ycombinator.com