Honored Contributor
Honored ContributorI'm trying to correlate TimeQuest's timing model to external values and make sure they make sense. In TimeQuest, the set_output_delay constraint says there is an external register being driven by the output port, that register is clocked by the -clock option, and the delay to that register is a -max and -min value. That's what it does timing analysis and I think it's easiest to understand when you think of it that way.
When TimeQuest does setup timing analysis, it needs to make sure the data gets to that register before the latch clock. For hold, it needs the data to get there after the latch clock. So that's how it's being analyzed, but as you point out, external devices don't usually say what there delays are inside themselves. They might say they have a Tsu of 3ns. One way a device has a Tsu of 3ns is by saying internally its data path is 3ns longer than its clock path, and hence the data must be available at the ports 3ns before the clock is available. That may not be what's happening, i.e. it may be the paths are equal but there is a PLL that phase-shifts the clock forward 3ns. I don't know, but for all intents and purposes I don't care. When I increase my -max value by 3ns, I am saying externally the data path is 3ns longer than the clock path, based on TimeQuest's model. So I'm making the datasheet match the model. You're right that the -min value is predefined by Synopsys. They could have had an option called set_output_delay -th, and the user could put it in directly. But then when absorbing the board delays, they would need to do max_clk_dly - min_data_dly, i.e. they would have to invert what they did for the max value. That's why I think Synopsyis/TQ's way is more consistent. Anything on the data path is always added and anything on the latching clock path is subtracted. For the -max value you use the larger value for the data path and smaller value for the clock path. For the -min value you do the opposite. But Synopsys could have done it a different way. So you're right that I don't know what's going on inside the device, and the Tsu is only at the I/O ports of the device, but the description of what's going on inside the device is not wrong, as you get the same analysis if you think of it that way. I'm just trying to help visualize it rather than plug in equations, which is how I think a lot of people get into trouble. And there is another way to think of it that you might like. When the -max value gets larger, that is telling the FPGA it needs to get its data out more quickly to meet the setup relationship. So when the -max value becomes 3ns, you're telling the FPGA to have its data available 3ns before the clock. Thinking of it that way is not implying what's going on inside the FPGA(but when you do timing analysis, you will see the data path has become 3ns longer). I think I understand your point, but I also don't think I said anything wrong either.
