Output signals not synchronized

there are also UCF lines:

NET ctrl_data SLEW = FAST; NET ctrl_data DRIVE = 2; NET ctrl_data IOSTANDARD = LVCMOS33;

To start with, your timing constraint of OFFSET = OUT 100 ps AFTER is not something that will make your outputs happen coincident with your clock, it's a specification that will simply fail in the place & route and timing analyzer. Take a look. The fastest your outputs will go depend on how fast an IOB register can deliver its output relative to your global clock. These numbers are documented and easy to prototype.

Second, the 2 mA drive level will give you a slower rise/fall. The skew in your output signal time can - depending on your load - be a noticeable time difference.

Third, the logic analyzer is an asynchronous device which will usually provide a 2.5 ns uncertainty in your results leaving only a 2.5 ns difference not explained by the test equipment.

Please find the online documentation (or a Xilinx class) that describes what you can and cannot do with constraints. This fundamental information usually is only understood after an engineer can't understand why their design isn't working. Learn it.

If you need your outputs to have very low skew, your only hope is to place all of the output flip-flops in the IOB's (IOB=TRUE attribute on the flip-flop or net). You can also globally place registers in IOB's using the synthesis and map properties. If your outputs are generated by fabric flip-flops it is very hard to get your skew below 2.5 nS

By the way, why do you need such low skew on these lines? Is the driven device asynchronous with respect to your clock?

Regards, Gabor

I need those signals to control the analog CMOS circuit that has a requirement for some signals not to overlap - this happens when the output from the FPGA is not synchronous enough.

I need those signals to control the analog CMOS circuit that has a requirement for some signals not to overlap - this happens when the output from the FPGA is not synchronous enough.

fast

These

what

These signals will never be "synchronous enough" to guarantee zero overlap when changing on the same clock cycle. Use a faster clock if you need to, but certainly add a clock cycle between assertion of signals that must not overlap.

timing

fast

These

in

time

what

Yes, I was thinking of using 16 times faster clock to add one clock cycle in between, but I have checked signals with the 500MHz scope (10Mohm, 9.5pF probes) and it looks like that digital analyser is giving misleading waveforms - there is almost no delay between these two signals (less then 1ns). The rise time is same for both signals, and this can be improved by increasing the drive in UCF file from the minimum 2mA, I don't know the load yet.

not

clock,

timing

how fast

These

skew in

time

describes what

You might want to learn how a logic analyzer works. It sounds like your analyzer has a 400 MHz sample clock because of your noted 2.5 ns uncertainty. This sample clock is of course asynchronous to your circuit. So even if your FPGA's outputs are skewed less than 1 ns (as you point out), that window might include the logic analyzer's sample point, and as such signals that are in reality only 500 ps apart appear on the analyzer to be 2.5 ns apart.

So you should ensure that all of your signals are registered by a low- skew clock in the IOBs and ensure that your PCB routing has equal length lines from the FPGA to the load. This should result in quite good skew matching. Also make sure the output s set to FAST, and increase the drive strength. Read your timing analyzer's report for I/ O clock-to-out times.

And if the requirement is to ensure that two outputs are never enabled simultaneously, then do as Gabor says and insert a one-clock dead time between the deassertion of one output and the assertion of the other.

-a

is not

clock,

timing

how fast

clock. These

skew in

noticeable time

usually

describes what

their

2.5ns did not bother me, as that is the finest resolution of the logic analyser. But 5ns did bother me as that is longer than the sampling resolution. Scope has given me more precise reading - propagation dealy is 700ps and the rise and fall times for both the signals aprox. 2.5ns which is perfectly fine.