--- Quote Start ---
I guess so. Note that by default the latch edge is always after the launch edge(we could use multicycle assignments to change that, but for now let's stick with that.) So when data is launched at time 0ns, the first assignment says it will be available between 1-3ns. First off, you're probably not going to meet that requirement, so if you go with this you won't be able to close timing. It's also kind of weird to say that your data needs to be available 9ns before the latch clock edge, as that's such a large number. (I'm somewhat curious where your 1-3ns range came from, as it's kind of strange. It could be correct, but it's uncommon.)
The second set say when it launches at time 0ns that data will be latched by the 10ns clock between times 11-13ns. You are much more likely to meet timing here, but this is still somewhat strange as your data doesn't have to be valid until after the clock edge. I have seen this more often, but it's still pretty uncommon. (And is the clock period really 10ns, as I thought I made that up as an example.)
--- Quote End ---
In my opinion both cases are equivalent in terms of valid window.
The second case says in effect I don't mind one clock delay ad should be easier to achieve. This is same as applying mcp of 2 for setup, 0 for hold.
For io stream, we usually don't care if stream is delayed by (n) clocks as long as stream is correct.
Honored Contributor
