Showing results for 
Show  only  | Search instead for 
Did you mean: 
Registered: ‎05-15-2014

I/O constraints with no clock

I've looked at several threads, one or two of which dance around the edge of this a bit, but no one seems to address the need for a simple xdc statement "this pin does not need any timing constraints, just route in however fits/works.  I don't care if the path is 10 ns or 10 ms, or if it has 1 ns of jitter or 100 ns."

What cases?  OK input from a push button.  Let's define a clock for that.  It is a human being with a highly unpredictable period of 100 ms or more and a jitter of probably at least 50 ms.  And throw in some mechanical contact bounce for good measure.  Yes, the logic needs to debounce it and synchronize it, but even the latter is rather slippery--it doesn't make any difference if it get picked up in this clock cycle or the next.

Case 2: output driving a relay (or LED or other annunciator). So let's try to define a clock for that.  The relay has a pull in time of around 25 ms with a jitter of about 10.  But again, who cares?  The relay will still operate whether driven from cycle n or n+1 of the source clock.

OK, I'm trying to insert a little humor in the process, but hopefully my point is not lost.  Timing of external signals in a digital world is often quite important, but in my experience as an embedded developer, many of my I/O's are connected to things where the concept of a clock is totally contrived.  Why can't we just say so?  Yes, there are fabricated constraints and false clock overrides, etc.  But why not a simple way to say, "This pin is a don't care.  Route it last using whatever resources are available and I will be quite happy"?


3 Replies
Registered: ‎01-23-2009

"This pin is a don't care. Route it last using whatever resources are available and I will be quite happy"?

So, first, let me address the "route it using whatever...". Almost always, the best way to deal with any input or output, is to use the IOB flip-flops; drive outputs directly from a flip-flop, capture inputs directly into a flip-flop and put the IOB property on the port

set_property IOB true [get_ports <portname>]

Yes, this means that you are creating a 1 clock period static timing path from "whatever generates the signal" to the IOB flip-flop, but the effect on the routing resources for a couple of pins will be negligible. If you really want to avoid this, you can leave the flip-flop in the fabric - if the timing is truly don't care, then this is probably OK (but I still recommend the IOB flip-flop),

Next, the question is "how do you tell the tools you don't care about timing". The answer is "Who is 'the tools'". Vivado has many aspects to it designed to help you. From the basic "static timing analysis" point of view, the answer to this is very simple; just don't supply a set_input_delay/set_output_delay command on this port. (I will stick to outputs for the rest of this post, just so that I can describe things more clearly - the inputs are the same).

Normally, a path through an output port starts at the clock pin of the flip-flop that launches the data out of the FPGA (if you use the above recommendation, that is the IOB flip-flop) - this is the "source", propagates through any logic between the source and the port, which includes the OBUF or IOBUF (again, using the IOB flip-flop, there is nothing other than the OBUF) goes of the FPGA to the system. As is, it is not part of a path - a path must have a source and a destination - from the static timing point of view, an unconstrained output port isn't a destination - there is no clock associated with the "end of the path" and hence it is not timed. Therefore, you don't need to do anything with it - just leaving it alone means it is unconstrained, and hence has no timing requirements.

However, Vivado also has a number of timing check design rule checks (DRCs) - check_timing, which is run automatically. The check_timing command looks for potentially "bad things" in your design. An unconstrained path portion is a "bad thing". So if you don't have a set_output_delay on an output port, the check_timing will flag it as two DRC warnings (I can't remember if they are "regular" warnings or Critical Warnings); an output with no set_output_delay and a path with no clock. You can simply ignore these and continue, and that's fine, but it is always recommended to fix DRC warnings (especially Critical Warnings).

The only way to fix this is to put a set_output_delay on the port - that makes check_timing happy. But, what timing value do you use? As you said, there is no timing requirement. So the "best" solution is

  • put a set_output_delay on it
    • you can use any clock and any value for the set_output_delay
    • this will keep "check_timing" happy
  • put a set_false_path on it as well
    • set_false_path -to [get_ports <port_name>]
    • (and for an input)
      • set_false_path -from [get_ports <port_name>]
    • This will remove any timing checks from the path, and hence not put any constraints on the tool in the routing of this path (if it isn't in the IOB) and will not generate any timing failure for the path (which is why you can put any clock and any delay on the set_output_delay)

With these two commands you have done what you need to keep the tool happy and to explicitly say "This port has no timing requirements".


Tags (1)
Registered: ‎05-15-2014

Thanks.  That was the conclusion I came to.  However, it is messy and "dishonest".  I work in the software/firmware world as well and we generally try to insure that all programs compile without errors or warnings--which is generally fairly easy.  Most warnings are significant, and on occasions where they aren't, something simple like a pair of parenthesis clarifies the issue and eliminates the warning.

But my experience with Vivado has been quite different.  I generally release PL designs with several hundred warnings!  None of them are significant.  Besides making my safety-critical customers uneasy, part of the bad side-effects is that when something that is significant comes up, it is easy for it to get overlooked in the "noise".  For instance, right now I'm tracking down an issue with a Verilog case statement that was supposed to be a multiplexer, but accidentally turned into a set of latches.  I belatedly discovered it, because of a warning about an invalid clock.  But it was one warning out of about 1000, 22 of which were unconstrained output pins. 

It just seems to me that rather than say, "here's a constraint.  By the way, the clock identified in the constraint has nothing to do with this pin and the numbers in the constraint are meaningless.  And also by the way, you can ignore that constraint" it would be a lot cleaner to have a command form that says no constraint is necessary.

I'd hate to be the person coming along after me and trying to understand a design with that sort of nonsense in it.  It turns HDL into a write-only language (difficult to impossible to read and understand).  I previously came across a computer language like that called RPG.

0 Kudos
Registered: ‎01-22-2015


I'm sure you understand that Avrum has answered your question given the constraints of Vivado.

Many years ago, I wrote a post and complained about the Vivado philosphy that more warnings is better.  However, it was explained to me that we are to blame - because we wanted more warnings.  Well, "we" as in not you and me.

In this day and age, it seems that we often ask-for/elect things/people that are bad for us.  

As Neil deGrasse Tyson suggested, we need a campaign to make the world smart again.