OFFSET with DCM NET or derived NET?

I have been trying to use an internal clock net in my offset constraint, sourced from a DCM instance. This appears to be legal, according to the CGD: "OFFSET is used only for padrelated signals, and cannot be used to extend the arrival time specification method to the internal signals in a design. A clock that comes from an internal signal is one generated from a synch element, like a FF. A clock that comes from a PAD and goes through a DLL, DCM, clock buffer, or combinatorial logic is supported."

But, this doesn't work for me. If I use the original clock pad in the constraint it works. However, these OFFSETS are driven by a DCM FX output, so the timing is different from the original. Will ISE infer this timing difference? It appears to be unclear to me...

Thanks,

-Brandon

Reply to
Brandon Jasionowski
Loading thread data ...

Normally ISE will infer the timing difference correctly if there is a simple relationship (like 1:1) from the external pad frequency to the internal FX clock frequency. Since the OFFSET is used for PAD signals, this would make sense, since there would have to be an assumed phase relationship between the external pad signal requiring the OFFSET constraint and the internal clock. If the signals requiring the OFFSET constraint are not externally generated, it would normally make sense to use a PERIOD or FROM : TO constraint instead.

HTH, Gabor

Reply to
Gabor

So, if I have an internally generated clock from a DCM's fx output, "CLK_FX" feeding a group of registers, which are driving pins, "DATA_OUT" what would you recommend?

TIMESPEC "TS_DATA_OUT" FROM "CLK_FX" TO "DATA_OUT" 5 ns; # how about this?

Thanks,

-Brand> Brand> > I have been trying to use an internal clock net in my offset

Reply to
Brandon Jasionowski

Use the original clock in your spec; the tools should infer the derived clock properly. I've seen the tool work properly when switching to or from the CLKFX domain internall, I'd be surprised if it didn't do a proper job externally.

Reply to
John_H

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.