Negative hold times in verilog
pks
I'm trying to simulate a design with negative hold time. I use cadence
simulators (verilog-xl and ncverilog) and I can configure them to
allow negative timing checks. The problem is that I don't know how to
tell the simulator to capture data input sometime before active clock
edge, therefore the captured data is the one of the previous clock
cycle.
For example:
______
CLK _______|
__________
DATA ___|
HOLD <-----> (negative hold time on DATA input).
In this clock edge, a 1 value of DATA is captured instead of the right
(0) one.
Thanks,
pks
Jonathan Bromley
message news:b4a6e932.03061...@posting.google.com...
It depends on what you mean by "tell the simulator to capture...".
If your target technology permits negative hold times, then you
need flip-flop models that work correctly with negative
hold times on the data input. If those models are behavioural,
something like this is one of many possibilities:
module neg_hold_FF(clk, d, q);
parameter Tnh = 3; // negative hold time
input clk, d;
output q;
reg q;
reg d_delayed;
// create virtual D signal by delaying d
always @(d) d_delayed <= #(Tnh) d;
// usual FF model
always @(posedge clk) q <= d_delayed;
endmodule
If the problem is related to capturing the data correctly
in a testbench, I usually find that it's best to set up
some kind of virtual clock that will be used to capture
your early DATA; then supply to the DUT a clock which is
the virtual clock delayed by one negative hold time.
There may be some clever ways of modelling these things
using specify blocks and/or UDPs, but that's outside my
expertise.
Hope I've understood your problem correctly.
--
Jonathan Bromley, Consultant
DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services
Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail: jonathan...@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com
The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
pks
Hi Jonathan,
I see that you understood my problem. The drawback of your
solution is that setup times will be also affected (setup
time will be reduced by the amount of delay introduced).
Moreover, the negative hold time may be different in each
instantion of the FF; therefore the introduced delay must
be also annotated from SDF timing check. So, I can't see
any easy solution in this way.
Anyway, my problem must be a very common problem when
simulating annotated netlists, so I can't believe that
commercial simulators don't have an easy solution for this
problem. If anyone knows a simulator that solves this problem,
please let me know.
> If the problem is related to capturing the data correctly
> in a testbench, I usually find that it's best to set up
> some kind of virtual clock that will be used to capture
> your early DATA; then supply to the DUT a clock which is
> the virtual clock delayed by one negative hold time.
>
> There may be some clever ways of modelling these things
> using specify blocks and/or UDPs, but that's outside my
> expertise.
>
Thanks a lot.
Steven Sharp
> I'm trying to simulate a design with negative hold time. I use cadence
> simulators (verilog-xl and ncverilog) and I can configure them to
> allow negative timing checks. The problem is that I don't know how to
> tell the simulator to capture data input sometime before active clock
> edge, therefore the captured data is the one of the previous clock
> cycle.
I am not an expert on timing checks, but have overheard an occasional
discussion on negative timing checks. It is my understanding that
they will provide an appropriately delayed version of the clock and/or
data signal to be used in latching the value during the window when
it is supposed to be valid.
Looking at the $setuphold description in the 2001 LRM, I see some
extra optional arguments for a "Delayed reference signal for negative
timing checks" and "Delayed data signal for negative timing checks."
However, I don't see any detailed explanation of this. I would guess
that you connect these two delayed signals to your model instead of
the original data and clock. However, I would suggest consulting the
simulator documentation for more reliable information.
Andy Botterill
<quijo...@hotmail.com> writes
>Hi Jonathan,
>I see that you understood my problem. The drawback of your
>solution is that setup times will be also affected (setup
>time will be reduced by the amount of delay introduced).
>Moreover, the negative hold time may be different in each
>instantion of the FF; therefore the introduced delay must
>be also annotated from SDF timing check. So, I can't see
>any easy solution in this way.
Assuming that you have an $sdf_annotate in your testbench you should
have timings defined for every gate instance. You will need to select
which timings to use e.g. min:typ:max.
There are then two system tasks $setup and $hold which allow setup and
hold tests to be performed. I have some simple code that does this if
you want it. It doesn't have an sdf file.
You will have to modify the stimulus to the device to achieve the
correct setup/hold. You could use relative values for the timings to
make the testbench do exactly what you want.
You could capture data on the inactive edge of the clock?
HTH
>
>Anyway, my problem must be a very common problem when
>simulating annotated netlists, so I can't believe that
>commercial simulators don't have an easy solution for this
>problem. If anyone knows a simulator that solves this problem,
>please let me know.
>
>
>
>> If the problem is related to capturing the data correctly
>> in a testbench, I usually find that it's best to set up
>> some kind of virtual clock that will be used to capture
>> your early DATA; then supply to the DUT a clock which is
>> the virtual clock delayed by one negative hold time.
>>
>> There may be some clever ways of modelling these things
>> using specify blocks and/or UDPs, but that's outside my
>> expertise.
>>
>
>Thanks a lot.
>
>> Hope I've understood your problem correctly.
>> --
>> Jonathan Bromley, Consultant
>>
>> DOULOS - Developing Design Know-how
>> VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services
>>
>> Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
>> Tel: +44 (0)1425 471223 mail: jonathan...@doulos.com
>> Fax: +44 (0)1425 471573 Web: http://www.doulos.com
>>
>> The contents of this message may contain personal views which
>> are not the views of Doulos Ltd., unless specifically stated.
--
Andy Botterill
Steven Sharp
I found some more detail on the delayed data and reference signals in
section 15.5.1 of IEEE Std 1364-2001. It seems to confirm what I said
earlier. It also says some things about when the notifier will be
toggled relative to the delayed signals. I'm afraid I don't understand
timing checks well enough to comment further.
pks
I'm afraid that there is some confussion on my question. I'll try to
explain it a little bit more.
Negative hold timing checks are correctly supported by simulators (at
least cadence simulators). So this is not the target of my question.
What I really can't solve is the problem with simulated values. Timing
checks function is to assure that inputs signals are estable during a
determined amount of time (setup before, hold after) a reference
signal (usually a clock).
In case of negative holds, timing checks allow variations of the
signal before clock edge (that's the objective of timing checks: show
a warning if timings are violated).
But the situation is the following one: timing check are not violated
but the captured data at clock edge is not correct because simulator
doesn't capture the data value some time before clock edge. Negative
holds are usually obtained when internal delay of clock net is slower
than data delay. I can't add extra delay on data signal because in
that case, setup timing check will not be the right one.
I hope my question is more clear now.
Thanks.
Robert Szczygiel
> What I really can't solve is the problem with simulated values. Timing
> checks function is to assure that inputs signals are estable during a
> determined amount of time (setup before, hold after) a reference
> signal (usually a clock).
> In case of negative holds, timing checks allow variations of the
> signal before clock edge (that's the objective of timing checks: show
> a warning if timings are violated).
> But the situation is the following one: timing check are not violated
> but the captured data at clock edge is not correct because simulator
> doesn't capture the data value some time before clock edge. Negative
> holds are usually obtained when internal delay of clock net is slower
> than data delay. I can't add extra delay on data signal because in
> that case, setup timing check will not be the right one.
Timing check commands provide delayed clock and data signals which can be
used to get the right simulation values. E.g. in the model of a flop we
have some thing like:
$setuphold (posedge CK,negedge D, 180.0, -1.9,notifier,,,dCK,dD);
$setuphold (posedge CK,posedge D, 218.0, -27.9,notifier,,,dCK,dD);
when CK and D are the inputs of the flop, than the dCK, dD and notifier
signals are used as UDP inputs:
UDP_DFF #1 UDP1 (Qi,dD,dCK,notifier)
This approach also allows to produce pessimistic unknown values in case
of timing violation.
Robert
--
** - Why a bike cannot stand up by itself?
** - Because it is two-tyred!
-- http://2510074626/~szczygie --
Steven Sharp
>
> Timing check commands provide delayed clock and data signals which can be
> used to get the right simulation values.
Yes, that is what I was describing, though not as knowledgeably as Robert.
pks
solutions.
I will try to use it. The only one problem is that I have different
hold times for rising/falling edge of data/clock_enable signal. I'll
try so manage this situation.
Thanks again for your help
Robert Szczygiel <Ro...@fake.addr.ess> wrote in message news:<slrn.pl.bf3e...@pcmic25.cern.ch>...
Robert Szczygiel
> Thank you Robert and Steven for your answers. Now I understand your
> solutions.
> I will try to use it. The only one problem is that I have different
> hold times for rising/falling edge of data/clock_enable signal. I'll
> try so manage this situation.
As you may have noticed in the example I have given you there were two
commands, first for the check on falling edge of the data, the second
for the rising edge.
>> $setuphold (posedge CK,negedge D, 180.0, -1.9,notifier,,,dCK,dD);
>> $setuphold (posedge CK,posedge D, 218.0, -27.9,notifier,,,dCK,dD);
Note that this two commands use the same dCK and dD wires.
don
"Steven Sharp" <sh...@cadence.com> wrote in message
news:3a8e124e.03061...@posting.google.com...
> quijo...@hotmail.com (pks) wrote in message
news:<b4a6e932.03061...@posting.google.com>...
>
> > I'm trying to simulate a design with negative hold time. I use cadence
> > simulators (verilog-xl and ncverilog) and I can configure them to
> > allow negative timing checks. The problem is that I don't know how to
> > tell the simulator to capture data input sometime before active clock
> > edge, therefore the captured data is the one of the previous clock
> > cycle.
>
> I am not an expert on timing checks, but have overheard an occasional
> discussion on negative timing checks. It is my understanding that
> they will provide an appropriately delayed version of the clock and/or
> data signal to be used in latching the value during the window when
> it is supposed to be valid.
I am no expert, either, but I believe the timing-checks ($setuphold
system task) and signal propagation are *independent* of each other.
In order for the gate library to correctly support negative
timing-checks, the gate primitives (verilog models) must correctly
handle situations where the D->Q latching occurs before the clock
edge, as opposed to assuming it always occurs @ clock-edge (or
slight after.) In other words, simply adding $setuphold commands
(with negative values in the appropriate fields) isn't enough.
That's my *inference* based on Artisan's TSMC 0.18 library. The
Verilog simulation library comes in two flavors -- one does not
support negative timing checks at all, where as the other
flavor does (at a purported performance penalty.) I briefly
skimmed through the negtchk library, and the gate-flipflop
primitives appeared to be much more complicated (than the baseline
non-negtchk library) in terms of #Verilog statements in the
flipflop models. It made my head hurt!
And of course, even though the library supported negative timing
checks, NC-verilog and Verilog-XL rounded up most of our negative
hold checks to 0, for some complicated reasons. (I think LDV41
and later fixes this...) Fortunately, this only seems to happen
during SCAN/ATPG simulations, where the (instantiated) flipflops
source data from an integrated mux'd scan-data input port. (The
scan datapath is direct flop->flop, no intervening combinational
logic.)
Uma Polisetti
The negative setup and hold times are an issue with smaller
geometries (especially 0.13um technolog) and the mux-D flops.
It is going to be an even bigger issue with 90nm :-(
The next issue you might face is, where the "tools" not able
to converge when the setuphold "violation" region for rise
and fall edges do not overlap. In that case, typical reaction
from the tool is to "zero out" the negative setup/hold time.
I think most of commercial tools have magic switches
to "extend" the violation region. Unfortunately, this has
penalty on simulation runtimes.
I am sorry that my explanation above "might not make sense" to
most of you. But if you have the simulator manuals, search for
"$setuphold" and "handling negative timing checks".
I can't give more details because it is Cadence's information
under NDA, but later versions of Cadence NC Verilog does very
good job on handling the rise and fall "Data" edges and different
negative setup/hold times on them.
--
Agilent Technologies Confidential
Uma Polisetti
Agilent Technologies, Inc
541-738-3335 Tel
541-738-3145 Fax