asdf44
Advanced Member level 4
Well this is hopefully a dumb question but I'm not finding it spelled out to my satisfaction.
I want to be sure that ISE is handling my synchronous clocks properly for a Spartan 6 design.
I have a 125MHz incoming clock which does the following:
1) Gets used directly for some logic
2) Goes into a DCM block and gets divided by 4 for some other logic
3) #2 goes to a flip-flop based counter divider for other slower logic
The end result I want is that signals on all 3 clocks can cross synchronously within the design. Because asynchronous clock domains are much more interesting I'm not finding where the behavior regarding these types of synchronous domains is spelled out. The DCM, #2, I trust is taken care of and I can see a timing constraint automatically generated for the divided down clock showing that it understand both the frequency and phase relationship to #1.
But #3 is where I'm a bit fuzzy on what the limits of the tool are in terms of interpreting the design and constraining it. What I'm assuming is the following:
A) The tool won't be necessarily be able to infer the actual speed of clock #3 [I could constrain it manually if I want] but:
B) The tool will apply timing constraints based on input clock #2 which it does know about thus:
C) Timing should be guaranteed between domain #3 and the other two domains.
Is this understanding correct?
I want to be sure that ISE is handling my synchronous clocks properly for a Spartan 6 design.
I have a 125MHz incoming clock which does the following:
1) Gets used directly for some logic
2) Goes into a DCM block and gets divided by 4 for some other logic
3) #2 goes to a flip-flop based counter divider for other slower logic
The end result I want is that signals on all 3 clocks can cross synchronously within the design. Because asynchronous clock domains are much more interesting I'm not finding where the behavior regarding these types of synchronous domains is spelled out. The DCM, #2, I trust is taken care of and I can see a timing constraint automatically generated for the divided down clock showing that it understand both the frequency and phase relationship to #1.
But #3 is where I'm a bit fuzzy on what the limits of the tool are in terms of interpreting the design and constraining it. What I'm assuming is the following:
A) The tool won't be necessarily be able to infer the actual speed of clock #3 [I could constrain it manually if I want] but:
B) The tool will apply timing constraints based on input clock #2 which it does know about thus:
C) Timing should be guaranteed between domain #3 and the other two domains.
Is this understanding correct?