Forum Discussion
Honored Contributorset_output_delay explained for dummies
Hello. I have tried to wrap my brain around the documentation describing "set_output_delay", but I just don't seem to get it.
My brain thinks like this: "Relative to the rising-edge of my output clock, the output data needs to be valid after 1 ns and remain valid for 2 ns". The documentation describes this: "The maximum output delay (-max) is used for clock setup checks or recovery checks and the minimum output delay (-min) is used for clock hold checks or removal checks. " So to me (please correct me if I'm wrong), "setup" sounds like the earliest time the data needs to be valid, and "hold" sounds like where the data is no longer required to be valid....But datasheets usually define setup as the time to the left of the clock, and hold as the time to the right of the clock. Since the valid window is to the right, one of these values should be negative? set_output_delay -max -1 set_output_delay -min 3 am I even close?16 Replies
Altera_ForumAh okay. Your post has made me realize that I was thinking the data would arrive too early (and maybe/maybe-not going invalid before 3.0 ns) while I think you were implying it would probably arrive too late to meet the 1.0 ns requirement.
In super general concepts: The FPGA data output is going to have its own output-valid window relative to that register's clock. I need to do whatever it takes to make sure the output valid window overlaps the downstream's devices input valid window (delay either clock or data, as appropriate). I should account for PCB delays and length-mismatches as well.- Altera_Forum
The ideal clock occurs at both the FPGA and the external device at times 0ns, 10ns, etc. If the FPGA needs to get its data out within 1ns, then making the clock delay to the external device longer would help with this setup, but the clock delay to the external device is outside the FPGA, i.e. the FPGA fit can't affect that. The only things the FPGA can affect are the clock coming into the FPGA to the output register(launch clock path) and the delay from the register to the output port(data path). These two things make up the Data Arrival Path, and we essentially want them to be less than 1ns.
I recommend not spending a lot of time on hypotheticals and instead figure out your specific timing case. There are all sorts of ways you can confuse yourself with hypotheticals that are not worth the time. - Altera_Forum
Isn't pushing the output clock forward time equivalent to pushing the data backwards in time? Why wouldn't that make sense?
I thought I had it, but I think I'm back to being confused. I guess I'm still confused as to why anything needs to be pushed negative in time. If the clock is output a time zero, and the data needs to arrive at t=1.0ns, wouldn't the proper skewing be that I need to add positive delay to the data and no delay to the clock? - Altera_Forum
Yes, I'm just saying it's unlikely you'll make timing. The delay chains only make it longer. They can't make the delay negative. You can shift your launch clock back with a PLL and use multicycles to say the data is launched before 0ns, but I don't think that really makes sense.
- Altera_Forum
The example was fake and exaggerated, just for me to get the basic understanding, +/- convention down. So now that I know how to constrain an output valid window, I want to address a different part of your post: "so if you go with this you won't be able to close timing." I thought the constraint simply defines timing relative to a clock: For example, if I generate a clock on an output port and send it to the receiving device, the timing tools will check if the output data can meet timing relative to my output clock. How I actually implement the design could be different, right? Maybe I use a PLL to generate a synchronous clock with a phase offset and use that as the output clock port, but the data is still being clocked out with a different phase. This is doable, correct? And the tools should be able to interpret my circuits and still tell me that the output pin timing is met?
I assume Altera parts have programmable delay lines to also help move data/clocks around? I'm targeting Cyclone IV BTW. - Altera_Forum--- 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.
- Altera_Forum
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.) - Altera_Forum
Lights are turning on...I'm getting closer! Hopefully this ascii art prints properly...
I'm not sure I get the difference between method 1 and method 2. They are essentially defining the same setup and hold times, just at different points. Would the 2nd version indicate that when I launch the output data, it would take an extra clock cycle before being latched compared with 1st version?# launch edge # | # | # V # ________________ ________________ # Launch CLK ______| |______________| |_____________ # ^ ^ # t=0.0 t=10.0 # # _______________ # Data XXXXXXXX___V_A_L_I_D___XXXXXXXXXXXXXXXX # ^ ^ # t=1.0 t=3.0 # # latch edge # | # | # V # ________________ ________________ # Latch Clk _______| |______________| |_____________ # ^ ^ # t=-10.0 t=0.0 # ^ # _______________ | # Data XXXXXXXX___V_A_L_I_D___XXXXXXXXXXXXXXX| # ^ ^ | # t=-9.0 t=-7.0 | # | # <--------max(+)---------------| # <----min(+)----| # # max/min arrows point to positive value convention # # set_output_delay -max 9 # set_output_delay -min 7 # # # # Alternative # # launched here latched here # | | # | | # V V # ________________ ________________ # Latch Clk _______| |______________| |_____________ # ^ ^ # t=-10.0 t=0.0 # ^ # | _______________ # Data XXXXXXXX??????????xxxxxxxxxxxxxxxxxxxx|xxx___V_A_L_I_D___xxxxxxxxxx # | ^ ^ # | t=1.0 t=3.0 # | # |---> max(-) # |-----min(-)------> # # set_output_delay -max -1 # set_output_delay -min -3 - Altera_Forum
Yes, in my example the data can be invalid between times 1-7ns(and is valid between times 7-11ns, where the latch edge is at 10). You need it valid between times 1-3ns. That's kind of a strange requirement, but nothing wrong with it. There are a couple ways to do this. Let's start with what you wrote, so data must be valid between 1-3ns, i.e. you're latching between 1-3ns. Then you would have:
set_output_delay -max 9 set_output_delay -min 7 So the data must get out of the FPGA and valid within 1ns. For hold, we're saying the data being launched can't corrupt the previous latch edge, which could be as high at time -7ns, so the min delay is +7ns. By having a positive 7ns delay, your Tco could be -7ns and still meet timing. Of course, that physically can't happen. I strongly recommend drawing a waveform with the launch clock, another with the latch clock, and then draw squares to show where the data is valid(e.g. -9to-7, 1to3, 11to13,etc.) and then everything in between is invalid. One quick test I do is that 9-7=2ns, so the data must be valid for at least 2ns. So that is probably not possible to do in hardware. When you launch data at time 0ns, your 10ns latch edge is better off grabbing the valid data at times 11-13. So for that you could subtract 10ns from everything: set_output_delay -max -1 set_output_delay -min -3 Now your data must get out later than time 3ns but no longer than time 11ns. That should be pretty easy to do. (I have no idea what your clock period is, so if it's not 10ns then how easy or not easy this is could change) - Altera_Forum
The simplest way is to use the equation:
set_output_delay -max tSU set_outpt_delay -min -tH ( minus tH) This applies when clock and data go together with same delay what might confuse here is that for set_input_delay we give offset relative to launch edge for set_ouput_delay we give offset relative to latch edge
