Timing Analysis

[berndl]

Hi,

I think I've still not got it right...

I have a fully synchronous design with an internal clock generated by a DCM (2x of input clock). And I have several external interfaces, where the external chips are master, e.g. an SPI or a microcontroller.

In order to constrain my data outputs (unidirectional for SPI and bidirectional for the uC bus), I thought I can use either OFFSET OUT or (found here in the forum) PAD TO PAD. I should mention, that I operate all interfaces fully synchronous internally (means: I synchronize the SCK of the SPI as well as the READ_ENA of the uC into my internal clock domain).

My ideas now:

1.) OFFSET OUT

I could declare the SCK/READ_ENA in the .ucf file, and then apply an OFFSET OUT to the MOSI data signal.

- Is this possible? (since OFFSET only works on input/ouput pins)

2.) PAD TO PAD

After a rising (or falling) edge of SCK/READ_ENA the output MOSI (or uC_DATA_OUT) the data should be faster than the value specified in the PAD TO PAD constraint.

- Is this 'more' elegant for such interfaces?

Anyway, could somebody provide me with some information on that (I'd really appreciate a simple example for the .ucf)?

Thanks and kind regards,

- berndl

[berndl]

Well, after reading my above post a couple of times, I think my real problem is not obviously visible from my description...

Let me give it a 2nd try:

Let's assume we have an external SPI master chip. The master sends out data with the rising edge of the SPI clock (SCK) and expects receive-data with the falling edge of SCK.

And now for my problem with the constraints...

1) Master sends data with SCK-rise, there is a hold time (spec) plus wiring delay on board or cable

2) I'm running my chip with an independent clock, and I synchronize SCK with this clock into my clock domain (gives some latency)

3) I'm now accessing my internal data (from a BRAM or some logic), and with some delay (some internal clock cycles) I put the data out on the SOMI line (slave data out).

4) It may take some time until this data arrives at the output pad (probably the data out FF is placed somewhere on the chip)

5) I now have some flight time of the signal to my master and I have a setup time of the master

For my problem: 2) and 3) cannot be taken into account by the timing tool, because the tool doesn't know how I synchronize the trigger signal into my logic and it doesn't know how long it takes to provide the data out

4) is the thing I want to constrain! And it is completely unrelated to the incomming SCK at the pad! It's really just 'allowing' some delay from the FF to the PAD.

And now, again, my question: How do I specifiy this in the .ucf?

Kind regards,

- berndl

PS: Hope it's now clearer what the problem is... For the simplicity of a fully synchronous design I now have to tackle stuff like this...

[austin]

b,

I think the first problem, is that it is not a synchronous interface (the clock of the interface has no relationship to the clock of the logic, or of the IO).

Thus, you have synchronizers to cross the clock domains, and rather than needing timing contraints, you need to ignore the timing, as there is no relationship of one, to the other.

[berndl]

Hi Austin, thanks for the reply.

But isn't it possible to constrain the maximum delay from an FF-output to a pad? With such a constrain I could 'force' the tools to use a FF close to the pad and use short/fast routing resources. And I would expect a timing failure when the constraint could not be met.

- berndl

[eteam00]

Berndl,  your problem description is still muddled.

Are you trying to implement an SPI slave interface?

Are you clocking the MISO (master in slave out) output with the internal clock or the SPI clock?

With such a constrain I could 'force' the tools to use a FF close to the pad and use short/fast routing resources

The HDL attribute and syntax for forcing a FF placement in the output logic can be found in the ISE Language Templates (click on the lightbulb icon in ISE Navigator).

Perhaps you should post your SPI output code

Please clarify what you mean by "How do I specifiy this in the .ucf?"  What is "this" ?

-- Bob Elkind

[berndl]

Hi Bob,

you asked for it, here it goes... :o)

* I'm clocking each FF (and output-FF) with my internal clock (currently 100MHz). This clock is completely independent from any other chips clock on this board.

* I'm currently implementing two different kind of interfaces, one is a bi-directional bus to a microcontroller, others are SPI slave interfaces.

* As Austin already figured out, there's no relation of my FPGA clock to any of the involved external 'master interfaces'.

* Furthermore, my particular question here relates to the fact, that I want to incorporate multiple designs (currently on a Spartan 3-200) into a larger FPGA (target is S3E-1600). The purpose is, that the users of these boxes can have multiple images in the FPGA (in opposite to the current state: They have 3 different boxes with the S3-200), and select via the microcontroller, which image they want to run. All these images operate on the same physical connections (mainly SPI).

* Boiled down, I just want to multiplex several internal designs to shared output ports.

* This introduces some multiplexors at the output signals which I just want to select/switch with a concurrent VHDL statement (select design1, design2, ...). And this places the output FF of such a design not in the IO-cell, the FF is buried somewhere in the LUT-FFs instead.

And what I know want to know: What is the delay from this somewhere placed output FF to the chip-pad. I can, of course, have a look into the place&route timing report, but I want to constrain the maximum delay of any of this FFs to the pad to a specified limit. And I want to get a timing-error when the tools cannot meet this maximum delay.

With Austins comments/explanations, it is clear, that I cannot use the OFFSET or PAD TO PAD constraints, these are always related to an incoming signal which triggers my ouputs action. And since I'm internally operating with a different clock and I need some clock cycles to provide the output data, the specification of such a 'delay' cannot be handled with the above mentioned constraints...

How are you specifying these signals? It's just an internal FF going to a pad. How do you tell the toolchain, that e.g. only 8.123ns delay to the pad are allowed?

Thanks and kind regards,

- berndl

[eteam00]

• I'm clocking each FF (and output-FF) with my internal clock (currently 100MHz). This clock is completely independent from any other chips clock on this board.
• I'm currently implementing two different kind of interfaces, one is a bi-directional bus to a microcontroller, others are SPI slave interfaces.
• As Austin already figured out, there's no relation of my FPGA clock to any of the involved external 'master interfaces'.

All three of these design attributes are typical of many FPGA designs.  As user forum topics, they are well-covered.

• This introduces some multiplexors at the output signals which I just want to select/switch with a concurrent VHDL statement (select design1, design2, ...). And this places the output FF of such a design not in the IO-cell, the FF is buried somewhere in the LUT-FFs instead.

A logical "multiplexer" between multiple "designs" is inherently similar to any other multiplexer.  In other words, the presumption that this "multiplexer" prevents an output-cell FF implementation is overly simplistic and mistaken.  What you see as an immutable barrier may be a simple logic design problem.

And what I know want to know: What is the delay from this somewhere placed output FF to the chip-pad. I can, of course, have a look into the place&route timing report, but I want to constrain the maximum delay of any of this FFs to the pad to a specified limit. And I want to get a timing-error when the tools cannot meet this maximum delay.

If clock to output delay is critical, the answer is simple:  put the FF in an output cell.  The datasheet has specific and detailed maximum clock to output delay specifications, which will not vary.

-- Bob Elkind

[berndl]

Hi Austin&Bob,

well, after thinking about the topic and reading some documents, it looks like I cannot do what I originally wanted...

But thanks for your suggestions&comments.

Kind regards,

- berndl