VHDL Case Statement

[Bassman59]

I've seen times when every iteration the names changed!  This is one of the reasons to use labels on everything hierarchical.

This is a really good idea.  I'll incorporate it the next time I write some VHDL.

Use labels everywhere. Every process should have a label. Case statements should have labels. Generate statements should have labels. I even put labels on if/then statements when the nesting gets deep. Labels are your friends!

[Bassman59]

Thanks again for the suggestions. As I said, I have only been learning VHDL for a week and have a lot to learn. My only other experience with a HDL was the nand2tetris site.

When you find educational sources, make sure they include coverage of VHDL-2008.  That was a significant improvement in the language with many usability features that make life with VHDL much better.

That's true. But I'm often surprised how far behind many courses and tutorials are. Heck, there are still many out there that don't even cover VHDL-93 properly and still stick to the original VHDL-87!

How many pieces of vendor-supplied example code -- in their fucking language-support manuals -- have ancient shit like clk'event and clk = '1' instead of rising_edge(clk)? And have no labels?

It's no wonder that in 2021 the newbies write code as if the language hasn't advanced past its 1987 version.

[SiliconWizard]

Thanks again for the suggestions. As I said, I have only been learning VHDL for a week and have a lot to learn. My only other experience with a HDL was the nand2tetris site.

When you find educational sources, make sure they include coverage of VHDL-2008.  That was a significant improvement in the language with many usability features that make life with VHDL much better.

That's true. But I'm often surprised how far behind many courses and tutorials are. Heck, there are still many out there that don't even cover VHDL-93 properly and still stick to the original VHDL-87!

How many pieces of vendor-supplied example code -- in their fucking language-support manuals -- have ancient shit like clk'event and clk = '1' instead of rising_edge(clk)? And have no labels?

It's no wonder that in 2021 the newbies write code as if the language hasn't advanced past its 1987 version.

Yep...

[admiralk]

Thanks again for the suggestions. As I said, I have only been learning VHDL for a week and have a lot to learn. My only other experience with a HDL was the nand2tetris site.

I would highly recommend https://vhdlwhiz.com/ for learning. I have paid for the Dot Matrix VHDL and FPGA Course as well as the new continuing membership. The explanations are quite thorough and easy to understand. Worth the money if you're just getting into VHDL.

I would love to take a structured course, but I am often working 10 hour days and when you add in all the other chores and what not I have to get done, there is not much time left for it. I have gone through most of and found it helpful. I plan to roughly revisit the nand2tetris course. I started reading FPGA-Based System Design on my breaks. This would be a good time to go back through Digital Fundamentals as well and program the circuits.

I will try to find more modern sources for the language, I still need to learn modern C++ also, I am pretty much limited to 98.

[gnuarm]

Thanks again for the suggestions. As I said, I have only been learning VHDL for a week and have a lot to learn. My only other experience with a HDL was the nand2tetris site.

When you find educational sources, make sure they include coverage of VHDL-2008.  That was a significant improvement in the language with many usability features that make life with VHDL much better.

That's true. But I'm often surprised how far behind many courses and tutorials are. Heck, there are still many out there that don't even cover VHDL-93 properly and still stick to the original VHDL-87!

How many pieces of vendor-supplied example code -- in their fucking language-support manuals -- have ancient shit like clk'event and clk = '1' instead of rising_edge(clk)? And have no labels?

It's no wonder that in 2021 the newbies write code as if the language hasn't advanced past its 1987 version.

Yep...

I'm working on an open source project with a guy who has his roots in some old software that uses drawn waveforms to drive simulations.  It doesn't use VHDL-2008 so he won't use any of the expedients.  His code is very hard to read and debug. 

I see many educational institutions still using clk'event and std_logic_arith.  I know this stuff will work, but there are issues depending on the systems you are using from what I've been told.  There being no standard each vendor's implementation is different.  It also bugs me that people keep using std_logic_vector as their default type when unsigned or signed give you much more capability and if nothing else, is much easier to type!!!

[Bassman59]

I'm working on an open source project with a guy who has his roots in some old software that uses drawn waveforms to drive simulations.  It doesn't use VHDL-2008 so he won't use any of the expedients.  His code is very hard to read and debug. 

My crystal ball says: run away.

I see many educational institutions still using clk'event and std_logic_arith.

Because an instructor wrote the curriculum in the last century and it hasn't been updated since. I wonder what software and hardware they want the students to use for development.

And you can see this is the case, as many instructors put class notes online, so you may come across them in a web search for something else.

  I know this stuff will work, but there are issues depending on the systems you are using from what I've been told.  There being no standard each vendor's implementation is different.  It also bugs me that people keep using std_logic_vector as their default type when unsigned or signed give you much more capability and if nothing else, is much easier to type!!!

You're absolutely right about using unsigned and signed types where they are useful. Ignore anyone who says to not use those types on entity port lists, too! Use ranged integers or naturals, too! Define an enumerated type instead of using std_logic_vector(X downto Y) with a bunch of constants!

There are so many useful features in VHDL that get ignored because they're either not specifically called out with examples in the synthesis reference manuals, or the class instructors never mention them. For example, the VHDL record can greatly simplify your port lists.

[gnuarm]

I'm working on an open source project with a guy who has his roots in some old software that uses drawn waveforms to drive simulations.  It doesn't use VHDL-2008 so he won't use any of the expedients.  His code is very hard to read and debug. 

My crystal ball says: run away.

Yeah, I've thought of that.  I was pretty psyched about working on it, but it is very poorly managed and I'm sick of dealing with the consequences of not having a set of requirements analysis.  We barely have anything documented at all.  Every time I push for something to be documented they create another spreadsheet rather than do a proper job of it! 

I see many educational institutions still using clk'event and std_logic_arith.

Because an instructor wrote the curriculum in the last century and it hasn't been updated since. I wonder what software and hardware they want the students to use for development.

And you can see this is the case, as many instructors put class notes online, so you may come across them in a web search for something else.

Not only the old courses, I've helped student who are still being told this is how you do it.  I guess many professors have not written any VHDL in over 20 years.  The students don't understand what is wrong with using these as it "seems to work".  I swear, I'm going to punch the next guy who tells me that!

  I know this stuff will work, but there are issues depending on the systems you are using from what I've been told.  There being no standard each vendor's implementation is different.  It also bugs me that people keep using std_logic_vector as their default type when unsigned or signed give you much more capability and if nothing else, is much easier to type!!!

You're absolutely right about using unsigned and signed types where they are useful. Ignore anyone who says to not use those types on entity port lists, too! Use ranged integers or naturals, too! Define an enumerated type instead of using std_logic_vector(X downto Y) with a bunch of constants!

There are so many useful features in VHDL that get ignored because they're either not specifically called out with examples in the synthesis reference manuals, or the class instructors never mention them. For example, the VHDL record can greatly simplify your port lists.

I've never gotten into records much.  Seems a bit of work if you don't have an actual reason to bundle signals.  I guess it is less typing given the many times you have to declare things in VHDL.  I used to copy a set of regular expressions in my source files that allow me to generate the different formats for the entity declaration, the component instance and the signals declaration to save on the typing.  Maybe I'll try using records next time.  The record declaration would need to be in a package to be useful, right?

[nctnico]

I am going to chalk this up to what ever the problem was, it is gone now, and move on. I would like to thank you all for your input and not trying to redesign my project.

Still a better way to implement something like this is using a for-loop. I'm not sure whether this excersize was to explicitely teach the case statement but for these kind of constructs a case statement is the worst choice. You have to write an expression for each input condition; that way writing VHDL gets cumbersome and lengthy.

Using functions, conditional code (generate), arrays, for-loops, records and numeric signals (which are easy to cast as an index to an array) make life much easier and VHDL code shorter & easier to follow / maintain.

Early in my career I made it a point to write VHDL as short as possible. Take time to understand how more complex constructs work and what kind of FPGA logic it results in. It paid off in spades. My first project was a 16 channel 'something'. A couple of months later my boss asked: we need your design to support 30 channels. How long does that take to re-code? My answer: 5 minutes. I just need to change 16 into 30. Not long after that the number of channels had to be upgraded to 128 with took the same amount of effort.

[SMB784]

Thanks again for the suggestions. As I said, I have only been learning VHDL for a week and have a lot to learn. My only other experience with a HDL was the nand2tetris site.

When you find educational sources, make sure they include coverage of VHDL-2008.  That was a significant improvement in the language with many usability features that make life with VHDL much better.

That's true. But I'm often surprised how far behind many courses and tutorials are. Heck, there are still many out there that don't even cover VHDL-93 properly and still stick to the original VHDL-87!

How many pieces of vendor-supplied example code -- in their fucking language-support manuals -- have ancient shit like clk'event and clk = '1' instead of rising_edge(clk)? And have no labels?

It's no wonder that in 2021 the newbies write code as if the language hasn't advanced past its 1987 version.

Sadly verilog is just as bad with this.

Most code examples are done in verilog 1995 (not even 2001!) when SystemVerilog has come so much further and is so much more readable/easier to debug.  All kinds of really non-obvious errors and pitfalls can arise with verilog 1995 that are mostly corrected in SystemVerilog, and yet people still do their teaching with verilog 1995.  Its crazy!

[Bassman59]

I've never gotten into records much.  Seems a bit of work if you don't have an actual reason to bundle signals.  I guess it is less typing given the many times you have to declare things in VHDL.  I used to copy a set of regular expressions in my source files that allow me to generate the different formats for the entity declaration, the component instance and the signals declaration to save on the typing.  Maybe I'll try using records next time.  The record declaration would need to be in a package to be useful, right?

Yes, the record type needs to be declared in a package, so it's visible to all entities that use it on ports. My designs tend to have a types_pkg package file so I can have types and constants and enumerations of all sorts shared across entities. That's how you make your entity ports have things more useful than simply std_logic and std_logic_vector.

Here's an example of where a record type is useful. The design had a lot of parameters that can be set by user command. The parameters are also stored in nonvolatile memory for recall at power-up or reset. So there's an entity that manages the user setting and getting the parameter values, an entity that manages the non-volatile storage (write and recall) and of course there are the various entities that actually use the parameters.

Obviously the parameters had to each be ports on each entity's port list. The command parser needed to drive as outputs a "new" parameter when the user changed it, along with a strobe telling the non-volatile memory manager to store that new parameter. The parser needed to take in the recalled parameters, too.

When I first started the design, there were only a handful of parameters, so having each on the port list was "manageable." But then as more things needed to be parametrized, the entity port lists got unwieldy. So I just wrapped up all of the parameters into one record. To support the user updating parameters, I created a second record with "new parameter" values and a write strobe for each. A "parameter manager" entity sat in the middle, dealing with new things from the command parser, initial values that are read from non-volatile store at reset, and it output the parameters used by the whole design.

Each entity that needed to consume parameters takes that record as an input. One port on the list, not ... a whole bunch.

The only annoyance is that the synthesis tool complained when a member of the parameter record wasn't used within a given entity.

But it sure made adding new parameters a cinch.

[admiralk]

I am going to chalk this up to what ever the problem was, it is gone now, and move on. I would like to thank you all for your input and not trying to redesign my project.

Still a better way to implement something like this is using a for-loop. I'm not sure whether this excersize was to explicitely teach the case statement but for these kind of constructs a case statement is the worst choice. You have to write an expression for each input condition; that way writing VHDL gets cumbersome and lengthy.

Using functions, conditional code (generate), arrays, for-loops, records and numeric signals (which are easy to cast as an index to an array) make life much easier and VHDL code shorter & easier to follow / maintain.

Early in my career I made it a point to write VHDL as short as possible. Take time to understand how more complex constructs work and what kind of FPGA logic it results in. It paid off in spades. My first project was a 16 channel 'something'. A couple of months later my boss asked: we need your design to support 30 channels. How long does that take to re-code? My answer: 5 minutes. I just need to change 16 into 30. Not long after that the number of channels had to be upgraded to 128 with took the same amount of effort.

I did not realize loops even existed in VHDL until it was mentioned here. I originally used a select statement, then learned about the case statement and changed it.

[nctnico]

I strongly suggest to go through a VHDL book and look at all the language constructs that are available. And then go through a synthesis guid (like this one from Xilinx: https://www.xilinx.com/support/documentation/sw_manuals/xilinx2019_2/ug901-vivado-synthesis.pdf) to learn how VHDL language constructs get mapped onto FPGA logic. I'll admit there is a lot to learn so don't try learn everything in one go.

Take a good mental note of what Bassman59 wrote earlier: most examples are horrible. I fully agree with that! For fun look at examples of a priority encoder. 9 out of 10 examples will write a line for each input combination. 1 out of 10 will use function (which uses a loop) which can be used for an arbitrary number of inputs. VHDL allows a large degree of code re-useability but very few seem so make full advantage of it.

One of the worst projects I've seen uses Python scripts to create VHDL files for registers connected to an address/data bus. It could have been written so much simpler using just VHDL and on top of that they could have made a generic component for it! 

[emece67]

.

[NorthGuy]

How many pieces of vendor-supplied example code -- in their fucking language-support manuals -- have ancient shit like clk'event and clk = '1' instead of rising_edge(clk)?

What difference does it make?

[pgo]

clk'event and clk='1' vs rising_edge(clk)

The first detects any transition that results in a final signal state of '1' on clock e.g. 'H'->'1'

The second is an IEEE standard library function that only detects sensible rising edges e.g.
'0' -> '1', '0'->'H' etc.

For synthesis is makes no difference.  For absolutely bug-free VHDL is make not much difference for simulation.
It's main advantages are:

• It's easier to read!!
• Most editors will highlight the keyword so above++
• In simulation it correctly rejects invalid transitions as rising edges.

bye

PS I taught Digital Systems for many years and the first version always annoyed me! 
I couldn't persuade other staff to change for some reason.

[emece67]

.

[pgo]

Hi,

rising_edge() function correctly handles 0->H transitions so will also work for the I2C case as stated.

FUNCTION rising_edge (SIGNAL s : std_ulogic) RETURN BOOLEAN IS
BEGIN
RETURN (s'EVENT AND (To_X01(s) = '1') AND
(To_X01(s'LAST_VALUE) = '0'));
END;


I don't have access to the source library at the moment so the above is from the internet but I believe it is representative of how the function is implemented.

bye

[emece67]

.

[NorthGuy]

PS I taught Digital Systems for many years and the first version always annoyed me! 

Since you teach the language, you're focused on the language. In contrast, I am focused on the design, and I want to use the language to describe my design with as little effort as possible.

The easiest way to infer flip-flops is to create a clocking process. So, I have a 4-line template which I paste. It happened to be "rising_edge" variety, so I use "rising_edge" everywhere. It could have been "clock'event" variety just as well, in which case I would use "clock'event" everywhere. Makes no difference, except one - with "rising_edge" I need to change the clock name twice. With "clock'event" I would have to do it three times. So, I would say "rising_edge" is somewhat better. But it would be even better if there was a construct where I need to change the clock name only once. Sorry, not in VHDL

[Bassman59]

PS I taught Digital Systems for many years and the first version always annoyed me! 

Since you teach the language, you're focused on the language. In contrast, I am focused on the design, and I want to use the language to describe my design with as little effort as possible.

The easiest way to infer flip-flops is to create a clocking process. So, I have a 4-line template which I paste. It happened to be "rising_edge" variety, so I use "rising_edge" everywhere. It could have been "clock'event" variety just as well, in which case I would use "clock'event" everywhere. Makes no difference, except one - with "rising_edge" I need to change the clock name twice. With "clock'event" I would have to do it three times. So, I would say "rising_edge" is somewhat better.

You're missing the point, which is that rising_edge(clk) is the proper modern idiom to use when inferring edge-sensitive flip-flops.

Also, your editor doesn't have a find-and-replace feature?

But it would be even better if there was a construct where I need to change the clock name only once. Sorry, not in VHDL

We know you're a Verilog partisan, so explain why the sensitivity lists for always blocks that are used to infer flip-flops with an asynchronous reset are sensitive to the edge of that reset?

To wit:

always @(posedge clk, negedge rst_l) begin
 if (!rst_l) begin
    q <= 1'b0;
  end
else begin
    q <= d;
  end
end

Flip-flop async resets are not edge triggered!

Also the above always block doesn't explicitly say that the q <= d assignment happens on the rising edge. It's implied because we know there are only two events which trigger the block. We explicitly test only for the state of rst_l first, and if that test is false, then we assume that the rising edge of clk was the trigger event.

But even the test for rst_l being low is sorta weird. The only event on rst_l that triggers the block results in that signal being low, so testing for it being low is redundant.

[SiliconWizard]

I did not realize loops even existed in VHDL until it was mentioned here. I originally used a select statement, then learned about the case statement and changed it.

There are not only loops, but also records (as mentioned earlier), arrays (all people know that), files, pointers, functions...

Not yet classes, but packages can, in some ways, emulate some aspects of classes.

But it seems that only some books do cover such topics, I'm still waiting to see a online resource that, really, teaches VHDL, not a minimal subset of it.

You also have:
- Function/procedure overloading, which is quite handy (and is used liberally in the standard IEEE libraries.)
- Generic packages (in VHDL-2008): great stuff.
- A lot of goodies for test bench code.
- Absolutely not exhaustive.

There are good and modern VHDL books out there, but the challenge for beginners will be to spot them when you don't actually know what you're looking for yet.

As to courses, they often are outdated indeed and rarely get into much depth either - often both for lack of knowledge/practice from those who teach, and for lack of time. Using "advanced" VHDL features can be immensely useful, but the hard part is to understand what those features are exactly and how they can actually map to hardware. (To put it simply - even though it's a simplification - that's what you'd call "synthesizable".) Many courses do no bother too much as it needs to get more in depth, so they tend to stick to a very simple subset which is guaranteed to be synthesizable without having to think much. So I'm not entirely blaming them.

Yes, I also wish more modern VHDL (/SystemVerilog) was taught, but OTOH, last thing you want is to get a bunch of young engineers writing overly convoluted code that is either not synthesizable (and may take days/weeks for them to figure out why), or synthesizable but with very poor results...

[pgo]

rising_edge() function correctly handles 0->H transitions so will also work for the I2C case as stated.

That's what I (tried to) say. The first form —scl'event and scl = '1'— doesn't work; the second one —rising_edge(scl)— does.

Hi emecce67,

I'm sorry if my post could be taken as a correction.
What you said was entirely correct.
You mentioned To_X01() so I thought the expansion of rising_edge() would be interesting

bye

[pgo]

Hi All,

This thread has wandered a bit from the original question - but why not!

Just to widen the discussion further - I think the easiest way to do the original process is to use array indexing (with a default value at top of process).  This requires conversion functions or casts.

BUT please keep in mind that often when teaching something the idea is to illustrate some point or technique, not necessarily to implement the functionality cleverly.  It may not even be the simplest solution.  I would however expect it to be equally efficient in actual synthesis.

The outcome of this is that the original solution posted ends up being pretty close to the usual solution given for the problem or just used as good example of a case statement.

Case statements really come into their own in more complex situations such as state machines but these are not good initial examples.

bye

PS. Pet peeve - people who think they are writing code not hardware. OK test-benches are code but the synthesis stuff needs to be written with hardware in mind.

[admiralk]

Speaking of books; Does anyone have an opinion on Effective Coding with VHDL: Principles and Best Practice for modern VHDL?

...
Yes, I also wish more modern VHDL (/SystemVerilog) was taught, but OTOH, last thing you want is to get a bunch of young engineers writing overly convoluted code that is either not synthesizable (and may take days/weeks for them to figure out why), or synthesizable but with very poor results...

...
PS. Pet peeve - people who think they are writing code not hardware. OK test-benches are code but the synthesis stuff needs to be written with hardware in mind.

I understand both of these thoughts very well. I have allways found it better to do something simply, and do it well, than to make it flashy, and mediocre at best.

[gnuarm]

PS I taught Digital Systems for many years and the first version always annoyed me! 

Since you teach the language, you're focused on the language. In contrast, I am focused on the design, and I want to use the language to describe my design with as little effort as possible.

The easiest way to infer flip-flops is to create a clocking process. So, I have a 4-line template which I paste. It happened to be "rising_edge" variety, so I use "rising_edge" everywhere. It could have been "clock'event" variety just as well, in which case I would use "clock'event" everywhere. Makes no difference, except one - with "rising_edge" I need to change the clock name twice. With "clock'event" I would have to do it three times. So, I would say "rising_edge" is somewhat better.

You're missing the point, which is that rising_edge(clk) is the proper modern idiom to use when inferring edge-sensitive flip-flops.

Also, your editor doesn't have a find-and-replace feature?

That's a bit silly.  I don't invoke a search and replace to change two things.  It's more work than it's worth.

But it would be even better if there was a construct where I need to change the clock name only once. Sorry, not in VHDL

We know you're a Verilog partisan, so explain why the sensitivity lists for always blocks that are used to infer flip-flops with an asynchronous reset are sensitive to the edge of that reset?

To wit:

always @(posedge clk, negedge rst_l) begin
 if (!rst_l) begin
    q <= 1'b0;
  end
else begin
    q <= d;
  end
end

Flip-flop async resets are not edge triggered!

That's not exactly correct.  All logic in HDLs take action on the transition.  Then that state is assumed to hold until something else takes action on the signal.  If you model a pull-up resistor with an 'H' or 'L' even that takes action when the signal that had been driving it makes the change to release the drive (an edge if you will). 

Yes, I know this is not considered to be edge sensitive logic, but that's the way models in HDL work, both HDLs. 

The only difference between saying rising_edge(signal_name) and adding signal_name to the sensitivity list is the sensitivity list acts on both edges.  You can describe a FF thus.

A <= B when rising_edge(clk);

Works pretty much like any other concurrent assignment.  The implied sensitivity list is (B, clk), so sensitive to edges of both signals, yet A only changes when there is a rising edge on clk.

Also the above always block doesn't explicitly say that the q <= d assignment happens on the rising edge. It's implied because we know there are only two events which trigger the block. We explicitly test only for the state of rst_l first, and if that test is false, then we assume that the rising edge of clk was the trigger event.

But even the test for rst_l being low is sorta weird. The only event on rst_l that triggers the block results in that signal being low, so testing for it being low is redundant.

Not redundant if the process was triggered on the clock while rst_l was low.  rst_l being low does not stop the triggers on clk.