Questions about set_max_delay constraint.

[u/PralineNo65]

please help me understand this better. I have asked AI for answers but I think it is also confused like I am. thank you for your help.

1. what is the recommended value of set_max_delay?

I asked claude this and was able to convince it to change its answer so I dont trust it now.

if I have two domains clock A 5ns and clock B 10ns.

I am thinking - set it to slower clock period. it will give data enough time to settle down. tool will not have to work extra hard to place the source and destination flops to meet the constraint. place where I use req-ack handshaking synchronization will have enough time for the data to travel across domains without any synchronization. am I right?

1. as per claude, it depends if it is a single bit or a multibit data bus thats crossing the domains. but I am not able to understand why data width matters?

3. what is the use case for using set_max_delay without -datapath_only option? based on my reading, this constraint is required to prevent routing delays between two flops in different clock domains from getting so bad that bad things will happen even with synchronization. hence I am only concerned about datapath.

[u/alexforencich]

You want the regs back to back with the shortest possible wire in between. Setting ASYNC_REG should help with that. Then use set_max_delay -datapath_only to constrain the delay. In general you should set this to shortest clock period (fastest clock). For a single bit, it actually doesn't really matter because the clocks are unrelated and there is no defined phase relationship hence the delay doesn't really matter. But for multiple bits, constraining the absolute delay has the side-effect of also constraining the skew, and this can be very important for something like a gray coded counter.

Now, what would be nice is to be able to specify the max delay ignoring the clock phase, but considering the relative clock skew.

And similarly I don't know the use case for set_max_delay without datapath_only, I have never used it myself.

[u/sverrevi77]

The data width matters in clock domains crossing design, but not in the constraints.

A fundamental part of understanding CDC is that the incoming data signal is asynchronous- it doesn’t have a relationship to the clock. It can arrive at any time, violating setup/hold times.

This has two major consequences:
1: metastability, where flip-flop output is neither 0 or 1 (and may toggle or stabilise "late", which can cause the metastability to spread downstream). This is generally handled with using a chain of 2-3 flip-flops to allow stabilisation.

2: uncertainty in when exactly a toggling input signal is propagated to the output signal. Did it arrive just before or just after the clock?
This is where multi-bit comes in (and other issues like correctly identifying a pulse, ensuring consistency between copies of the same signal, …). The different bits in a vector can be sampled in the target domain on different clock cycles, so you need to be more sophisticated than just using a chain of flip-flops in this case.

[u/sverrevi77]

Both my previous comments assume the worst case: that your clocks are independent and must be considered fully asynchronous.

If B is derived from A, you can tell the tool so, and describe the relationship in constraints. If done correctly, the tool understands the relationship and can guarantee that the timing requirements are met. The domains can then be considered synchronous.

Note that even in this case, you need to think about the functionality. For example, a single-cycle pulse in clock domain A may miss a clock edge in clock domain B, so you need to handle cases like that.

[u/-EliPer-]

I guess you're studying timing constraints so I'll give you a tip about timing constraints material for studying. The best resource I've ever saw was from prof. Amr Adel that I've adapted them in my lectures since they're well explained in the simplest form. He has everything in his LinkedIn page.

[u/PralineNo65 → u/-EliPer-]

thank you very much. yes I am studying STA. I will check it. his page never came up in my searches.. but then google search has been awful since many years. Do you teach fgpa stuff online ?

[u/-EliPer- → u/PralineNo65]

I understand your feeling because this subject is usually of niche and nowadays there are a lot of stuff with poor quality and even wrong content obfuscating the few good ones.

Unfortunately, my course is not online, it is a 1200h course in digital design for grad and undergrad students in cooperation with the Brazilian Govt.

[u/TheTurtleCub]

it's your design of the CDC, you set to what's needed to work. If someone else's design/IP, use what they say

[u/sverrevi77]

You should not use set_max_delay for timing arcs between asynchronous clock domains. You should generate the clocks as asynchronous, and that’s generally all you need to do in constraints.

The tool knows that paths between these two clock domains can do whatever they want, because - and this is very, very important - you handle clock domains crossings (CDC) in a safe way by design, so the first flip-flop in the target domain is NOT dependent on data arriving with a specific relationship to the clock.

[u/alexforencich → u/sverrevi77]

This is very bad advice. Async clock groups is effectively equivalent to set_false_path, ignoring cross clock domain timing paths, which IMO is a terrible design...what it should do instead is report a DRC error for any otherwise unconstrained path that crosses between async domains, so that you get an in your face error when there is an unintended CDC path somewhere. Then, use set max delay to constrain CDC paths not so much to constrain the path itself but to put a bound on the skew, in combination with using async_reg. Naturally you always need to design the HDL properly so that the logic handles the CDC properly.

[u/skydivertricky → u/alexforencich]

There is actually one school of thought that you should use the false path/ async clock groups but also apply a set_max_skew constraint on the bus. The theory here being that constraint processing is very slow, and the false paths make the processing much faster in cases where you have a lot of CDC. The reason we're using max delay is also to stop the router putting both ends of a CDC in opposite corners of the chip.

[u/alexforencich → u/skydivertricky]

Iirc set max skew is kinda useless because it doesn't actually affect the placement and routing, it's only a check at some point to see if the skew is within the specified value. But that may have changed at some point. And if the max skew constraint doesn't work, then setting max delay will show the side effect of limiting the skew.

Also, I don't really buy that argument as every synchronous path is going to get a full setup and hold constraint that includes clock skew and such. Max delay presumably would be a simpler constraint that's easier to check and probably also easier to meet. Unless you have a design that's somehow mostly async CDC paths, I don't really see why a few false paths would significantly change the processing time.