synchronous data in, synchronous data out issue

[Altera_Forum]

I have a single data rate edge-aligned (video) input signal consisting of the following lines: 

IMAGER_PCLK (the pixel clock) IMAGER_VSYNC (vertical sync pulse) IMAGER_HSYNC (horizontal sync pulse) IMAGER_DATA(15 downto 0) (16 bits parallel data)   My goal is simple, I want to have a process that latches the input signal and then outputs it to the following output lines: ECU_PCLK (the pixel clock) ECU_VSYNC (vertical sync pulse) ECU_HSYNC (horizontal sync pulse) ECU_DATA(15 downto 0) (16 bits parallel data)   The latency of data coming in and data coming out of the FPGA is not important, but the relation between the pixel clock and the vsync, hsync and data lines is (needs to be in sync)! Because of the latter, I applied data input and data output constraints based on datasheet values.    A snipped of my top level vhdl file given below:    architecture logic of temp_project is signal imager_pclk_launch : std_logic := '0'; -- frequency of IMAGER_PCLK not shifted signal imager_pclk_latch : std_logic := '0'; -- frequency is 2xIMAGER_PCLK 90 degrees shifted -- we use ALTCLKCTRL ip block because IMAGER_PCLK is not connected to dedicated input pin component imager_pclk_regional is port ( inclk : in std_logic := '0'; outclk : out std_logic ); end component imager_pclk_regional; -- we use Altera PLL ip block to generate the (source synchronous) latch clock component imager_pclk_pll is port ( refclk : in std_logic := '0'; rst : in std_logic := '0'; outclk_0 : out std_logic ); end component imager_pclk_pll; begin u0: component imager_pclk_regional port map ( inclk => IMAGER_PCLK, outclk => imager_pclk_launch ); u1: component imager_pclk_pll port map ( refclk => imager_pclk_launch, rst => ECU_RESET, outclk_0 => imager_pclk_latch ); p1: process (imager_pclk_latch) begin if (imager_pclk_latch'event and imager_pclk_latch = '1') then ECU_PCLK <= IMAGER_PCLK; ECU_VSYNC <= IMAGER_VSYNC; ECU_HSYNC <= IMAGER_HSYNC; ECU_DATA <= IMAGER_DATA; end if; end process p1; end logic;    My Synopsys Design Constraint file is given below:   # **************************************************************# Create Clock# ************************************************************** create_clock -period 13.468 # **************************************************************# Create Generated Clock# ************************************************************** derive_pll_clocks create_generated_clock -source # **************************************************************# Set Clock Uncertainty# ************************************************************** derive_clock_uncertainty # **************************************************************# Set Input Delay# ************************************************************** # IMAGER clock domain (edge-alligned single data rate input signals) set_input_delay -clock -min -2.500 }] set_input_delay -clock -max 2.000 }] # **************************************************************# Set Output Delay# ************************************************************** # ECU clock domain (edge-alligned single data rate input signals) set_output_delay -clock -min -2.500 }] set_output_delay -clock -max 2.000 }] # **************************************************************# Set Maximum Delay# ************************************************************** set_max_delay -from }] -to }] 13.468 # **************************************************************# Set Minimum Delay# ************************************************************** set_min_delay -from }] -to }] 0    The problem is that I get timing violations, see picture timing_violations.JPG for more information. Furthermore, I have an unconstrained clock ECU_PCLK~reg0.  http://www.alteraforum.com/forum/attachment.php?attachmentid=11504&stc=1   It would be great is someone could help me fix these issues.  Thanks in advance.  Regards, Richard.

[Altera_Forum]

You've generated a gated clock in 'ECU_PCLK'. Gated clocks are not a good idea and often result in, as you've seen, timing problems. However, I'm not sure that's a problem... 

   --- Quote Start ---   I want to have a process that latches the input signal  --- Quote End ---   So, when 'imager_pclk_latch' is active (high) 'ECU_PCLK' simply latches the state of 'IMAGER_PCLK'? Is that right? In which case 'ECU_PCLK' isn't a clock. However, you've constrained it as one in your generated clocks section.  You've also constrained 'ECU_VSYNC', 'ECU_HSYNC' & 'ECU_DATA' with respect to 'ECU_PCLK'. However, (I'm pretty sure - you've not posted all the code) they're not generated from this clock.  Does your code do what you're expecting - in simulation? What frequency is 'imager_pclk_latch'? I think I need a more complete picture to fully help.  Cheers, Alex

[Altera_Forum]

--- Quote Start ---  You've generated a gated clock in 'ECU_PCLK'. Gated clocks are not a good idea and often result in, as you've seen, timing problems. However, I'm not sure that's a problem...   So, when 'imager_pclk_latch' is active (high) 'ECU_PCLK' simply latches the state of 'IMAGER_PCLK'? Is that right? In which case 'ECU_PCLK' isn't a clock. However, you've constrained it as one in your generated clocks section.  You've also constrained 'ECU_VSYNC', 'ECU_HSYNC' & 'ECU_DATA' with respect to 'ECU_PCLK'. However, (I'm pretty sure - you've not posted all the code) they're not generated from this clock.  Does your code do what you're expecting - in simulation? What frequency is 'imager_pclk_latch'? I think I need a more complete picture to fully help.  Cheers, Alex  --- Quote End ---    Alex, you're right, I believe I do not want ECU_PCLK to be a gated clock, I want it to be a 'real' clock. Actually I want it to be an exact copy of IMAGER_PCLK.  What I really want is that the FPGA at every rising edge +90 degrees of IMAGER_PCLK captures the state of the IMAGER_VSYNC, IMAGER_HSYNC and IMAGER_DATA(15 downto 0) and then set ECU_VSYNC, ECU_HSYNC and ECU_DATA(15 downto 0) accordingly. ECU_PCLK may be derictly derived from IMAGER_PCLK as long as ECU_VSYNC, ECU_HSYNC and ECU_DATA(15 downto 0) lines are edge-aligned with respect to ECU_PCLK. For constraining the edge-alignment I use the values which can be found in the Synopsys Design Constrain file (min=-2.5ns max=2.0ns).  I posted all of the code. It might look useless to just copy the input state from the IMAGER to the ECU output, but I want to add functionality to the process (lets say a shift operation on the data lines) to the process later.  Regards, Richard.

[Altera_Forum]

What frequency is 'IMAGER_PCLK'? 

 Assuming it's appropriate, I suggest you use a PLL, driven by 'IMAGER_PCLK', with two output clocks. The first you will use internally to the FPGA. This will latch the data in to and out of the FPGA. The phase of this clock will need to be appropriately aligned to the data on the incoming 'IMAGER_XXX' signals. The second clock output will drive out of the FPGA. This one you will shift in phase with respect to the data coming out on your latched 'ECU_XXX' signals, to suit the alignment requirements of the device receiving these signals.   If the frequency of 'IMAGER_PCLK' is too low for this (which it may well be, depending on the VGA resolution you're using) then you'll have to use an independent, faster clock to latch the data at 90 degrees. You can then either regenerate 'ECU_PCLK' with logic or, as per your original design, simply drive it directly from 'IMAGER_PCLK'.  Cheers, Alex

[Altera_Forum]

--- Quote Start ---  What frequency is 'IMAGER_PCLK'?  Assuming it's appropriate, I suggest you use a PLL, driven by 'IMAGER_PCLK', with two output clocks. The first you will use internally to the FPGA. This will latch the data in to and out of the FPGA. The phase of this clock will need to be appropriately aligned to the data on the incoming 'IMAGER_XXX' signals. The second clock output will drive out of the FPGA. This one you will shift in phase with respect to the data coming out on your latched 'ECU_XXX' signals, to suit the alignment requirements of the device receiving these signals.   If the frequency of 'IMAGER_PCLK' is too low for this (which it may well be, depending on the VGA resolution you're using) then you'll have to use an independent, faster clock to latch the data at 90 degrees. You can then either regenerate 'ECU_PCLK' with logic or, as per your original design, simply drive it directly from 'IMAGER_PCLK'.  Cheers, Alex  --- Quote End ---    Hi Alex,  Thanks a lot for your detailed reply!! Based on your reply I modified my design and Synopsys Design Constraint file. Below is my new VHDL file:   architecture logic of temp_project is signal imager_pclk_launch : std_logic := '0'; signal imager_pclk_latch : std_logic := '0'; signal ecu_pclk_launch : std_logic := '0'; signal temp_data : std_logic_vector(15 downto 0); signal temp_vsync : std_logic; signal temp_hsync : std_logic; component imager_pclk_regional is port ( inclk : in std_logic := '0'; outclk : out std_logic ); end component imager_pclk_regional; component imager_pclk_pll is port ( refclk : in std_logic := '0'; rst : in std_logic := '0'; outclk_0 : out std_logic; outclk_1 : out std_logic ); end component imager_pclk_pll; begin u0: component imager_pclk_regional port map ( inclk => IMAGER_PCLK, outclk => imager_pclk_launch ); u1: component imager_pclk_pll port map ( refclk => imager_pclk_launch, rst => ECU_RESET, outclk_0 => imager_pclk_latch, outclk_1 => ecu_pclk_launch ); p1: process (imager_pclk_latch) begin if (imager_pclk_latch'event and imager_pclk_latch = '1') then temp_vsync <= IMAGER_VSYNC; temp_hsync <= IMAGER_HSYNC; temp_data <= IMAGER_DATA; ECU_VSYNC <= temp_vsync; ECU_HSYNC <= temp_hsync; ECU_DATA <= temp_data; end if; end process p1; ECU_PCLK <= ecu_pclk_launch; end logic;   And my SDC file:   create_clock -name IMAGER_PCLK -period 13.468 create_clock -name virt_imager_pclk -period 13.468 create_clock -name virt_ecu_pclk -period 13.468 create_generated_clock -name ECU_PCLK -source .gpll~PLL_OUTPUT_COUNTER|divclk] set_input_delay -max -clock virt_imager_pclk 2.000 }] set_input_delay -min -clock virt_imager_pclk -2.500 }] set_output_delay -max -clock virt_ecu_pclk 2.000 }] set_output_delay -min -clock virt_ecu_pclk -2.500 }] derive_pll_clocks   The frequency of IMAGER_PCLK is 74.25MHz. The clock used for the process, imager_pclk_latch, is 74.25MHz, shifted 180 degrees (with respect to IMAGER_PCLK). All my input timing violations are gone and I concluded that the 180 phase shift is correct. The clock used to drive out of the FPGA, ecu_pclk_launch, is 74.25MHz, not shifted (with respect to IMAGER_PCLK). I tried a few phase shifts (0, 90, 180, 270) for ecu_pclk_launch but I did not succeed to get rid of the output timing violations (every time I tried another phase shift I also changed the waveform of the virt_ecu_pclk accordingly).  My question is whether i'm still doing something wrong? Am I missing something? I there a guideline for trying different phase shifts for launch/latch clocks instead of just trying the brute force way? Is my SDC file complete? Is there a way to reduce the data path lengths or to apply trace length matching within the FPGA?  Thanks in advance! Any help is again much appriciated.  Kind regards, Richard.

[Altera_Forum]

--- Quote Start ---  What frequency is 'IMAGER_PCLK'?  Assuming it's appropriate, I suggest you use a PLL, driven by 'IMAGER_PCLK', with two output clocks. The first you will use internally to the FPGA. This will latch the data in to and out of the FPGA. The phase of this clock will need to be appropriately aligned to the data on the incoming 'IMAGER_XXX' signals. The second clock output will drive out of the FPGA. This one you will shift in phase with respect to the data coming out on your latched 'ECU_XXX' signals, to suit the alignment requirements of the device receiving these signals.   If the frequency of 'IMAGER_PCLK' is too low for this (which it may well be, depending on the VGA resolution you're using) then you'll have to use an independent, faster clock to latch the data at 90 degrees. You can then either regenerate 'ECU_PCLK' with logic or, as per your original design, simply drive it directly from 'IMAGER_PCLK'.  Cheers, Alex  --- Quote End ---    Alex,  Just wanna bring this to your attention again. Sorry for being pushy.   Can you please reply on my last post?  Thanks in advance.  Kind regards, Richard.

[Altera_Forum]

--- Quote Start ---  every time I tried another phase shift I also changed the waveform of the virt_ecu_pclk accordingly  --- Quote End ---  I'm not sure what you mean by this?   How did you come up with your min/max output delay values? The fact their the same as your input delay values makes me suspicious.  How did you put your sdc file together? What are your 'ECU_XXX' signals driving? What setup and hold times does that device require?  The question of how to correctly specify timing constraints is frequently discussed and frequently described badly. So, I'm not going to risk doing the same by explaining how I think of it.  However, I'll refer you to a document I've previously found useful. The timequest user guide (https://www.google.nl/url?sa=i&rct=j&q=&esrc=s&source=images&cd=&cad=rja&uact=8&ved=0ahukewj9ylzhr7rjahwi7hokhrxbaggq5tuicq&url=http%3a%2f%2fwww.eet.bme.hu%2f~nagyg%2fmikroelektronika%2ftimequest_user_guide.pdf&psig=afqjcnh7w_3m7obncm5ryoefdwvvbzuqfg&ust=1449049374815784) has a section on I/O Timing. It talks you through both input and output delay in a way that, I found, somewhat clearer than many explanations I've read.  I hope that helps.  Cheers, Alex

[Altera_Forum]

--- Quote Start ---  I'm not sure what you mean by this?   How did you come up with your min/max output delay values? The fact their the same as your input delay values makes me suspicious.  How did you put your sdc file together? What are your 'ECU_XXX' signals driving? What setup and hold times does that device require?  The question of how to correctly specify timing constraints is frequently discussed and frequently described badly. So, I'm not going to risk doing the same by explaining how I think of it.  However, I'll refer you to a document I've previously found useful. The timequest user guide (https://www.google.nl/url?sa=i&rct=j&q=&esrc=s&source=images&cd=&cad=rja&uact=8&ved=0ahukewj9ylzhr7rjahwi7hokhrxbaggq5tuicq&url=http%3a%2f%2fwww.eet.bme.hu%2f~nagyg%2fmikroelektronika%2ftimequest_user_guide.pdf&psig=afqjcnh7w_3m7obncm5ryoefdwvvbzuqfg&ust=1449049374815784) has a section on I/O Timing. It talks you through both input and output delay in a way that, I found, somewhat clearer than many explanations I've read.  I hope that helps.  Cheers, Alex  --- Quote End ---    Alex, thanks again for your reply! At a first glance that document you refer to seems very detailed and useful. Until now I used a document from Altera titled "Constraining and Analyzing Source-Synchronous Interfaces" but that did not help a lot.  Regards, Richard.