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: 
Scholar mistercoffee
Scholar
835 Views
Registered: ‎04-04-2014

Do I need IOB constraint?

Jump to solution

Hi,

I have a timing input (from a GPS..) on and IO pin that I clock into a couple of global clock domains in my fabric. I would like make sure that the timing coming off the IO pin is repeatable to deliver consistent timing and repeatable behaviour between builds.

So, I could specify the LOC for the first FF, then after that the timing analyser will make sure everything is in order.

Would it be better to place that first register (or two) in the IOB? this has the advantage of:

- Delay from IO pin to the first clocked FF would be v small

- Forcing a LOC on these won't impact place and route for the rest of the design becauses its away form the fabric.

 

I have just tried doing this but not sure it worked. I have two chained FDPE, with the IO signal going to the PRE and the Q from the first FF to the D of the second. I clocked them both with a BUFR derived from the BUFG of the domains I want them to drive. I wasn't sure if the BUFG clock could drive IOB FF... The idea is that this creates at least a one cycle pulse from what could be a shorter asynchronous pulse on the input.

So I placed the IOB attribute on the signals on the Q of both these FDPE. Synthesis picks up the attribute, doesn't complain. Implementation makes no reference to the IOB attribute, or the BUFRs, but removes the BUFRs and drives the FDPE with the BUFG instead,as if not needed but didn't tell me. Then the two FDPE don't seem to be placed in IOB, they're just in a slice in the same clock region

Whats going on?

Thanks

0 Kudos
1 Solution

Accepted Solutions
818 Views
Registered: ‎01-22-2015

Re: Do I need IOB constraint?

Jump to solution

@mistercoffee

     Would it be better to place that first register (or two) in the IOB?
I will assume that the “timing input (from a GPS..)” is asynchronous with any clocks in your design.  So, you must bring this signal into the FPGA through a synchronizer.  A 2-flip-flop (2FF) synchronizer should work fine and you are correct to think that registers for the 2FF should be placed in the IOB to “make sure that the timing coming off the IO pin is repeatable”. 

One of the problems you are facing is that you can *normally* pack only one register into the IOB.  So, if you need a synchronizer then you *normally* need to place the synchronizer in the fabric – because that is *normally* the only place where you can ensure that registers in the synchronizer are held physically close to each other (a condition for proper operation of the synchronizer).

Long story short, you can use a trick from Avrum that he calls the “perfect (2FF) synchronizer”, which is to use the IDDR in the special way described <here>.

Avrum’s “perfect synchronizer” is:

  • Already locked into the IOB near the FPGA pin that brings in your GPS timing signal (because that’s where the IDDR is located)
  • Does not require you to write an ASYNC_REG=TRUE constraint for the registers. For a 2FF located in the FPGA fabric, setting ASYNC_REG=TRUE is necessary to hold the registers physically close to each other and to make the 2FF work properly.  However, for the “perfect synchronizer” the two registers in the IDDR are already locked next to each other.

Any of the global clocks in your design can be used to clock the registers of the IDDR "perfect synchronizer".

Cheers,
Mark

0 Kudos
10 Replies
819 Views
Registered: ‎01-22-2015

Re: Do I need IOB constraint?

Jump to solution

@mistercoffee

     Would it be better to place that first register (or two) in the IOB?
I will assume that the “timing input (from a GPS..)” is asynchronous with any clocks in your design.  So, you must bring this signal into the FPGA through a synchronizer.  A 2-flip-flop (2FF) synchronizer should work fine and you are correct to think that registers for the 2FF should be placed in the IOB to “make sure that the timing coming off the IO pin is repeatable”. 

One of the problems you are facing is that you can *normally* pack only one register into the IOB.  So, if you need a synchronizer then you *normally* need to place the synchronizer in the fabric – because that is *normally* the only place where you can ensure that registers in the synchronizer are held physically close to each other (a condition for proper operation of the synchronizer).

Long story short, you can use a trick from Avrum that he calls the “perfect (2FF) synchronizer”, which is to use the IDDR in the special way described <here>.

Avrum’s “perfect synchronizer” is:

  • Already locked into the IOB near the FPGA pin that brings in your GPS timing signal (because that’s where the IDDR is located)
  • Does not require you to write an ASYNC_REG=TRUE constraint for the registers. For a 2FF located in the FPGA fabric, setting ASYNC_REG=TRUE is necessary to hold the registers physically close to each other and to make the 2FF work properly.  However, for the “perfect synchronizer” the two registers in the IDDR are already locked next to each other.

Any of the global clocks in your design can be used to clock the registers of the IDDR "perfect synchronizer".

Cheers,
Mark

0 Kudos
Scholar mistercoffee
Scholar
807 Views
Registered: ‎04-04-2014

Re: Do I need IOB constraint?

Jump to solution

Thanks so much for that.

You're right in that we need to treat the input GPS as asynchronous so yes I was planning on putting 2FF in the IOB, I asn't aware of the limitations. I am generally sturggling to find info about the IO banks and how to use them, nothing I've read has been very enlightening.

I'll giver Avrums suggestion a go.

Thanks

0 Kudos
Scholar mistercoffee
Scholar
793 Views
Registered: ‎04-04-2014

Re: Do I need IOB constraint?

Jump to solution

There is a slight problem with this solution with my particular situation. I am trying to sync the asynchronous GPS input intop two global clock domains (I have two separate clocked data "channels" that use it).


So, I tried the IDDR but then it complains that I am trying to pack and drive two IDDRs at once, which is doens't like. Not sure if I can use it. In hindsight, I could have routed (on the PCB) two GPS tracks to feed a different input and therefore treat them separately. 

 

0 Kudos
781 Views
Registered: ‎01-22-2015

Re: Do I need IOB constraint?

Jump to solution

     I am trying to sync the asynchronous GPS input intop two global clock domains...
As you say, having a separate GPS-input for each clock domain would have been best. However, with only one GPS-input, I recommend that you use the IDDR synchronizer to bring it into the domain of your fast-clock, CLKF. Then, cross the GPS-input from the CLKF-domain into the domain of your slow-clock, CLKS. A synchronous crossing between CLKF and CLKS domains might be possible if both clocks come from the same clock management tile (eg. MMCM). When you try this synchronous crossing, Vivado timing analysis will tell you if it is possible. If the synchronous crossing is not possible, then you must create/use a 2FF synchronizer in the fabric to make the crossing safe (metastable-free).

Since the GPS-input is asynchronous with the CLKF used on the IDDR, you will not know exactly when edges of the GPS-input arrive. That is, the edge arrival time uncertainty will be 1 period of CLKF. So, using your short-period (ie. fast-clock) CLKF on the IDDR will reduce uncertainty of the GPS-input arrival time into your FPGA. If you must use another 2FF synchronizer to pass the GPS-input from your CLKF to CLKS domains, then this second 2FF will add (in root-sum-squares sense) extra uncertainty (1 period of CLKS) to the GPS-input arrival time into the CLKS domain.

Mark

0 Kudos
Scholar mistercoffee
Scholar
776 Views
Registered: ‎04-04-2014

Re: Do I need IOB constraint?

Jump to solution

Thanks for your reply. There is a also a bit of an issue with your proposal. The two clock domains I want to sync to, although they are the same rate, are not free running in the system and it is possible either one may start first. So I can't really use one to sync first.

There is a free running clock, clocking a GTX, but it's slower than both the other domains. I could generate an even faster clock from that I suppose, and then CDC into the other two domains. it's a bit messy though isn't it? Also, I want the delay between the domains to be consistent too, which I don't think will happen (see below).

So, I just tried two separate 2FF syncs in the fabric. I don't mind if there is a bit of a longer delay but I really want the delay to be repeatable between builds.

I have a test project with just this module in with some MMCMs. Very very small just to try out ideas. I have the the asynchronous input going to the rst pins of two chains of two FPDEs (one for each clock domain).

Here was my plan:

- add a large a set_max_delay

- Sucessively reduce the constraint until the first FF is as close as poss to the input pin

- constrain the location for that FF so that it is repeatable.

However, despite the design being very small and the input pin and FF are placed very close to each other, vivado has done a crazy routing of around 7ns and it totally fails even my most relaxed constraint.

So, it's not that I can't place the FF close the IO Pin. It's not that the design is congested. It's just vivado doing crap routing. 

How on earth do I make this design low delay AND repeatable? Even if I constrain the FF my larger project that will contain this module will surely apply a completely different route each time. Set max delay isn't working.

Surely locking the route isn't the best option?

0 Kudos
Scholar mistercoffee
Scholar
770 Views
Registered: ‎04-04-2014

Re: Do I need IOB constraint?

Jump to solution

Ok, I just managed to get Vivado do a good short delay route. I changed my set_max_delay constraint to apply from the IBUFDS output pin, rather than before when I set it to time from the actual input port (the other side of the IBUFDS). Now the routing is good...

 

 

0 Kudos
Scholar mistercoffee
Scholar
756 Views
Registered: ‎04-04-2014

Re: Do I need IOB constraint?

Jump to solution

Ok  this is getting frustrating. A thte moment I have two approaches to setting the input path set_max_delay:

1. Set Max Delay from the input port to the first FF pin. This always fails timing as it does a craxy high delay route, despite the FF being near to the input.

2. Set Max Delay from the output pin of the IBUFDS to the first FF pin. This generates a good short delay track as I want. However because the IBUFDS output pin is not a valid start point for set_max_delay, I get a critical warning about path segmentation.

So, what do I do?

0 Kudos
742 Views
Registered: ‎01-22-2015

Re: Do I need IOB constraint?

Jump to solution

@mistercoffee

     Ok  this is getting frustrating.
Hang in there!  You're soooo close.

     So, I just tried two separate 2FF syncs in the fabric. I don't mind if there is a bit of
     a longer delay but I really want the delay to be repeatable between builds. 
OK.  This can be done!

     Here was my plan:
        - add a large a set_max_delay
        - Sucessively reduce the constraint until the first FF is as close as poss to the input pin
Good plan.  It will work! 

As you did, I made a simple Vivado project for a Kintex-7 to work out the details.  Here’s the schematic for my project.  One 2FF is composed of the registers (meta_2ffa and out_2ffa).  The other 2FF is composed of the registers (meta_2ffb and out_2ffb).  CLK2GEN is an MMCM.
schem_2ff.jpg

Here’s the Vivado Device window showing the end result.  Note that the synchronizer register pairs are packed into the same slice and are located near the GPS_IN pin.
device_2ff.jpg

Here’s the XDC constraints I used:

set_input_delay -clock [get_clocks <one of your clocks>] <delay1> [get_ports GPS_IN]
set_max_delay -datapath_only -from [get_ports GPS_IN] -to [get_cells meta_2ffa_reg] <delay2>
set_max_delay -datapath_only -from [get_ports GPS_IN] -to [get_cells meta_2ffb_reg] <delay3>
set_property ASYNC_REG TRUE [get_cells meta_2ffa_reg]
set_property ASYNC_REG TRUE [get_cells meta_2ffb_reg]
set_property ASYNC_REG TRUE [get_cells out_2ffa_reg]
set_property ASYNC_REG TRUE [get_cells out_2ffb_reg]

The approach is to fiddle with the delays that I called <delay1>, <delay2>, and <delay3>,  making them smaller and smaller until the design just passes timing analysis (just as you planned).  Be sure to use -datapath_only with the set_max_delay constraints. 

Mark

 

 

 

 

 

0 Kudos
Scholar mistercoffee
Scholar
728 Views
Registered: ‎04-04-2014

Re: Do I need IOB constraint?

Jump to solution

ok thans Mark, I will try this at work on Monday. It is close to what I was doing. I hadn't used the set_input_delay quite as you had and I was going in on the PRE pin of the FFs asynchronously, instead of D, as I didn't want to assume the pulse I want to capture was wider than my clock.

I'll let you know...

Thanks

0 Kudos
Scholar mistercoffee
Scholar
682 Views
Registered: ‎04-04-2014

Re: Do I need IOB constraint?

Jump to solution

Hi,

 

Yes, I can confirm the above works just fine with my design. I had issues with another constraint conflicting with these but it is now sorted.

Thanks for your help

 

0 Kudos