Coding style, wait statement, sensitivity list and synthesis.

[AG]

Hi,

I am new in vhdl.

In my book, the following code is given :

entity LATCH ....
end entity;

architecture A of LATCH is
begin
process
begin
if CK='1' then
Q <= D;
QB <= not D;
end if;
wait on CK,D; -- compiler error
end process;
end A;

Compilier says during elaboration :
'Wait Statement must contain condition clause with UNTIL keyword'

If I use the sensitivity list instead, the problem disappears. (except the
fact that the behavior is not strictly equivalent).

In my book, it says that using "sensitivity list" is an old fashion way of
coding, and using the wait statement is better (more generic). Who should I
believe ?

This leads me to the following question : if not all vhdl statement are
valid, how do I write portable vhdl so that it can be compiled on several
targets ?

I use Quartus II web free edition.

Thanks.

Heydji.

 

[antonio bergnoli]

AG ha scritto:

Hi,

I am new in vhdl.

In my book, the following code is given :

entity LATCH ....
end entity;

architecture A of LATCH is
begin
process
begin
if CK='1' then
Q <= D;
QB <= not D;
end if;
wait on CK,D; -- compiler error

it is valid VHDL but
it is the sythesis that failed, you try to build a 2-edge triggered
clocks FF and this stuff doesnt exist in a FPGA.

end process;
end A;


Compilier says during elaboration :
'Wait Statement must contain condition clause with UNTIL keyword'

If I use the sensitivity list instead, the problem disappears. (except the
fact that the behavior is not strictly equivalent).

In my book, it says that using "sensitivity list" is an old fashion way of
coding, and using the wait statement is better (more generic). Who should I
believe ?

What's the title of this book!?

This leads me to the following question : if not all vhdl statement are
valid, how do I write portable vhdl so that it can be compiled on several
targets ?

I use Quartus II web free edition.

Important: Coding Vhdl not only mean synthesis but even simulation,
verification, autodocumentation....

 

[Harpreet]

Hello AG,

Even I am new to VHDL but I did a course on it as part of my undergrad
program recently.
In my opinion, your problem is quite simple. You have a statement in
your code "wait on D, CK", Now, according to this statement, the
simulation won't progress until you have events on both the signals.
However, putting them in the sensitivity list resolves your problem
because the sensitivity list checks for events on any the arguments
specified in it.

Regarding the sensitivity list being an outdated way of coding, there
might be debates on that. However, it goes without saying that wait
statements are more popular state machine coding wise.

I can't really answer your last query as I myself am novice in this
field.

Hope that helps.
-Harpreet

 

[AG]

In my opinion, your problem is quite simple. You have a statement in
your code "wait on D, CK", Now, according to this statement, the
simulation won't progress until you have events on both the signals.
However, putting them in the sensitivity list resolves your problem
because the sensitivity list checks for events on any the arguments
specified in it.

Sure, but why the "wait on D,CK" can't be synthesised while the same
behavior with the sensitivity list way can.

Antonio says it's because a "wait on D,CK" statement corresponds to a 2-edge
triggered clocks which doesn't exist in FPGA. But how does the synthesis do
to build the equivalent with the sensitivity list ?

Adji.

 

[Nicolas Matringe]

AG a écrit:

Sure, but why the "wait on D,CK" can't be synthesised while the same
behavior with the sensitivity list way can.
Antonio says it's because a "wait on D,CK" statement corresponds to a 2-edge
triggered clocks which doesn't exist in FPGA. But how does the synthesis do
to build the equivalent with the sensitivity list ?

Hi
The "wait on d, ck;" statement is strictly equivalent to a sensitivity
list. It does _not_ imply a 2-edge triggered FF or anything, and it
doesn't wait for activity on both signals either.
All synthesis tools do not support 100% of the sythesizable subset of
the language. You sometimes find that what worked with some tool does
not with another.
It seems that QII does not support your wait statement, well, don't use
it and go with a sensitivity list instead.
And for your book's statement about sensitivity list, my opinion is
that it is utterly wrong.
What book is it?

Nicolas

 

[AG]

And for your book's statement about sensitivity list, my opinion is
that it is utterly wrong.
What book is it?

Some french book. Probably a bad one. I have ordered a better one.

Thanks anyway.

 

[antonio bergnoli]

Nicolas Matringe ha scritto:

AG a écrit:



Hi
The "wait on d, ck;" statement is strictly equivalent to a sensitivity
list. It does _not_ imply a 2-edge triggered FF or anything, and it
doesn't wait for activity on both signals either.

Yes Nicolas, you're definitively right. Rereading now what i wrote
yesterday i recognize that i said a silly thing. But the statement "wait
on..." is not completely equivalent to put a sensitivity list, this is
true only if "wait on..." is the first statement after "begin" process.
Or i'm going wrong again?

 

[Nicolas Matringe]

AG a écrit:

Some french book. Probably a bad one.

I know a few (being french myself ), which one is it?

Nicolas

 

[Nicolas Matringe]

antonio bergnoli a écrit:

But the statement "wait on..." is not completely equivalent to
put a sensitivity list, this is true only if "wait on..." is the first
statement after "begin" process. Or i'm going wrong again?

I think you're right, actually.
It doesn't make big difference except at first simulation cycle where
the process with the 'wait on' at the end is executed and the two
others are not.

Nicolas

 

[AG]

I know a few (being french myself ), which one is it?

VHDL du langage a la modélisation

 

[Mike Treseler]

It seems that QII does not support your wait statement, well, don't use
it and go with a sensitivity list instead.

Leo synthesizes the OP's code correctly without complaint.
Quartus is unhappy first with the entity name "LATCH"
which is reserved. Once I fix that, I get
the same error message as the OP. Once I fix
that using process(CK,D) it works fine:
http://home.comcast.net/~mike_treseler/latch.pdf

And for your book's statement about sensitivity list, my opinion is
that it is utterly wrong.

Yes, the list format has much better support,
but note that leo can go either way.
The wait style process better matches
how the language works, but the list style
is much better for reuse.

The OP should note that synthesis of a latch
is only a good idea for educational purposes.
process(reset, clock) is a more practical start
for useful synthesis.

-- Mike Treseler

 

[Nicolas Matringe]

AG a écrit:

VHDL du langage a la modélisation

1990
A bit outdated maybe...

Nicolas

 

[AG]

The OP should note that synthesis of a latch

is only a good idea for educational purposes.
process(reset, clock) is a more practical start
for useful synthesis.

-- Mike Treseler

Thank you Mike. The OP is learning VHDL, indeed.

 

[Rob Dekker]

Hi Mike, AG,

I wrote the VHDL synthesis front-end for both Leonardo (when at Exemplar) and Quartus (when at Verific),
so I feel somewhat responsible for this thread... )

Indeed the 'on' clause in a wait statement is identical to a sensitivity list on the process
(apart from the initialization run through the process), so we should really allow it for synthesis.

I will remove this test in future releases, also because it is a cosmetic test :
Ignoring the message would allow normal combinational synthesis of the process to be done
(which will result in a latch in this case).

Verific exports a feature to downgrade any errors to warnings at run time,
and if Altera exports this feature in Quartus, you might want to use that (I'm not sure if they do).

Apologies for this inconsistency in VHDL synthesis front-ends.

Rob

 

[Jim Lewis]

Rob,
So what you propose is that synthesis tools should
accept the following:
sen_list_equiv : process
begin
if CK='1' then
Q <= D;
QB <= not D;
end if;
wait on CK,D;
end process;

Will you also support the following hardware equivalent
process:
hardware_equiv: process
begin
wait on CK,D;
if CK='1' then
Q <= D;
QB <= not D;
end if;
end process;

Can I put the "wait on" anywhere else?
Can I have multiple "wait on" in the process?

Can I have one wait on at the end of each
path through the process (which is also similar
to a sensitivity list):

also_sen_list_equiv : process
begin
if CK='1' then
Q <= D;
QB <= not D;
wait on CK,D;
else
wait on CK,D;
end if;
end process;

It is great to make enhancements, but hopefully
at the same time you can keep the rules simple.

You will note that there are other valuable features
that are in 1076.6-2004, such as multiple edge
registers that I would consider higher priority than
yet another way to do a sensitivity list.

Cheers,
Jim

Hi Mike, AG,

I wrote the VHDL synthesis front-end for both Leonardo (when at Exemplar) and Quartus (when at Verific),
so I feel somewhat responsible for this thread... )

Indeed the 'on' clause in a wait statement is identical to a sensitivity list on the process
(apart from the initialization run through the process), so we should really allow it for synthesis.

I will remove this test in future releases, also because it is a cosmetic test :
Ignoring the message would allow normal combinational synthesis of the process to be done
(which will result in a latch in this case).

Verific exports a feature to downgrade any errors to warnings at run time,
and if Altera exports this feature in Quartus, you might want to use that (I'm not sure if they do).

Apologies for this inconsistency in VHDL synthesis front-ends.

Rob

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:[email protected]
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[Rob Dekker]

Hi Jim,

Rob,
So what you propose is that synthesis tools should
accept the following:
sen_list_equiv : process
begin
if CK='1' then
Q <= D;
QB <= not D;
end if;
wait on CK,D;
end process;
Yes.


Will you also support the following hardware equivalent
process:
hardware_equiv: process
begin
wait on CK,D;
if CK='1' then
Q <= D;
QB <= not D;
end if;
end process;
Yes.


Can I put the "wait on" anywhere else?

Yes, but that might have functional implications (the function might change).
This example :

process begin
<statement1>
wait on CK,D;
<statement2>
end process

is functionally equivalent to this process :

process begin
wait on CK,D;
<statement2>
<statement1>
end process

note that the order of the statements in flipped !
That is because the wait statement determines when the simulator 'stops' updating the drivers.
This change in ordering should be supported by the synthesis tool (and it is in Verific, if we only
downgraded the current error).

Can I have multiple "wait on" in the process?

You can in some synthesis tools, but Verific does not support multiple wait statements in one process.

Can I have one wait on at the end of each
path through the process (which is also similar
to a sensitivity list):

also_sen_list_equiv : process
begin
if CK='1' then
Q <= D;
QB <= not D;
wait on CK,D;
else
wait on CK,D;
end if;
end process;

In prociple, we could support this, since it is similar to a single wait at the end of
the process. However, just to be on the safe side, synthesis tools not supporting
multiple waits per process might error out.

It is great to make enhancements, but hopefully
at the same time you can keep the rules simple.

Simple rule that I used to use :
A process can have only one wait statement, and it needs an 'until' clause.

Simple rule that I will use :
A process can have only one wait statement.

You will note that there are other valuable features
that are in 1076.6-2004, such as multiple edge
registers that I would consider higher priority than
yet another way to do a sensitivity list.

Interesting, I just investigated this last month :
I personally find the 'multiple edge' feature in 1076.6 extremely confusing, and potentially incorrect.

The example given in 1076.6 is this :
Example 1:

process (reset, clk1, clk2) begin
if (reset) then
Q <= '0' ;
elsif rising_edge(clk1) then
Q <= data1 ;
elsif rising_edge(clk2) then
Q <= data2 ;
end if ;
end

Clearly, no hardware element (that I am aware of) can update its output on multiple rising edges,
so you should get a synthesis error.
But 1076.6 now proposes to accept this style, and that we should ignore the second (clk2) edge.
So, a Flip-flop should be synthesized which triggers on 'clk1' only.

I find that very uncomforting, because there will at least be big-time simulation-synthesis differences.

Now lets look at a similar, but different example (not in the 1076.6 LRM) :
Example 2:

process (reset, clk1, clk2) begin
if (reset) then
Q1 <= '0' ;
Q2 <= '0' ;
elsif rising_edge(clk1) then
Q1 <= data1 ;
elsif rising_edge(clk2) then
Q2 <= data2 ;
end if ;
end

This should in prociple be synthesizable (without risking simulation/synthesis differences), with two flip-flops :
Q1 clocked on clk1 and Q2 clocked on clk2. The only assumption is that the two clock edges
do not occur simultaniously (which is a very light assumption, considering delta-time event driven simulators,
and even 1076.6 states that this assumption can be made).

However, if we follow the 1076.6 rule, this process should ignore the second edge :
(6.1.3.3, Note 2: "The determination of the functional clock is made on a process-by-process basis; the
intended clock has to be coded first in each process").
So the (one and only) functional clock should be determined per process, and not per signal.

That is an incorrect rule !
It tells us that we should ignore clk2 in example 2, and thus Q2 will not be clocked.
And that is just plain wrong.

So, I would recommend NOT promoting this 1076.6 rule.
Verific will continue to error out on example1. It is really not synthesizable.

Just stick with a single clock per process, since that is supported by every vendor,
prevents any simulation-synthesis mismatch and does not violate any 1076.6 rules.

 

[Dave Higton]

In message <[email protected]>

I personally find the 'multiple edge' feature in 1076.6 extremely
confusing, and potentially incorrect.

The example given in 1076.6 is this :
Example 1:

process (reset, clk1, clk2) begin
if (reset) then
Q <= '0' ;
elsif rising_edge(clk1) then
Q <= data1 ;
elsif rising_edge(clk2) then
Q <= data2 ;
end if ;
end

Clearly, no hardware element (that I am aware of) can update its output on
multiple rising edges, so you should get a synthesis error.

OK, I'll bite:

I think you can synthesise this "element" from 4 D-types, one S-R
latch and a 2-input multiplexer. You use 1 D-type to register data1
from clk1, another to register data2 from clk2; then you use 2
D-types and the S-R latch to detect which edge, clk1 or clk2, was
most recent, and switch the multiplexer's output appropriately.

It depends on what you define as an element - also on whether I'm
right about the functionality above.

Dave

 

[Mike Treseler]

I wrote the VHDL synthesis front-end for both Leonardo (when at Exemplar) and Quartus (when at Verific),
so I feel somewhat responsible for this thread... )

Thanks for the posting, and for your
concern about the standards.
It is a rare event to get info
right from the horse's mouth!

Indeed the 'on' clause in a wait statement is identical to a sensitivity list on the process
(apart from the initialization run through the process), so we should really allow it for synthesis.

If the "wait on foo" is at the end of the process,
it is exactly the same as process(foo) at the top.
See:
http://groups.google.com/groups?q=wait+statement+Menchini+Sinha

-- Mike Treseler

 

[Rob Dekker]

In message <[email protected]>


OK, I'll bite:

I think you can synthesise this "element" from 4 D-types, one S-R
latch and a 2-input multiplexer. You use 1 D-type to register data1
from clk1, another to register data2 from clk2; then you use 2
D-types and the S-R latch to detect which edge, clk1 or clk2, was
most recent, and switch the multiplexer's output appropriately.

It depends on what you define as an element - also on whether I'm
right about the functionality above.

Dave

That is creative, and indeed at first glance your trick should work.

Two remarks :
(1) Note that 1076.6 does NOT define that we should mimic the Verilog
behavior (with whatever hardware we can). Instead, they say that we should
use a normal DFF, and ignore the second clock !

(2) I am not sure if a Verilog designer would really want to see such
odd hardware being created. It is more likely that this designer is
more of a newbie in RTL Verilog modeling, and therefor it might be
more appropriate to issue an error any way.
A very experiences designer willing to risk the hardware implications
could always do hard gate-instantiations to achieve the exact hardware
they deem necessary. But create this from benign looking piece of
Verilog at least unorthodox, and somewhat misleading.
Similar to accepting a division operator "/" on two 48 bit variables...
and creating the massive amount of hardware that goes with that.
Part of the task of RTL synthesis tools is to make designers aware
(sometimes painfullly aware) when they do something that would create
very unorthodox (amounts) of hardware.

Rob

 

[Dave Higton]

In message <QK%qf.39240$q%[email protected]>

That is creative, and indeed at first glance your trick should work.

Two remarks :
(1) Note that 1076.6 does NOT define that we should mimic the Verilog
behavior (with whatever hardware we can). Instead, they say that we should
use a normal DFF, and ignore the second clock !

(2) I am not sure if a Verilog designer would really want to see such
odd hardware being created. It is more likely that this designer is
more of a newbie in RTL Verilog modeling, and therefor it might be
more appropriate to issue an error any way.
A very experiences designer willing to risk the hardware implications
could always do hard gate-instantiations to achieve the exact hardware
they deem necessary. But create this from benign looking piece of
Verilog at least unorthodox, and somewhat misleading.
Similar to accepting a division operator "/" on two 48 bit variables...
and creating the massive amount of hardware that goes with that.
Part of the task of RTL synthesis tools is to make designers aware
(sometimes painfullly aware) when they do something that would create
very unorthodox (amounts) of hardware.

There are a couple of things that I find interesting:

1) The topic of flip-flops triggered from multiple edges keeps cropping
up here. I'm inclined to the view that at least some of those people
know what they're asking for.

2) I think there's a whole family of flip-flops triggered from
multiple edges. I feel sure that the scheme I put forward above
can be extended to an arbitrary number of inputs. There is also
the simple FF with one clock and one D input that registers on both
rising and falling edges; this is the one that's most commonly
requested, I think. There exist at least two implementations
of it.

Dave