constraintsfpgaintel-fpga

What is "strictly control signal" and Why is its input unconstrained?


This is from book "STA for nanometer design"

This section describes the constraints for the input paths. The important point to note here is that STA cannot check any timing on a path that is not constrained. Thus, all paths should be constrained to enable their analysis. Examples where one may not care about some logic and can leave such in -puts unconstrained are described in later chapters. For example, one may not care about timing through inputs that are strictly control signals, and may determine that there is no need to specify the checks described in this section. However, this section assumes that we want to constrain the input paths.


Solution

  • Reading the chapter, I believe the authors are implying here that "strictly control signals" are:

    1. Signals that can change independently of whatever may be on the data path at that time
    2. Are asserted / de-asserted for a sufficiently long enough time relative to your clock such that you don't need to worry about having to capture it on only a single clock cycle

    As an example, let's say you had a physical button that you used as an input to reset your design. Even if you quickly press the button you will still produce a long enough reset relative to your design clock that you don't need an input constraint on the pin (i.e. you can consider it a false path, or set an arbitrary max delay). You just need to properly synchronize it within your design, but you otherwise don't need to care about the external delay of the signal. In this case there's no external clock either.

    A more interesting example is if you have a microcontroller producing control signals into your FPGA. This signal is going to be synchronous to some clock and may have a time scale more comparable to your FPGA design. In this case, if you can guarantee the microcontroller will satisfy the 2 conditions I mentioned above, then you can leave the input unconstrained. The benefit of this is it gives the tool more placement flexibility for logic that consumes that input, because it doesn't necessarily need to be placed close to the physical pin input buffer.

    Hope this helps!