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

 

[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

 

[Jonathan Bromley]

On Wed, 28 Jul 2004 23:26:58 -0700, "The Weiss Family"
<weissfamily97@charter.net> wrote:

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:jonathan.bromley@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.

 

[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;

The Weiss Family wrote:

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