How to fix delay between input pad and a register

[Altera_Forum]

Hi, I'm using a Cyclone V and I try to get pictures from a camera with 8 lvds channels. 

Input signals are DDR so I used 2 process to catch rising and fallin edge and I have to  get a syncronization code. It seems to work but when I add stuff in my design (unrelated with the camera)  and I compile again, I don't succeed to get some channels. I think the problem is during Place & route but I'm not sure. Is there a way to force to place all the syncronization part near the input pads connected to the camera ?  Thanks,

[Altera_Forum]

Hi,  

 Do you have input and clock constrains in your design? Have you checked TimeQuest reports to see if your design meets timing?

[Altera_Forum]

Thanks for your reply. 

 I have set input and clock constrains in my design but I'm not sure I'am using it right. When I set an input or output delay, is there a consequence on placement and routing or is it just to perform time analysis ? And when I set maximum and minimum delay ?

[Altera_Forum]

First of all, your design should be properly constrained. Without that how can you tell that delay is to large? 

 Place and route process tries to get positive slack in all paths inside FPGA to meet your timing requirements. So yes there are consequences. Basically with timing constrains you are telling with what timing parameters data reaches FPGA from external device and you want that your design should be working at X MHz clock rate. Then TimeQuest will tell you if your design can work that way. If it fails timing at this point you can not solve timing problems by entering some numbers in .sdc file. You should change your design, add PLL to phase shift clocks ect.   Try to properly constrain your design. Run timing analysis to see if there are critical paths which fails timing.

[Altera_Forum]

Ok thanks, it's really helpful.  

 I have other questions about timing contraints if you don't mind : - if there is a setup time issue and latch and lauch clock are not the same but in the design, but it is not important if the data arrives 2 or 3 edges of clock latch later, do i need to use multicycle path ? - How is it possible to fix removal & recovery mode with global asynchronous reset ?

[Altera_Forum]

--- Quote Start ---   - How is it possible to fix removal & recovery mode with global asynchronous reset ?  --- Quote End ---    Removal and recovery are asynchronous equivalents of setup and hold. The same rules apply as there, recovery and removal errors can be caused by high fan outs and long nets. I assume your global async reset is a synchronised version of some asynchronous reset signal (like a button). You would apply the reset asynchronously and remove it synchronously. Once you've done this, and still get recovery and removal violations: 1. Duplicate the synchronisation registers in the reset path and have different parts of the chip reset from different nets. 2. Use a Global Clk net to get the reset around the chip quickly 3. Set a max delay on the reset

[Altera_Forum]

--- Quote Start ---  First of all, your design should be properly constrained. Without that how can you tell that delay is to large?  Place and route process tries to get positive slack in all paths inside FPGA to meet your timing requirements. So yes there are consequences. Basically with timing constrains you are telling with what timing parameters data reaches FPGA from external device and you want that your design should be working at X MHz clock rate. Then TimeQuest will tell you if your design can work that way. If it fails timing at this point you can not solve timing problems by entering some numbers in .sdc file. You should change your design, add PLL to phase shift clocks ect.   Try to properly constrain your design. Run timing analysis to see if there are critical paths which fails timing.  --- Quote End ---    One other note on this: make sure your PLL for input capture is set to source synchronous mode to match up the data and clock paths for the input DDR signals.

[Altera_Forum]

--- Quote Start ---  Removal and recovery are asynchronous equivalents of setup and hold. The same rules apply as there, recovery and removal errors can be caused by high fan outs and long nets. I assume your global async reset is a synchronised version of some asynchronous reset signal (like a button). You would apply the reset asynchronously and remove it synchronously. Once you've done this, and still get recovery and removal violations: 1. Duplicate the synchronisation registers in the reset path and have different parts of the chip reset from different nets. 2. Use a Global Clk net to get the reset around the chip quickly 3. Set a max delay on the reset  --- Quote End ---    In fact, I am processing a frame from a cmos sensor and doing conditioning on it. At the end of each frame processed, I apply an asyncronous reset (driven by an internal fpga signal) to ensure that the system always start a new frame in the same condtion.   1 - About creating syncronizer for metastability, I am not sure to understand how to do this. I have written in vhdl design a cascade of register, I have assigned each register "Syncronizer Identification"= "Forced" but I still have same result in Timequest Analysis... Do I miss something ? 2 - I have assign "Global signal"="Global Clock" to reset register but still no different result in Timequest, is it normal ?

[Altera_Forum]

1. How is the asynchronous reset generated? is it from a synchronous source? if so, then there is no problem and no need for synchronisation. Altera recommends async resets are asserted asynchronously but synchronously de-asserted. So if it is generated on the same clock domain then no problem. I do recommend having the reset come directly from a register, not from logic (as this could cause from R+R delays) 

2. You may have to manually instatiate a CLKCTRL block to get it onto the global nets. There are attributes to do this too.  See http://quartushelp.altera.com/14.1/mergedprojects/hdl/prim/prim_file_global.htm

[Altera_Forum]

--- Quote Start ---  1. How is the asynchronous reset generated? is it from a synchronous source? if so, then there is no problem and no need for synchronisation. Altera recommends async resets are asserted asynchronously but synchronously de-asserted. So if it is generated on the same clock domain then no problem. I do recommend having the reset come directly from a register, not from logic (as this could cause from R+R delays) 2. You may have to manually instatiate a CLKCTRL block to get it onto the global nets. There are attributes to do this too.  See http://quartushelp.altera.com/14.1/mergedprojects/hdl/prim/prim_file_global.htm  --- Quote End ---    Thanks for the link. The reset is generated directly from a register but it resets registers in differents clock domains.