Verilog or VHDL?

[Sal Ammoniac]

I'm curious how many people on this forum use Verilog and/or VHDL...

[ataradov]

Verilog, and even that is too verbose for my taste. I can't deal with the amount of typing required for VHDL.

[exmadscientist]

There are entire classes of stupid Verilog mistakes that are simply not possible in VHDL. Given that hardware design is challenging enough, I'm happy to trade a bit of verbosity for a lot of type-safety.

(And it's not like VHDL is that verbose, anyway, given its domain. It's certainly a lot more pleasant to write than yet another AbstractFactoryConstructorDelegationVisitorSingletonFactory!)

[scatha]

It depends on the existing project codebase - if it's Verilog I use Verilog, VHDL then I use VHDL. Mixed-source projects can be a pain because invariably someone's chosen port names which are reserved keywords in the alternate language.

I've been too mentally scarred by other people's horrible, horrible Verilog to use it in my personal projects - I tend to use VHDL for synthesis and SystemVerilog for verification which gives me the best of both worlds.

[obiwanjacobi]

I am a hobbiest and invested in learning a bit of VHDL. Being a C/C++/C# developer I am amazed at the verbosity of the syntax and cannot yet type a simple 'program' without looking stuff up - probably because I do not use it very often.

As I learned PSoC5 and their(Cypress) Creator software I have looked into Verilog and it looks a lot simpler, but have not invested in learning that. But I probably will when I need to do some advanced custom components...

[mikeselectricstuff]

There are entire classes of stupid Verilog mistakes that are simply not possible in VHDL. Given that hardware design is challenging enough, I'm happy to trade a bit of verbosity for a lot of type-safety.

That's the  reason I chose VHDL - I'm sure if I used it a lot I'd prefer Verilog, and find some aspects of VHDL just plain stupid (e.g. no block comments or #define/#ifdef), but as I only do maybe one FPGA project a year, I'm never going to get really familiar with it, so any help the language can give to avoid mistakes is welcome.
 

[hamster_nz]

I use VHDL as that was the language used in an old University Text book I got for $5 at a bookshop sale before I purchased my first FPGA board.

[nctnico]

There are entire classes of stupid Verilog mistakes that are simply not possible in VHDL. Given that hardware design is challenging enough, I'm happy to trade a bit of verbosity for a lot of type-safety.

That's the  reason I chose VHDL - I'm sure if I used it a lot I'd prefer Verilog, and find some aspects of VHDL just plain stupid (e.g. no block comments or #define/#ifdef), but as I only do maybe one FPGA project a year, I'm never going to get really familiar with it, so any help the language can give to avoid mistakes is welcome.

#define #ifdef is certainly there. Create a package with some constants (number of channels, options, etc), include that package in your VHDL sources and use 'if ... generate' to include or exclude certain parts.
In general: the trick to use VHDL efficiently is to treat it as a programming language. Too many people are still describing logic instead of a solution for the problem they are solving. It is like programming C using lots of inline assembly and that leads to a lot of typing.

[hamster_nz]

#define #ifdef is certainly there. Create a package with some constants (number of channels, options, etc), include that package in your VHDL sources and use 'if ... generate' to include or exclude certain parts.
In general: the trick to use VHDL efficiently is to treat it as a programming language. Too many people are still describing logic instead of a solution for the problem they are solving. It is like programming C using lots of inline assembly and that leads to a lot of typing.

Isn't the stuff within generate blocks still parsed, so it has to be 'correct' code? (e.g. signals need to be defined, no hanging nested 'if's... )

[Cerebus]

VHDL was designed by a committee, a military committee. That single sentence ought to be enough to steer any sane person away from it.

I can pretty much guarantee that almost every bit of VHDL that anyone here has ever seen or written begins (excluding possible comments) with the lines:

Code: [Select]

library IEEE;
use IEEE.std_logic_1164.all;
A hint that there's something fundamentally flawed is when what are essentially the fundamental types most commonly used in a programming language require definition for each and every program, and require you to type something to invoke that definition.

When defending VHDL people always say "type safety" as if it's some magic mantra. Type safety is a wonderful thing, and I heartily encourage anybody designing a programming language to adopt it. The thing is type safety doesn't require an abstruse syntax that requires repeated, pointless verbiage¹. A hint, if you claim type safety is important to you and also choose to program in C you don't really care about type safety and you're using "type safety" as a mantra to defend your choice of VHDL. It's like buyer regret when a car buyer defends their car on its great fuel mileage and you can see their disappointment that they didn't get the little red sports car².

Another hint is in that second line of code. It's the ".all". If you're aiming for as much compile time checking as possible it's a bad idea to design a language in a way that encourages users to include every type in a type library including all the types they don't intend to use. You can't check for unintended type usage if you've set yourself up to encourage unintended type definition.

If you're determined to use VHDL my primary recommendation is a touch typing course, you'll need it.

1 The syntax of VHDL is modelled on ADA. As well as being user hostile, the ADA syntax is compiler hostile too. It's one excuse to mangle the formal syntax of a programming language to make it easier for the users, it's another excuse to make it easier for the compiler writer, but mangling it for both is close to a useful working definition of insanity. As they say in the British Army: "There are three ways to do a job. There's the right way, the wrong way and there's the Army way.".

2 The author does have a little red sports car, and has few if any regrets.

[Kilrah]

A hint, if you claim type safety is important to you and also choose to program in C you don't really care about type safety and you're using "type safety" as a mantra to defend your choice of VHDL.

It's different, you usually don't program in C because you chose to, it's just that it's where everything is. If you later get to choose your HDL you might want to precisely try something else that hypotherically could help you avoid the mistakes you know all too well about.

I find VHDL verbosity to be a pain mostly for instatiation/port mapping. There should be implicit maps that can be overridden if needed (e.g. using external components), but when you design your own components and system you shouldn't need to type each signal name umpteen times.

[hamster_nz]

I find VHDL verbosity to be a pain mostly for instatiation/port mapping. There should be implicit maps that can be overridden if needed (e.g. using external components), but when you design your own components and system you shouldn't need to type each signal name umpteen times.

This works just fine:

Code: [Select]

architecture Behavioral of tb_debug_test is
    component debug_test is
    Port ( clk        : in  STD_LOGIC;
           serial_out : out STD_LOGIC;
           probes     : in  STD_LOGIC_VECTOR (8 downto 0));
    end component;
   ...
begin
  ...
i_debug_test : debug_test port map (clk, serial_out, counter);
  ...

Let us know how well it works out for you...

[nctnico]

A hint, if you claim type safety is important to you and also choose to program in C you don't really care about type safety and you're using "type safety" as a mantra to defend your choice of VHDL.

It's different, you usually don't program in C because you chose to, it's just that it's where everything is. If you later get to choose your HDL you might want to precisely try something else that hypotherically could help you avoid the mistakes you know all too well about.

BTW Nowadays a good C/C++ compiler throws an error if you use the wrong type and don't explicitly cast it.

I find VHDL verbosity to be a pain mostly for instatiation/port mapping. There should be implicit maps that can be overridden if needed (e.g. using external components), but when you design your own components and system you shouldn't need to type each signal name umpteen times.

You can use packages (only one component instantiation) and records to reduce the amount of text significantly. If you have a bunch of related variables in C you typically put them in a struct and pass the struct to a function instead of each variable seperately.

[Kilrah]

Let us know how well it works out for you...

Well you still need internal signals, don't you?

What I mean is that the following:

Code: [Select]


entity design_1 is
  port (
    btn : in STD_LOGIC;
    clk : in STD_LOGIC;
    led : out STD_LOGIC;
    sw : in STD_LOGIC_VECTOR ( 3 downto 0 )
  );
end design_1;

architecture STRUCTURE of design_1 is
  component design_1_clk_wiz_0_0 is
  port (
    clk_in1 : in STD_LOGIC;
    clk_out1 : out STD_LOGIC
  );
  end component design_1_clk_wiz_0_0;
  component design_1_pwm_0_0 is
  port (
    clk_i : in STD_LOGIC;
    reset_i : in STD_LOGIC;
    led_o : out STD_LOGIC;
    val_i : in STD_LOGIC_VECTOR ( 3 downto 0 )
  );
  end component design_1_pwm_0_0;
  signal btn_1 : STD_LOGIC;
  signal clk_1 : STD_LOGIC;
  signal clk_wiz_0_clk_out1 : STD_LOGIC;
  signal pwm_0_led_o : STD_LOGIC;
  signal sw_1 : STD_LOGIC_VECTOR ( 3 downto 0 );
begin
  btn_1 <= btn;
  clk_1 <= clk;
  led <= pwm_0_led_o;
  sw_1(3 downto 0) <= sw(3 downto 0);
clk_wiz_0: component design_1_clk_wiz_0_0
     port map (
      clk_in1 => clk_1,
      clk_out1 => clk_wiz_0_clk_out1
    );
pwm_0: component design_1_pwm_0_0
     port map (
      clk_i => clk_wiz_0_clk_out1,
      led_o => pwm_0_led_o,
      reset_i => btn_1,
      val_i(3 downto 0) => sw_1(3 downto 0)
    );
end STRUCTURE;

Should be possible to express with:

Code: [Select]

entity design_1 is
  port (
    btn : in STD_LOGIC;
    clk : in STD_LOGIC;
    led : out STD_LOGIC;
    sw : in STD_LOGIC_VECTOR ( 3 downto 0 )
  );
end design_1;

architecture STRUCTURE of design_1 is
  signal clk_wiz_0_clk_out1 : STD_LOGIC;
begin
clk_wiz_0: component design_1_clk_wiz_0_0
     port map (
      clk_in1 => clk,
      clk_out1 => clk_wiz_0_clk_out1
    );
pwm_0: component design_1_pwm_0_0
     port map (
      clk_i => clk_wiz_0_clk_out1,
      led_o => led,
      reset_i => btn,
      val_i(3 downto 0) => sw(3 downto 0)
    );
end STRUCTURE;

I.e.
- Skip the component port declaration, that should be inferred straight from the component's source. Copypasta between the component and the entity that instantiates it is ridiculous...
- Skip the local signals that have no other purpose than connecting a port of the entity straight to a port of a component, connect those directly
- Local signals that are used to connect ports between components are fine, they're required due the possibility of having multiple instances of the same component, no issue there.

You already save half the code lines, and it seems you don't lose anything. You need a little more back and forth between files to check component declarations when doing the mapping, but I'd take that any day over having to copy them across and maintain that copy, every language requires that kind of thing anyway.

Disclaimer: I'm pretty much a beginner in VHDL and I'm probably missing something including the possibility that my proposed version could be OK  , and I've never tried verilog so maybe that does just this - if so I'd happily have a look at it, I'm here to learn!

Note: obviously modern tools e.g. Vivado are able to hide that away from you by autogenerating the top module from the much easier to specify graphical block diagram, but still.

[mikeselectricstuff]

There are entire classes of stupid Verilog mistakes that are simply not possible in VHDL. Given that hardware design is challenging enough, I'm happy to trade a bit of verbosity for a lot of type-safety.

That's the  reason I chose VHDL - I'm sure if I used it a lot I'd prefer Verilog, and find some aspects of VHDL just plain stupid (e.g. no block comments or #define/#ifdef), but as I only do maybe one FPGA project a year, I'm never going to get really familiar with it, so any help the language can give to avoid mistakes is welcome.

#define #ifdef is certainly there. Create a package with some constants (number of channels, options, etc), include that package in your VHDL sources and use 'if ... generate' to include or exclude certain parts.
In general: the trick to use VHDL efficiently is to treat it as a programming language. Too many people are still describing logic instead of a solution for the problem they are solving. It is like programming C using lots of inline assembly and that leads to a lot of typing.

You can do some things using constants but it's often more fiddly and there are some things you just can't easily do. I'm specifically thinking build variants where you may want to selectively include/exclude whole blocks, or have completely different functionality, which #ifdef could do much more easily.
#ifdef would also be an easy way to work round the lack of block comments for temporarily disabling sections for debugging.

[Kilrah]

OK, just ran a quick test, and interestingly

- Skip the local signals that have no other purpose than connecting a port of the entity straight to a port of a component, connect those directly

This seems perfectly fine 

- Skip the component port declaration, that should be inferred straight from the component's source. Copypasta between the component and the entity that instantiates it is ridiculous...

Big nope for that one though

That's already something though! I'm all for fewer indirections, having to create and assign useless signals was nothing other than an opportunity for mistakes IMO.

And that was another learning opportunity to port a design from a board to another , and integrate some autogenerated code from a Vivado block design into a pure code project. I'm starting to get a hang of the tools and their "behind the scenes" workings if anything 

[asgard20032]

I tried both, and there is mostly one thing I would like to be ported to Verilog : type. Being able to create a type, like an enum, for state machine, is a clean approach. Just implement something like enum/type for Verilog just for the sake of state machine.

[parasole]

I learned FPGA programming myself as hobbyist, initially started with Verilog, however it turn out VHDL to be much easier to learn and understand... By now I am doing every thing in VHDL and use Verilog only as readily available functions, although may adjust them to my need if required...

[Someone]

- Skip the component port declaration, that should be inferred straight from the component's source. Copypasta between the component and the entity that instantiates it is ridiculous...

Big nope for that one though

Time to learn the entity declaration:
http://insights.sigasi.com/tech/four-and-half-ways-write-vhdl-instantiations.html

[dmills]

I come from the background of having an expert knowledge of C, so I quite deliberately set out to learn VHDL, Verilog is just sufficiently C like that I find myself in a 'software' mindset and HDL written as if it was sequentially executing software is horrible when it works at all.

The verbosity is a price worth paying for making things explicit IMHO, and do NOT underestimate that type safety thing, annoying? Sure, but less so then trying to figure out why the thing has guessed wrong about a signed/unsigned math operation.

Regards, Dan.

[rstofer]

VHDL was designed by a committee, a military committee. That single sentence ought to be enough to steer any sane person away from it.

I can pretty much guarantee that almost every bit of VHDL that anyone here has ever seen or written begins (excluding possible comments) with the lines:

Code: [Select]

library IEEE;
use IEEE.std_logic_1164.all;
A hint that there's something fundamentally flawed is when what are essentially the fundamental types most commonly used in a programming language require definition for each and every program, and require you to type something to invoke that definition.

#include <stdio.h>
#include <stdint.h>

[legacy]

vhdl under CoNix with ghdl + gtkwave (sometimes ModelSim) and ISE-v14.1
edit:
oh, I am also tempted by VHDL-AMS(1), it's a derivative of  VHDL
(IEEE standard 1076-1993), and it includes analog and mixed-signal extensions
but ... it's not supported by ghdl 


(1) you can, in the theory, describe a PLL, or things that require pspice
so, it sounds interesting, in the theory, where in the practice it's useless
mainly because you can't find an useful tool

[Kilrah]

Time to learn the entity declaration:
http://insights.sigasi.com/tech/four-and-half-ways-write-vhdl-instantiations.html

Interesting, thanks for the link!

Seems "Four-and-a-half" matches what I'd like, unfortunately it doesn't seem to work in Vivado (seems to be equal to "One", only works if the declaration is present).
"Four" does the job, but a caveat is that it won't work if the component is written in Verilog, have to go back to "One" again for those.
Haven't tried "Two" yet, "Three" just seems too messy to use.

[ataradov]

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.

[Sal Ammoniac]

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. It'll be interesting to see if the results change as North Americans wake up and cast their votes. Out where I am (Silicon Valley), HDL usage tends to heavily favor Verilog.

I cast my vote for "both" because I just got started with FPGAs a few weeks ago and haven't decided whether I like Verilog or VHDL best. Each has its strong points and annoyances, so I'm alternating between them until I settle on one or the other.

I find VHDL too verbose for my taste, and its extreme type safety just too much. I'm primarily an embedded C type, so perhaps if I worked in Ada I wouldn't be so turned off by this.

Verilog is more like what I'm used to in a language, but it also has its issues. I'm constantly forgetting the differences between blocking and non-blocking assignments and constantly forgetting to use "assign" before a con-current statement. Since Verilog is so C-like already, I wish that they'd made it a little more succinct by using {}s rather than begin/end.

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

[ehughes]

http://www.bawankule.com/verilogcenter/contest.html

In most real world scenarios, Verilog wins.

Verilog was created by 2 guys working in the industry to solve a real world problem.

VHDL was the result of government and academia trying to come up  with the end all modeling language.

Design by committee languages often end up ridiculously fluffed.

When it takes 3x the code to get the same functionality, VHDL ends up as an unreadable mess for large designs.

Once you get past FPGAs and move to ASICs, it is overwhelmingly Verilog (Cadence owns Verilog and is a huge player in the ASIC world)

[scatha]

http://www.bawankule.com/verilogcenter/contest.html

In most real world scenarios, Verilog wins.

Verilog was created by 2 guys working in the industry to solve a real world problem.

VHDL was the result of government and academia trying to come up  with the end all modeling language.

Design by committee languages often end up ridiculously fluffed.

When it takes 3x the code to get the same functionality, VHDL ends up as an unreadable mess for large designs.

Once you get past FPGAs and move to ASICs, it is overwhelmingly Verilog (Cadence owns Verilog and is a huge player in the ASIC world)

I don't see how that link constitutes a 'real world scenario' - it's from 1997 and based on a toy problem.

To claim a 3x overhead for VHDL is hyperbole - *maybe* if you were to maximise the number of small design units and then used the most verbose form of component instantiation, but in larger design units the LoC difference is small. I've certainly been subjected to more 'unreadable mess' Verilog projects than VHDL based-ones, to the point where I actively dread the language. Maybe things are different in ASIC land, but that's not a space I play in.

[nctnico]

http://www.bawankule.com/verilogcenter/contest.html

In most real world scenarios, Verilog wins.

If you think in logic and want to create a netlist then Verilog is the right tool. Verilog code looks exactly like a netlist to me. However I think I'd be done in 30 minutes to create the design requested by the contest with a few lines of VHDL and then tweak the synthesizer options to optimise the end result. VHDL versus Verilog starts to sound like an assembly versus C discussion.

[Cerebus]

VHDL versus Verilog starts to sound like an assembly versus C discussion.

Well, C and assembler are essentially the same thing. C is just an assembler that's non machine specific and somewhat less programmer hostile than most assemblers. No bounds checking (almost universal in other common HLLs at the time of C's inception), ability to freely switch between any interpretation of a string of bits as an integer or a pointer or a character, register variables, #define, #ifdef - classic macro assembler, the 'for' loop that looks like nothing more than an assembler macro etc. etc. To anybody who knows PDP-11 assembler (which was the original target for the K&R compiler) it's blindingly obvious where (++i) and (i++) came from - the C expression (a = *b++) compiles into a single instruction on a PDP-11; in fact I think even (*--a = *b++) would be a single instruction on a PDP-11 but honestly I'd have to check that particular expression.

C is, and always has been, a fancy assembler on steroids - that is its strength and its weakness.

[zapta]

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.

Few years ago I needed to program a FPGA for the first time. When I shawn my initial code to a colleague with HDL experience, he gave me a good advice:  "avoid 'if' statements, use conditional expressions instead".

Something along these lines:

my_signal <= condition1 ? value1:
                     condition2 ? value2:
                     ...
                     default_value;

That made VHDL programming much easier for me, eliminating the complexity of multiple assignments per signal. This rule applied to all signals, not only state machines (where my_signal depends on itself).

[helius]

ability to freely switch between any interpretation of a string of bits as an integer or a pointer or a character

This violates the weak aliasing rule present in every version of ANSI and ISO C.

Qualifiers like const or restrict, variable-length arrays, and complex numbers, are also without any corresponding construct in assembly language.

These changes are part of a much wider shift in compiler technology, that means assembly programs are poorly optimized in comparison with compiled programs. A backward "assembler on steroids" is no longer relevant, and today's C doesn't fit that description. C programs that depend on being compiled into instructions just like they are written no longer work with today's compilers.

[Cerebus]

ability to freely switch between any interpretation of a string of bits as an integer or a pointer or a character

This violates the weak aliasing rule present in every version of ANSI and ISO C.

Still true though, vis:

Code: [Select]

void junk()
{
char *aBuffer;
unsigned long int aNumber;

aNumber = (unsigned long int) aBuffer;
aBuffer[0] = (char) aNumber;
}

That compiles in C99 without even a warning. A properly typed programming language wouldn't let me do that. An overgrown assembler would.

Qualifiers like const or restrict, variable-length arrays, and complex numbers, are also without any corresponding construct in assembly language.

These changes are part of a much wider shift in compiler technology, that means assembly programs are poorly optimized in comparison with compiled programs.

To be precise, those changes have nothing to do with compiler technology. They are changes in the language definition and could have easily been compiled with the same level of compiler technology as K&R C was. I'd strongly dispute your second assertion; with the exception of instruction sets that make extensive use of delay slots and similar hardware optimization techniques - a compiler will nearly always do a better job with those than a human.

A backward "assembler on steroids" is no longer relevant, and today's C doesn't fit that description.

Of course it's relevant, it's called embedded and systems programming. C is used for that because of its ability to get close enough to the hardware that twiddling bits in registers in predictable fashion.

 And of course modern C isn't an "assembler on steroids", it's an overgrown assembler on steroids. I'm messing with you here. C needed revising if it was going to continue to be used outside its original target environment but really it ought not have been and better programming languages ought to have become widespread instead.

C programs that depend on being compiled into instructions just like they are written no longer work with today's compilers.

I don't believe I said or implied anything like that. The nearness of the PDP-11 pre and post increment and decrement instructions and the C equivalents are just evidence of its quintessential nature, not an advocacy of that as a programming style. At any time with any compiler, any (non systems) code that depends on being compiled into particular explicit instructions should be immediately put into the bin.

My opinion stands. And it's just that, an opinion, but based on 40 years programming in literally dozens of different programming languages on dozens of different architectures. I've worked as a systems programmer ferreting about on the insides of operating systems and as a compiler writer writing code generators. My programming days pre-date the existence of C outside of the Bell Labs community. Prior to C, I spent many tedious hours writing assembler because there was no other way to get close enough to the hardware. Post C, I've been able to do those same tasks, sometimes quite portably, in C. That I have substituted C for assembler is pretty strong evidence of its basic nature.

[hamster_nz]

I am quite fond of C being so light-weight a language - and that you can build whatever you want on top of it's minimal library functions.

On big projects where issues slowly creep in I've added in my own safe-guards (like heap corruption detection, and data type verification) that disappears when _DEBUG isn't defined. It really isn't that hard - make a "safe_malloc(site_t size, unsigned data_type_magic)" that actually allocates a little more memory than needed and store a little metadata in the extra space.

You can then:
* verify that memory space hasn't been blown out - check the known value at the end
* verify that the pointer has been allocated to be the type expected - check the type value
* verify that you have allocated enough space - check the size value in the start
* verify that all allocated space gets free()ed

If you are really fussy you can have the C compiler include the file name and line number (have the preprocessor include __FILE__ and __LINE__ on the safe_malloc() call) so it can tell you where memory was allocated.

[mikeselectricstuff]

Still true though, vis:

Code: [Select]

void junk()
{
char *aBuffer;
unsigned long int aNumber;

aNumber = (unsigned long int) aBuffer;
aBuffer[0] = (char) aNumber;
}

That compiles in C99 without even a warning. A properly typed programming language wouldn't let me do that. An overgrown assembler would.

But the use of casting implies you know what you're doing - even the best-designed language can fail if people abuse it.
I'm sure it would have given warning is the casing wasn't there.

[nctnico]

Still true though, vis:

Code: [Select]

void junk()
{
char *aBuffer;
unsigned long int aNumber;

aNumber = (unsigned long int) aBuffer;
aBuffer[0] = (char) aNumber;
}
That compiles in C99 without even a warning. A properly typed programming language wouldn't let me do that. An overgrown assembler would.

But the use of casting implies you know what you're doing - even the best-designed language can fail if people abuse it.
I'm sure it would have given warning is the casing wasn't there.

Same here. Even in VHDL you can cast some types into another but without such a cast it won't 'compile'.

[Cerebus]

Can we get back on topic please? Y'know, Verilog, VHDL.

[Sal Ammoniac]

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.

Yes, you need "memory" to build sequential circuits, but not always a full-blown state machine (with, for example, the two-process approach which you mention). Not everything is complex enough to require an FSM.

Here's an example: I recently implemented a simple serial port in Verilog, first as a full-blown state machine, and then as a much simpler non-FSM model.

Code: [Select]

`timescale 1ns / 1ps

module serial
  #(parameter TBIT=868,             // bit time in 100 MHz clocks for 115,200 baud
  )
  (
    input logic clk,
    input logic rst,
    input logic start,
    input logic [7:0] din,
    output logic [7:0] dout,
    output logic dataready,
    output logic txbusy,
    input logic RX,
    output logic TX
    );
   
  enum logic [2:0] {TXIDLE, TXSTARTBIT, SEND1, SEND2, TXSTOP} txstate, next_txstate;
  enum logic [2:0] {RXIDLE, RXSTARTBIT, RECEIVE1, RECEIVE2, RXSTOP} rxstate, next_rxstate;
  logic [11:0] txtimer, rxtimer;
  logic [7:0] data, data_next;
  logic [7:0] rdata, rdata_next;
  logic [3:0] bits, bits_next;
  logic [3:0] rbits, rbits_next;
  logic [11:0] txcount, rxcount;
  logic rx1, rx2;
 
  // Transmit
  always_ff @(posedge clk, posedge rst) begin
    if (rst) begin
      txcount <= 0;
      txstate <= TXIDLE;
    end
    else begin
      bits <= bits_next;
      data <= data_next;
      txcount <= txcount + 1;
      if (txcount >= txtimer) begin
        txstate <= next_txstate;
        txcount <= 0;
      end
    end
  end
 
  always_comb begin
    bits_next = bits;
    case (txstate)
      TXIDLE: begin
        txtimer = 1;
        data_next = din;
        TX = 1'b1;
        bits_next = 8;
        if (start == 1'b1)
          next_txstate = TXSTARTBIT;
        else
          next_txstate = TXIDLE;
      end
      TXSTARTBIT: begin
        txtimer = TBIT;
        data_next = din;
        TX = 1'b0;
        next_txstate = SEND1;
      end
      SEND1: begin
        data_next = data;
        TX = data[0];
        txtimer = TBIT;
        next_txstate = SEND2;
      end
      SEND2: begin
        txtimer = 0;
        TX = data[0];
        data_next = {1'b0, data[7:1]};
        bits_next = bits - 1;
        if (bits == 1) begin
          txtimer = 0;
          next_txstate = TXSTOP;
        end
        else begin
          next_txstate = SEND1;
        end
      end
      TXSTOP: begin
        TX = 1'b1;
        txtimer = TBIT;
        data_next = din;
        next_txstate = TXIDLE;
      end
      default: begin
        txtimer = 1;
        TX = 1'b1;
        data_next = din;
        next_txstate = TXIDLE;
      end
    endcase     
  end
 
  // Receive
  always_ff @(posedge clk, posedge rst) begin
    if (rst) begin
      rxcount <= 0;
      rdata <= 0;
      rxstate <= RXIDLE;
    end
    else begin
      rx1 <= RX;
      rx2 <= rx1;
      rbits <= rbits_next;
      rdata <= rdata_next;
      rxcount <= rxcount + 1;
      if (rxcount >= rxtimer) begin
        rxstate <= next_rxstate;
        rxcount <= 0;
      end
    end
  end
 
  always_comb begin
    rbits_next = rbits;
    rdata_next = rdata;
    case (rxstate)
      RXIDLE: begin
        rxtimer = 0;
        if (rx2 == 1'b0)                    // start bit
          next_rxstate = RXSTARTBIT;
        else
          next_rxstate = RXIDLE;         
      end
      RXSTARTBIT: begin
        rxtimer = TBIT/2 - 1;                   // 1/2 bit time
        rbits_next = 7;
        next_rxstate = RECEIVE1;
      end
      RECEIVE1: begin
        rxtimer = TBIT - 2;
        next_rxstate = RECEIVE2;
      end
      RECEIVE2: begin
        rxtimer = 0;
        rdata_next = {rx2, rdata[7:1]};
        rbits_next = rbits - 1;
        if (rbits == 0) begin
          rxtimer = 0;
          next_rxstate = RXSTOP;
        end
        else
          next_rxstate = RECEIVE1;
      end
      RXSTOP: begin
        rxtimer = TBIT - 2;
        next_rxstate = RXIDLE;
      end
      default: begin
        rxtimer = 1;
        next_rxstate = RXIDLE;
      end
    endcase
  end
 
  assign dout = rdata;
  assign dataready = (rxstate == RXSTOP);
  assign txbusy = (txstate != TXIDLE);
   
endmodule


Code: [Select]

`timescale 1ns / 1ps

module serial
  #(parameter TBIT=10               // bit time in 100 MHz clocks for 115,200 baud
  )
  (
    input logic clk,
    input logic rst,
    input logic start,
    input logic [7:0] din,
    output logic [7:0] dout,
    output logic dataready,
    output logic txbusy,
    input logic RX,
    output logic TX
    );
 
 
  // Transmit
  logic tx_started;
  logic [9:0] tdata; 
  logic [3:0] tbits = 0;
  logic [11:0] tcounter;
 
  always_ff @(posedge clk) begin
    if (start) begin
      tcounter <= TBIT - 1;
      tdata <= {1'b1, din, 1'b0};
      tbits <= 0;
      tx_started <= 1;
    end
    else if (tx_started) begin
      TX <= tdata[0];
      tcounter <= tcounter - 1;
      if (tcounter == 0) begin
        tcounter <= TBIT - 1;
        tbits <= tbits + 1;
        tdata = {1'b0, tdata[9:1]};
        if (tbits == 9)
          tx_started <= 0;
      end
    end
  end
 
  assign txbusy = tx_started;



  // Receive 
  logic rx_start;
  logic rx_started = 0;
  logic [7:0] rdata;
  logic [3:0] rbits = 0;
  logic [11:0] rcounter;
  logic [2:0] rxd = 3'b0;
 
  // synchronize to the incoming RX data line using a 3-bit shift register
  always_ff @(posedge clk) begin
    rxd <= {rxd[1:0], RX};
  end
 
  assign rx_posedge = (rxd[2:1] == 2'b01);              // positive edge on the RX line
  assign rx_negedge = (rxd[2:1] == 2'b10);              // negative edge on the RX line
  assign rx_start = (rx_negedge && ~rx_started);        // start bit detected
 
  always_ff @(posedge clk) begin
    if (rx_start) begin
      rcounter <= TBIT/2 - 1;
      rdata <= 8'b0;
      rbits <= 0;
      rx_started <= 1;
    end
    else if (rx_started) begin
      rcounter <= rcounter - 1;
      if (rcounter == 0) begin
        rdata <= {rxd[2], rdata[7:1]};
        rcounter <= TBIT - 1;
        rbits <= rbits + 1;
        if (rbits == 8)
          rx_started <= 0;
      end
    end
  end
 
  assign dout = rdata;
  assign dataready = ~rx_started;
   
endmodule


[nctnico]

Again: what often helps is to make a flowchart on paper first. This usually shows which states are irrelevant and/or can be combined.

[Kilrah]

I don't consider these being "making a state machine" or "not making a state machine", it's just different levels of optimization (more as source code amount than in resources) / expression of the same state machine.

Yes when you have to send 10 bits you can have an idle state and 10 "bitX" states, or you could only have one "running" flag and use a bit counter to know where you are... both are state machines just as much, they simply use a more or less explicit way to express it.

[Muxr]

My fulltime job is a programmer (distributed systems not embedded). When I got into FPGA for hobby purposes I looked at the syntax and liked Verilog better.. so I've been using Verilog 

[Sal Ammoniac]

I don't consider these being "making a state machine" or "not making a state machine", it's just different levels of optimization (more as source code amount than in resources) / expression of the same state machine.

Yes when you have to send 10 bits you can have an idle state and 10 "bitX" states, or you could only have one "running" flag and use a bit counter to know where you are... both are state machines just as much, they simply use a more or less explicit way to express it.

My point wasn't directed towards what you call these things, but that sometimes a more formal description of a problem is overkill and a simpler approach is not only more readable, but more likely to correct by inspection.

[legacy]

Code: [Select]

  type   state_t is
         (
         s_idle_w,
         s_idle_r,
         s_start_w,
         s_start_r,
         s_data0_w,
         s_data0_r,
         s_data1_w,
         s_data1_r,
         s_data2_w,
         s_data2_r,
         s_data3_w,
         s_data3_r,
         s_data4_w,
         s_data4_r,
         s_data5_w,
         s_data5_r,
         s_data6_w,
         s_data6_r,
         s_data7_w,
         s_data7_r,
         s_stop_w,
         s_stop_r
         );

well, on the psx_pad ... data_out is written on the falling edge
whereas the data_in is read on the rising edge

that means that, in the theory, you need both the edge types {falling edge, rising edge}
but you can't have both the logic on your fpga's project, you have to choose, it's mutually exclusive

personally i prefer "rising_edge", therefore I am using the following trick

Code: [Select]

  -- pad clock
  process(in_clock,in_reset,state_curr)
  begin
    if (in_reset = '1') then
       pad_out_clk  <= '1';
    elsif rising_edge(in_clock) then
       case state_curr is
          ------------------------------
          when s_data0_w =>
            pad_out_clk  <= '0';
          when s_data0_r =>
            pad_out_clk  <= '1';

_w stands for write data_out on falling edge
_r stands for read data_in on rising edge

therefore it actually reads date on rising edge, whereas it writes data on falling edge

Code: [Select]

constant tick         : integer := (clk_freq/baudrate);

the psx_pad's baudrate needs to be 250Khz, while clk_freq can be 50Mhz, so, since clk_freq < 2 * baudrate, the finite state machine can evolve its state_next at the *double speed* (that is the limitation of this method), and this permits to have the full control of both rising_edge and falling_edge (including delays)

Code: [Select]

  --fsm state_next
  process(in_clock,in_reset,state_curr)
  begin
    if (in_reset = '1') then
       state_next   <= s_idle_w;
    elsif rising_edge(in_clock) then
      if (tick_counter = tick-1) then
         case state_curr is
            ------------------------------
            when s_idle_w  =>
              state_next   <= s_idle_r;
            when s_idle_r  =>
              if (write_en = '1') then
                 state_next   <= s_start_w;
              else
                 state_next   <= s_idle_w;
              end if;
            ------------------------------
            when s_start_w =>
              state_next   <= s_start_r;
            when s_start_r =>
              state_next   <= s_data0_w;
            ------------------------------
            when s_data0_w =>
              state_next   <= s_data0_r;
            when s_data0_r =>
              state_next   <= s_data1_w;

it's not elegant and compact, it eats resources, but I am satisfied by the result 

[whollender]

you can't have both the logic on fpga, you can't have rising_edge and falling_edge
you have to choose, it's mutually exclusive: "rising_edge" is my best choice

You can actually use both, at least on Xilinx Spartan 6 using ISE 14.7.  I would assume that newer Xilinx devices also support both rising and falling edge clocks.  The only constraint is that all logic in a slice must use the same edge type, but you can use both on a single device.

[legacy]

The only constraint is that all logic in a slice must use the same edge type, but you can use both on a single device.

if all logic in a slice *MUST* use the same edge type it means you have to *choose the edge type*, and you can't use both types in your project, that is exactly what made me to think about the trick 

here I am on Spartan3E, ISE v10.1, and it claims errors if i try to do so (if i try to have both edge types in a single slice), whereas it's perfectly fine for ghdl, but ghdl doesn't have to fit to real hardware, therefore I can have both edge types only in RTL simulation.

[whollender]

if all logic in a slice *MUST* use the same edge type it means you have to *choose the edge type*, and you can't use both types in your project, that is exactly what made me to think about the trick 

here I am on Spartan3E, ISE v10.1, and it claims errors if i try to do so (if i try to have both edge types in a single slice), whereas it's perfectly fine for ghdl, but ghdl doesn't have to fit to real hardware, therefore I can have both edge types only in RTL simulation.

It does look like the Spartan3E CLBs are missing the inverter and mux on the clock input that the Spartan6 CLBs have.

On a Spartan6, code like this works just fine:

Code: [Select]

shift_in: process (BCLK)
begin
if rising_edge(BCLK) then
shiftreg_in <= shiftreg_in(shiftreg_in'high-1 downto 0) & I2S_DATA_IN;
end if;
end process;

shift_out: process (BCLK)
begin
if falling_edge(BCLK) then
if fs_str = '1' then
shiftreg_out <= data_reg_out;
else
shiftreg_out <= shiftreg_out(shiftreg_out'high-1 downto 0) & '0';
end if;
end if;
end process;

That way you don't absolutely need to have a double rate clock for doing that type of shift register work.

[Cerebus]

if all logic in a slice *MUST* use the same edge type it means you have to *choose the edge type*, and you can't use both types in your project, that is exactly what made me to think about the trick 

here I am on Spartan3E, ISE v10.1, and it claims errors if i try to do so (if i try to have both edge types in a single slice), whereas it's perfectly fine for ghdl, but ghdl doesn't have to fit to real hardware, therefore I can have both edge types only in RTL simulation.

It does look like the Spartan3E CLBs are missing the inverter and mux on the clock input that the Spartan6 CLBs have.

On a Spartan6, code like this works just fine:

Code: [Select]

shift_in: process (BCLK)
begin
if rising_edge(BCLK) then
shiftreg_in <= shiftreg_in(shiftreg_in'high-1 downto 0) & I2S_DATA_IN;
end if;
end process;

shift_out: process (BCLK)
begin
if falling_edge(BCLK) then
if fs_str = '1' then
shiftreg_out <= data_reg_out;
else
shiftreg_out <= shiftreg_out(shiftreg_out'high-1 downto 0) & '0';
end if;
end if;
end process;

That way you don't absolutely need to have a double rate clock for doing that type of shift register work.

I have vague memories from some years back of being forced to use a multiphasic clock on a Spartan 3 when I'd originally coded for using both clock edges. It was actually a blessing in disguise as I then came up with a much tidier design using 4 clock phases.

[Buriedcode]

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.

Beat me to it.  State machines are much easier with it.

I can't say I have much experience (like 3 *working* projects?) but had to translate some VHDL to verilog and I realized that I can actually sit down and type verilog that makes sense to me - without having to stop every 5 minutes to google something - it makes sense, but as many have said, C-like yes, but of course - its a HDL, not software.

I had to learn VHDL at university, and I have used it here and there.  I don't like writing it at all, its an arse and takes *me* a long time to write any module.  But the plus is, once the design software stops pointing out errors - it generally works exactly as intended.  Where-as verilog, I usually have to verify with a logic analyzer and seemingly endeless simulations, even then it often doesn't do what I intended first time. So really both have their place, for reliability and if you were going to do it for a job, I would learn VHDL (having to actually do that now..).

[legacy]

even if I can use a spartan6 board like the papilio/pro, I have legacy reasons to support spartam3e boards,

using both clock edges seems a blessing in disguise (a false blessing), especially if the playstation's pad uses a long cable (~half meters between the pad and the controller), spi doesn't work well with long cables, and you come into troubles if you don't provide extra sample & hold 






in the simulation the fpga clock is 50Mhz, the psx_pad clock is 12.5MHz
note the delay between psx_pad's clock and psx_pad's cmd (data out)

[legacy]

main reasons to use vhdl: tools!

I don't feel comfortable with verilog's tools, whereas ghdl has offered the opportunity to develop the following building tool, it's written in C under linux, it's a project I have developed to boost my productivity, and it's fine

Code: [Select]

# cat project.list.myprj
../../rtl/package
../../rtl/bus-mm
../../rtl/bus-mm-controller-sram-asynchronous
../../rtl/controller-sram-asynchronous
./
define sources

Code: [Select]

# cat project.analysis.myprj
measure bus_clock
time_lapse dtack
define what you want to observe from the RTL simulation

Code: [Select]

# cat project.time.myprj
100us
define simulation time

Code: [Select]

# myghdl-build-project-makefile-v6
once all of the above has been defined,  the tool automatically builds the Makefile

Code: [Select]

# myghdl-build-project-makefile-v6
[*] ../../rtl/package
[*] ../../rtl/bus-mm
    [[bus_mm_alignment.interface]]
    bus_mm_alignment
    [bus_mm.def]
    [[bus_mm_device.interface]]
    [[bus_mm_device_sel.interface]]
    bus_mm_device_sel
    bus_mm_device
    [[bus_mm.interface]]
    [[bus_mm_size_mask.interface]]
    bus_mm_size_mask
    bus_mm
    stage_load_store
[*] ../../rtl/bus-mm-controller-sram-asynchronous
    [[bus_mm_controller_sram_asynchronous.interface]]
    bus_mm_controller_sram_asynchronous
[*] ../../rtl/controller-sram-asynchronous
    [[controller_sram_asynchronous.interface]]
    controller_sram_asynchronous
[*] ./
    tb_my
#
packages are handled as "definitions", components are handled as "interfaces", everything else is handled as "behavioral implementation", this tool is able to resolve the dependency tree, in order to allow to compile without errors. ghdl needs some external work, whereas Xilinx ISE is also able to do the same without any external help, I like ISE, I don't like iSim

Code: [Select]

co-nix arise-v2-bus-mm # make
compiling bus_mm.def ... done
compiling controller_sram_asynchronous.def ... done
compiling +definitions ... done
compiling bus_mm_alignment.interface ... done
compiling bus_mm_device.interface ... done
compiling bus_mm_device_sel.interface ... done
compiling bus_mm.interface.interface ... done
compiling bus_mm_size_mask.interface ... done
compiling controller_sram_asynchronous.interface ... done
compiling stage_load_store.interface ... done
compiling +interfaces ... done
compiling bus_mm_alignment ... done
compiling bus_mm_controller_sram_asynchronous ... done
compiling bus_mm_device_sel ... done
compiling bus_mm_device ... done
compiling bus_mm_size_mask ... done
compiling bus_mm ... done
compiling stage_load_store ... done
compiling controller_sram_asynchronous ... done
compiling tb_my ... done
compiling +behaviorals ... done
running simulation ... done, see report.txt
running analysis ... done, see analysis.txt
a gtkwave file (tbencha.ghw) is now available with time details, while analysis.txt contains a lot of useful information, e.g. time/frequency report

Code: [Select]

..
bus_clock: 40000000 fs, 25000000 Hz
dtack: 120000000 fs
..


Code: [Select]

# make view
it launches gtkview

also I am using this vhdl-helper, it's a collection of useful functions which help me a lot with the test bench activity 


I don't yet have a similar ecosystem (tools and helpers) with verilog, not yet 

edit:
I have also developed other tools which help me to create the test-bench and interfaces, it partially understands vhdl, the parser doesn't understand the whole vhdl grammar, just a subset, anyway it's enough to extract entities, build components, etc etc. it's not like Sigase, but it's fine for me, and it doesn't cost a license.

[nctnico]

I use the Eclipse and the (free) veditor plugin to write VHDL because it is 1000 times better than the crummy editor in ISE. Veditor is not perfect yet when it comes to cross referencing type declarations and syntax checking but it already makes life a whole lot easier.

[legacy]

I use the Eclipse

at the beginning I was interested because enthusiast of such of tools and IDE, after a very bad job experience with Windriver and their Workbench (which is based on Eclipse) my feelings changed and now I hate those hyper complex tools, and this is the main reason why I wrote my own tool: with Eclipse I have always been doomed with metafiles and other stuff, not mentioning that those tools (Eclipse and something that is based on its source) are also too slow on my laptop(1)

with "too slow" I means that it makes me annoyed, delays are in order of seconds 
and, in my experiences, when it failed with metadata ... I lost the whole project, wasting a lot of time to figure out what was wrong without finding an answer, therefore the only solution I found was a brutal "erase and rewind"

 

• delete  the whole project (except source files)
• click on "new project", attach source files, and start to describe it from the scratch

veditor plugin to write VHDL because it is 1000 times better than the crummy editor in ISE

ISE looks very comfortable once integrated with Scriptum by HDL Works (there is a freeware edition)
it's a pure HDL editor with syntax highlighting, no other special features (unless you buy the full version)
anyway it's very comfortable, and it's able to track the line error if used with ISE

ghdl is still missing a good error report engine (on Sigasi's blog people also reported the same comment about it), sometimes it's not clear *WHAT* is wrong and *WHERE*, but you can ask ISE to give you an hand, ISE's checker (syntax and semantic) can be set to be very fussy, which is useful
and in case of error it invokes Scriptum which is able to track me back to the code's line


(1) WindowsXP/32bit +CoNix, cooperative unix under Windows, running gentoo/x86
hw specifications, intel i2@1.6Ghz, with 2Gbyte of ram

[legacy]

verilog books

I was given a gift, it's an old book (1st Edition, more than 10 years old), Real World FPGA Design with Verilog by Ken Coffman (Author)

my impression? From a preliminary read it seems that it needs tune up since it's based on old technology, anyway it looks teaching real world trips and tricks, and hey? it's a free gift, and those things are always welcome, oh, and it comes with a CD, it includes a few trial tools, whereas it doesn't tell a word about alternative tools like icarus (probably because icarus was not mature/usable when the author wrote the book) 

[gauravmp]

There is a saying for VHDL: Very Hard Description Language.

Verilog is very intuitive and doesn't require one to remember a lot of syntaxes so I use Verilog.

[free_electron]

systemverilog 2005. hands down

- less keyboard pounding ( especially all the boilerplate junk you need to replicate in each and every file with vhdl )
- no stupid 2 times declaration of every single signal ( once in module header, once in signal type)
- can use output signals immediately ( contrary to vhdl )
- constructs like always_ff , always_comb , always_latch


this results in much higher productivity.

[rstofer]

There is a saying for VHDL: Very Hard Description Language.

Verilog is very intuitive and doesn't require one to remember a lot of syntaxes so I use Verilog.

Everybody keeps saying all that neat stuff about Verilog.  How come I just don't 'get it'?  Seriously, I have made several attempts to get started with Verilog and every time I just started over in VHDL.  Maybe it's just old age... 

[photon]

There is a saying for VHDL: Very Hard Description Language.

Verilog is very intuitive and doesn't require one to remember a lot of syntaxes so I use Verilog.

Everybody keeps saying all that neat stuff about Verilog.  How come I just don't 'get it'?  Seriously, I have made several attempts to get started with Verilog and every time I just started over in VHDL.  Maybe it's just old age...

If you asked specific questions about what you find hard to understand in verilog, I bet you'll get good answers on this board.

[rstofer]

There is a saying for VHDL: Very Hard Description Language.

Verilog is very intuitive and doesn't require one to remember a lot of syntaxes so I use Verilog.

Everybody keeps saying all that neat stuff about Verilog.  How come I just don't 'get it'?  Seriously, I have made several attempts to get started with Verilog and every time I just started over in VHDL.  Maybe it's just old age...

If you asked specific questions about what you find hard to understand in verilog, I bet you'll get good answers on this board.

No doubt! 

I have a few reasons why I don't like the syntax and that is probably the real reason I don't put in the effort to learn the language.  In the end, both languages describe the same hardware and there are only so many constructs.  And there's no need to learn the language because a) VHDL works fine and b) I'm not looking for a job.  Retirement is excellent!

[legacy]

my problems with vhdl:

• buffer <- it might cause a lot of problems with hierarchical designs, according to Xilinx App Notes you'd better avoid to use it, they say it might cause problems with the synthesizer
• out <- due to strange limitation in vhdl, you can't read back signals once defined as "out"
• inout <- it's not a real problem but it needs some works

solutions

• buffer <- I don't use it, never, it's a banned keyword in my vhdl dictionary
• out <- I define a local signal inside my modules, and assign it to the "out", this solutions costs a few more logic gates, but it's fine
• inout <- I define the behavior for the high impedance, it's just a few line of code, don't use it to pass information through sub-modules, therefore I use "inout" only at the top-module because I have to route it to physical constraints (mapped pins)

[rstofer]

my problems with vhdl:

• buffer <- it might cause a lot of problems with hierarchical designs, according to Xilinx App Notes you'd better avoid to use it, they say it might cause problems with the synthesizer
• out <- due to strange limitation in vhdl, you can't read back signals once defined as "out"
• inout <- it's not a real problem but it needs some works

solutions

• buffer <- I don't use it, never, it's a banned keyword in my vhdl dictionary
• out <- I define a local signal inside my modules, and assign it to the "out", this solutions costs a few more logic gates, but it's fine
• inout <- I define the behavior for the high impedance, it's just a few line of code, don't use it to pass information through sub-modules, therefore I use "inout" only at the top-module because I have to route it to physical constraints (mapped pins)

All true!

i also use the approach of defining an internal version of an output signal I want to read back.  I don't know that it actually generates more logic.  But, yes, it's a PITA.

I have used inout but not all that often.  Further, I'm not sure that FPGAs like the idea of tri-state buses.  They seem to prefer muxes.

OK, here's my issue with Verilog:

I first list a signal name in the module definition.  Some time later, I declare it as input or output and some time after that I have to refine the definition if it is registered.  I have to write 3 different definitions, in three different lines of code to replace a single line of code in VHDL.  Looking at the module definition only, I can't even tell which signals are inputs or output and I can't determine whether they are a single signal or a logic vector.  I have to scan farther down the page to figure it out.

And what's this 'wire' vs 'reg' thing all about?  If a signal is set in a clocked process, it is a register.  If it is set in a combinatorial process it is a wire.  There's no need to get all pedantic about defining the signal, it's just a signal.

I still haven't sorted out 'blocking' vs 'non-blocking'.  Again, if a signal is set in a clocked process, it is registered and it's value changes on a clock edge.  If it is set outside of a clocked process, it is not registered and it's value changes when the other logic levels change and the change is not synchronized.  "assign"?  Why go through these push-ups?

I also prefer the module instantiation syntax of VHDL over Verilog.  I like the more tabular arrangement.  Yes, I could come up with a pretty way to instantiate a Verilog module but, more often than not, I see something like:

Code: [Select]

module dff (clk, d, q);
input clk, d;
output q;
reg q;
always @(posedge clk) q = d;
endmodule
 
module top;
reg data, clock;
wire q_out, net_1;
  dff inst_1 (.d(data), .q(net_1), .clk(clock));
  dff inst_2 (.clk(clock), .d(net_1), .q(q_out));
endmodule


In any event, it's really a matter of preference.  Neither language can 'invent' new features in the logic matrix.  Both describe exactly the same logic.  It's just a matter of syntax.

[Cerebus]

I first list a signal name in the module definition.  Some time later, I declare it as input or output and some time after that I have to refine the definition if it is registered.  I have to write 3 different definitions, in three different lines of code to replace a single line of code in VHDL.  Looking at the module definition only, I can't even tell which signals are inputs or output and I can't determine whether they are a single signal or a logic vector.  I have to scan farther down the page to figure it out.

You don't, not since (I think) Verilog 1995.  Your version:

Code: [Select]

module dff (clk, d, q);
input clk, d;
output q;
reg q;
always @(posedge clk) q = d;
endmodule

can be much more succinctly written as:

Code: [Select]

module dff (input clk, d, output reg q);
always @(posedge clk) q = d;
endmodule


[Sal Ammoniac]

And what's this 'wire' vs 'reg' thing all about?  If a signal is set in a clocked process, it is a register.  If it is set in a combinatorial process it is a wire.  There's no need to get all pedantic about defining the signal, it's just a signal.

SystemVerilog has a new type called "logic" that can replace both wire and reg. You can use it interchangeably for both and no longer need to worry about whether you're defining combinatorial logic or sequential logic. SystemVerilog merged with Verilog in 2009 and now SystemVerilog and Verilog are the same thing. Verilog now supports enums, structs/unions, interfaces, and a bunch of other stuff.

Not liking Verilog based on some ancient definition of the language is not logical.

[rstofer]

I first list a signal name in the module definition.  Some time later, I declare it as input or output and some time after that I have to refine the definition if it is registered.  I have to write 3 different definitions, in three different lines of code to replace a single line of code in VHDL.  Looking at the module definition only, I can't even tell which signals are inputs or output and I can't determine whether they are a single signal or a logic vector.  I have to scan farther down the page to figure it out.

You don't, not since (I think) Verilog 1995.  Your version:

Code: [Select]

module dff (clk, d, q);
input clk, d;
output q;
reg q;
always @(posedge clk) q = d;
endmodule

can be much more succinctly written as:

Code: [Select]

module dff (input clk, d, output reg q);
always @(posedge clk) q = d;
endmodule


And that's the problem with books and the Internet.  It is pretty easy to find archaic ways to use a language and not pick up on the far superior syntax of the more advanced revision.

I didn't invent that example, I just Googled for 'Verilog module declaration', found a web page and went down the TOC to module instantiation:

http://verilog.renerta.com/source/vrg00027.htm

I could deal with the revised syntax - everything is in one place.  Thanks!

[Sal Ammoniac]

And that's the problem with books and the Internet.  If is pretty easy to find archaic ways to use a language and not pick up on the far superior syntax of the more advanced revision.

Yep, that's a big problem, especially for beginners who aren't aware of the changes.

You can't blame the language itself, however. You just need to be able to differentiate the old from the new, which, without clues, can be difficult. Kind of like someone who doesn't know English well Googling "English Poetry" and coming up with the Canterbury Tales and thinking it's representative of modern English.

[rstofer]

And that's the problem with books and the Internet.  If is pretty easy to find archaic ways to use a language and not pick up on the far superior syntax of the more advanced revision.

Yep, that's a big problem, especially for beginners who aren't aware of the changes.

You can't blame the language itself, however. You just need to be able to differentiate the old from the new, which, without clues, can be difficult. Kind of like someone who doesn't know English well Googling "English Poetry" and coming up with the Canterbury Tales and thinking it's representative of modern English.

It's a big enough problem, when comparing Verilog to VHDL, for my purposes, to just kiss off Verilog as obscure or difficult.

Then too, there is often a huge disconnect between old and new.  There is very little similarity between FORTRAN IV and whatever we call it today (FORTRAN 95?).  Learning with version IV was pretty easy.  I'm not so sure about the new version.  Yes, the changes were necessary to keep up with people's expectations of a programming language for a modern computer but they definitely increase the height and slope of the learning curve.

[legacy]

a) VHDL works fine and b) I'm not looking for a job.  Retirement is excellent!

I like ADA, I am a freelancer working in the avionics's field, a few months ago I was contacted by some dudes in nuclear physics (gamma-gamma experiments(1)) field because they needed someone with some skill in vhdl and fault tolerant techniques in order to provide some "radiation hardening" tricks to their equipment

I am afraid that I am not the right dude, I don't have skills in physics, even my skills with vhdl are not brilliant, still under the supervision of those experts in the specific fields, we have been implementing a lot of R-H-tricks since the first meeting, oh and my personal part of fun is that ... I am using a lot of optical fiber patches, and I like to put my hands on lasers and optical detectors 

anyway, I am located in Europe: do you think I'd better learn Verilog?
Since I am ADA addicted (due to my job in avionics and personal mind set, pascal was my first language, before C/C++) I find vhdl more closed to my mind

therefore I have *a lot* of difficulties with verilog, and  ... I am afraid that knowing just one HDL language might be a problem in the near future for the industry 


(1) as far as I understood they are studying what happens when two gamma ray photons collide together, it seems you have something like the following

mass-less waves, photons --> collision, something happens --> massive particles arise up

I don't know about details, but I know that during the collision there is *a lot* of radiation propagation around the digital equipment which collects and transmits data from the sensor array, and some electrons which are flowing through their electronic-circuits might be affected by the radiation which can cause  to turn over with a sudden sharp movement resulting some bits to toggle randomly, and we can't avoid it to happen, we can just avoid to read wrong information, we have some techniques to do so, e.g. implementing devices with hamming encoding and decoding

[rstofer]

Learning Verilog...

Yes, I think you should take it up.  BTW, I'm starting to play with Ada and struggling with AdaCore and it's apparent total lack of documentation.  I just want to use the SPI gadget, not write a revision of "War and Peace".  I digress...

In the end, there are only a few constructs that get created by any HDL.  Logic equations (AND, OR, NOT, etc), register/counter, multiplier, ALU, MUX, decoder, priority encoder and state machine.  I may have missed a couple...  So, get a book that covers the latest version of the language and learn to implement these gadgets.  Everything else is details.  Check the RTL to see what gets synthesized for various implementations of the fundamental blocks.  Alternate codings will produce somewhat different logic.

I have also seen code directed straight at the LUT.  This code tends to be highly optimized but certainly non-portable.  I don't know what I think about that...  Nevertheless, different chips will probably have different ways to implement the various gadgets as a function of the LUT design.  Worth knowing about...

[legacy]

it seems that VHDL wins in the both hobbyist and pro fields 

[Someone]

it seems that VHDL wins in the both hobbyist and pro fields 

Its a matter of style without a clear winner. I can only think of a few minor things which can only be done in VHDL and cannot in Verilog (but they might be important to you!) while many simple things in Verilog require verbose casting or assignment in VHDL. It really depends how you see it, the strict casting and control flows of VHDL can enforce "better" design, or they can pollute a simple module with distractions from the underlying function.

VHDL 2008 advances a few of the bigger stumbling blocks:
https://www.doulos.com/knowhow/vhdl_designers_guide/vhdl_2008/vhdl_200x_ease/
But there will still be a need for writing and including clumsy type casting functions:
http://www.ics.uci.edu/~jmoorkan/vhdlref/typeconv.html

[legacy]

VHDL 2008 advances a few of the bigger stumbling blocks:
https://www.doulos.com/knowhow/vhdl_designers_guide/vhdl_2008/vhdl_200x_ease/
But there will still be a need for writing and including clumsy type casting functions:
http://www.ics.uci.edu/~jmoorkan/vhdlref/typeconv.html

that's a +1 in my VHDL choice 

[legacy]

I'd like to learn and use verilog, in order to do so I need a tool similar to ghdl, and the following seems perfect

Code: [Select]

*  sci-electronics/iverilog
      Latest version available: 0.9.6
      Latest version installed: 0.9.6
      Size of files: 1,192 KiB
      Homepage:      http://iverilog.icarus.com/
      Description:   A Verilog simulation and synthesis tool
      License:       GPL-2


[nctnico]

it seems that VHDL wins in the both hobbyist and pro fields 

Its a matter of style without a clear winner. I can only think of a few minor things which can only be done in VHDL and cannot in Verilog (but they might be important to you!) while many simple things in Verilog require verbose casting or assignment in VHDL. It really depends how you see it, the strict casting and control flows of VHDL can enforce "better" design, or they can pollute a simple module with distractions from the underlying function.

One of the biggest problems I see with people writing VHDL is that they use std_logic_vector for everything. This then needs lots of casting and makes the code look bulky and clumsy.

[legacy]

One of the biggest problems I see with people writing VHDL is that they use std_logic_vector for everything. This then needs lots of casting and makes the code look bulky and clumsy.

I am one of those, I don't use the "unsigned" type
(also because I have troubles exporting it from ghdl to C modules)

[legacy]

conclusion:
since defining functions is very useful, and it's not so complex
probably we'd better define a pair of direct conversion functions

input: std_logic_vector
output: integer

input: integer
output: std_logic_vector

[nctnico]

conclusion:
since defining functions is very useful, and it's not so complex
probably we'd better define a pair of direct conversion functions

input: std_logic_vector
output: integer

input: integer
output: std_logic_vector

Those functions are already there! Cast the std_logic_vector to signed or unsigned and then use the function to_integer.

http://stackoverflow.com/questions/26683335/vhdl-code-to-convert-5-bit-vector-to-integer

[legacy]

Cast the std_logic_vector to signed or unsigned and then use the function to_integer.

look at your sentence, "and then" means we need two steps, and this is what I want to avoid!
I want a directly (1 step) conversion from integer to std_logic_vector
therefore the following needs to be defined

u_integer_to_std_logic_vector(integer, size) <---- internally handled as "unsigned"
s_integer_to_std_logic_vector(integer, size) <---- internally handled as "signed"
positive_to_std_logic_vector(integer, size)

std_logic_vector_to_u_integer(std_logic_vector,size) <---- internally handled as "unsigned"
std_logic_vector_to_s_integer(std_logic_vector,size) <---- internally handled as "signed"
std_logic_vector_to_positive(std_logic_vector,size)

[legacy]

Code: [Select]

u_integer/positive <= to_integer(unsigned(std_logic_vector));

the above will look like

Code: [Select]

u_integer/positive <= std_logic_vector_to_u_integer(std_logic_vector,size);

which makes less confusion and it's absolutely clear
(even if the operator's name is too long)

[nctnico]

What happened to 'don't use std_logic_vector'?

[legacy]

in case, tell me alternatives

[legacy]

(and don't forget that ghdl has some problems with the unsigned type
when it needs to be interfaced with C-modules, don't ask me why  )

[legacy]

also the following doesn't work under ghdl

Code: [Select]

library IEEE;
    use IEEE.STD_LOGIC_1164.ALL;
    use IEEE.STD_LOGIC_ARITH.ALL;
    use IEEE.STD_LOGIC_UNSIGNED.ALL;

...
  constant XLEN : integer := 32;
  subtype  cpuWord is std_logic_vector(XLEN -1 downto 0);
...

      when alu_add =>
        res  <= opa + opb + (getStdLogicVectorZeroes(XLEN-1) & cin);


Code: [Select]

    use IEEE.STD_LOGIC_ARITH.ALL;
    use IEEE.STD_LOGIC_UNSIGNED.ALL;

those libraries are NOT defined in ghdl and can't be used easily
therefore the "+" operator is not defined for std_logic_vector
and the attempt to simulate "opa + opb" will result an error

instead you need to use

Code: [Select]

library ieee;
    use ieee.std_logic_1164.all;
    use ieee.numeric_std.all;

along with the following ugly code

Code: [Select]

        when alu_add =>
          result  <= std_logic_vector
                  (
                  unsigned(opa) + unsigned(opb) +
                  unsigned(getStdLogicVectorZeroes(XLEN-1) & cin)
                  );
          work <= std_logic_vector
                  (
                  unsigned("0" & opa) + unsigned("0" & opb) +
                  unsigned(getStdLogicVectorZeroes(XLEN-1) & cin)
                  );

in this case "unsigned(opa) + unsigned(opb)" is allowed
because the "+" operator is defined along with unsigned
but the result needs to be std_logic_vector 


both the above pieces of code come from OpenCores
therefore I assume it's a common trouble 


edit:

Code: [Select]

entity ALU_arithmetic is
    Port
    (                   
      enable : in  std_logic;
      -----------------------
      opa    : in  cpuWord;
      opb    : in  cpuWord;


[nctnico]

in case, tell me alternatives

The signed and unsigned types. If a signal represents a number of index (and surprisingly many multi bit signals do) you should not use std_logic_vector. And yes, do use use ieee.numeric_std.all;

[Pack34]

I'm a professional and use both.

For maintaining older projects originally written by someone else I use VHDL. However, for newer projects I prefer to use Verilog.

I personally prefer Verilog because I just feel more comfortable using it. It's what I was trained on in college and grad school and I feel it's a bit more readable but that's most likely just because I have more experience with it.