VHDL Case Statement

[NorthGuy]

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.

In my purely pragmatic view, you do not need anything on top of the process, nor do you need any process at all:

Code: [Select]

  e <= e15&e14&e13&e12&e11&e10&e9&e8&e7&e6&e5&e4&e3&e2&e1&e0;
  mux <= e(to_integer(sel));

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

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.

My assumption was that NorthGuy wanted to change the name of the clock in more than one process/block. Basically a refactor. Hence, search and replace. In emacs, that's M-x replace-string.

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

Actually, they take action when there is an event on a signal. An assignment to a signal creates an event on that signal, even if the new value assigned is the same as the previous.

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

Well, yes, but the point is that the always block should not be sensitive to the edge of the reset if the reset is actually a level. 

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.

No -- the sensitivity list triggers the process on any event on its signals.

This is why we are discussing the use of VHDL's rising_edge(clk) vs clk'event and clk = '1'! The process is sensitive to any event on the signals in the list. We have shown, the transition from 'H' to '1' creates an event which the latter idiom will say "yes! You have a rising edge!" whereas the former (the rising_edge() function) will not.

You can describe a FF thus.

A <= B when rising_edge(clk);

Works pretty much like any other concurrent assignment.

Yes, it does.

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.

Yes, and the B on the list is superfluous -- and that's why the model for the synchronous process includes only the clock and async resets. You don't trigger the process on changes in the D input. Remember the model here: a D flip-flop ignores its D input except on the active edge of the clock input.

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.

What I'm saying is that the block is triggered by the falling edge of rst_l, and Verilog doesn't have a way of describing the innards of the block in a non-redundant way.

Yes, the clock can toggle while rst_l is asserted low. Yes, the correct operation is for the clock to be ignored as rst_l low has precedence.

But the block is sensitive only to the falling edge of rst_l so the test for rst_l = '0' is redundant but necessary because Verilog gives you no way to discern that the block was triggered by rst_l and not the clock. VHDL says, "there was some event on a signal on your sensitivity list, please check for the conditions of interest on all of them."

[NorthGuy]

My assumption was that NorthGuy wanted to change the name of the clock in more than one process/block. Basically a refactor. Hence, search and replace. In emacs, that's M-x replace-string.

No, you misunderstood my post. What I said is that when I want to create a clocked process I paste a template:

Code: [Select]

  process(clk)
  begin
    if rising_edge(clk) then

    end if;
  end process;
then I need to change the clock name twice:

Code: [Select]

  process(clk_mine)
  begin
    if rising_edge(clk_mine) then

    end if;
  end process;
That's a lot of redundancy here.

P.S. Sorry, cannot answer your Verilog question. I don't use Verilog and know very little about it.

[gnuarm]

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.

In my purely pragmatic view, you do not need anything on top of the process, nor do you need any process at all:

Code: [Select]

  e <= e15&e14&e13&e12&e11&e10&e9&e8&e7&e6&e5&e4&e3&e2&e1&e0;
  mux <= e(to_integer(sel));

One of the issues of advanced age is the lack of instant learning.  I never took notes in classes through graduate school.  But now I code in VHDL infrequent enough that when I run into a stumbling block and research it to find out the cause and how to deal with it, I seldom retain the details.  However...

I seem to recall that there is an issue, perhaps tool specific, with indexing an array with a non-static signal.  I remember being thwarted by terms like "globally non-static" and "locally non-static" and having little idea of what the **** they are talking about.  Am I misremembering this?  Have you used this code?

[asmi]

In Verilog/SystemVerilog you specify a working edge of a clock straight in the block declaration, so that you only specify a clock once.
In VHDL it would look like
process (rising_edge(clk))
begin
  //what happens on a rising edge
end process;

I never understood why in VHDL there is a construct "if rising_edge(clk)" - to me the presence of "if" implies a possibility of "else" - but what "else" can really happen in this case?

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

My assumption was that NorthGuy wanted to change the name of the clock in more than one process/block. Basically a refactor. Hence, search and replace. In emacs, that's M-x replace-string.

If I used emacs enough to be facile with it, I would just use C-x M-c M-butterfly

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

Actually, they take action when there is an event on a signal. An assignment to a signal creates an event on that signal, even if the new value assigned is the same as the previous.

I think you just described a transaction, not an event.  An event is always a change in value.  I discovered this once when my code was malfunctioning and traced it to a bug in the simulator that was running an event triggered process on transactions.  Very tricky to figure out.  Maybe the code was not malfunctioning, but in debugging the simulator kept stopping on a breakpoint when there was no signal value change.  Without a signal value change the code should not have been run at all.

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

Well, yes, but the point is that the always block should not be sensitive to the edge of the reset if the reset is actually a level. 

I don't know why you assert that given acknowledgement of the previous statement.  Simulators don't run on levels.  They run on edges.  When you use a signal name in a sensitivity list that is functionally similar to saying rising_edge(x) OR falling_edge(x). 

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.

No -- the sensitivity list triggers the process on any event on its signals.

Sorry, I fail to see the difference.  Ok, I guess you mean it includes other values than 0, 1, L and H, yes, that is true.  However, there is no reason to run a clocked process on any event other than the ones that will result in a change in a signal or variable value.  That's why they use neg_edge for the low true reset. 

This is why we are discussing the use of VHDL's rising_edge(clk) vs clk'event and clk = '1'! The process is sensitive to any event on the signals in the list. We have shown, the transition from 'H' to '1' creates an event which the latter idiom will say "yes! You have a rising edge!" whereas the former (the rising_edge() function) will not.

Ok, but there's no point to this assertion.  I don't think this is what the issue is about.  I think you are actually talking about the logic used in the IF statements.  The sensitivity list typically simply has "clk" and runs on ALL events.  It is the conditional logic that must separate the times the FF needs to change the output.  We need to not confuse the two. 

You can describe a FF thus.

A <= B when rising_edge(clk);

Works pretty much like any other concurrent assignment.

Yes, it does.

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.

Yes, and the B on the list is superfluous -- and that's why the model for the synchronous process includes only the clock and async resets. You don't trigger the process on changes in the D input. Remember the model here: a D flip-flop ignores its D input except on the active edge of the clock input.

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.

What I'm saying is that the block is triggered by the falling edge of rst_l, and Verilog doesn't have a way of describing the innards of the block in a non-redundant way.

I don't understand what you mean.  Once in the block the logic has to distinguish the reset from the clock.  Are you calling that "redundant"?

Yes, the clock can toggle while rst_l is asserted low. Yes, the correct operation is for the clock to be ignored as rst_l low has precedence.

But the block is sensitive only to the falling edge of rst_l so the test for rst_l = '0' is redundant but necessary because Verilog gives you no way to discern that the block was triggered by rst_l and not the clock. VHDL says, "there was some event on a signal on your sensitivity list, please check for the conditions of interest on all of them."

So Verilog and VHDL are the same in this respect, no?  Or am I missing your point?

This conversation is getting hard to follow.

[gnuarm]

In Verilog/SystemVerilog you specify a working edge of a clock straight in the block declaration, so that you only specify a clock once.
In VHDL it would look like
process (rising_edge(clk))
begin
  //what happens on a rising edge
end process;

I never understood why in VHDL there is a construct "if rising_edge(clk)" - to me the presence of "if" implies a possibility of "else" - but what "else" can really happen in this case?

I suppose your code does not use async resets?  Others do and that needs to be separated. 

I read that the VHDL standard specifies what it synthesizable.  Seems the specify some specific formats.  I don't know that they explain the whys.  I do know there were many earlier languages to design logic with that simply allowed you to specify "this is a register assignment" which would simply create a register.  No one uses them anymore.

[asmi]

I suppose your code does not use async resets?  Others do and that needs to be separated. 

In that case you specify your working reset edge in a block header as well. In VHDL-speak it would be something like:
process (rising_edge(clk) or rising_edge(async_reset))
begin
if (async_reset = 1)
begin
  //reset logic
end else begin
  //clock logic
end
end process

Though I almost never use async resets in my designs.

[nctnico]

Async resets are never edge sensitive.

It is always something like this:

Code: [Select]

process (reset, clk)
begin
if reset ='1' then
 --reset statements
else
  if rising_edge(clk) then
  -- clock synchronous logic
  end if;
end if;
end process;

The reason to do this is because most flipflops in FPGAs / CLPDs support asynchronous reset only. However there are setup/hold requirements and time is needed to let the logic settle before the next clock edge arrives. So all in all it is a good idea to make sure the asynchronous reset has a timing relation to the clock.

[asmi]

Async resets are never edge sensitive.

WHAT? Async resets are edge-sensitive by definition as reset happens immediately as soon as reset reaches active level.

[pgo]

Hi All,
I think most of this comes down to terminology.

A edge-sensitive input is one that has effect ONLY on an edge.  This would be a clock input.  I think everyone would agree that this is a very special kind of input where a considerable degree of care has been taken to make it have effect only on a particular edge.

To give an example of the difference when considering reset inputs and the fact that they MAY have an effect on an edge:
Consider a set dominant,set-reset flip-flop (without any clock) i.e.

S R Action
0 0 hold
1 0 set
0 1 reset
1 1 set

For the following sequence
1. R = 1  Q = 0
2. S = 1  Q = 1
3. S = 0  Q = 0

The change at step 3 is due to the negation of S but the value of Q is actually determined by the value of R .  The result is sensitive to S and respond on both changes of S.

[NorthGuy]

I seem to recall that there is an issue, perhaps tool specific, with indexing an array with a non-static signal.  I remember being thwarted by terms like "globally non-static" and "locally non-static" and having little idea of what the **** they are talking about.  Am I misremembering this?  Have you used this code?

I don't remember seeing these error messages. Vivado produced a perfect mux:



Here's the whole VHDL file:

Code: [Select]

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

entity top is
  port (mux: out std_logic; sel: in unsigned(3 downto 0);
    e0,e1,e2,e3,e4,e5,e6,e7,e8,e9,e10,e11,e12,e13,e14,e15: in std_logic);
end top;

architecture bhv of top is

signal e: std_logic_vector(15 downto 0);

begin
  e <= e15&e14&e13&e12&e11&e10&e9&e8&e7&e6&e5&e4&e3&e2&e1&e0;
  mux <= e(to_integer(sel));
end bhv;

[gnuarm]

I suppose your code does not use async resets?  Others do and that needs to be separated. 

In that case you specify your working reset edge in a block header as well. In VHDL-speak it would be something like:
process (rising_edge(clk) or rising_edge(async_reset))
begin
if (async_reset = 1)
begin
  //reset logic
end else begin
  //clock logic
end
end process

Though I almost never use async resets in my designs.

So you think VHDL needs to be more like Verilog?  I don't really get your point.  Even Verilog has the redundancy of specifying async_reset more than once.  In VHDL a process uses a sensitivity list which may rule out using a function (I'm not certain).  So you specify in the logic that the FF is edge sensitive.  Your issue is just that it has more typing?  Yeah, I think we all have figured out that VHDL requires more typing than Verilog.

If you don't have an async reset you can't meet requirements in many designs.  Without an async control there is no way to set a chip into known state if the clock fails.  This can be a significant issue in equipment that has safety concerns.  Obviously not all equipment has such requirements.

[gnuarm]

Async resets are never edge sensitive.

It is always something like this:

Code: [Select]

process (reset, clk)
begin
if reset ='1' then
 --reset statements
else
  if rising_edge(clk) then
  -- clock synchronous logic
  end if;
end if;
end process;

The reason to do this is because most flipflops in FPGAs / CLPDs support asynchronous reset only. However there are setup/hold requirements and time is needed to let the logic settle before the next clock edge arrives. So all in all it is a good idea to make sure the asynchronous reset has a timing relation to the clock.

Ok, one more time...  Because processes only run on signal events (value changes) all assignments are edge sensitive functionally.  The assignment is made at the time the process is run which is always triggered by an edge (value change) in the signal in the sensitivity list. 

Additional assignments may be made to the same value on other edges than the initial edge such as in a combinational logic process.

Code: [Select]

Foo: process(A, B)
begin
Y <= A or B;
end process;
A goes a '1' and Y is set to a '1'.  B goes to a '1' and the process runs again, but still assigns a '1' to Y.  Every action in process Foo happens on some edge of a signal.  So no, this is not "edge triggered logic", but the code is all edge triggered because of the sensitivity list.

[pgo]

Async resets are never edge sensitive.

It is always something like this:

Code: [Select]

process (reset, clk)
begin
if reset ='1' then
 --reset statements
else
  if rising_edge(clk) then
  -- clock synchronous logic
  end if;
end if;
end process;

The reason to do this is because most flipflops in FPGAs / CLPDs support asynchronous reset only. However there are setup/hold requirements and time is needed to let the logic settle before the next clock edge arrives. So all in all it is a good idea to make sure the asynchronous reset has a timing relation to the clock.

Ok, one more time...  Because processes only run on signal events (value changes) all assignments are edge sensitive functionally.  The assignment is made at the time the process is run which is always triggered by an edge (value change) in the signal in the sensitivity list. 

Additional assignments may be made to the same value on other edges than the initial edge such as in a combinational logic process.

Code: [Select]

Foo: process(A, B)
begin
Y <= A or B;
end process;
A goes a '1' and Y is set to a '1'.  B goes to a '1' and the process runs again, but still assigns a '1' to Y.  Every action in process Foo happens on some edge of a signal.  So no, this is not "edge triggered logic", but the code is all edge triggered because of the sensitivity list.

Hi
You are discussing how the VHDL simulator works - far enough.
Most people describe this as event driven rather than edge triggered.
I think the distinction is not vitally important but consider the following.
In VHDL a process sensitive to a signal X will be evaluated for a change of 'H'->'1'.  Most people would not consider this an edge.
In terms of actual hardware this distinction would disappear because it is not physically realizable to implement a circuit sensitive to this transition.

I think it helps to use the term 'edge-triggered' to refer to clock related events but this is just an preference but I think a common one..

bye

[gnuarm]

Hi
You are discussing how the VHDL simulator works - far enough.
Most people describe this as event driven rather than edge triggered.
I think the distinction is not vitally important but consider the following.
In VHDL a process sensitive to a signal X will be evaluated for a change of 'H'->'1'.  Most people would not consider this an edge.
In terms of actual hardware this distinction would disappear because it is not physically realizable to implement a circuit sensitive to this transition.

I think it helps to use the term 'edge-triggered' to refer to clock related events but this is just an preference but I think a common one..

bye

Yes, you are absolutely right.  But look at the context of this discussion where someone was complaining the Verilog syntax requires specifying the edge of the async input.  So this discussion is about the HDL world and not the physical world of logic devices.

[pgo]

Hi,
I don't use Verilog but but I am curious is is permissible to use:

Code: [Select]

always @(posedge clock, reset) begin
  if (reset) begin 
    q <= 1'b0;
  end
  else begin
    q <= d;
  end
end

or is mixing posedge with an unqualified signal not allowed?
(I know it would be less efficient to simulate but resembles the VHDL style more).

Also is is allowed to use posedge outside of the sensitivity list?

[NorthGuy]

I don't use Verilog but but I am curious is is permissible to use:

Code: [Select]

always @(posedge clock, reset) begin
  if (reset) begin 
    q <= 1'b0;
  end
  else begin
    q <= d;
  end
end


Wouldn't that trigger "q <= d" coming out of reset, even if the clock is not present?

[pgo]

Yes,
That was why I asked if posedge ca be used outside of a sensitivity list.
bye

[nctnico]

Async resets are never edge sensitive.

It is always something like this:

Code: [Select]

process (reset, clk)
begin
if reset ='1' then
 --reset statements
else
  if rising_edge(clk) then
  -- clock synchronous logic
  end if;
end if;
end process;

The reason to do this is because most flipflops in FPGAs / CLPDs support asynchronous reset only. However there are setup/hold requirements and time is needed to let the logic settle before the next clock edge arrives. So all in all it is a good idea to make sure the asynchronous reset has a timing relation to the clock.

Ok, one more time...  Because processes only run on signal events (value changes) all assignments are edge sensitive functionally.  The assignment is made at the time the process is run which is always triggered by an edge (value change) in the signal in the sensitivity list. 

Why would a process run only when a signal changes? That would make sense if you make a simulator and optimise it to only do stuff when a signal changes (which can go horribly wrong.. ghdl..) but the code holds true whether the process is being run continuously or only when the signal changes. The functionality / meaning of the code doesn't change.

[gnuarm]

Ok, one more time...  Because processes only run on signal events (value changes) all assignments are edge sensitive functionally.  The assignment is made at the time the process is run which is always triggered by an edge (value change) in the signal in the sensitivity list. 

Why would a process run only when a signal changes? That would make sense if you make a simulator and optimise it to only do stuff when a signal changes (which can go horribly wrong.. ghdl..) but the code holds true whether the process is being run continuously or only when the signal changes. The functionality / meaning of the code doesn't change.

I don't follow your reasoning at all.  An event on one signal causes another signal to change.  So an event is the precursor to any process running to change the value of signals that have a dependency on the changed signal.  Otherwise, why would you need to do anything?  Until a signal changes you can just leave everything where it is and do nothing. 

The way simulators work is to schedule transactions.  An event causes a process to run and the assignments in the process create a scheduled action on a signal.  Typically the action is one delta time away (a way to order transactions with no time ticking off the game clock), but they can be scheduled some time off if running a timing sim.  Otherwise nothing happens until the next event. 

[Daixiwen]

Why would a process run only when a signal changes? That would make sense if you make a simulator and optimise it to only do stuff when a signal changes (which can go horribly wrong.. ghdl..) but the code holds true whether the process is being run continuously or only when the signal changes. The functionality / meaning of the code doesn't change.

Because it says so in the VHDL specification? VHDL 2008, §11.3

If  a  process  sensitivity  list  appears  following  the  reserved  word  process,  then  the  process  statement  is  assumed to contain an implicit wait statement as the last statement of the process statement part; this implicit wait statement is of the form

Code: [Select]

wait on sensitivity_list ;

So in a simulator, the process must be paused until one of the signals from the list changes. This is of course for simulators. When synthesizing, the tool must map this to actual hardware, and usually only recognises two types of sensitivity lists:

• a clock (single edge) and an (a)synchronous reset
• a combinatorial process with all input signals in the sensitivity list

If you deviate from those you will either generate some hardware that doesn't behave as described, or have the tool yell at you.

[SiliconWizard]

Async resets are never edge sensitive.

It is always something like this:

Code: [Select]

process (reset, clk)
begin
if reset ='1' then
 --reset statements
else
  if rising_edge(clk) then
  -- clock synchronous logic
  end if;
end if;
end process;

The reason to do this is because most flipflops in FPGAs / CLPDs support asynchronous reset only. However there are setup/hold requirements and time is needed to let the logic settle before the next clock edge arrives. So all in all it is a good idea to make sure the asynchronous reset has a timing relation to the clock.

Ok, one more time...  Because processes only run on signal events (value changes) all assignments are edge sensitive functionally.  The assignment is made at the time the process is run which is always triggered by an edge (value change) in the signal in the sensitivity list. 

Why would a process run only when a signal changes? That would make sense if you make a simulator and optimise it to only do stuff when a signal changes (which can go horribly wrong.. ghdl..) but the code holds true whether the process is being run continuously or only when the signal changes. The functionality / meaning of the code doesn't change.

There was a whole thread about this, how simulation and synthesis can diverge and what the standard says. I don't remember the topic's title but I suggest looking it up. In short, this is just how processes are defined in the VHDL standard. I suggest getting ahold of it (even if it's and older version) and read a bit.

[emece67]

.