The Designer's Guide Community
Forum
Welcome, Guest. Please Login or Register. Please follow the Forum guidelines.
Aug 16th, 2024, 4:22am
Pages: 1
Send Topic Print
What happens if a Verilog always statement is re-triggered before it finishes? (Read 3969 times)
ViggoBiggo
New Member
*
Offline



Posts: 3

What happens if a Verilog always statement is re-triggered before it finishes?
Jun 18th, 2009, 4:13pm
 
I wonder what happens if one of the signals in an always statement's sensitivity list changes before the always statement has completed?

Should the always statement get restarted?

Should the always statement get restarted after the first pass has completed?

Or should the sensitivity list get "de-activated" until the first pass has completed?

Does anybody know what the LRM says and what section in the LRM that deals with this issue?

Back to top
 
 
View Profile   IP Logged
jbdavid
Community Fellow
*****
Offline



Posts: 378
Silicon Valley
Re: What happens if a Verilog always statement is re-triggered before it finishes?
Reply #1 - Jun 18th, 2009, 5:31pm
 
Well you can read the LRM..
but the always block can NOT get restarted or rerun.. until it finishes.
any changes to the sensitivity list are ignored while the block is active.

It should NOT get restarted if any signal changes (unless its a zero delay).  there are ways of doing non-blocking actions, but once an always block starts it will not start again until its done.


the LRM section you want to read is the one on Behavioral Modeling.

Back to top
 
 

jbdavid
Mixed Signal Design Verification
View Profile WWW   IP Logged
ViggoBiggo
New Member
*
Offline



Posts: 3

Re: What happens if a Verilog always statement is re-triggered before it finishes?
Reply #2 - Jun 18th, 2009, 6:02pm
 
Thanks for the response!

It is in line with how VCS behaves.

As far as I can tell, the consequence though is that an always statement is TOTALLY useless with regard to modeling of combinatorial logic.

Back to top
 
 
View Profile   IP Logged
jbdavid
Community Fellow
*****
Offline



Posts: 378
Silicon Valley
Re: What happens if a Verilog always statement is re-triggered before it finishes?
Reply #3 - Jun 23rd, 2009, 1:55pm
 
the always block has a long history with many uses..

I'd say its fine for combinatorial logic as long as any "delay" in your always block is on the order of the delay of the logic.  if your logic is getting faster glitches, it will probably not work in reality anyway!

but most folks use assign statements for zero delay combinatorial logic, and use the always blocks for latches/flops.

If logic is what you want to model, you might want to stick to the "Synthesizable" subset of verilog also known as "RTL". Most verilog books have a good chapter on that.. and I'm sure there are tutorials on the web. too..
Maybe one of the few RTL experts on the forum here (most of us are analog guys, and we only touch verilog-D for behavioral modeling, never synthesis) can point you at the right resources.
 
have fun
Back to top
 
 

jbdavid
Mixed Signal Design Verification
View Profile WWW   IP Logged
ViggoBiggo
New Member
*
Offline



Posts: 3

Re: What happens if a Verilog always statement is re-triggered before it finishes?
Reply #4 - Jun 23rd, 2009, 2:55pm
 
Section 11.4.1. of the IEEE std 1364-2005 says: Statements within a begin-end block shall be executed in the order in which they appear in that begin-end block. Execution of statements in a particular begin-end block can be suspended in favor of other processes in the model.

Example (only to illustrate the uselessness of always statements):

always @(a) begin
 b = a;
 c = a;
end

Here we have an always statement that does not contain any delays.  The begin-end block will get executed in 0 time when activated.

I think most designers would expect "b" and "c" always to be equal. Maybe they'll change in different delta cycles, but after the simulation time is advanced they should be the same ... right? Otherwise, all behavioral code examples in all text books are wrong!

Now let's say "a" changes from "0"->"1", "b" is set to "1" and the simulator scheduler decides to suspend the process, it does something else that results in "a" going back to "0". Now when it comes back to the begin-end block (all in 0 time) it now assigns "0" to "c". And per your previous response (and I think you are right) the transition of "a" from "1" to "0" (the 2nd trigger) is ignored because it happen while the simulator was in the middle of the begin-end block. Thus we end up with "b" equal to "1" and "c" equal to "0".

Now obviously this only happens if
1) processing of the begin-end block is suspended -and-
2) "a" changes while the begin-end block is suspended -and-
3) triggers are ignored while processing of an always statement is suspended

If the always statement was re-triggered (on "a" going from "1" back to "0") we'd see a glitch on "b" (not different from real gates) but "b" and "c" would both be "0" (correct value) when the simulation time was advanced.

Thus my original question: Does a suspended always statement get re-triggered if a signal in its sensitivity list changes?

If the answer is NO then I believe always statements are TOTALLY useless per the example above with regard to modeling of combinatorial logic (even for DV).

And it does indeed look like the simulators from all the big EDA vendors work like illustrated above ... scary!!!

Likewise, if begin-end blocks w/o timing control aren't suspended we (RTL designers / DV engineers) wouldn't have a problem either ... but that is totally legal per the reference above.

I haven NOT be able to find it, but I 'd really like to know what the LRM (IEEE 1364-2005 ... I think the standard number has changed though) say about triggers that happens while an always statement is suspended ... could somebody point me to that section in the LRM ... that would be really great. Thanks a lot!
Back to top
 
 
View Profile   IP Logged
Pages: 1
Send Topic Print
Copyright 2002-2024 Designer’s Guide Consulting, Inc. Designer’s Guide® is a registered trademark of Designer’s Guide Consulting, Inc. All rights reserved. Send comments or questions to editor@designers-guide.org. Consider submitting a paper or model.