cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Explorer
Explorer
8,067 Views
Registered: ‎08-23-2011

reg: TIG/multi-cycle path, timing constraints ...

hi,

i had been working on timing closure for the first time and i had posted a bunch of questions on the forums. i got
quite a few clarifications (thanks :)) but i had some more NEW queries/doubts regarding the overall approach ...

 

as before, in my design, im doing a CDC from 20M to 110M (both clocks generated by the same PLL), i/p clk to PLL
is constrained in UCF. i got a lot of timing violation on the 20M to 110M CDC path so i used TIG from 20M clk to 110M clk to get rid of the violations, as shown in this xilinx answer - http://www.xilinx.com/support/answers/34348.htm

 

my queries/doubts -

 

1) while doing timing closure on clock domain crossing paths, which is the CORRECT constraint to use - false path (TIG) or multi-cycle path? any other constraint that could be used?

 

2) is it even ACCEPTABLE to do TIG on CDC paths (or any other paths) that fail? i mean - we're telling the tool to IGNORE these paths, which actually give timing issues. so is this even correct?

 

3) if we do use TIG on some CDC path (or any other path) and the tool ignores analyzing this path, could it mean that
even though the xilinx timing report/implementation is clean, on the actual FPGA, there could be a chance that this path may not work correctly because it was not analyzed by the tool?

 

4) another option, given in xilinx answers, is to constrain the PLL o/p yourself in ucf file rather than letting the tool do auto-constraining. so between TIG/multi-cylce and constraining the PLL o/p paths manually, which is the most "correct or preferred" approach for removing CDC violations? does it depend on whichever helps in getting a clean design summary/timing report?

 

5) the syntax for multi-cycle path is - TIMESPEC TS_clk1_to_clk2 = FROM clk1 TO clk2 <delay> ns;
how does one calculate this <delay> (assuming clk1 is 20M and clk2 is 110M)?

 

6) suppose i have some paths in my design that are not valid every clk cycle (such as non periodic register writes and/or reset paths), which show up in timing violation. what constraints should one use for them? TIG/multi-cycle or something else?

 

7) i also understand that IO placement can effect timing. any doc that i can be pointed to which tells some thumb rules for good i/o placement? i did google but could not find something very explanatory ...

 

apologies in case i've repeated some of my questions but i feel the proper constraint/usage still eludes me :)

 

thanks in advance for your inputs ...

 

z. 

0 Kudos
Reply
6 Replies
Highlighted
Instructor
Instructor
8,056 Views
Registered: ‎07-21-2009

Do you have CDC logic to ensure that the 20M data will meet setup and hold time to the 110M clock domain?  If yes, then TIG is justified.  The phase relationship between the 20M clock and the 110M clock is constantly varying (although you can do the math and figure out the worst case phase offset at any given clock edge).

 

EDIT:  while the phase relationship between the two clocks is variable, it is not continuously variable -- it is cyclically variable in discrete steps.  You may be able to convince yourself that (with properly constrained interconnect delay between the two domains) that the domain crossing cannot fail.  Anyone care to check me on this?

 

-- Bob Elkind

SIGNATURE:
README for newbies is here: http://forums.xilinx.com/t5/New-Users-Forum/README-first-Help-for-new-users/td-p/219369

Summary:
1. Read the manual or user guide. Have you read the manual? Can you find the manual?
2. Search the forums (and search the web) for similar topics.
3. Do not post the same question on multiple forums.
4. Do not post a new topic or question on someone else's thread, start a new thread!
5. Students: Copying code is not the same as learning to design.
6 "It does not work" is not a question which can be answered. Provide useful details (with webpage, datasheet links, please).
7. You are not charged extra fees for comments in your code.
8. I am not paid for forum posts. If I write a good post, then I have been good for nothing.
0 Kudos
Reply
Highlighted
Explorer
Explorer
8,029 Views
Registered: ‎08-23-2011

hi bob,

 

when you say -

 

Do you have CDC logic to ensure that the 20M data will meet setup and hold time to the 110M clock domain?

 

do you mean CDC logic like double flop from slow to fast clock domain? 

handshaking from fast to slow domain?

fifo on clock boundaries?

 

or are you referring to something else?

 

if i do have the above, then i guess TIG would be fine? the rtl i have was taken through cdc check (which passed) ... so is my understanding correct?

 

z.

0 Kudos
Reply
Highlighted
Instructor
Instructor
8,012 Views
Registered: ‎07-21-2009

Do you have CDC logic to ensure that the 20M data will meet setup and hold time to the 110M clock domain?

 

do you mean CDC logic like double flop from slow to fast clock domain? 

handshaking from fast to slow domain?

fifo on clock boundaries?

 

Yes, I mean any of these types of means to ensure that the 110M register is sampling stable and settled 20M data.  There are at least 5 110M clock rising edges between each successive 20M clock rising edges, so it should be fairly simple to enable the receiving 110M data register to sample 20M data when the 20M data is valid.  As you noted, there are several ways to accomplish this reliably.

 

Note that the two clocks (20M and 110M) are isochronous, they are not truly asynchronous to each other.

 

Here is an example of a typical mailbox flag approach for ensuring that the 110M data register samples only stable and settled data --

 

reg [63:0] data20m, data110m;  // data output from 20M domain and input to 110M domain
reg newdata20m;  // mailbox flag reg, 20M domain
reg [2:0] newdata110m; // mailbox flag regs, 110M domain
reg sample_ena110m; // sample the 20M data, clear the mailbox flag

always @(posedge clk20m) data20m <= indata;  // 20M data reg

always @(posedge clk20m, posedge sample_ena110m) // mailbox flag
    if (sample_ena110m)  newdata20m <= 1'b0;  // 'async' clear of the flag
    else                 newdata20m <= 1'b1;  // set the flag at every clk20m posedge

always @(posedge clk110m)  // handshake from 20M to 110M domain
  begin
    newdata110m <= {newdata110m[2:0], newdata20m};  // 3-stage delay of 20M flag
    sample_ena110m  <= (newdata110m[2:1] == 2'b01);  // 20M data is stable, OK to sample
    
    if (sample_ena110m)  data110m <= data20m; // sample the 20M data
  end
//                 _   _   _   _   _   _   _   _   _   _   _   _   _   _   _  
// clk110m       _| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_
//                 __________           __________           __________       
// clk20m        _|          |_________|          |_________|          |______
//               __ ____________________ ____________________ ________________
// data20m       __X____________________X____________________X________________
//                  ____________         ___________          __________      
// newdata20m     _|            |_______|           |________|          |_____
//                      ___________         ___________         ___________   
// newdata110m[0] _____|           |_______|           |_______|           |__
//                          ___________         ___________         __________
// newdata110m[1] _________|           |_______|           |_______|          
//                              ___________         ___________         ______
// newdata110m[2] _____________|           |_______|           |_______|      
//                              ___                 ___                 ___   
// sample_ena110m _____________|   |_______________|   |_______________|   |__
//                  _______________ ___________________ ___________________ ___
// data110m         _______________X___________________X___________________X___

 

-- Bob Elkind

SIGNATURE:
README for newbies is here: http://forums.xilinx.com/t5/New-Users-Forum/README-first-Help-for-new-users/td-p/219369

Summary:
1. Read the manual or user guide. Have you read the manual? Can you find the manual?
2. Search the forums (and search the web) for similar topics.
3. Do not post the same question on multiple forums.
4. Do not post a new topic or question on someone else's thread, start a new thread!
5. Students: Copying code is not the same as learning to design.
6 "It does not work" is not a question which can be answered. Provide useful details (with webpage, datasheet links, please).
7. You are not charged extra fees for comments in your code.
8. I am not paid for forum posts. If I write a good post, then I have been good for nothing.
0 Kudos
Reply
Highlighted
Explorer
Explorer
8,000 Views
Registered: ‎08-23-2011

thanks for the explanation bob.

 

like i said - the rtl code i have did pass spyglass checks before (for cdc) so i think i should be good while using TIG as you said.

 

however, instead of letting xilinx auto-constrain the 20M and 110M clocks (which are coming out from the PLL), i am now manually constraining them and i am able to slowly increase the design frequency too. but xilinx says that by manually constraining the PLL outputs (and by not making them related), cdc analysis is overlooked.

 

so between TIG and manually constraining the PLL outputs, which is a more "acceptable" solution? 

 

also, could there be a chance that since the cdc paths are not being analyzed (through manual constraining or TIG), then even though the implementation is clean, the final bit file could still fail, esp on the cdc paths. could this be a possibility for TIG and/or manual constraint?

 

would be great if you could shed some light on that ...

 

z.

 

 

0 Kudos
Reply
Highlighted
Instructor
Instructor
7,991 Views
Registered: ‎07-21-2009

like i said - the rtl code i have did pass spyglass checks before (for cdc) so i think i should be good while using TIG as you said.

 

I am not familiar with spyglass.

 

however, instead of letting xilinx auto-constrain the 20M and 110M clocks (which are coming out from the PLL), i am now manually constraining them and i am able to slowly increase the design frequency too. but xilinx says that by manually constraining the PLL outputs (and by not making them related), cdc analysis is overlooked.

 

I do not understand what you are saying.  What do you mean by 'auto-constrain' ?  If you define an input clock period to the PLL, ISE toolset calculates the derived periods for the output clocks.  By 'manually constrain', do you mean you are over-riding the inferred clock period?

 

And what do you mean by "cdc analysis is overlooked" ?

 

so between TIG and manually constraining the PLL outputs, which is a more "acceptable" solution?

 

The acceptable solution is being able to prove that your design is absolutely, positively solid over the specified operating temperature range.  The tools are tools, not gods.  Use the tools to their maximum advantage, but you -- the designer -- must bear the final responsibility for a solid design.  It's a very simple thing to use the tools to 'pass', and yet leave an unreliable or non-working design.  This is particularly true with instances of clock domain crossing and asynchronous inputs.

 

-- Bob Elkind

SIGNATURE:
README for newbies is here: http://forums.xilinx.com/t5/New-Users-Forum/README-first-Help-for-new-users/td-p/219369

Summary:
1. Read the manual or user guide. Have you read the manual? Can you find the manual?
2. Search the forums (and search the web) for similar topics.
3. Do not post the same question on multiple forums.
4. Do not post a new topic or question on someone else's thread, start a new thread!
5. Students: Copying code is not the same as learning to design.
6 "It does not work" is not a question which can be answered. Provide useful details (with webpage, datasheet links, please).
7. You are not charged extra fees for comments in your code.
8. I am not paid for forum posts. If I write a good post, then I have been good for nothing.
0 Kudos
Reply
Highlighted
Explorer
Explorer
7,979 Views
Registered: ‎08-23-2011

hi bob,

 

when i say auto constraint, i mean that if you  put a constraint on the i/p of the PLL, then the tool automatically puts constraints on the PLL o/p. and when it does this, then the o/p of the PLL get related constraints and then xilinx tries to do CDC analysis.

 

however, as per an official xilinx answer - http://www.xilinx.com/support/answers/34348.htm

 

"You can also add non-related PERIOD constraints for theDCM/PLL/MMCM output clocks manually in UCF instead ofautomatic propagation. The tool will not analyze the cross-domain paths as long as they are not applied related PERIOD constraints."

 

so when it says - the tool will not analyze cross-domain paths ... does it mean that even if you've manually constrained the PLL o/p and the implementation is clean, beacause the CDC paths were not analyzed, there is a chance they could fail (despite having CDC logic in place)? im just not very clear on this ...

 

and a similar thing with TIG - I have CDC logic in place but TIG ignores clock domain crossing analysis. so is there any chance of these paths failing in the bit file (even though implementation is now clean)?

 

z.

0 Kudos
Reply