set_max_skew command

OK, agreed. But if I set my constraint to a value that (I think) can't possibly pass timing, for example;

set_max_skew -to [get_ports data_out[*]] 0.0

Then wouldn't I expect TQ to report a failure?

--- Quote Start ---

I'm clocking a data bus out of my Cyclone V and want to constrain the maximum skew between data lines. I'm using;

# 100 ps max skew

set_max_skew -to [get_ports data_out

[*]] 0.1

It seems like this should be straightforward, but if I set the skew value to something really small, like 1ps (or even 0 ps) TimeQuest does not report any failure to meet the constraint. My concern is that I'm not really constraining anything. Am I missing something?

--- Quote End ---

As far as I am aware TimeQuest does not report failure with respect to just any of user settings. Rather it reports on timing failure i.e. tSU/tH, tREC/tRem as pass or failure and achieved slack whether inside fpga or at io. But you can use reporting to find out what has been achieved.

Again, maybe I'm missing something, but I thought that when I apply the constraint;

set_max_skew -to [get_ports data_out[*]] 0.1

I'm telling Quartus that when it compiles the design, it should do so in a way that maintains a maximum skew between my data outputs of 100ps. If it fails to meet that criterion, then it gets reported as a timing violation, much the same as a failure to meet tSU/tH. No?

--- Quote Start ---

Again, maybe I'm missing something, but I thought that when I apply the constraint;

set_max_skew -to [get_ports data_out

[*]] 0.1

I'm telling Quartus that when it compiles the design, it should do so in a way that maintains a maximum skew between my data outputs of 100ps. If it fails to meet that criterion, then it gets reported as a timing violation, much the same as a failure to meet tSU/tH. No?

--- Quote End ---

The target of TQ is to achieve timing closure and that is equivalent to having +ve tSU/tH slack. Once achieved, it doesn't for example even try to optimise tSU/tH balance (except for dc fifos clock crossing paths).

It sees user constraints and things like multicycle are respected as it helps closure.

If you got different skew from your aimed one but timing passed then in effect it says don't worry, it is not needed given your io constraints

--- Quote Start ---

OK, agreed. But if I set my constraint to a value that (I think) can't possibly pass timing, for example;

set_max_skew -to [get_ports data_out

[*]] 0.0

Then wouldn't I expect TQ to report a failure?

--- Quote End ---

It depends on your io constraints i.e set_output_delay figures and clock rate.

skew does not tell TQ what are your actual constraints (clock data offset).

I know skew method is used for some cases of DDR if the external chip asks for skew only but I am not sure then how TQ check the tSU/tH. I believe in such cases the external chip doesn't care about data/clock offset as it may have automated logic to align.