TimeQuest: set_max_delay constraint

Nope.

That being said, what value would you set it to? For example, if you set it to 5ns, so you're saying the delay between those two points would fail if it were greater than 5ns. If the delay were 4ns it would make it, but the path is considerably different if it were 0ns of skew or -2ns of skew(i.e. the latter would actually fail).

My guess is that the clocks are asynchronous, and you don't have a hard requirement, and just want to throw something in to make sure the datapath isn't 200ns, or something like that, not that it would ever be. There isn't a way to do this, and in the end you just have to accept that it takes in clock skew, but since the requirement probably isn't too tight, it shouldn't be a problem. (Please set me straight if I'm missing something from your situation, I'm just describing what I've seen a lot of)

As Rysc thought, it sounds like you want the constraint on a crossing between asynchronous clock domains. That what the examples below are for on the set_max_delay and set_min_delay on-line help pages.

--- Quote Start ---

# Apply a 10ns max delay between two unrelated clocks

set_max_delay -from [get_clocks clkA] -to [get_clocks clkB] 10.000

--- Quote End ---

--- Quote Start ---

# Apply a 0ns min delay between two unrelated clocks

set_min_delay -from [get_clocks clkA] -to [get_clocks clkB] 0.000

--- Quote End ---

--- Quote Start ---

Nope.

That being said, what value would you set it to? For example, if you set it to 5ns, so you're saying the delay between those two points would fail if it were greater than 5ns. If the delay were 4ns it would make it, but the path is considerably different if it were 0ns of skew or -2ns of skew(i.e. the latter would actually fail).

My guess is that the clocks are asynchronous, and you don't have a hard requirement, and just want to throw something in to make sure the datapath isn't 200ns, or something like that, not that it would ever be. There isn't a way to do this, and in the end you just have to accept that it takes in clock skew, but since the requirement probably isn't too tight, it shouldn't be a problem. (Please set me straight if I'm missing something from your situation, I'm just describing what I've seen a lot of)

--- Quote End ---

Thanks for your reply.

To clarify the actual situation, I have two signals crossing clock domains, the first one being a data_enable pulse, the second, being the (latched) data itself. I delay the data_enable signal by a few (e.g. 2 or 3) clock cycles (in the orignal clock domain) to give enough time to the data to propagate through. I want to set the max delay for the data to be equal to the total delay of those (2 or 3) clock cycles (by which the data_enable is delayed). Both signals will be double flopped afterwards (in the destination clock domain).

Edit: I don't want to set a fixed value between the clock domains as I may use a different number of clock cycles as a delay (for different data_enable's) at different points in my design.

One point on Brad's comment above, the set_max_delay and set_min_delay do use clock skew in their calculations. (Basically, all they do is override the launch and latch edge times for your setup and hold analysis. So set_max_delay of 10.0 will override that path so the launch edge is at 0.0 and the latch edge is at 10.0. The clock delays to the destination registrs is then used.

For the second post, it sounds like clock skew is important. If the skew to the clock on data was 3 clock cycles, then your enable would occur before the data did.

Note that I don't get the Edit: comment, that you don't want a fixed number. Are you saying you want Quartus to figure out how many delay elements you pass the enable through and apply a delay requirement for that? Or just that you will change the value for different parts of the design, which is doable, you just have to apply the constraint between registers and not clock domains.

--- Quote Start ---

One point on Brad's comment above, the set_max_delay and set_min_delay do use clock skew in their calculations. (Basically, all they do is override the launch and latch edge times for your setup and hold analysis. So set_max_delay of 10.0 will override that path so the launch edge is at 0.0 and the latch edge is at 10.0. The clock delays to the destination registrs is then used.

--- Quote End ---

Which I understand, but isn't what I want to achieve!

--- Quote Start ---

For the second post, it sounds like clock skew is important. If the skew to the clock on data was 3 clock cycles, then your enable would occur before the data did.

--- Quote End ---

This is exactly the reason why I want to set a max delay on the data to be equal to those 2 or 3 clock cycles! I want the data to reach the destination register before the data_enable. Since the data_enable is delayed by a few clock cycles, I want to specify this period of time as the max delay for the data.

--- Quote Start ---

Note that I don't get the Edit: comment, that you don't want a fixed number. Are you saying you want Quartus to figure out how many delay elements you pass the enable through and apply a delay requirement for that? Or just that you will change the value for different parts of the design, which is doable, you just have to apply the constraint between registers and not clock domains.

--- Quote End ---

Sorry for the confusion: I wanted to express the second interpretation: I will change the value for different parts of the design by applying the constraint between registers and not clock domains (I was basically eliminating the use of set_max_delay between the two clock signals as a possible solution to my problem).

I'm unsure on how to proceed with this one, hence my question in the first place. Does anyone have any ideas on how to constrain this scenario?

Technically, I still think you want skew. If the data enable goes through two delay registers before enabling the destination register to accept the data, what if the source data register had clock skew that was greater than two clock periods? (Or data delay AND clock skew that was greater than two clock periods.) Then the destination register would latch in the wrong data.

Of course, you could say that you know the clock skew is way too low for that to happen, but in that case it doesn't matter that clock skew is measured in, since it's a low number.

Regardless, I'm pretty sure there is no way to just do a point to point requirement between two registers. But as I type it, and if it's pretty easy to meet timing, you could constrain it(or not) with set_max_delay, and then your analysis script could use report_path, which does report what you want, it just doesn't constrain the fitter. You could put it in a panel and check it after each compile, or put a warning out if it fails with an equation. I think you can use post_message -warning "blaa blaa blaa" or something like that.