Timing

Preben, The IOBs have an optional delay element. RTM. If you use this with the IOB input flip-flop, you eliminate pad-to-pad hold time. Cheers, Syms.

Thanks, but I guess it's quite more than I've learned so far during courses!

What is pad-to-pad holdtime? How do I setup the delay element? Input flip-flops are these any different from other flip-flops?

I have an idea about some constraint-editor may be able to help me out here, but searching the net gives me nothing!

Thanks Preben

courses!

Search harder! Look for xapp133 "input delay properties" Good luck, Syms.

This is (as I know) definitely not a good idea. You cannot using both the edges of a clock in evaluating. Somebody please correct me if I am wrong.

Thanks.

Howdy Praveen,

Why not?

No offense intended, but why not try it rather than asking people to correct you?

Synplify has no problem with his code. The style may not fit everyones taste, but works fine as written. Depending on the clock and data delay, it may not do what the OP wanted it to do (namely catch his data that appears to only be valid on a rising edge), but that's a different problem.

Have fun,

Marc

Pretty confused now...

Pad-to-pad delay is the delay between the two IC's (without thinking of prop. delay), but there is approx. no delay having short paths between the IC's. Is this correct?

The obtional delay-element gives me nothing - I think!

There is a 1.05+0.09 ns delay (for LVCMOS33) when no delay element, and a approx. 4.5ns delay when there.

This doesn't help me in the 100MHz application which I should get documented well, even though I can't test it through the IO-connector on my board!

Synthethis says that the signal should be stable about 4 ns before clock-edge and approx. the same after the clock edge. This is quite much and almost the most of a 100MHz clock cycle (10ns)! Btw. is this caused by automatic IOB "obtional" delay? Even though synthethis says that the maximum frequency is approx. 180 MHz?

The input flip flop doesn't help either (I think) - this requires an extra clock on some input-pin - doesn't it?

I guess the solution is to "move" the clock some ticks with a DCM and then use this clock to sample the data. But this isn't smart because it uses a DCM and I already use 2 and maybe in the final application I need more!

Please comment and let me learn what I've guess I missed.

Thanks Preben

IOB

Incorrect. In your case, pad to pad delay is the delay from the clock arriving at the FPGA input pad, to the clock input of the IOB FF in the data input IOB, plus the hold time of the FF. This delay must be less than the time from the clock transition to the data transition. The optional IOB input delay in the data IOB delays the data transition, so you have more time to get the clock to the data IOB's FF. Is that any help? Cheers, Syms.

Well, actually no!! But I don't get the idea about what the Input FF can do for me at all - so let's forget about that in the first time. Is the delay element any good when not using the input FF.

What clock arriving at the FPGA input pad - some special input clock or the overall system clock?

The delay element makes my signal settle approx. 4 ns later which means

1 ns ((7+4) mod 10 = 1) after the rising edge of the clock - that's where I don't understand it anymore?

My earlier answer is probably easier to understand if you're looking at figure 1 in the ds099-2.pdf (Spartan-3 FPGA Functional Description)