Verilog or VHDL?

[kfnight]

For design I use a safe-subset or lowest-common-demoninator of Verilog/SystemVerilog that I know will work on most EDA tools. It sucks because if I could use some of the newer features of the language my productivity would increase and the code intent would be more readable, but it's always one damn tool that doesn't support that new feature, so I gotta wait like 5 years for everyone to catch up before I can use it.

[mark03]

Just thought I should mention that there are other alternatives, e.g. the Python-based MyHDL:

http://www.myhdl.org/start/why.html

Before anyone hears "Python" and gets their hackles up, this is *not* a high-level synthesis project, rather a mapping of HDL essentials into Python syntax.  The principal author happens to be a European who prefers VHDL, and he considers MyHDL as inheriting many of VHDL's best features, only with less verbosity.  The tools convert MyHDL into either language for importation into your vendor toolchain.

From my naive perspective as a rank beginner in FPGA design, he makes some compelling arguments.  The ability to write your testbenches in Python seems like a big win, particularly for DSP.

Thoughts or opinions?

[sporadic]

No MyHDL love?

EDIT: Looks like I was a little late on hitting submit

[ataradov]

Thoughts or opinions?

Marginal thing that will never be useful. Plus adding Python syntax introduces a lot of inconveniences. Programming languages are for programming, HDL languages are for hardware design.

[mark03]

Adding Python syntax introduces a lot of inconveniences. Programming languages are for programming, HDL languages are for hardware design.

I'm not sure you understand what the project is about.  That is why I took pains to point out that it is an HDL, not a higher-level abstraction.  It just happens to be built using Python syntax.  (Python can be stretched much further than most people realize.  In the case of MyHDL it turns out that an obscure feature called "generators" is just the thing for expressing concurrency in an HDL.)

[ataradov]

Python can be stretched much further than most people realize

Yes, but why? I'd rather use a language with syntax specifically designed for target application.

[Kilrah]

Interesting results so far. Most of the responders have been from Europe or Oceania, so the skew towards VHDL isn't surprising as those are two VHDL strongholds.

I forgot to mention in the poll context that while I consider myself a beginner I have "picked" VHDL because that's we used during my enginnering studies 12 years ago, so it made more sense to make use of the little remains there might be in my memory. So yes, region-biased

[mark03]

Python can be stretched much further than most people realize

Yes, but why? I'd rather use a language with syntax specifically designed for target application.

Well, the developer, an experienced ASIC designer, clearly feels that his syntax is superior to VHDL's.  It wouldn't hurt to at least hear him out.  I know I asked for "opinions" but it would be polite to read his arguments and respond on the merits (or demerits).

[suicidaleggroll]

Interesting results so far. Most of the responders have been from Europe or Oceania, so the skew towards VHDL isn't surprising as those are two VHDL strongholds.

I forgot to mention in the poll context that while I consider myself a beginner I have "picked" VHDL because that's we used during my enginnering studies 12 years ago, so it made more sense to make use of the little remains there might be in my memory. So yes, region-biased

Same here, but the University I went to also used VHDL even though it's in the US.

[lem_ix]

I like that VHDL is very different from C. Easier for me to keep a different mindset while "coding"/describing.

[asgard20032]

Just implement something like enum/type for Verilog just for the sake of state machine.

Then you need to look at SystemVerilog. It implements many new features like this, while keeping syntax clean and simple.

I like what I read so far about system verilog. The only problem is that not every tool support it. Does Quartus support it (what about the legacy Quartus version they use in most university because of cyclon II to cyclon IV... like DE2 board)? Does ISE support it? Does Vivado support it (yes for this one)

[nctnico]

Systemverilog seems to me like it is similar to Borland Delphi with all the C/C++ stuff bolted onto Pascal. If you want the VHDL goodies then just use VHDL.

[ataradov]

All reasonably recent versions of Quartus and Vivado (but not ISE) support it. I use iverilog for simulations, and it does not support it either, so I'm sticking with plain Verilog 2001.

[photon]

Only a subset of SystemVerilog is synthesizable. The additions to Verilog mostly help verification.

[ataradov]

Only a subset of SystemVerilog is synthesizable.

That is true for every language.

The additions to Verilog mostly help verification.

Well, I particularly like structured data, for example. This helps to simplify module interfaces a lot.

[Scrts]

I did a number of designs with VHDL and was happy with it. In general, I could have moved to Verilog at some points because of already written code that I had to learn and understand to re-use, but having records in VHDL still kept me the same way. I did not find verbosity to be a major problem for me.

[Sal Ammoniac]

Only a subset of SystemVerilog is synthesizable. The additions to Verilog mostly help verification.

True. Same goes for plain old Verilog and VHDL too.

I like SystemVerilog's logic type (no more wire/reg nonsense) and always_ff/always_comb.

[Sal Ammoniac]

I like that VHDL is very different from C. Easier for me to keep a different mindset while "coding"/describing.

I haven't noticed that. When I first started writing HDL, it didn't matter whether I was using Verilog or VHDL--I still tended to think in software terms. I have over 30 years experience as an embedded engineer, so those habits are deeply ingrained and were hard to break.

I implemented almost everything at first as a state machine. This approach works, but can be unnecessarily complicated. It's familiar to embedded software types, which is why I suppose so many of us tend to use state machines for everything we do in an HDL. As an example, I recently implemented an SPI slave in SystemVerilog. I implemented it using a state machine that sequenced through eight states, and this took 289 lines of Verilog. After I got it working, I thought to myself, "hey, SPI is a very simple protocol and you're overthinking the problem." I started thinking about it at a purely hardware level and threw out the state machine approach and rewrote it in 36 lines. That's 253 lines shorter, and this version used 12 LUTs and 25 FFs versus 24 LUTs and 37 FFs in the state machine version.

[legacy]

like this  ?
it's written in vhdl, basically the psx_pad controller is an spi_master
with a few customization by Sony, but my approach was ... too-fsm oriented
resulting no less than 194 lines of code

[rstofer]

Python can be stretched much further than most people realize

Yes, but why? I'd rather use a language with syntax specifically designed for target application.

Well, the developer, an experienced ASIC designer, clearly feels that his syntax is superior to VHDL's.  It wouldn't hurt to at least hear him out.  I know I asked for "opinions" but it would be polite to read his arguments and respond on the merits (or demerits).

I read the sales literature and have seen two other approaches to abstracting HDL into something else.  Seriously, my indent level determines whether I am in a particular statement block?  I have been messing around with Python and it has a lot of neat features for strings, lists, tuples and dictionaries.  I got started because I saw an assembler in one page of code (something like that).  Intriguing!  But the syntax is abominable.  I much prefer the rigid block structure of languages like Pascal, Modula 2 and Oberon.  I think I'll like Ada if my fingers don't fall off typing...

Were I to adopt MyHDL, I would need to learn two languages:  MyHDL to write the stuff and VHDL to see if it compiled correctly.  Do MyHDL and I agree on what I want to create?

One of the sales points was that I didn't need to know whether my register represented an integer or a vector; the compiler would figure it out for me.  I don't want the compiler to assume anything!  If my code doesn't uniquely define some logical function, flag it and make me write it again!  VHDL does just that:  I either write it correctly or I write it again.

On the separate issue of state machines, I don't see how you retain state without a state machine.  Now, there are a number of ways to code state machines but you can't get sequential operation without maintaining state.  In school we spent a lot of time minimizing state machines.  Even in the days of the 2102 bit slices, minimizing states was important.  Fortunately, there is only a minor penalty for having additional states (one more bit in the one-hot encoding) and the code becomes a lot more obvious.  I don't see the point of obscuring the code in order to save a few flops when I have tens of thousands.  I would rather the code tell a good story.

But my code is going nowhere.  It is strictly for a hobby, there is no pressure to use a smaller device and I don't want to clever myself into a hole.

[asgard20032]

On the separate issue of state machines, I don't see how you retain state without a state machine.  Now, there are a number of ways to code state machines but you can't get sequential operation without maintaining state.  In school we spent a lot of time minimizing state machines.  Even in the days of the 2102 bit slices, minimizing states was important.  Fortunately, there is only a minor penalty for having additional states (one more bit in the one-hot encoding) and the code becomes a lot more obvious.  I don't see the point of obscuring the code in order to save a few flops when I have tens of thousands.  I would rather the code tell a good story.
But my code is going nowhere.  It is strictly for a hobby, there is no pressure to use a smaller device and I don't want to clever myself into a hole.

like this  ?
it's written in vhdl, basically the psx_pad controller is an spi_master
with a few customization by Sony, but my approach was ... too-fsm oriented
resulting no less than 194 lines of code

I implemented almost everything at first as a state machine. This approach works, but can be unnecessarily complicated. It's familiar to embedded software types, which is why I suppose so many of us tend to use state machines for everything we do in an HDL. As an example, I recently implemented an SPI slave in SystemVerilog. I implemented it using a state machine that sequenced through eight states, and this took 289 lines of Verilog. After I got it working, I thought to myself, "hey, SPI is a very simple protocol and you're overthinking the problem." I started thinking about it at a purely hardware level and threw out the state machine approach and rewrote it in 36 lines. That's 253 lines shorter, and this version used 12 LUTs and 25 FFs versus 24 LUTs and 37 FFs in the state machine version.

I wonder if there are other methodology to develop than state machine, maybe some sort of variant of them. I doubt everyone do state machine, there are maybe other strategy. But fore sure, everything need a way to keep some sort of state. So those other strategy are maybe not a classic state machine like everyone else do, but are surely based on the same concept, but structured/implemented differently. Like in software programming, there are many design pattern, many different programming paradigm, even if some of those paradigm are similar...

Maybe someone that did lot of study on FPGA or work in a big company using FPGA may know more about the different way to implement something.

[ataradov]

I wonder if there are other methodology to develop than state machine, maybe some sort of variant of them.

There is a blend between CPUs and state machines - programmable state machines. Xilinx PicoBlaze is one, for example.

I doubt everyone do state machine, there are maybe other strategy.

There is nothing really wrong with state machines that needs changing.

[rstofer]

There is no alternative to saving state.  You can't build a sequential circuit without states.  The question is:  How do you code the FSM?  I use the two-process approach, one clocked process that simply updates the current state and the other is just an unclocked process that does all the work.

Another alternative that may result in lower resource usage involves writing logic combining the current state and various inputs to provide a specific output.  Dozens and dozens of logic blocks spread all over the place.  Unintelligible for the most part.  One of the PDP-11 projects I ran across used this approach.  Writing code down at the LUT level...  Ugly!

I haven't done it recently but I like microcoding as in the old 2102 days.  All of the logic is contained in a ROM (BlockRAM) and each address results in certain signals being tickled.  Load a register, test and branch, things like that.  With this approach, the entire microcode can be built outside the FPGA and simply stuffed into the BlockRAM at startup.  The result is usually a very clean machine design.  I'm going to try that next time.  Write the meta-assembler in Python and have it generate code for 'dat2mem'.  This could actually work!  Design the data path and do the control code elsewhere.

But it's still a state machine...

[nctnico]

When it comes to statemachines the first thing to do is to realise that you are making a statemachine. Too often you'll see code like 'if a=1 and b=5 then do X else if b=2 and c=2 then do Y' which is just a big stinking pile of unmaintainable sh*t.

BTW In VHDL you can make enumeration types which leave the synthesizer total freedom to choose between any statemachine encoding it likes. A VHDL statement like

Code: [Select]

state_number <= to_unsigned(Esys_state'pos(sys_state), state_number'length); can be used to convert the encoded state into a number for reading it back to debug.

@rstofer: I used something similar over a decade ago for a design which needed to do various operations on samples for a number of channels. My colleague and I came up with a bidirectional bus (supported in Xilinx Spartan2) to which all input and outputs of the ADC interface and processing modules where connected and used Perl to generate the blockram data which was used as a 'microcode' program.

[rstofer]

Back in the mid '70s, I designed the CPU for the IBM 1130 using microcode stored in blown-link PROMs.  It was a really fun project!  At the time, RAM wasn't readily available for hobbyists and all I could get was dynamic so I never finished that project.  The microcode was all done on punch cards, listed and then transferred into manually blowing links.

Fast forward to early '00s and I finally built the machine in an FPGA;  I have had a 46 year love affair with that machine.  First computer and all...

One of the neat things about microcode is that it allows for 'stepwise refinement' without rebuilding the VHDL.  I suspect this would be truly useful when trying to implement really complex things like floating point and trig functions.  Even non-restoring signed division would be a lot easier to write in a meta-assembler than in VHDL.

What I don't know is how to define the data path such that it remains constant as more functionality is added.  Sure, there may need to be small changes but I would like the main register transfer and ALU pieces to remain fixed.  That implies I could define them correctly in the first place - not a good bet, I fear...