I/O Timing constraints

[Altera_Forum]

Hi, 

 In our design we are using NIOS II processor running at 100MHz with many I2C, UART and SPI interfaces, DVI input and many other stuff. We are having hard time to meet timing requirements.  My question is this: How can I constrain I/Os like I2C, or UART outputs? Actually, should I?  Correct me if I am wrong: Normally, I think Quartus would try to route those signalls such a way that they will reach to the outside in 1/100MHz period because they are driven by a 100MHz clock. However, I want to inform Quartus that those signals will be at most 1/57.6KHz, so it is OK to route with a longer path. Therefore there would be more space for faster signals like DVI.  I have a clock input for DVI, so I can easly constrain DVI related signals using its clock. However there is no clock generated for UART, I2C or SPI. Actually I2C and SPI have clocks but they are created as a regular I/O.   Should I use virtual clocks (i.e. 57.6KHz clock) or multi_cycle_paths (i.e. 100M / 57.6K = 1736??), or any other syggestions?   Thanks :)   M.U. Buyuksahin

[Altera_Forum]

Serial port signals usually runs at a slow clock rate and they don't need to be constrained because a synchronization stage to the fast system clock is included in the serial port IP core. 

(With slow I mean a clock rate up to 1MHz or a few MHz. If you are driving a spi at 50MHz you do need to specify some timing constraints). The serial clock itself is usually a generated signal coming from a register or even a combinatorial net; it is not a true clock. We generally consider 'slow' serial port signals like common I/O. Then you can ignore their timing by setting them to false paths or specifying multicycles.

[Altera_Forum]

I am not concerned about timings of these slow signals, I am actually trying to create more space for others :) I want to ease routing efforts by giving Quartus an imaginary, slow (57.6K) clock, so that faster signals could be routed easily. 

   --- Quote Start ---  Then you can ignore their timing by setting them to false paths or specifying multicycles.  --- Quote End ---    Actually, Multicycle soulds resonable, but I ve never seen like multicycle_path with quite large numbers like 1700 :confused:: set_multicycle_path -setup -end -from -to 1736  false_path seems a bit risky, it may give different results compile to compile? false_path == completly ignore timings?   By the way, thank you for quick reply.

[Altera_Forum]

--- Quote Start ---   Actually, Multicycle soulds resonable, but I ve never seen like multicycle_path with quite large numbers like 1700  --- Quote End ---    You don't need to match the actual signal frequency. Even a low multicycle value, for example 10, would ease a lot the routing effort.  Infact this means you allow the signal to propagate along the path in 10 clock cycles, namely 100ns @ 100MHz. It's unlikely that those signals needs so a long delay to settle, even in the worst case. Then the router need not to worry about them and it will have more routing resources for the time critical signals.