Skew constraints on asynchronous signals

mtwieg said:

In a design I'm working on, I have two PWM signals generated by a switchmode power supply controller. The two signals are "mostly" complementary with a small amount of dead time t_dead inserted where both signals must be low. For my application, t_dead is around 5ns.
View attachment 173551
I want to use an FPGA to gate both these signals, but want to ensure skew is limited so t_dead is not significantly altered.

I'm fairly new to SDC. I am aware of the set_max_skew command, but all the guidance I see on its usage refer to clocks or signals launched by clocks, whereas in my case my signals are totally asynchronous. And I want to consider skew all the way from the input pin to the output pin (including io delays), but most of the examples only consider pins to registers, or registers to pins.

The example I've found that seems most relevant is this:


But I don't really see how to adopt this to my needs. Let's assume my code looks like this:

Code:

entity pwm_example is
    port (
        pwmA_in        : in    std_logic;
        pwmB_in        : in    std_logic;
        pwmA_out    : out    std_logic;
        pwmB_out    : out    std_logic;
        pwm_en        : in    std_logic
    );
end pwm_example;

architecture rtl of pwm_example is
-- no declarations!
begin
    pwmA_out <= pwmA_in when (pwm_en='1') else '0';
    pwmB_out <= pwmB_in when (pwm_en='1') else '0';
end rtl;

So I want to constrain skew between the in > out paths (skew from the pwm_en signal isn't a concern).

Click to expand...

FPGAs are meant for synchronous design and its timing targets clocked signals. So in principle you cannot control your signals by defining delays through constraints which will vary anyway from build to build.
Why don't you try a clock at say 200 MHz for 5 ns resolution then you can control both the dead and the live sections of your signals.

kaz1 said:

FPGAs are meant for synchronous design and its timing targets clocked signals. So in principle you cannot control your signals by defining delays through constraints which will vary anyway from build to build.

Click to expand...

Not sure what you mean by "vary from build to build". Surely the timing analyzer is capable of checking the total delays along paths through combinational logic and IO. In principle, all I want is to do that, then take the difference between different paths, and report a timing error if it's above a max skew or not.

kaz1 said:

Why don't you try a clock at say 200 MHz for 5 ns resolution then you can control both the dead and the live sections of your signals.

Click to expand...

The dead time is around 5ns, but the timing resolution of the edges is actually <0.2ns, so I would need a >5GHz clock to avoid degrading the timing resolution (which is critical in my application). Far beyond the specs of my FPGA.

Although SDC is focussed on synchronous design, it can constrain purely asynchronous paths without registers. According to documentation, set_minimum_delay and set_maximum_delay is suited for port to port delay. There's probably no relative (skew) constraint.

FvM said:

Although SDC is focussed on synchronous design, it can constrain purely asynchronous paths without registers. According to documentation, set_minimum_delay and set_maximum_delay is suited for port to port delay. There's probably no relative (skew) constraint.

Click to expand...

My understanding of Quartus/Vivado STA and their sdc processing is that if there is no clock there is no timing path to report. If there is clock the tool targets passing tSU/tH relevant to that clock and once achieved it stops there. So the primary question raised is "can" or "how" a design can be constrained in an FPGA without any clock, and especially so for delays such as 0.5ns. I can imagine that is possible in ASIC.
The set_min_delay/set_max_delay are meant for clock as alternative to tH, tSU, or multicycle paths as well as for ports instead of set_input_delay/set_output_delay. This is still tied up to clock concept at io port. So please, FvM , can you elaborate on your thoughts on how to constrain an asynchronous path in an FPGA without any clock.
I believe FPGA vendors could have done that but their central design methodology is based on clocks.

kaz1 said:

My understanding of Quartus/Vivado STA and their sdc processing is that if there is no clock there is no timing path to report.

Click to expand...

Well without a clock there certainly aren't any tsu or th to report, but there still is delay. From what I understand, report_path just reports delays, not slack or tsu/th. Maybe as a first step I should just have my tcl report the delays for each pwm signal.

kaz1 said:

If there is clock the tool targets passing tSU/tH relevant to that clock and once achieved it stops there. So the primary question raised is "can" or "how" a design can be constrained in an FPGA without any clock, and especially so for delays such as 0.5ns. I can imagine that is possible in ASIC. The set_min_delay/set_max_delay are meant for clock as alternative to tH, tSU, or multicycle paths as well as for ports instead of set_input_delay/set_output_delay.

Click to expand...

I think I understand where you are coming from. In general, meeting tsh/th (plus removal/recovery) is the only objective. But then what it the intended purpose of set_max_skew?

FvM said:

Although SDC is focussed on synchronous design, it can constrain purely asynchronous paths without registers. According to documentation, set_minimum_delay and set_maximum_delay is suited for port to port delay. There's probably no relative (skew) constraint.

Click to expand...

So again, what is set_max_skew for? Maybe the definition of "skew" it's referring to is completely different from what I'm interested in?

Reporting delays on any path is available after STA is done provided the path survives fitting. I have noticed that a pass/fail of timing means synchronous paths only. If the tool does not achieve your specific request then it is up to you to get specific report on your path. The tool is not obliged to apply your delay constraints if it passes tSU/tH timing. For example you may set min/max delay more restrictive than clock frequency and so I expect they will be ignored because internal max delay is meant to be alternative to tSU and min delay is meant to be alternative to tH. For ports it is meant to inform the tool for same purpose regarding data/clock relationship at ports.

set_max_skew is meant for multiple registers/nodes such as a data bus with 2 bits or more. So it may apply to your ports . You can experiment directly and see. My main concern is that if we divert from intended methodology of synchronous design then it becomes a case of experimenting that may or may not succeed.

@mtwieg you should probably consider specifying placement constraints for the input/output/gating logic for these "gated" signals. Co-located input/output for each of the signals, replicate the same relative placement on another set of pins, use information from the FPGA manufacturer on the package delay for pin pairs you want to use to ensure the skew is the same for both paths.

Doing the above you won't even need to add constraints other than to verify the place and route tools didn't screw up and ignore the placement or routes the signal across the die for some reason.

If you've already got a poor placement of I/O pins then you will have to live with any skew issues unless you take advantage of any skew compensation logic in the I/O that you device might have (it's the logic that is used to run DDRx memory interfaces). That would have to tuned in after you've implemented the design and locked down the placement/routing of the poorly placed logic.

Other than assumed, set_max_skew also works for asynchronous paths. SDC commands are conveniently embedded in VHDL.

As mentioned by ads-ee, it's essential to place the port pins appropriately and to avoid pins that involve extra delay or delay skew.

kaz1 said:

set_max_skew is meant for multiple registers/nodes such as a data bus with 2 bits or more

Click to expand...

So skew refers to the difference in delay of a single clock along multiple paths to different registers? I suppose that's a valid use of the term, but not relevant in my case.

kaz1 said:

My main concern is that if we divert from intended methodology of synchronous design then it becomes a case of experimenting that may or may not succeed.

Click to expand...

This is what I was anticipating. I'm not expecting anyone here to promise me a working solution.

ads-ee said:

@mtwieg you should probably consider specifying placement constraints for the input/output/gating logic for these "gated" signals. Co-located input/output for each of the signals, replicate the same relative placement on another set of pins, use information from the FPGA manufacturer on the package delay for pin pairs you want to use to ensure the skew is the same for both paths.

Doing the above you won't even need to add constraints other than to verify the place and route tools didn't screw up and ignore the placement or routes the signal across the die for some reason.

If you've already got a poor placement of I/O pins then you will have to live with any skew issues unless you take advantage of any skew compensation logic in the I/O that you device might have (it's the logic that is used to run DDRx memory interfaces). That would have to tuned in after you've implemented the design and locked down the placement/routing of the poorly placed logic.

Click to expand...

Yes, locking down the synthesis of this logic sounds worthwhile, but that's another thing I've never done before. I assume it's very tool-dependent (I'm using quartus). I'll probably come back asking about that if the skew turns out to be significant.

If it turns out I chose my IO poorly and there's bad skew, it's possible for me to compensate for it on the pwm synthesis side. So long as the skew is consistent across PVT....

FvM said:

Other than assumed, set_max_skew also works for asynchronous paths. SDC commands are conveniently embedded in VHDL.

As mentioned by ads-ee, it's essential to place the port pins appropriately and to avoid pins that involve extra delay or delay skew.

Code:

library ieee;
use ieee.std_logic_1164.all;

entity async is
    port
    (
        a  :  in  std_logic;
        b  :  in  std_logic;
        en :  in  std_logic;
        qa :  out  std_logic;
        qb :  out  std_logic
    );
end async;

architecture rtl of async is

attribute altera_attribute : string;
attribute altera_attribute of rtl : architecture is
    "-name sdc_statement ""set_false_path -from [get_ports {en}]"";" &
    "-name sdc_statement ""set_max_skew 0.65 -from [get_ports {a b}] -to [get_ports {qa qb}]""";
   
begin
    qa <= a and en;
    qb <= b and en;
end rtl;

Click to expand...

Interesting, I've never seen sdc commands in source code before. Does this change how compilation/synthesis/timing analysis work vs putting everything in the sdc file?

Does this work if this entity/component is buried in deeper in a hierarchical design? I'm assuming it would only consider skew due to logic external to the component?

mtwieg said:

So skew refers to the difference in delay of a single clock along multiple paths to different registers? I suppose that's a valid use of the term, but not relevant in my case.

Click to expand...

skew affects data path so it can be applied to your inputs. clock paths are kept clean untouched. I view skew purpose as follows:

if a design passes tSU/tH timing then skew on related parallel paths is irrelevant since any skew is absorbed.
If timing is not to be checked e.g. false paths then skew control becomes important such as inside dual clock fifo on their read/write pointers.

mtwieg said:

Interesting, I've never seen sdc commands in source code before. Does this change how compilation/synthesis/timing analysis work vs putting everything in the sdc file?

Does this work if this entity/component is buried in deeper in a hierarchical design? I'm assuming it would only consider skew due to logic external to the component?

Click to expand...

Embedded SDC commands are evaluated before the global SDC file. In the present case, skew analysis is referring to design ports, respectively it should use top level pin names. That's not the typical usage of embedded SDC commands. We normally use it to constrain modules, e.g. cut the path in a synchronizer. To generate valid hierarchical names, we have wildcards for the hierachy and a combination of module and signal names to identify source and target.

As far as I understand, set_max_skew does exactly what you are requesting in post #1, ensuring that the delay skew between high and low side driver signals doesn't exceed a certain margin. The total pin-to-pin delay is varying over a range of about 5 to 11 ns over all corners, thus set max and min delay doesn't guarantee a useful skew.