( ESNUG 343 Item 8 ) --------------------------------------------- [2/16/00]
Subject: ( ESNUG 341 #11 ) Strange Timing Bug *NOT* Found In VSS 99.10
> I want to share with you and the ESNUG crowd an amazing VSS bug. I had
> this fragment of code:
>
> p0 : process (clk, GSR)
> begin
> if (GSR = '1') then
> addr_d <= (others => '0');
> elsif (clk'event and clk = '1') then
> addr_p <= ui_addr;
> end if;
> end process;
>
> that refused to simulate the way it should with VSS 99.10. addr_p was not
> the registered version of ui_addr, but an identical copy of it. After a
> few hours I discovered that the problem was with the "addr_p" identifier:
> changing the name of the signal to "addr_d" solved the problem. Isn't
> this amazing?
>
> - Dr. Arrigo Benedetti
> Caltech Pasadena, CA
From: Evan Lavelle <eml@riverside-machines.com>
Hi, John,
I was interested to see this code on ESNUG. Agreed, the simulation
results are nothing like the expected results, but to be fair to Synopsys
(not that I normally am) this is a tricky problem. This is a known
pathological case for synthesizers, since it's not easy to represent the
code in real hardware. The problem is in deciding what to do when there's
a rising clock edge, but GSR is already at '1' (or, even worse, a rising
clock edge and a rising GSR edge at the same time). In this case, the
GSR has the higher priority, and the clock must be ignored. The 'real'
hardware should therefore look something like this:
-----------------------
| ___ ------ | ADDR_P
-----| | | Q|---.---------
|MUX|----|D |
UI_ADDR -------|___| --|> |
| | ------
GSR---------- |
CLK --------------
In other words, if GSR is already high, then the clock edge simply loads
ADDR_P back into the register. This isn't perfect, since some delay has
to built into CLK to account for a rising edge on both GSR and CLK at
the same time.
Of course, VSS isn't a synthesizer and should be able to show the
expected output from the model. This makes you wonder if it has some
special synthesis knowledge, and was getting confused because of that.
- Evan Lavelle
Riverside Machines Ltd. UK
---- ---- ---- ---- ---- ---- ----
From: [ A Synopsys VSS VHDL CAE ]
John,
I believe the problem is with the code and not VSS. But, I'm assuming
he was trying to model a typical register. If he was attempting to
model something else, please let me know.
A process that models the rising edge registering of an input value with an
asynchronous reset should assign the reset value and the input value to the
same target. His original code assigned the reset value to addr_d and the
input value to addr_p under the reset and rising edge clock conditions
respectively. When he modified the code to assign the input value to the
same target as the reset value (addr_d), he fixed the problem in the VHDL.
In his simulation, addr_p would never have been reset to all 0's when the
GSR signal toggled high. It would have retained its current value.
Conversely, addr_d would start simulation with it's initial value (probably
all U's) and would have toggled to all 0's when GSR went high and then
remained that value throughout the simulation. (This assumes that there
are no other drivers for addr_d and addr_p).
- [ A Synopsys VSS VHDL CAE ]
|
|
