asynchronous signal problem

[The Weiss Family]

I have an asynchronous signal coming into my chip.
I route it through two back-to-back flip-flops to synchronize it to the
system clock.
However, when I simulate (post place and route) the design in ModelSim I see
problems.
Whenever an asynchronous input edge coincides (within a few tens of ps) with
the system clock, the simulator says there is a timing violation and puts an
'X' on the signal. Thus, everything that is derived from that signal also
gets an 'X'.

I'm wondering if this is truly what will happen, or if the simulator does
not properly model the synchronizer circuit.
The probablility of a metastable condition is supposed to be extremely low
by using two flip-flops.
Is it possible that ModelSim simply propagates the 'X' as soon as it detects
a timing violation?

I would try it on real hardware, but I don't have it yet ;-)

Any ideas?

Adam

 

[Wallclimber]

I have an asynchronous signal coming into my chip.

I route it through two back-to-back flip-flops to synchronize it to the
system clock.
However, when I simulate (post place and route) the design in ModelSim I see
problems.
Whenever an asynchronous input edge coincides (within a few tens of ps) with
the system clock, the simulator says there is a timing violation and puts an
'X' on the signal. Thus, everything that is derived from that signal also
gets an 'X'.

This is one of the standard problems of asynchronous design.
Basically, the simulator does exactly what it's told to do: complain
when a signal violates setup and hold requirements. Except, of course,
that in this case you have taken the right precautions.

I don't really know about a solution to this that doesn't look like a
hack.
What I have done in the past (and this seems to be a common fix), is
hack the SDF file and set the setup and hold requirements for the
first FF to zero. This way, the simulator won't complain...
Another one (that comes down to the same thing), is to replace the
verilog model of that particular FF with another one that doesn't do
setup and hold checking.
In some cases, when the overall interface is simple, you solve it by
forcing valid values on the output of the first FF.

I'd love to hear about better solutions!

Tom Verbeure

 

[Charles M. Elias]

I have an asynchronous signal coming into my chip.
I route it through two back-to-back flip-flops to synchronize it to the
system clock.
However, when I simulate (post place and route) the design in ModelSim I see
problems.
Whenever an asynchronous input edge coincides (within a few tens of ps) with
the system clock, the simulator says there is a timing violation and puts an
'X' on the signal. Thus, everything that is derived from that signal also
gets an 'X'.

I'm wondering if this is truly what will happen, or if the simulator does
not properly model the synchronizer circuit.
The probablility of a metastable condition is supposed to be extremely low
by using two flip-flops.
Is it possible that ModelSim simply propagates the 'X' as soon as it detects
a timing violation?

I would try it on real hardware, but I don't have it yet ;-)

Any ideas?

Adam

Adam,

I have had similar problems with my Aldec simulator. It doesn't do
probabilites, so there will almost certainly be timing violations with
some asynchronous inputs. In the real world, the 2 flip-flop
synchronizers work quite well. I have used a number of schemes to
avoid this problem in simulation. All involve modifying the
asynchronous input in some way. One scheme is to instantiate a d
flip-flop or a synchronous register that is clocked with the UUT's
clock and to feed your stimulus signal to the input(s) and then use
the output(s) of the flop or register as the "asynchronous" input(s)
to the UUT. In other cases, I have used a "wait until" statement to
force the asynchronous input to change only when the UUT's clock is
'0' (preferably not too close to the rising edge of the clock).
Anyway, I'm sure you get the idea.

Good Luck and Best Regards,

Charles

 

[The Weiss Family]

Thanks for the input guys.
I had a feeling that it was just the simulator.
I'll try forcing the setup time on that first FF to 0.
Thanks again,

Adam

 

[Mike Treseler]

I have an asynchronous signal coming into my chip.
I route it through two back-to-back flip-flops to synchronize it to the
system clock.
However, when I simulate (post place and route) the design in ModelSim I see
problems.

http://groups.google.com/groups?q=charles+dqdq

-- Mike Treseler

 

[Jonathan Bromley]

I have an asynchronous signal coming into my chip. [...]

Is it possible that ModelSim simply propagates the 'X'
as soon as it detects a timing violation?

Not ModelSim, but perhaps the flip-flop model, is behaving
like this.

You've made, and received, some sensible suggestions. You can
also try to solve the problem by making your models as realistic
as possible. All this depends on being able to replace the
"synchroniser" instances of flip-flop library models with
a different model.

One useful possibility is to make a really good model of
a flip-flop's metastability. To do this, you need to model
some of the FF's internal delays, and measure the setup
or hold time relative to the effective clock that decides
when the FF samples. Then the flip-flop output is
modelled using something like

q <= 'X' after Q_hold_time,
D after propagation_delay;

where "propagation_delay" is calculated as a function of
the setup time - the nearer this is to zero, the longer
the propagation delay.

A second possibility is to avoid X propagation completely,
but instead to get the flip-flop to settle to a random
value if setup/hold times are violated. However, it's
tough to get useful results from this sort of thing.

In general, though, there's no substitute for very
careful theoretical analysis of what's happening at
the asynchronous interface. If you can be completely
confident that your resynchroniser behaves correctly in
all possible situations, it's then legitimate to replace
it with an idealised model that doesn't propagate X.
--
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, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail:[email protected]
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.

 

[The Weiss Family]

In general, though, there's no substitute for very

careful theoretical analysis of what's happening at
the asynchronous interface. If you can be completely
confident that your resynchroniser behaves correctly in
all possible situations, it's then legitimate to replace
it with an idealised model that doesn't propagate X.

Today, I just received a memec proto board with the Xilinx chip that I am
using on it.
It turns out that my design works great.
Can you suggest any ways I might stress the sync circuit?
I tried sweeping the frequency of the asynchronous signal throughout its
valid range.
No problems there.
I don't want to miss that one case that will cause the chip to lock up, so
any suggestions are extremely welcome.

thanks,

Adam

 

[Ronald Hecht]

Good practice is to disable timing checks at (and only at!) synchronizer
flops. This can be done with VHDL configuration for example. Here is a
part of an example for Xilinx flops:

library simprim;
use simprim.vcomponents.all;

configuration hdlc_layer_tb_ba_cfg of hdlc_layer_tb is
for beh
for DUT : hdlc_layer
-- ....

-- These dedicated FFs may go metastable by design!
-- Therefore, timing checks must be turned of here selectively!
for STRUCTURE
for
-- FIFO gray pointer synchronizer
hl_tx_fifo_rd_wr_ptr_gray_sync_0_q,
hl_tx_fifo_rd_wr_ptr_gray_sync_1_q,
hl_tx_fifo_rd_wr_ptr_gray_sync_2_q,
hl_tx_fifo_rd_wr_ptr_gray_sync_3_q,
hl_tx_fifo_rd_wr_ptr_gray_sync_4_q,
hl_tx_fifo_rd_wr_ptr_gray_sync_5_q,
hl_tx_fifo_rd_wr_ptr_gray_sync_6_q,
hl_tx_fifo_rd_wr_ptr_gray_sync_7_q,
hl_tx_fifo_rd_wr_ptr_gray_sync_8_q,
hl_tx_fifo_rd_wr_ptr_gray_sync_9_q,
hl_rx_fifo_rd_wr_ptr_gray_sync_0_q,
hl_rx_fifo_rd_wr_ptr_gray_sync_1_q,
hl_rx_fifo_rd_wr_ptr_gray_sync_2_q,
hl_rx_fifo_rd_wr_ptr_gray_sync_3_q,
hl_rx_fifo_rd_wr_ptr_gray_sync_4_q,
hl_rx_fifo_rd_wr_ptr_gray_sync_5_q,
hl_rx_fifo_rd_wr_ptr_gray_sync_6_q,
hl_rx_fifo_rd_wr_ptr_gray_sync_7_q,
hl_rx_fifo_rd_wr_ptr_gray_sync_8_q,
hl_rx_fifo_rd_wr_ptr_gray_sync_9_q,
hl_tx_fifo_wr_rd_ptr_gray_sync_0_q,
hl_tx_fifo_wr_rd_ptr_gray_sync_1_q,
hl_tx_fifo_wr_rd_ptr_gray_sync_2_q,
hl_tx_fifo_wr_rd_ptr_gray_sync_3_q,
hl_tx_fifo_wr_rd_ptr_gray_sync_4_q,
hl_tx_fifo_wr_rd_ptr_gray_sync_5_q,
hl_tx_fifo_wr_rd_ptr_gray_sync_6_q,
hl_tx_fifo_wr_rd_ptr_gray_sync_7_q,
hl_tx_fifo_wr_rd_ptr_gray_sync_8_q,
hl_tx_fifo_wr_rd_ptr_gray_sync_9_q,
hl_rx_fifo_wr_rd_ptr_gray_sync_0_q,
hl_rx_fifo_wr_rd_ptr_gray_sync_1_q,
hl_rx_fifo_wr_rd_ptr_gray_sync_2_q,
hl_rx_fifo_wr_rd_ptr_gray_sync_3_q,
hl_rx_fifo_wr_rd_ptr_gray_sync_4_q,
hl_rx_fifo_wr_rd_ptr_gray_sync_5_q,
hl_rx_fifo_wr_rd_ptr_gray_sync_6_q,
hl_rx_fifo_wr_rd_ptr_gray_sync_7_q,
hl_rx_fifo_wr_rd_ptr_gray_sync_8_q,
hl_rx_fifo_wr_rd_ptr_gray_sync_9_q : X_SFF
use entity simprim.X_SFF(X_SFF_V)
generic map (TimingChecksOn => false);
end for;
end for;
end for;
end for;
end hdlc_layer_tb_ba_cfg;

 

[scary_jeff]

This is the top result for 'vhdl asynchronous inputs' on google, so I thought I would post a solution (I didn't follow the previous post, and the one before that doesn't tell you how to actually turn off X propogation).

In Xilinx ISE (9.1, maybe earlier):

Edit > Language templates > VHDL > Synthesis Constructs > Coding Examples > Misc > Asynchronus Input Synchronization

It uses attributes ASYNC_REG and TIG on the two registers in order to prevent X propogation.