Timequest User Guide and Source-Synchronous Outputs

Yikes. Good catch. I don't have any examples of source synchronous, and that description is wrong. If the clock were sent off chip from a PLL, then a generated clock should be applied to the output port sending the clock. I will fix that.

I think the two things I want to add near-term are:

1) A longer discussion on general I/O constraints, with examples.

2) A section on source synchronous, with examples.

Just hard to find the time. But I will try to change this and upload it shortly, since it is incorrect, and that's the whole benefit of a wiki. Thanks for pointing it out.

Hey thanks for the quick reply! That clears up my confusion with that. I think a section on source synchronous would be greatly appreciated :)

I did have another question:

I have a lot of places where a base clock coming into the fpga is connected to an output pin for a source synchronous interface. How do I specify this in the sdc file? Note - the output pin is simply connected to the input clock, it is not a ripple clock or a pll output. Should I create a generated clock on this port?

As a follow-up to this, I also have some ripple clocks that are ouput from the FPGA and I have generated clocks associated with them in the sdc file, however when I run a report unconstrained paths, it reports the clock output pin as unconstrained, although it does mention that the port has a clock assignment. Do I need another constraint for this output clock pin?

If using a clock going off chip, apply a create_generated_clock assignment to the output port. It may not be any different than the input clock, i.e. there aren't any -multiply_by/-phase/etc. attributes, but you're telling timing HOW the clock gets off chip, and then using that path for reference.

Always do a "report_timing -detail full_path" to make sure the clock analyzes back to the source where it comes in. There is a warning if the generated clock can't be traced back, but users often ignore warnings.

And yes, output clocks show up as unconstrained for me too. I let it be. You can add constraints and then cut them to get this to go away, but not worth the hassle, in my opinion.

Hello,

I am another happy reader of the TimeQuest User Guide: I mean that it looks like it has been written by someone that really uses the tool while some application notes seems written by someone that designed the tool (or have studied it) but used it rarely. This is my poor opinion, I hope no-one takes offence at this (I'm sorry if this happens). Thanks a lot, Rysc!

I have a question which is not intended to be answered only by Rysc, I think anyone with enough experience can give a hint.

I have a signal which is generated by a state machine and is sent out of the fpga to a device that use it as a clock to capture data which are output by the same state machine. This interface is something like an SPI, to explain better the situation.

The transmission is centre-aligned.

The state machine has been designed to keep data stable at least an entire clock cycle (12.5 ns) before and after the rising edge of the generated clock: the output clock is the flip-flop clock divided by four, the data are refreshed when the output clock is falling.

For timing constraints I have the following scenarios:

1) given the possible jitter, the trace delays and the requirements of the slave external device, I could be confident that the requirements are met by design ad put a set_false_path

2) open the window of the timing using the multicycle constraints, constraint the output of the state machine to the flip-flop clock putting the little of Tsu, Th, board delay in the count. The relation between the output clock and the data is determined by the design and enforced by constraining the relation of both the lines to the real clock.

Personally, I don't like the option (1). Option (2) seems what I usually do for flash devices, which are asynchronous. I would not put any virtual clock nor generated clock. Any suggestion?

Thanks,

Gabriele

Thanks.

- I would suggest using generated clocks. Note that clocks do not propagate through registers(ripple clocks), so without them the delays of the clock going off chip will be ignored, making the analysis incorrect. At 12.5ns delays, there's definitely some risk in ignoring them.

- Put a generated clock on the register(use get_keepers) that drives the clock out of the state-machine. The -source should be the output of the PLL that drives it and can be found by running report_clocks and looking at the Target column of clocks created by derive_pll_clocks. If there is no PLL, then it's just the input clock pin.

- Put a second generated clock on the output port sending out data, it's source being the register that the clock is generated from. This shows TQ how the clock gets out, and this clock will be used by your set_output_delay constraints.

- Use multicycles to create the correct setup and hold relationships.

- Finally add the external -max/-min valuse to the set_output_delay based on the external delays.

When you run:

report_timing -setup -detail full_path -npaths 50 -to_clock output_clock_name -panel_name "Interface_name||setup"

Make sure your data arrival path has the entire path from the clock coming in all the way to going out of the device. This means your generated clocks are correct. If they're not, you get a warning about not being able to determine clock latency from the source, but I find looking at the timing report easier.

A complement goes a long way... : )

Thanks for the fast answer.

Take your time, when you can, for the complement to the guide, people will appreciate your effort even if it takes some time.