UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
4,327 Views
Registered: ‎01-22-2015

IOB Register and Synchronizer

Jump to solution

As described in <this post>, it is sometimes necessary to place a synchronizer near the FPGA port where an asynchronous signal enters the FPGA.  However, the IOB associated with 7-series FPGA ports has only one register – and synchronizers require two or more registers.  So, two questions:

 

Should I try to use the IOB register as part of the synchronizer – or for any other reason?

 

How do I write constraints that cause the synchronizer to be placed near the FPGA port?

0 Kudos
1 Solution

Accepted Solutions
Historian
Historian
7,649 Views
Registered: ‎01-23-2009

Re: IOB Register and Synchronizer

Jump to solution

However, the IOB associated with 7-series FPGA ports has only one register

 

That's actually not true... (sneaky trick!)

 

The IOB flip-flop doesn't really exist - it is actually part of the IDDR. The "basic" IDDR (in mode OPPOSITE_EDGE") has two flip-flops, one to capture the rising edge data (Q1 on rising edge clock) and one to capture the falling edge data (Q2 on falling edge data). But it also has other modes, which add more flip-flops. If you put it in "SAME_EDGE" mode, it adds a second rising edge flip-flop on the Q2 output to delay the falling edge data to the next rising edge. The last mode, "SAME_EDGE_PIPELINED" adds a second rising edge flip-flop to the Q1 output, keeping the latency of the Q1 and Q2 outputs the same.

 

So, in the end, if you hand instantiate an IDDR (instead of inferring a flip-flop) and place it in "SAME_EDGE_PIPELINED" mode, then you get two back to back flip-flops inside the IOB - the perfect synchronizer! (assuming the clock is slow enough that 2 FFs is sufficient).

 

You don't even need any constraints on this - the two FFs are hard placed in the IOB, so you don't even (technically) need the ASYNC_REG property on them (although if you should anyway - they are necessary if you plan to do back-annotated simulations) - you can take a look at this thread on simulating IDDRs with asynchronous inputs...

 

If you need more flip-flops, one choice would be to put the extra ones in the fabric. But the path from an IOB FF to a fabric FF is longer than between two fabric FFs. In this case, you may want to do the opposite - use no flip-flops in the IOBs and put all the synchronizing flip-flops (with ASYNC_REG) in the fabric.

 

If you do place it in the fabric, you can put a set_max_delay -datapath_only on the path from the input port to the first capture flip-flop - this will limit the delay to the first FF. You may need to put a (meaningless) set_input_delay on the port first (which will be overridden by the set_max_delay -datapath_only).

 

Avrum

Tags (1)
4 Replies
Historian
Historian
7,650 Views
Registered: ‎01-23-2009

Re: IOB Register and Synchronizer

Jump to solution

However, the IOB associated with 7-series FPGA ports has only one register

 

That's actually not true... (sneaky trick!)

 

The IOB flip-flop doesn't really exist - it is actually part of the IDDR. The "basic" IDDR (in mode OPPOSITE_EDGE") has two flip-flops, one to capture the rising edge data (Q1 on rising edge clock) and one to capture the falling edge data (Q2 on falling edge data). But it also has other modes, which add more flip-flops. If you put it in "SAME_EDGE" mode, it adds a second rising edge flip-flop on the Q2 output to delay the falling edge data to the next rising edge. The last mode, "SAME_EDGE_PIPELINED" adds a second rising edge flip-flop to the Q1 output, keeping the latency of the Q1 and Q2 outputs the same.

 

So, in the end, if you hand instantiate an IDDR (instead of inferring a flip-flop) and place it in "SAME_EDGE_PIPELINED" mode, then you get two back to back flip-flops inside the IOB - the perfect synchronizer! (assuming the clock is slow enough that 2 FFs is sufficient).

 

You don't even need any constraints on this - the two FFs are hard placed in the IOB, so you don't even (technically) need the ASYNC_REG property on them (although if you should anyway - they are necessary if you plan to do back-annotated simulations) - you can take a look at this thread on simulating IDDRs with asynchronous inputs...

 

If you need more flip-flops, one choice would be to put the extra ones in the fabric. But the path from an IOB FF to a fabric FF is longer than between two fabric FFs. In this case, you may want to do the opposite - use no flip-flops in the IOBs and put all the synchronizing flip-flops (with ASYNC_REG) in the fabric.

 

If you do place it in the fabric, you can put a set_max_delay -datapath_only on the path from the input port to the first capture flip-flop - this will limit the delay to the first FF. You may need to put a (meaningless) set_input_delay on the port first (which will be overridden by the set_max_delay -datapath_only).

 

Avrum

Tags (1)
Highlighted
4,276 Views
Registered: ‎01-22-2015

Re: IOB Register and Synchronizer

Jump to solution

Avrum -  Thanks for very cool and very clear answer!  With this sneaky knowledge about the IDDR/synchronizer, I feel that I am part of a secret society.

 

With regards to placing the synchronizer in the FPGA fabric:

 

You may need to put a (meaningless) set_input_delay on the port first (which will be overridden by the set_max_delay -datapath_only).

 

In Vivado 2016.1, I can confirm that the “(meaningless) set_input_delay” is needed for the “set_max_delay -datapath_only” to have an effect. I recall now that set_input_delay completes the description for a path that extends outside the FPGA.  Then, set_max_delay constrains the delay of this path.    FYI – I simply fiddled with the time parameter for set_max_delay until this path just passed timing analysis – resulting in the synchronizer being placed near the FPGA port (just as you said).

 

Again, many thanks!!

0 Kudos
Visitor harshan
Visitor
2,765 Views
Registered: ‎08-03-2017

Re: IOB Register and Synchronizer

Jump to solution
Even if the IDDR is configured in "SAME_EDGE_PIPELINED" mode, the asynchronous input from the IOB will be sampled twice consecutively first on the falling edge, next on the rising edge. Both the sampled values will be given out of the IDDR on the rising edge. As the time between the 2 consecutive samplings is half the clock period, the effectiveness of the double flop synchronizer has been reduced here.
So, isn't it better not to use IDDR for input signal synchronization??
Correct me if I am wrong.

Thanks,
Harshan
0 Kudos
2,747 Views
Registered: ‎01-22-2015

Re: IOB Register and Synchronizer

Jump to solution

hi harshan – welcome to the Xilinx Forum!

 

Usually you’ll get a quicker and better response to your question if you start a new post, rather than adding onto old posts. -but, no worries. 

 

       So, isn't it better not to use IDDR for input signal synchronization??

 

Well, if you only want a 2-flop synchronizer then (as Avrum says) the IDDR is perfectly setup to provide this.  If you need more flops in your synchronizer (eg. 3-flop synchronizer), then you should not use the IDDR and instead build the synchronizer using registers found in the FPGA fabric. 

 

Below is an old image for the inner workings of the IDDR that I got from Xilinx UG070 (v01Dec2008). When you configure the IDDR to operate in "SAME_EDGE_PIPELINED" mode then the upper two flops operate like a 2-flop synchronizer (just as Avrum says). So, you can use only the Q1-output of the IDDR to get a synchronized version of the D-input to the IDDR.

IDDR_A.jpg