VHDL Signal Assignment Rules 
Author Message
 VHDL Signal Assignment Rules

VHDL's rules for concurrently assigned signals seem to
be inconsistent, logically contradictory, and poorly
conceived (if you consider that VHDL is for design of
actual logic circuits).  Can anyone point me to a book
or other resource which might clear this up?

Here's a crude example of what I'm talking about:

signal d : std_logic := '0';
begin
        gate: dff port map (d, q, clk, reset);

        test: process
        begin
                reset <= '1';
                wait for period;
                reset <= '0';
                wait for period;
                d <= '1';
                clk <= '1';
                wait;  -- at this time q = '1' !!!
        end process test;
end test_arch;

In the above example, the first time clk goes high, d goes
from low to high concurrently.  Yet if you simulate this,
you will find that q gets assigned a value of 1 at the rising
edge of clk.  Thus a contradiction in VHDL is revealed:
if the assignments of clk and d are truly concurrent, then
how can q be assigned '1'?  This could only happen if d were
in fact assigned BEFORE clk...  Note that reversing the order
of the assignments of clk and d in the process makes no
difference:  q will still be assigned a '1'.

Now, if I use a slightly different example:

signal d1, d2 : std_logic := '0';
begin
        gate1: dff port map (d1, q1, clk, reset);
        gate2: dff port map (d2, q2, clk, reset);

        d2 <= q1;

        d1 <= d and not d2;

        test: process
        begin
                reset <= '1';
                wait for period;
                reset <= '0';
                wait for period;
                d <= '1';
                for i in 0 to 2 loop
                        clk <= '1';
                        wait for period;
                        clk <= '0';
                        wait for period;
                end loop;
                clk <= '1';
                d <= '0';
                wait for period;
                clk <= '0';
                wait;
        end process test;
end test_arch;

The simulation results of this 2nd example are inconsistent
with the first:  in this example, d changes from 0 to 1 at
the same time clk does.  However, d1 does not get it's new
value based on the new value of d.  Yes, there is an AND gate
in between d1 and d, but this assignment still happens concurrently
and in zero time as described above.  Yet q1 in this example
will remain at '0' upon the first rising edge of clk.

Why did VHDL's creators choose an assignment scheme that
has no connection whatsoever with reality?  The worst thing
about all of this is that it can cause a larger design like a
synchronous state machine design to fail simulation.  Yet,
when actually implemented in silicon, the design will of course
work, because in reality it is impossible for a signal to behave
anything like the above VHDL representations.  What use is
simulation if it can't reliably predict actual outcomes?

Or, put another way, how can I get around the above "feature" of
VHDL in order to do some useful simulations?

M.



Thu, 12 Sep 2002 03:00:00 GMT  
 VHDL Signal Assignment Rules
Hi Marrow,
Quote:

> VHDL's rules for concurrently assigned signals seem to
> be inconsistent, logically contradictory, and poorly
> conceived

Well, formal languages tend to be infuriating - everyone
of them which I learned made me scream at some stage, and VHDL
is no exception, oh no. :^)
Having said that - the VHDL execution model is actually pretty handy -
although maybe tough to understand.
Quote:
> gate: dff port map (d, q, clk, reset);

> test: process
> begin
> reset <= '1';
> wait for period;
> reset <= '0';
> wait for period;
> d <= '1';
> clk <= '1';
> wait; -- at this time q = '1' !!!
> end process test;
> end test_arch;

> In the above example, the first time clk goes high, d goes
> from low to high concurrently. Yet if you simulate this,
> you will find that q gets assigned a value of 1 at the rising
> edge of clk. Thus a contradiction in VHDL is revealed:
> if the assignments of clk and d are truly concurrent, then
> how can q be assigned '1'? This could only happen if d were
> in fact assigned BEFORE clk... Note that reversing the order
> of the assignments of clk and d in the process makes no
> difference: q will still be assigned a '1'.

The problem is actually the simulation model - this is a functional
simulation, and therefore an abstraction of reality. It only works
under certain assumptions. A physical flipflop always has a
setup and a hold time - the data input needs to be stable some time
before and some time after the clock edge. In a functional simulation
you tend to think of the setup and hold values as "0". Problem:
what happens if d and clk change at the same time?
The causality is undefined - how should the simulator know what we
wan't to do?

- Show quoted text -

Quote:
> Now, if I use a slightly different example:

> signal d1, d2 : std_logic := '0';
> begin
> gate1: dff port map (d1, q1, clk, reset);
> gate2: dff port map (d2, q2, clk, reset);

> d2 <= q1;

> d1 <= d and not d2;

> test: process
> begin
> reset <= '1';
> wait for period;
> reset <= '0';
> wait for period;
> d <= '1';
> for i in 0 to 2 loop
> clk <= '1';
> wait for period;
> clk <= '0';
> wait for period;
> end loop;
> clk <= '1';
> d <= '0';
> wait for period;
> clk <= '0';
> wait;
> end process test;
> end test_arch;

One important thing here is that the signal assignment, models
a buffer, not a wire. This means there's going to be a delay
from q1 to d - in other words d has to happen after q1. d1 therefore
happens after d and d2.
Quote:
> Or, put another way, how can I get around the above "feature" of
> VHDL in order to do some useful simulations?

Basically: you don't want to model a clock like that - you can, but it's
going to be very painful.
I would suggest this approach instead:
signal clk: std_logic := '0';
begin
clk <= not clk after t_clk/2; -- specify desired clock period
Then your stimulus process can use statements like:
wait until clk = '1'
d <= '0'; -- now it's clear that this happens after the clock
...
Once you use that approach you basically don't have to worry about
the execution model anymore, VHDL will just behave as you would
expect the circuit to behave.
BTW: I've put a website together for VHDL design verification,
if you are interested:
http://www.i2.i-2000.com/~stefan/vcourse/html/index.html
Hope that helps
Stefan

Sent via Deja.com http://www.deja.com/
Before you buy.



Thu, 12 Sep 2002 03:00:00 GMT  
 VHDL Signal Assignment Rules

Quote:
>VHDL's rules for concurrently assigned signals seem to
>be inconsistent, logically contradictory, and poorly
>conceived (if you consider that VHDL is for design of
>actual logic circuits).  Can anyone point me to a book
>or other resource which might clear this up?

The rules are consistent , not at all contradictory, and very carefully
thought out - once you understand the delta delay model it'll all become
clear. Any VHDL book should explain.
A delta, like the mathematical delta function, is infinitely short, i.e.
less than the simulator time resolution (and appears as 0ns or 0 ps on the
time

Quote:

>Here's a crude example of what I'm talking about:

>signal d : std_logic := '0';
>begin
>    gate: dff port map (d, q, clk, reset);

>    test: process
>    begin
>            reset <= '1';
>            wait for period;
>            reset <= '0';
>            wait for period;
>            d <= '1';
>            clk <= '1';
>            wait;  -- at this time q = '1' !!!
>    end process test;
>end test_arch;

>In the above example, the first time clk goes high, d goes
>from low to high concurrently.

Yes. More strictly, both rising edges are scheduled within the same delta
cycle, and performed at the end of that delta. Since one of them causes an
action (there is a process, the dff, that is waiting for an event on clk)
there will be another delta cycle to process that event. And in that second
delta, the 'D' input is high, therefore this value is copied onto Q.
(In this simple example, that does not cause any further delta to be
executed.

Quote:
>how can q be assigned '1'?  This could only happen if d were
>in fact assigned BEFORE clk...

No. It happens when D and Clk are asserted simultaneously ... in the _next_
delta, Clk is processed (to clock the DFF) .. in that second delta, D is
already high, therefore this value is copied onto Q. (In this simple
example, that does not cause a third delta to be executed)

Quote:
>    d1 <= d and not d2;
[...]
>            wait for period;
>            d <= '1';
>            for i in 0 to 2 loop
>                    clk <= '1';
>                    wait for period;

Here three processes run in parallel: the AND, the DFF, and the main loop
(the testbench)

Note that 'D' and 'clk' are asserted simultaneously;
this schedules a second delta in which 2 things happen;

the FF clocks the _current_ value of d1 (which is 0)
the AND generates the _next_ value of d1 (which is 1)
the value of d1 you want is one delta late to be clocked into the FF.
This models the delay through the AND gate without requiring accurate
values for propagation delay...

Quote:
> Yes, there is an AND gate
>in between d1 and d, but this assignment still happens concurrently
>and in zero time as described above.

In zero time, but in a separate delta.

Quote:
>Why did VHDL's creators choose an assignment scheme that
>has no connection whatsoever with reality?  The worst thing
>about all of this is that it can cause a larger design like a
>synchronous state machine design to fail simulation.

The connection with reality is obvious: you are deliberately designing
circuits with race conditions and wondering why you get undesirable
results.

You WANT such a circuit to fail simulation; since it points out a basic
flaw in your design which you'd better put right before commiting to
silicon.

Quote:
>Or, put another way, how can I get around the above "feature" of
>VHDL in order to do some useful simulations?

Synchronous design techniques. One obvious way is to make the clock a
separate process from the test stimulus, and use the clock signal to
trigger the update of test signals.
Another way ( a simple bodge) would be to delay data transitions in the
testbench e.g.

d <= '1' after 1 ns;

- Brian



Thu, 12 Sep 2002 03:00:00 GMT  
 VHDL Signal Assignment Rules
Thanks everyone, for the responses.  Brian, your discussion of
delta cycles in particular has cleared things up considerably.
I think I need to read a good book on VHDL simulation, as the
ones I've read have focused more on design entry and synthesis.
Any recommendations?

Interestingly, in my own VHDL designs I have never really run
into the problem I previously described.  I always use separate
processes to drive my clocks, and I use proper synchronous
design techniques and proper handling of asynchronous inputs.
The deliberately crude handling of the clock in my examples was
just the easiest way to stress the point that the clock is changing
at the same time as an input.

Where I've run into problems was when debugging or modifying
designs originally created by others, finding simulation failures
on a module which was already working in real silicon.  I'm working
on one of those "inherited" designs right now.  Your responses have
cleared things up enought that I'm going to have another look at that
simulation to see if the design is flawed.

M.



Quote:

> >VHDL's rules for concurrently assigned signals seem to
> >be inconsistent, logically contradictory, and poorly
> >conceived (if you consider that VHDL is for design of
> >actual logic circuits).  Can anyone point me to a book
> >or other resource which might clear this up?

> The rules are consistent , not at all contradictory, and very carefully
> thought out - once you understand the delta delay model it'll all become
> clear. Any VHDL book should explain.
> A delta, like the mathematical delta function, is infinitely short, i.e.
> less than the simulator time resolution (and appears as 0ns or 0 ps on
the
> time



Fri, 13 Sep 2002 03:00:00 GMT  
 VHDL Signal Assignment Rules

Quote:
>Thanks everyone, for the responses.  Brian, your discussion of
>delta cycles in particular has cleared things up considerably.

Amazing, considering how much I messed up editing in that post!
(Maybe I should mess up more often...

I honestly believe that the VHDL model does the best job of simulation that
can be done _in_the_absence_ of timing information, and I think it
highlights mistakes that uh, that other language, might conceal.
You can think of a delta as an ideal gate delay.
In ModelSim's listing window, you can see each signal, delta by delta.
Sometimes there are 5 or 6 deltas after a clock edge as changing signals
ripple through the design.

But it's no substitute for a timing simulation.

Quote:
>I think I need to read a good book on VHDL simulation, as the
>ones I've read have focused more on design entry and synthesis.
>Any recommendations?

I hesitated to recommend a book for the same reason. Peter Ashenden's book
(Designer's Guide to VHDL) is pretty good all round. He doesn't spend long
covering this topic, but his explanation seems clear to me. Any better
suggestions?

Quote:
>Where I've run into problems was when debugging or modifying
>designs originally created by others, finding simulation failures
>on a module which was already working in real silicon.  I'm working
>on one of those "inherited" designs right now.  Your responses have
>cleared things up enought that I'm going to have another look at that
>simulation to see if the design is flawed.

Then you know the device works; but you may not know that it works safely,
and if you have to migrate it to a different process or interface it to a
different environment it pays to take care.

If you are responsible for the testbench, then remember it may be at fault,
rather than the design. (hence, use the clock to trigger the test stimulus,
rather than generating them simultaneously)

Or there may be some "knowledge" in the design that is not visible in the
VHDL model. For example, in an FPGA, clocks are usually routed using
reserved high speed interconnects with guaranteed low skew, and therefore
(barring interfacing mistakes) such a design is safe.

Failing all that you may want to model the behaviour more accurately by
including relevant timing information in the design, e.g. model the AND
gate as
d1 <= d and xxx after 700 ps;
-- the after clause is ignored by synthesis tools
and there are ways to incorporate setup/hold time models in the DFF and
assert when they are not met. But WHICH information is relevant?

In extremis, synthesise it to the original technology, extract VITAL timing
information from the synthesis tools, and run a simulation on the
timing-annotated gate-level design! But for design maintenance that looks
like desperation to me...

- Brian



Fri, 13 Sep 2002 03:00:00 GMT  
 VHDL Signal Assignment Rules

Quote:

> But it's no substitute for a timing simulation.

That scares me.  In FPGA designs, you are much better off using functional
simulation and a thorough static timing analysis.  It is too easy to miss
critical things in a timing simulation.  For example, consider an adder tree.
In an FPGA, as we probably are all aware by now, a significant part of the
propagation delay is in the connections between logic blocks, and that delay is
determined by the path the routing takes.  The worst case paths tend to be the
ones through the carry chain, and in the ideal world the longest delay is from
the LSB to the carry out.  However, when you lump in the routing delay to the
adder, it is quite likely (especially if you haven't done any floorplanning)
that the delay through some other input to the adder is longer than that
through the LSB inputs.  In an adder tree you have a number of adders cascaded,
each of which has an unknown critical path.  It can be very difficult or even
impossible to generate and simulate a set of vectors that correctly exercises
every path through that adder tree (remembering that any one of them could be
the critical path).  The worst part is, if you don't exercise that path, your
simulation will tell you everything is hunky-dory. Guess what?, Even the test
coverage tools won't necessarily ferret out that you missed the worst case
path, because all of that path will have been toggled in segments, but not
necessarily end to end all at once.

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950

http://users.ids.net/~randraka



Fri, 13 Sep 2002 03:00:00 GMT  
 VHDL Signal Assignment Rules

Quote:


> > But it's no substitute for a timing simulation.

> That scares me. In FPGA designs, you are much better off using
> functional simulation and a thorough static timing analysis. It is
> too easy to miss critical things in a timing simulation.

I agree, however I usually do both, static timing analysis and
backannotated simulation. The reason is that in a complex design, it's
quite possible to miss constraining something, you then have a chance
to find that in timing simulation.

Stefan

Sent via Deja.com http://www.deja.com/
Before you buy.



Fri, 13 Sep 2002 03:00:00 GMT  
 VHDL Signal Assignment Rules


Quote:



>> > But it's no substitute for a timing simulation.

>> That scares me. In FPGA designs, you are much better off using
>> functional simulation and a thorough static timing analysis. It is
>> too easy to miss critical things in a timing simulation.

>I agree, however I usually do both, static timing analysis and
>backannotated simulation. The reason is that in a complex design, it's
>quite possible to miss constraining something, you then have a chance
>to find that in timing simulation.

>Stefan

Exactly. To expand this a bit, the timing simulation tests:

(1) whether you missed constraining something, and
(2) whether you understand the constraints mechanism, which can be
very complex, and
(3) whether the STA works as advertised.

If you expand 'timing simulation' to mean gate-level simulation,
either zero-delay or back-annotated, then the gate-level sim also
tests

(1) whether the real device will exit from reset - may be impossible
to test from RTL
(2) whether the synthesiser has worked as intended
(3) if the map/P&R process has carried out any transformations,
whether these have worked as expected.  

(2) and (3) give you a cheap equivalency tool (Ok, so the tool was
meant to replace gate-level simulation, but try buying that on an FPGA
budget).

Evan



Fri, 13 Sep 2002 03:00:00 GMT  
 VHDL Signal Assignment Rules

Quote:


>> But it's no substitute for a timing simulation.

>That scares me.  In FPGA designs, you are much better off using functional
>simulation and a thorough static timing analysis.  

I mis-spoke, you are quite correct. I should have allowed for the
possibility of static timing analysis + functional simulation instead of
timing simulation. You make some good points about its advantages.

But the original poster is analysing an old ASIC design not an FPGA, he may
not have access to the full design database.

- Brian



Sat, 14 Sep 2002 03:00:00 GMT  
 VHDL Signal Assignment Rules


Quote:
>That scares me.  In FPGA designs, you are much better off using functional
>simulation and a thorough static timing analysis.  It is too easy to miss
>critical things in a timing simulation.  For example, consider an adder
tree.
>In an FPGA, as we probably are all aware by now, a significant part of the
>propagation delay is in the connections between logic blocks, and that
delay is
>determined by the path the routing takes.  The worst case paths tend to be
the
>ones through the carry chain, and in the ideal world the longest delay is
from
>the LSB to the carry out.  However, when you lump in the routing delay to
the
>adder, it is quite likely (especially if you haven't done any
floorplanning)
>that the delay through some other input to the adder is longer than that
>through the LSB inputs.  In an adder tree you have a number of adders
cascaded,
>each of which has an unknown critical path.  It can be very difficult or
even
>impossible to generate and simulate a set of vectors that correctly
exercises
>every path through that adder tree (remembering that any one of them could
be
>the critical path).  The worst part is, if you don't exercise that path,
your
>simulation will tell you everything is hunky-dory. Guess what?, Even the
test
>coverage tools won't necessarily ferret out that you missed the worst case
>path, because all of that path will have been toggled in segments, but not
>necessarily end to end all at once.

Ray, I agree with you when you say that timing simulation won't help in
finding a critical path.

But, when i make a design including Coregen elements, the functional
simulation uses :
- RTL files that i wrote, these files are synthesized and there's no problem
with them.
- Behavi{*filter*}descriptions of Xilinx cores : these files have not been
synthesized (because they are not synthesizable). You should hope that these
files have been tested, but i believe that this test is not always done.
So, it's possible to get a different behavior between functional and
backannotated simulation (especially when you use "{*filter*}" cores). e. g. I
believe that the asynchronous FIFO for Virtex (Coregen IP4) has not been
tested with Rd_Count and Wr_Count (to build Half Full and Half Empty flags)
because this feature causes the VHDL model compilation to fail.

That's why i feel more comfortable when i make a backannotated simulation.
Of course i use static timing analysis to find critical paths.

J-P GOGLIO
GETRIS S.A.
13 Chemin des Prs
38240 Meylan
Tel : (33) 4 76 18 52 10

Fax : (33) 4 76 18 52 01



Sat, 14 Sep 2002 03:00:00 GMT  
 VHDL Signal Assignment Rules
I think maybe I am misunderstanding you or vice versa.  For synthesis, I do run
a simulation on the output from the FPGA tools, but only for function, not
timing.  The synthesis does too many funny things that can make the
implementation not work, so that final simulation is pretty much necessary to
verify that nothing got broken by synthesis tools.  For schematics in Xilinx, I
am pretty comfortable not doing a simulation on the mapped output as I can't
recall ever seeing the implementation tools break the design (it really is
wysiwyg).  This is not the case for Altera, where even a schematic design is
broken down and synthesized.

Quote:


> >That scares me.  In FPGA designs, you are much better off using functional
> >simulation and a thorough static timing analysis.  It is too easy to miss
> >critical things in a timing simulation.  For example, consider an adder
> tree.
> >In an FPGA, as we probably are all aware by now, a significant part of the
> >propagation delay is in the connections between logic blocks, and that
> delay is
> >determined by the path the routing takes.  The worst case paths tend to be
> the
> >ones through the carry chain, and in the ideal world the longest delay is
> from
> >the LSB to the carry out.  However, when you lump in the routing delay to
> the
> >adder, it is quite likely (especially if you haven't done any
> floorplanning)
> >that the delay through some other input to the adder is longer than that
> >through the LSB inputs.  In an adder tree you have a number of adders
> cascaded,
> >each of which has an unknown critical path.  It can be very difficult or
> even
> >impossible to generate and simulate a set of vectors that correctly
> exercises
> >every path through that adder tree (remembering that any one of them could
> be
> >the critical path).  The worst part is, if you don't exercise that path,
> your
> >simulation will tell you everything is hunky-dory. Guess what?, Even the
> test
> >coverage tools won't necessarily ferret out that you missed the worst case
> >path, because all of that path will have been toggled in segments, but not
> >necessarily end to end all at once.

> Ray, I agree with you when you say that timing simulation won't help in
> finding a critical path.

> But, when i make a design including Coregen elements, the functional
> simulation uses :
> - RTL files that i wrote, these files are synthesized and there's no problem
> with them.
> - Behavi{*filter*}descriptions of Xilinx cores : these files have not been
> synthesized (because they are not synthesizable). You should hope that these
> files have been tested, but i believe that this test is not always done.
> So, it's possible to get a different behavior between functional and
> backannotated simulation (especially when you use "{*filter*}" cores). e. g. I
> believe that the asynchronous FIFO for Virtex (Coregen IP4) has not been
> tested with Rd_Count and Wr_Count (to build Half Full and Half Empty flags)
> because this feature causes the VHDL model compilation to fail.

> That's why i feel more comfortable when i make a backannotated simulation.
> Of course i use static timing analysis to find critical paths.

> J-P GOGLIO
> GETRIS S.A.
> 13 Chemin des Prs
> 38240 Meylan
> Tel : (33) 4 76 18 52 10

> Fax : (33) 4 76 18 52 01

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950

http://www.*-*-*.com/ ~randraka


Sat, 14 Sep 2002 03:00:00 GMT  
 VHDL Signal Assignment Rules


Quote:
>I think maybe I am misunderstanding you or vice versa.  For synthesis, I do
run
>a simulation on the output from the FPGA tools, but only for function, not
>timing.  The synthesis does too many funny things that can make the
>implementation not work, so that final simulation is pretty much necessary
to
>verify that nothing got broken by synthesis tools.  For schematics in
Xilinx, I
>am pretty comfortable not doing a simulation on the mapped output as I
can't
>recall ever seeing the implementation tools break the design (it really is
>wysiwyg).  This is not the case for Altera, where even a schematic design
is
>broken down and synthesized.

In fact, i think that wee agree. I will try to explain what i mean in
another way.

There are (at least) 3 levels where we can simulate a FPGA:

1) RTL simulation.
2) Post-synthesis simulation.
3) Post implementation simulation.

I was just meaning that it's not possible to bypass the step 3, and that
this step must be a timing simulation.
But of course, if the static timing analysis says that the max frequency is
50 MHz (with a critical path on a carry chain) and if the simulation seems
to work at 60 MHz, The design can run at 50 and not 60 MHz.

Sorry for my misunderstanding.

 J-P GOGLIO
 GETRIS S.A.
 13 Chemin des Prs
 38240 Meylan
 Tel : (33) 4 76 18 52 10

 Fax : (33) 4 76 18 52 01



Sun, 15 Sep 2002 03:00:00 GMT  
 VHDL Signal Assignment Rules


Quote:
> The synthesis does too many funny things that can make the
> implementation not work, so that final simulation is pretty much necessary
to
> verify that nothing got broken by synthesis tools.

An example of this is FPGA Express not supporting default expressions for
interface elements.  A std_logic port input whose default expression is '1'
and which is left unassociated will be connected to '0' by FPGA Express.
FPGA Express prints an easily overlooked warning message.

Maybe you have a more universal example?

Paul Butler



Sun, 15 Sep 2002 03:00:00 GMT  
 
 [ 17 post ]  Go to page: [1] [2]

 Relevant Pages 

1. VHDL GUARDED signal assignment question

2. VHDL Assignment of INOUT signals

3. Assignment Rules

4. Variable/Signal assigned by multiple non-blocking assignments

5. conditional signal assignment

6. Signal <=Variable assignment?

7. Signal Assignment conflicts, What can I do?

8. final assignment of a internal declared signal and output port

9. Signal assignment mismatch with Aldec 5.1 problem

10. Help with multiple signal Assignments

11. question about signal assignment in "case"

12. Time Delay in signal assignment

 

 
Powered by phpBB® Forum Software