Verilog standardization ruling needed.

S

Stephen Williams

Guest
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Here's a snippet of code that reflects what I found in some modules
in the wild. It turns out that it seems to work for some compilers,
and it will work for Icarus Verilog too if the order of the assignments
after the #100 are switched, but this strikes me as a race condition
plain and simple. I can't find anything in the LRM that justifies
and expectation that this program can possibly be correct.

Here's the snippet:

~ time period;
~ reg lock_period;
~ initial begin
~ period = 0;
~ lock_period = 0;

~ #100 ;
~ lock_period <= 1;
~ period <= 250;
~ end // initial begin

~ assign #(period) lock_period_dly = lock_period;
~ assign lock_period_pulse = lock_period && !lock_period_dly;

Note that the process does a non-blocking assign to both the
"period" and the "lock_period" variables. The period is then
used as a delay for the lock_period propagating through the
continuous assignment to lock_period_dly.

This screams "Race!" to me. Can anybody else find rules that
justify this code?
- --
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFIUVEXrPt1Sc2b3ikRArBXAJ9rCClwTlqmqoUJ7Y3FXSeDrtFYLwCfbApf
NrE6YVUbBfgHNCcJyQFzHPY=
=HF0f
-----END PGP SIGNATURE-----
 
On Jun 12, 12:38 pm, Stephen Williams <spamt...@icarus.com> wrote:
Note that the process does a non-blocking assign to both the
"period" and the "lock_period" variables. The period is then
used as a delay for the lock_period propagating through the
continuous assignment to lock_period_dly.
Though the LRM does not require constant expressions for structural
delays, it doesn't say anything about how non-constant delays are
supposed to work.

I can appeal to the old de facto standard by trying this in Verilog-XL
with all optimizations turned off. It prints that there is no delay.
If I reverse the two assignments, it passes. So if that is what you
are getting, you are in good company.
 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

sharp@cadence.com wrote:
| On Jun 12, 12:38 pm, Stephen Williams <spamt...@icarus.com> wrote:
|>
|> Note that the process does a non-blocking assign to both the
|> "period" and the "lock_period" variables. The period is then
|> used as a delay for the lock_period propagating through the
|> continuous assignment to lock_period_dly.
|
| Though the LRM does not require constant expressions for structural
| delays, it doesn't say anything about how non-constant delays are
| supposed to work.
|
| I can appeal to the old de facto standard by trying this in Verilog-XL
| with all optimizations turned off. It prints that there is no delay.
| If I reverse the two assignments, it passes. So if that is what you
| are getting, you are in good company.
|

So far, the only tools that gets anything other then a zero
delay is ModelSim and cver. Icarus Verilog, ncsim and XL all
get a zero delay (no VCS results yet) and I think they all also
get a non-zero delay if the order of the assignments is switched.
But I believe that only proves that there is a race and all the
results I've seen are valid.

The code is distilled from the pertinent parts of the DCM.v
Verilog source from Xilinx ISE, releases 9.x to the present. It
makes sense that Modelsim and cver are the only tools that print
the result they get, because I suspect Modelsim is the only tool
they test with (and cver got lucky.)

Anyhow, I filed a webcase with Xilinx, and I got the usual drummed
up request for clarification from their Indian call center within
the required 24hours, and the usual nothing since.

Thanks for checking my work, Steve. Sometimes things seem so
obvious that I feel like I must have missed something:)

- --
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFIUoMsrPt1Sc2b3ikRAjV8AKDXlIlWk6fQkJNW18QgO1M4exOyXACgok/0
/gXhEtIfPO1CyX9Kd3OWdss=
=Tqha
-----END PGP SIGNATURE-----
 

Welcome to EDABoard.com

Sponsor

Back
Top