Constraining Asynchronous I/O´s

[Altera_Forum]

Hi, 

I am currently in the process of constraining a design using timequest (Cyclone III). Thus far I have been successfuly able to constrain a synchronous interface using the set_input_delay command. However I still see many unconstrained inputs and outputs when I execute the report_ucp command which i am working on constraining   Many of the unconstrained ports are asynchronous inputs and I don´t really care at what time they arrive. I have for example an asynchronous reset and I don´t care if it takes 2ns or 22ns to reach the register. I was using the set_max_delay and set_min_delay to constrain this port. Is this the correct way to go about it?    Anyway my main question is, what time should I put if I don´t really care? I don´t want to put something aggressive that may be difficult to meet for the fitter and therefore may cause other important constraints not to be met. Generally what do people do when presented with a situation like this? By way of testing my constraints, I have used 15ns for the max and 0 ns for the min for the 3 registers that are affected by this reset, but I have not used any method for calculating these values (other than the clock which controls most of the logic has a period of 15ns). By having such a large gap between min and max, it is possible that the arrival times for different registers could differ substanially? e.g. one could be reset at 2ns and another at 14ns. (Not that this would be a problem)   Also I have a similar issue with outputs. I am resetting various components on the board from the FPGA based on the value written by another component in an internal register of the FPGA. These resets are triggered on a clk edge but I do not really care how long it takes the reset to reach the target component. The set_max_delay and set_min_delay commands can be used again, but I would be grateful if someone could give me some guidance on how to elect a sensible delay value to constrain these ports.   Many thanks for the help.

[Altera_Forum]

Most people just don't constrain these and allow them to show up in the UCP report. 

Some people will put a set_input/output_delay constraint on it, so it's not longer in the UCP report, and then add a set_false_path to it.  If you want an actual number, do a couple clock periods, something it could easily meet. You state that one reset could be at 2ns and one at 14ns and this would not be a problem. Constraints are generally supposed to show where it would be a problem, so if there is no condition, there is no need. That being said, I understand the safety blanket of wanting it bounded. There's always the, if it were 1000ns later, it might be a problem thought. Note that, even on unconstrained paths, the fitter will try to put things close together and use as little routing as possible, as this frees up resources for the critical stuff. It will always give constrained paths(that are tight on timing) priority on resources, but it's not like unconstrained paths will just be routed around the device a few times and be many tens to hundreds of ns long.

[Altera_Forum]

Thank you for your response Rysc. 

 You mentioned that people would place a "set_input/output_delay " constraint on it. I didn´t realise it was possible to use this constraint without using a clock. Can you just verify that for me?   Also just one final thing I was curious about: I have some combinational logic carrying out a certain function which need to complete in 45ns once a signal is asserted. Quartus has no issue in meeting this time, but it does show up in the UCP, so I had a go at constraining it. I placed the following constraints (which it meets comfortably): set_max_delay = 20ns set_min_delay = 0ns  My question is, is there any need to place the min constraint? Obviously Quartus can´t do it in 0ns, but it may do it in 8ns without any problems, so I didn´t want to put a min constraint in which would be above a value which Quartus could meet comfortably. Is just specifying the max delay sufficient in this case? What does Quartus do in this case, settle on any value less than 20ns for all corners or would it attempt to the delay close to 20ns? (I seem to remember reading something about classic timing analyzer when I used to use it where only specifying a max constraint would imply a min constraint of the same value, does timequest work in the same way?)   Many thanks for the help

[Altera_Forum]

They create a clock like: 

create_clock -name notaclock -period 1.0 and use that. Note that I said they put in the constraint(to satisfy the unconstrained paths check) and then do a set_false_path assignment so it's not analyzed, and the clock doesn't really matter. The min is up to you. In general it doesn't hurt and some people feel like they're doing everything, while others think it's more confusing. My only comment is to be sure you comment where each I/O timing constraint came from. Be as verbose as necessary: set_min_delay -from -to 0ns ;# I made up this 0ns delay just to have a constraint, even though it could never be violated 2009_06_09.   Designs get passed around, picked up years later, etc., and I hate when they have timing constraints that no one knows where it came from or why it's important, but yet they won't change it and have to continue meeting it.

[Altera_Forum]

Thanks for the advise Rysc. 

I have been trying to comment my .sdc file clearly as you mentioned, as I did have a bad experience about 6 months ago. I was working on an old design done by someone else with random contraints placed all over the place with no proper explanations. It was a nightmare and something I wouldn´t want anyone to have to go thorugh again.

[Altera_Forum]

I am interested in the use of a 'notaclock' to allow async read paths to be constrained 

I have a register block in my CPLD that is accessed to by a processor using a fairly standard async bus with addr, /cs, /rd, /wr and data lines  I find that I can do the following quite happily:  either...  a) Constrain my write timings by defining /wr as a write clock with timings that match my processor, and set_input_delays on the addr and cs that match the write cycle waveform from the processor  or...  b) Constrain my read timings by using set_max_delay -from[get_ports{/cs /addr /rd}] -to[get_ports{data}] <processor's required read decode Tpd time, ns>  But when I put both together, the set_input_delays used to constrain writes get added to the read decode timings, so my read decode time appears much longer than it really is Worse, I cannot just add matching extra margin to set_max_delay in order null the unwanted set_input_delays. This is because some of my registers are write/read so have a write clock associated (and so set_input_delays times are added to the read decode logic), but some regs are read only, so have no delays added   Q: Can I use a 'notaclock' to trick the set_max_delay constraint to just 'work' and time the async addr, /cs, /rd --> data decode timing and get rid of the unwanted write delay additions? Is there any other simple way around these problems that I have missed?