12-30-2012 07:08 AM
How we can write a setup or hold time constraints for a clock that isn't a global clock, it's come from a combinational logic inside my code ?
Take in mind that the tool gives me an error that the this net isn't connected to a pad or a pin when i type the constraints as shown:
NET "u0_dphy_data_master/the_dphy_master_lp_rx/rx_clk_tmp" TNM_NET = clock;
TIMEGRP "clock" OFFSET = IN 0.2 ns VALID 50 ns BEFORE "u0_dphy_data_master/the_dphy_master_lp_rx/rx_clk_tmp" RISING;
While um reading in the UCF constraints user manual i found that we have to use this commands with a global clocks only
Is my understanding to this point is true or we have another way to define a constraints to a not global clock ?
Thanks in advance
12-30-2012 09:52 AM
clock that isn't a global clock, it's come from a combinational logic inside my code
Just this line makes me shiver. Why do you have a clock derived from combinatorial logic? Why?
You should constrain your input clock with (a minimum of) a PERIOD constraint. Correctly derived clocks (i.e. from PLL, DCM, etc.) will have constraints automatically flowed down onto them by the tools. Combinatorially derived clocks are just plain wrong.
12-30-2012 11:43 AM
It is my understanding that you just cannot do this in ISE.
The OFFSET IN constraint relates the timing of the data arriving at a data pin to a clock pin. The arrival time is not actually specified against a clock, but against a pin (although one generally has a PERIOD constraint attached to the clock pin).
Next, lets look at some other things. Internally generated clocks are BAAAAD
- if not placed on a clock network (global or regional) they will have bad skew
- if coming from a LUT, they can have glitches
- (and most importantly here), they have no known phase relationship with anything else in the system
Particularly due to the last one, how do you expect a constraint to be met? Since these kinds of generated clocks are not generally used in FPGAs, there is no mechanism of constraining this internally generated clock. The tools may take 1ns or 100ns to route the clock from where it is generated to where it is used. Given this, its pretty much impossible to have this unknown phase clock capture an input.
You probably need to find another architecture for doing what you are trying to do. We don't know enough about what you are trying to do to give you any ideas, but, in general, you should be using some dedicated clocking resources to generate your clock - either a DCM/MMCM or a BUFGCE. In either of these cases, the there will be mechanisms of constraining the input - you will specify it with respect to the input clock pin, and the tools will do the required clock propagation.
12-31-2012 12:16 AM
Thanks all for your reply,
I know that the combinatorial clock isn't the best way, But my current combinatorial clock is generated from another clock in my working project code, So i know its phase relationship.
Any way, This clock is an input for different modules not an input directely to flops in the same module. In this case can we make our constraints on these input pins of the these modules that use this generated clock?
12-31-2012 03:45 AM
In this case can we make our constraints on these input pins of the these modules that use this generated clock?
The short answer is NO. You cannot constrain either the generated clock nor the inputs of these modules in the way that you describe.
Let's also be clear on one other thing:
WHAT YOU ARE PROPOSING IS FUNDAMENTALLY BAD DESIGN PRACTICE.
Just don't do it. With a correctly designed clock scheme you will make it much easier to constrain your design, easier for the tools to meet your constraints and easier to produce a working, reproducible hardware design across a wide range of physical factors, e.g. temperature variance. Do it right and save yourself hours, even weeks, of tail-chasing.
But my current combinatorial clock is generated from another clock in my working project code, So i know its phase relationship.
Given what Avrum wrote earlier about logic generated clocks, how could you possibly KNOW the phase relationship? It just can't be done, certainly not with any consistency. There is no way to predict the behaviour, skew and routing delay of a "clock" generated in this way.
12-31-2012 05:19 AM
But my current combinatorial clock is generated from another clock in my working project code
You still haven't told us what the relationship between the original clock and the derived clock is, but my suspicion is that this derived clock can be generated "properly" using a BUFGCE.
The BUFGCE is a variation of the BUFG that allows you to gate the clock (using the CE). By controlling the CE properly you can enable the clock on a period by period basis. This allows you to do lots of things
- enable only one out of N clocks to generate a decimated clock - effectively a clock that runs at a frequency of 1/N of your original clock
- enable the clock only at certain times
- this can be used to reduce power
- it can also be used to enable the clock only at times when an I/O protocol requires it
When using a BUFGCE, you will need to also use a BUFG. The I input of both the BUFG and BUFGCE are connected to the input clock (whether it is directly from a clock capable pin or through an MMCM/DCM). The BUFG clock is then used in any logic required to generate the CE input for the BUFGCE. When done this way, the BUFG clock and the BUFGCE clock are guaranteed to be in phase (when the BUFGCE clock is enabled).
Since the BUFG and BUFGCE clocks are in phase (and have known phase relationships with the input pins) the tools can properly analyze an OFFSET IN constraint specified with respect to the incoming clock pin, regardless of whether the flip-flops are clocked on the BUFG clock or the BUFGCE clock.
Of course, now you have to look at the timing of the input. Your original post shows an input with almost no setup, and TONS of valid time (are you sure that's correct - we don't know what your input clock frequency is, but its suspicious that an input would have 50ns of valid time - the interface would need to be running significantly below 20MHz for this to be possible).
Using a clock capable input to a BUFG and capturing the input data in an IOB flip-flop, the timing requirement is specified in the datasheet for your device - it will be Tpsfd/Tphfd. We don't know what device/speed grade you are using, but in most devices, this is fairly long (although at speeds less than 20MHz, this should be possible). I would expect that you will need clock using the falling edge of clock to center your clock in the window.
If you want to have a smaller SU/H window you will need to use a DCM or MMCM to deskew the clocks. This can be done by using the output of the BUFG as the feedback input to the DCM/MMCM. The BUFG clock and BUFGCE clocks will still be in phase. When done this way, the input timing is determined by Tpsdcm/Tphdcm or Tpsmmcm/Tphmmcm (or a similar parameter depending on the architecture). In addition to the smaller SU/H window, this has the advantage of being able to use the DCM/MMCM change the phase of your clocks to center the clock in the data valid window.
01-01-2013 01:25 PM - edited 01-09-2013 10:40 AM
check this AR #38099 http://www.xilinx.com/support/answers/38099
I am really not a fan of this answer record for a couple of reasons.
While the opening statement of the AR does suggest using an MMCM or DCM instead of a divided clock like this, I feel that it still "recommends" generating clocks this way. While there may be cases where it is necessary, it should always be considered a mechanism of absolute last resort.
First, the diagram is incomplete - for this to do what is decribed by the constraint, each of the four FFs need to have the inverter from the Q back to the D (making these all toggle flip-flops). I presume the intent was for the other inverters to be implied, but the text in the solution says "four flip-flops and one inverter".
Next, in the diagram supplied, all of the clocks will end up being locally routed clocks - none of them show an explicit BUFG. Locally routed clocks pose all kinds of problems with clock skew. Now, for the clocks that go only from the 1st to 2nd FF, 2nd to 3rd, and 3rd to 4th, skew isn't a problem (since presumably they have only one load). As for CLKOUT, one could add a BUFG after the 4th FF to make it a global clock (thus making it a global clock, and removing all skew problems).
However, even making the final clock global, we have no idea of the phase relationship between the clocks. While the answer record has "PHASE XYZ ns" in the constraint, the implication is that there is a way that you could somehow calculate what XYZ should be. There is no way to do so. Each of these local clocks gets routed in fabric logic. As such, the amount of delay on the "clock" is unknown. The PHASE XYZ does not place a constraint on this phase, it merely explains to the tool (for subsequent timing analysis) what the PHASE is - there is, in fact, no (practical) mechanism to place a constraint on the routing of these local clocks. As a result, the XYZ is unknowable, and will vary from implementation run to implementation run (and across process temperature and voltage).
Now, if CLKOUT is used only inside the FPGA (i.e. there is no I/O referenced to it), and we don't try and do any synchronous clock crossing between CLKOUT and (say) CLKIN, then this may be OK. However, using the constraint supplied, the tool will believe the PHASE XYZ and will treat the two clocks (CLKIN and CLKOUT) as having this PHASE relationship. In other words, it will think that it is legal to cross between the two domains as long as the static timing path between them is less than XYZ.
What makes all of this worse is that there are other mechanisms for generating divided clocks that don't have all these problems. As is mentioned by the AR, generating the clock from an MMCM or DCM (ideally, generating both the slow and fast clock from the same MMCM/DCM) has no static timing problems - the resulting clocks are in phase, and the tool knows the timing relationship between the two clocks.
If you cannot use an MMCM/DCM, then you can use a BUFGCE or a BUFHCE. By using the CE of these clock buffers, you can generate in-phase decimated clocks with the required "frequency" relationship - by enabling the buffer only one out of N base clocks, you end up with a clock that (effectively) has a frequency of 1/N of the base clock. The only disadvantage is that this clock has a very non-50/50 duty cycle, which means that you can't (or shouldn't) use this clock to clock an IDDR/ODDR or a negative edge FF.
Attached to this post is a diagram for the BUFGCE. The next post will have the diagram for the BUFHCE (I don't know how to attach to files two the same post).
In either of the two mechanisms shown in the attachments, the fastClk and slowClk are in phase - the tool will be able to synchronously cross between these two domains (the crossings will be effectively constrained to one fastClk period).
Furthermore, constraining these are very easy. Assuming the input clock (be it from an input or via a DCM/MMCM) is constrained
NET "inClk" TNM_NET = tgrp_inClk;
TIMESPEC TS_INCLK = PERIOD tgrp_inClk 10 ns HIGH 50%;
The fastClk is already constrained. The slow clock can easily be constrained by a multicycle path constraint (lets, for the sake of argument, assume N is 16 as was the case for the answer record).
NET "slowClk" TNM_NET = tgrp_slowClk;
TIMESPEC TS_SLOWCLK = FROM tgrp_slowClk TO tgrp_slowClk TS_INCLK*16;
This is a far preferable way of doing the same thing. The only disadvantages are that the BUFGCE approach takes a 2nd BUFG (as, probably does the AR approach, since CLKOUT will have to be buffered). The BUFHCE approach doesn't take any "extra" buffers (since BUFHs are inferred for all global clocks anyway), but when manually instantiated, the clock generated by a BUFHCE can only clock FFs in one clock region.