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: 
Observer adrianf0
Observer
5,774 Views
Registered: ‎01-25-2013

constrain delay time bondary of asynchronous latch signal

Hello,

I am implementing a simple TDC in FPGA.

I am have a asynchronous trigger witch latches my coarse and fine timestamps --- it is connected to few clock inputs of the FFs. It is crucial, that all values are latched with in a certain time range (resolution of my simple TDC), thus I would like to define boundaries in which this trigger signal should reach all clock inputs of the involved FFs.

How to do it properly ?

 

So far I have defined the asynchronous trigger as an asynchronous clock with a period corresponding to the maximum trigger rate. I also defined set_max_delay and set_min_delay in order to define delay time boundaries. The problem is that tool tries to meet also hold time, which, according to my understanding, is irrelevant in this case.

Thus it became iterative problem where having constraints:

set TDC_PATH_MIN 12.7
set TDC_PATH_MAX [expr {$TDC_PATH_MIN + $TDC_PRECISION}] 
set_max_delay -from [get_clocks TDC_In] -to [get_pins FPGA0/TDC0/u0.TDC_Stamp/STAMP*/C] $TDC_PATH_MAX
set_min_delay -from [get_clocks TDC_In] -to [get_pins FPGA0/TDC0/u0.TDC_Stamp/STAMP*/C] $TDC_PATH_MIN

after each implementation (with failed timing) I checked the obtained delay, I apply it as a new TDC_PATH_MIN and re-run the synthesis. However, so far, I haven't managed to close the timing.

0 Kudos
7 Replies
Moderator
Moderator
5,767 Views
Registered: ‎01-16-2013

Re: constrain delay time bondary of asynchronous latch signal

Hi,

so as per my understanding the async LATCH is driving the FF's clock pin, this looks incorrect as per FPGA clocking topology. Is it possible to share the schematic of your design?

Regarding the constraint as you are trying to only providing min delay tool is calculating it for hold. In case if you want only setup calculation then there is no need of min delay and the max delay should be used with -datapath_only keyword.

When you set set_max_delay -datapath_only tool analyze setup as per requirement keeping hold as false path and no analysis will be performed.

Still I would like to check for the schematic, if you are willing to share.

Thanks,
Yash
0 Kudos
Observer adrianf0
Observer
5,759 Views
Registered: ‎01-25-2013

Re: constrain delay time bondary of asynchronous latch signal

No, it's not a latch driving FF's clock pin, but external signal itself:

TDC.png

I want to be sure that delay of TDC_In to all those registers differs less than resolution of my simple TDC. Thus I need max and min delays. Moreover, it seems to me to be more clock path than data path.

0 Kudos
Guide avrumw
Guide
5,744 Views
Registered: ‎01-23-2009

Re: constrain delay time bondary of asynchronous latch signal

The problem is that tool tries to meet also hold time, which, according to my understanding, is irrelevant in this case.

 

No, it's not...

 

All timing analysis in SDC/XDC is path based. By using the set_max_delay as you have done here, you are specifying the timing requirements on a path. You are saying

  - set_max_delay - the path can be no longer than this - this is a setup check

  - set_min_delay - the path must be at least this long - this is a hold check

 

Static timing analysis in Vivado is done at both timing corners - both the setup and hold check are done at both timing corners (resulting in 4 checks [well really 8, but the other set of 4 aren't important for this discussion]).

 

So, almost certainly what you are seeing is the worst slack on the setup check at one timing corner and the worst hold slack on the path at the other timing corner. You can see this in the analysis under "Path Type" - it will say "Min at Fast Process Corner" and "Max at Slow Process Corner" (or vice versa).

 

The difference in propagation delay of a cell between slow and fast timing corner is around 3:1 - so unless your TDC_PRECISION Is huge (like 2x the size of TDC_PATH_MIN), then these constraints will be impossible to meet.

 

Now, if all you care about is skew, then it doesn't make sense to do this analysis at both timing corners. So you will have to force it to do the analysis at the same timing corner - this isn't particularly easy to do...

 

To change the timing corners used, you can use the "config_timing_corners" command. So, for example, to do the analysis at slow process corner you would use

 

    config_timing_corners -corner Slow -delay_type max

    config_timing_corners -corner Slow -delay_type min

 

(then you can do your timing analysis to determine the skew on these paths)

 

BUT... These commands are global - they affect all paths. So, this will basically render all other setup/hold analyses (particularly hold analysis) within the design useless - this is not a sufficiently pessimistic set of timing corners for proper analysis of a synchronous circuit.

 

Now on to your actual problem. What you are trying to do is "not recommended". In FPGAs, the clocks should always use dedicated clock resources - which means a clock capable I/O, no fabric resources (like your OR gate), possibly an MMCM/PLL, a clock buffer (BUFG, BUFH, BUFR, BUFIO) and the dedicated clock network driven by the clock buffer. Trying to do what you are doing here forces the clock into general fabric routing, which will make it slow, have lots of skew, and unpredictable from run to run (although the constraints may help).

 

In general, it is important to note that FPGAs are designed to implement synchronous designs efficiently and effectively. TDCs, by definition, are not synchronous designs. So, as you are starting to find out, by trying to use these tools and devices (that are designed for synchronous circuits) for TDCs, you will constantly be fighting the tools - they just are not meant to do what you are trying to do...

 

Avrum

0 Kudos
Observer adrianf0
Observer
5,727 Views
Registered: ‎01-25-2013

Re: constrain delay time bondary of asynchronous latch signal

@avrumw thank you for your verbose reply.

 

So I underestimated, there is no way to express my requirements in a XDC file in order to guide synthesis/implementation. I would probably need to fix a location of those registers and place them each other such the TDC_In skew is minimized or you have some other ideas ?

0 Kudos
Guide avrumw
Guide
5,711 Views
Registered: ‎01-23-2009

Re: constrain delay time bondary of asynchronous latch signal

I would probably need to fix a location of those registers and place them each other such the TDC_In skew is minimized or you have some other ideas ?

 

I can't really advise you - as I mentioned, trying to do TDC in an FPGA is not an intended use for the FPGAs.

 

You might be able to manage something with the constraints by disabling the multi-corner analysis (as I showed in the previous post), but that might/can "break" all the normal logic in your design.

 

But knowing about the multi-corner analysis, you might be able to find a combination of max and min that ends up constraining the path to have little skew. Knowing that the variation across process/voltage/temperature (PVT - i.e. the process corners) is about 3:1 if you set your min and max such that the max is approximately 3 times the min and then successively tweaking the numbers until the setup and hold both JUST pass (with no or little margin). By doing this, you will end up forcing the tool to balance the insertion delay to all points (at least to as well as it can). You can then disable the multi-corner analysis and do timing analysis to determine if the skew is less than your desired skew. If it is, then great. If it isn't then there is a good possibility that what you are asking for is simply architecturally impossible in the FPGA.

 

Fixing the placement of the receivers is not enough - you would probably need to fix the routes as well (create "DIRT" strings) - this is a very intensive process.

 

Again, this is not what the architecture is designed to do. Clocks are supposed to be on global clock networks which ensures the clock skew due to the fact that the dedicated clock networks are pre-routed; they don't rely on fabric routing (and hence are not controlled via constraints).

 

Avrum

Tags (1)
Teacher muzaffer
Teacher
5,707 Views
Registered: ‎03-31-2012

Re: constrain delay time bondary of asynchronous latch signal

@avrum
>> I can't really advise you - as I mentioned, trying to do TDC in an FPGA is not an intended use for the FPGAs.

Be that as it may, lots of people have implemented TDCs in FPGA with great success. So it's certainly doable and it works well.

 

Another comment would be that any decent TDC should be calibrated against PVT, periodically, so meeting timing for some paths globally is not necessary (nor possible as you say). The design has to be done with a structural netlist, with manual placement options and even potentially with manual routing options. This is not a trivial flow.

- 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
Explorer
Explorer
5,000 Views
Registered: ‎02-13-2012

Re: constrain delay time bondary of asynchronous latch signal

NOTE, without knowing which FPGA family, the following comments/advice may or may not be applicable.

 

What is the purpose of the OR gate?  If you are using it to:

- enable/disable the clock, then look at using a BUFGCE (or similar).

- start/stop the TDC, then adding CE inputs to the FFs will do the same thing.

- to choose between different clock sources, a BUFGMUX is a better solution.

 

The important thing here, as others have mentioned in various ways, is to route the clock signal on the clocking fabric and not the general fabric.  Removing the OR gate from the clock signal and replacing it's functional with your FPGA's appropriate solution is essential.

0 Kudos