cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Anonymous
Not applicable
7,616 Views

asynchronous input to IDDR

I've got an asynchronous single bit data input signal at 120 Mbps. I'm using an IDDR clocked at 240 MHz to sample on both edges, resulting in 4X oversampling.

 

Since the input data is asynchronous, I don't have any constraints on the signal. The timing analysis doesn't give me any errors, but when I run back annotated simulations, I get setup violations, which result in the IDDR putting out X's. 

 

Any ideas as to how to fix this? I thought of synchronizing the registers myself before the IDDR block, but the IDDR block has to be connected to an input signal.

 

iddr_fail.jpg

0 Kudos
19 Replies
Highlighted
Teacher
Teacher
7,607 Views
Registered: ‎03-31-2012

@Anonymous if you really have an asynchronous signal, ie a signal which has unknown and potentially changing phase to the clock with which you are sampling it, you cannot fix this problem. Other than figuring out what the phase relationship is and adjusting the clock to track the input, that is.

 

Anyway, why are you doing this? If you tell us why you need this circuitry maybe we can come up with a solution.

 

Finally if your problem is just the Xs (which denote the event that the flop doesn't either know which output will come out (which is OK as at an edge near the data change you don't care) or that the flop can go meta-stable (which is bad)) then you can disable the timing entries in IDDR to get around it.

- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.
0 Kudos
Highlighted
Anonymous
Not applicable
7,598 Views

Muzaffer -

Thanks for the response. The design is running cleanly in the lab, but it's a commercial V5 instead of the SIRF flight part. That's not coming in for months, so I thought I'd do some back-annotated sims to get a head start on any potential issues. I think you might have already answered my question--I can't fix this problem without disabling timing checks.

 

Still, I'd definitely appreciate your opinion on the design. The source chip is an Artix, sending a single data signal running off a 60 MHz oscillator and using ODDR to get 120 Mbps. This signal is sent over a cable to another box, where the receiving chip is a V5. I've generated, via PLL, a 240 MHz clock. I use IDDR to grab data on both edges, resulting in 4X oversampling. The data comes in a continuous stream, with a start and stop bit for each eight bits. My receiving logic realigns to the start bit each time, then takes the second of the four sampled bits for the next eight bits. Then it finds the stop bit, and starts over again.

 

If you've got any ideas about how to better use Xilinx tools/technology or general comments about the design, I'd really appreciate hearing them. 

0 Kudos
Highlighted
Guide
Guide
7,595 Views
Registered: ‎01-23-2009

Whenever you sample an asynchronous signal, you will eventually violate the setup/hold of the sampling flip-flop. In timing simulations, the modeled behavior in this case is to set the output of the flip-flop to X.

 

For normal flip-flops, the solution to this is to set the ASYNC_REG property on the flip-flop. This tells the simulation (among other things) that the input signal is asynchronous, and hence suppresses the behavior of it going to X. The ASYNC_REG should always be set on any flip-flop that is part of a metastability reduction chain.

 

However, I am not certain that you can set the ASYNC_REG property on the IDDR - the property isn't documented in the HDL guide. However in the comments of the simulation model there is a reference to "async reg" using the "XON" parameter; looking at the XON parameter, this is, indeed, what we want...

 

So, first try setting the ASYNC_REG property on the IDDR. It may be possible to do in the RTL with an attribute, but since it isn't documented in the RTL guide I would do it through XDC

 

set_property ASYNC_REG [get_cells <hierarchical_instance_name_of_IDDR>]

 

If that doesn't work (and try a couple of variations), then you can try an manipulate the XON property directly using a defparam in your testbench - something like

 

defparam <dut_name>.<hierarchy>....<iddr_instance_name> XON = "FALSE";

 

This being said, you still need to deal with metastability. If you do this on the IDDR, then you need to ensure that you have proper synchronizers on the Q1 and Q2 outputs of the IDDR. You may be able to use the SAME_EDGE_PIPELINED mode to do some of the metastability hardening, but at 240MHz, you may want more than 2 back to back flip-flops...

 

Avrum

 

Highlighted
Teacher
Teacher
7,572 Views
Registered: ‎03-31-2012

@Anonymous I think what you are doing looks quite reasonable, but as @avrumw says metastability still needs to be handled robustly. At 240 MHz, I am not sure if ISERDES registers give you enough protection. Before deploying, I'd do some BER measurements at varying temperatures or figure out a way to add one more stage of registers.

- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.
Highlighted
Anonymous
Not applicable
7,555 Views

Avrum, Muzaffer-

Thanks for your help! Here's what I've done, based on your suggestions:

 

To reiterate, the issue is getting X's in timing sims because of asynchronous inputs to an IDDR instance. 

 

Added to my constraints:

INST "path-to-iddr-inst" ASYNC_REG=TRUE 

Though the assignment was accepted, the SDF file still had timing checks on the instance. Out of curiosity, I checked the SDF file for registers I set to ASYNC_REG in the code, and they still had timing checks as well. So it would seem that the timing checks really do need to be disabled in the simulation. In the Questasim environment, my verification engineer did some digging and found the following:

tcheck_set {path-to-IDDR_2CLK } ON OFF

This keeps the timing checks on and turns off the X's. Anyone who wants to remove timing checks as well can do "OFF OFF".

 

Added to my design:

IBUF -> IDDR -> synchronizing registers -> logic

 

Though this wasn't part of my initial question, this was incredibly useful feedback. I thought metastability would be OK with the IDDR's same edge pipeline, so I definitely appreciated the recommendation to add robustness by synchronizing Q1/Q2. 

 

Thanks again for helping out!

0 Kudos
Highlighted
Guide
Guide
7,536 Views
Registered: ‎01-23-2009

the SDF file still had timing checks on the instance

 

Looking at the SDF file isn't really sufficient. If the ASYNC_REG property is respected, the SDF will still contain setup and hold checks for the flip-flop. However, the mechanism that forces the output to X on setup/hold check failure (through the notifier) is disabled - this is the XON parameter in the simulation model.

 

For a regular flip-flop, the ASYNC_REG property sets the XON parameter to FALSE - I just don't know if the mechanism works for the IDDR.

 

Here is what I see in the post-implementation simulation netlist for a pair of FDCE's with the ASYNC_REG property set. Note that the XON parameter is set to FALSE.

 

  initial assign signal_dst_reg.notifier = 1'bx;
(* ASYNC_REG *)
  (* KEEP = "yes" *)
  FDRE #(
    .INIT(1'b0),
    .XON("FALSE"))
    signal_dst_reg
       (.C(clk_dst),
        .CE(1'b1),
        .D(signal_meta),
        .Q(signal_dst),
        .R(rst_dst));
  initial assign signal_meta_reg.notifier = 1'bx;
(* ASYNC_REG *)
  (* KEEP = "yes" *)
  FDRE #(
    .INIT(1'b0),
    .XON("FALSE"))
    signal_meta_reg
       (.C(clk_dst),
        .CE(1'b1),
        .D(signal_src),
        .Q(signal_meta),
        .R(rst_dst));

 

Avrum

Highlighted
Anonymous
Not applicable
7,486 Views

Avrum -

OK, thanks--I didn't realize where I needed to look. I see that other async registers, which I tagged as ASYNC_REG in the code, show XON as FALSE in the netlist. The IDDR_2CLK instance doesn't have the XON parameter set, so putting it in the constraints didn't work for me.

 

We ran back-annotated tests last night. The tcheck_set command worked to stop the X's on the IDDR signals. So, we've got a working solution. However, if you have any other suggestion on something to try with the constraints file, I can check it out. 

 

Kari

0 Kudos
Highlighted
Guide
Guide
7,471 Views
Registered: ‎01-23-2009

Kari,

 

So, first, I keep forgetting that you said this is a Virtex-5 - therefore, you are using ISE, not Vivado. So my references to the XDC file aren't correct...

 

The ASYNC_REG property would have to be placed either in the UCF file or in the RTL - and, again, I don't know for a fact that the tools (particularly ISE) handle the ASYNC_REG on the IDDR properly.

 

That being said, you are using an IDDR_2CLK. I looked at the simulation model for this primitive, and, surprisingly, this primitive does NOT have the XON parameter in the simulation model. This is almost certainly a bug (it exists in the IDDR, but not the IDDR2_CLK), but will almost certainly not be fixed in ISE (since ISE isn't going to have any more releases). However, the IDDR2_CLK primitive does still exist in 7 series devices under Vivado - so the fact that it doesn't have an XON parameter is still a bug.

 

So, until/unless the bug is fixed, the solution you have through the simulation tool is going to be your best bet (unless you can switch to using a regular IDDR).

 

Avrum

Highlighted
Anonymous
Not applicable
7,466 Views

Avrum -

Even if ISE was going to be updated, I have to use 13.2, so I'd never get the fix, anyway. I'd translated your XDC constraint suggestion into UCF, but as you said, if there's no XON parameter in IDDR_2CLK, it was never going to work.

 

I'm not sure how to switch to using a regular IDDR. I instantiated a regular IDDR, but it chooses an IDDR_2CLK in synth. This might be because I chose "ASYNC" for SRTYPE? This isn't necessary, as I've sync'ed the reset to the clock domain anyway. I'll try it to see if it comes up with another result.

 

Kari

0 Kudos
Highlighted
Guide
Guide
6,955 Views
Registered: ‎01-23-2009

If you instantiated a regular IDDR, it is likely that during the generation of the structural netlist it was converted to the IDDR_2CLK. You probably have no control over this... I don't think it has anything to do with the SRTYPE.

 

Avrum

 

 

0 Kudos
Highlighted
Adventurer
Adventurer
5,407 Views
Registered: ‎01-28-2013

I'm not sure if I need to make a new post? I'm facing a similar issue except I'm sampling at 250MHz DDR a 125MHz DDR signal using IDDR with SAME_EDGE_PIPELINED mode and having meta-stability issues.

 

Avrum, 

With regards to your comment "You may be able to use the SAME_EDGE_PIPELINED mode to do some of the metastability hardening, but at 240MHz, you may want more than 2 back to back flip-flops"

 

Is there a way to add it as a parameter in IDDR to add more to the pipeline or should I manually pipeline the output from Q1 and Q2?

Also if manually pipeline the output from Q1, Q2 then the wrong value is going to be propagated forward?

 

 

0 Kudos
Highlighted
Guide
Guide
5,360 Views
Registered: ‎01-23-2009

Is there a way to add it as a parameter in IDDR to add more to the pipeline or should I manually pipeline the output from Q1 and Q2?

 

The structure of the IDDR only has the 4 flip-flops for implementing the SAME_EDGE_PIPELINED mode. Metastability resolution is not the intended purpose of this structure - it is primarily for sampling synchronous DDR input signals. Using the SAME_EDGE_PIPELINED mode on an asynchronous input signal is a trick to do metastability resolution for SDR signals.

 

But, the metastability resolution time is pretty limited. For the rising edge sample, it provides one clock period of metastability resolution time - this may be enough for slower frequencies. For the falling edge sample of a DDR signal, it only provides 1/2 clock of metastability resolution time, which is rarely enough - hence this isn't really a solution for DDR signals.

 

Also if manually pipeline the output from Q1, Q2 then the wrong value is going to be propagated forward?

 

I don't understand what you are asking here...

 

Avrum

0 Kudos
Highlighted
Adventurer
Adventurer
5,323 Views
Registered: ‎01-28-2013

Ah OK, that explains why I'm having metastability issues on the falling edges only. Now that you mentioned 1/2 clock for the falling edge, it makes sense.

 

I understand what metastability is fundamentally, the value not settling down at the right level. I"m not clear how adding back to back FF's can result in getting the right values. Since essentially adding FF's is queuing.

 

For example, I'm having issues with output from Q1. Let's say I add few FF's in the path Q2, Q4. Now even though Q1 is not having the right settled value, is Q4 going to have the right value. If the value is not settled at Q1 isn't that going to be propagated forward?

 

I like system synchronous designs but I'm learning it is better to use source synchronous design for DDR at high speeds like 125MHz. Looking into some of your other discussions in the forum on this.

 

Thanks

0 Kudos
Highlighted
Guide
Guide
5,307 Views
Registered: ‎01-23-2009

I like system synchronous designs but I'm learning it is better to use source synchronous design for DDR at high speeds like 125MHz. Looking into some of your other discussions in the forum on this.

 

I don't understand why you are talking about source/system synchronous interfaces and metastability hardening at the same time.

 

By definition if you are worrying about metastability, the "interface" is asynchronous - the original thread here was about simulating an over-sampled asynchronous "interface". And when dealing with an asynchronous "interface", there are far bigger problems to deal with than just the metastability - some sophisticated mechanism is required to deal with bus correlation if the "interface" is more than one bit wide.

 

I use the word "interface" in quotes, since interfaces are usually a correlated collection of signals. For them to be correlated, they need to be synchronous to each other, and usually this means they are synchronous to a clock. A system synchronous or source synchronous interface is (tightly) correlated to a clock. The whole point of this is to synchronously capture the data of the interface using the correlated clock (or a clock derived from that correlated clock). If you do this, then there is no need to worry about metastability; the signals are synchronously sampled...

 

So what is it that you are trying to do?

 

Avrum

0 Kudos
Highlighted
Adventurer
Adventurer
5,298 Views
Registered: ‎01-28-2013

 

I'm used to sampling source synchronous interfaces with speeds of 25/ 50MHz using IDDR at much higher sampling frequency usually 4 times the clock speed in my previous designs with edge detection logic. So I thought I'll try the same at 100MHz/ 125MHz but didn't step up the clock too high and tried out with 250MHz only to learn it is not possible to do that.

 

I'm designing a HDL to handle RGMII signals and also for a similar custom interface but 8 bits at 100MHz DDR. That's why I got into this thread.

 

 

But looks like source synchronous design is the best way to handle this.

0 Kudos
Highlighted
Teacher
Teacher
5,265 Views
Registered: ‎03-31-2012

@tn45eng

 

>> I understand what metastability is fundamentally, the value not settling down at the right level.

 

This is not strictly true. At the point of metastability, there is actually no "right level" as by definition the signal is changing so close to the clock that it is difficult to make a choice. Either answer (high or low) is acceptable. Metastability means the circuit can't make up its mind and it is possible (although highly unlikely) that it can go into oscillation indefinitely.

 

>> I"m not clear how adding back to back FF's can result in getting the right values. Since essentially adding FF's is queuing.

 

You are not necessarily getting the "right value" but just "some value" by giving the previous flop time to settle. If the likelihood of one flop to go meta is p, every flop you add gives you another p multiplier ie a second one p^2, a third one p^3 etc. (this is a simplified but representative view).

- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.
0 Kudos
Highlighted
Guide
Guide
5,258 Views
Registered: ‎01-23-2009

As @muzaffer said, metastability occurs when you sample a signal too close to when it is changing. Since the signal is changing, it is no more correct to sample it as a 0 or a 1.

 

Whenever you sample an asynchronous signal, metastability is a possibility - in fact, it is a certainty given enough transitions.

 

So, given that the signal was changing around the sample time, and it is no more correct to "decide" this is a 0 or a 1, what is the purpose of a metastability resolution (or reduction) circuit (i.e. back to back flip-flops)?

 

Since a metastable signal is neither a 0 nor a 1, the behavior of a gate or flip-flop using that metastable signal is unknown. It may (effectively) treat the metastable input as a 0, as a 1, or as neither and can itself go metastable. All of this is unavoidable.

 

The real problem with metastable signals is that different receivers of a metastable signal can do different things. Take the example of a state machine that is in the 00 state. Assume that when it sees the incoming signal (after a single synchronization FF) as a 0 it will remain in this state, but when it sees it as a 1 it should go to the 11 state. If the flip-flop sampling the asynchronous input samples it around the changing point, then it would be equally acceptable for the state machine to remain in the 00 state or transition to the 11 state.

 

However, if the flip-flop sampling the asynchronous input goes metastable, this metastable signal feeds to the input logic generating the "next_state". This is really two cones of logic; one for generating the next state for bit 0 of the state machine and one for bit 1. Since the synchronized input is metastable, one of the cones may interpret the metastable signal as a 1, and the other as a 0. In this case, the state machine will transition into the 10 state. This is a system failure; remaining in the 00 state would have been legal, as would transitioning to the 11 state, but the 10 state is not an acceptable state in this situation, so the system has failed.

 

Metastability will resolve (probabilistically) with time. By putting a second FF back to back with the first FF in the synchronizer, if the first FF goes metastable, there is a probability that the metastability will have resolved by the time the second FF samples it - 1 clock cycle later. This is the basis of the 2 stage (or more stage) synchronizer. Furthermore, even if the metastable first stage has not yet settled, the second stage may

  - see it as a 0 (which is OK)

  - see it as a 1 (which is OK)

  - or go metastable (which isn't OK)

 

In the first two cases, the system will not fail. This is the case because there is only one receiver of the potentially metastable signal - we do not create the possibility of two different receivers interpreting the metastable signal differently.

 

Avrum

0 Kudos
Highlighted
Adventurer
Adventurer
5,244 Views
Registered: ‎01-28-2013

Thanks muzaffer and avrumw, for clarifying the different possibilities with asynchronous input. Adding synchronization flip flops makes sense from metastability point of view.

 

So if the synchronizing flip flops are for only to prevent the metastability of the flip flop themselves then what can we do to guarantee the right logic level? I have used FIFO IPs for CDC but now I"m wondering how these work?

 

" Furthermore, even if the metastable first stage has not yet settled, the second stage may

  - see it as a 0 (which is OK)

  - see it as a 1 (which is OK) "

 

This is not OK in the sense that I'm expecting it to have the right level. How to handle this?

0 Kudos
Highlighted
Guide
Guide
5,234 Views
Registered: ‎01-23-2009

This is not OK in the sense that I'm expecting it to have the right level. How to handle this?

 

By definition, there is no right level. If metastability occurred, you sampled the signal as it was transitioning - it was changing from a 0 to a 1. If you sampled it 1ps earlier then it would have given you the old value, 1ps later it would have given you the new value. Neither is correct or incorrect. Between these two is the point of metastability, where it can be sampled as a 0, a 1, or go metastable.

 

A clock crossing FIFO still has an inherent uncertainty about it, since, internally, it also has to do clock crossing. The clock crossing for a FIFO is in the generation of the FULL and EMPTY flags (not the data). The net result of this is that (for example) the exact delay from the WRITE on the wr_clk side to the deassertion of the EMPTY on the rd_clk side is not entirely predictable. Depending on the exact phase relationship of the wr_clk and rd_clk, the delay will be something like N*wr_clk + (M to M+1)*rd_clk (where N and M are determined by the structure of the synchronizer). In a FIFO, you don't care if it is M or M+1 as long as it is not metastable.

 

Avrum

 

 

Tags (1)
0 Kudos