Honored Contributor
Honored Contributori have a question about this... i may not have completely understood the document but in my case the transmitter and the receiver won't have a PLL neither i'll have a PLL on the board. in this case i assume the board has uniform delay on clock and data.
from the document it's not clear how to set up the whole thing if a PLL is not involved in fact if for example i create my virtual clock as: create_generated_clock -name ODCLK -source [get_ports {iDCLK}] [get_ports {oDCLK}] where oDCLK is the source synchronous clock pin, and define data delays as: set_output_delay -max -clock DCLK -reference_pin [get_ports {oDCLK}]# # [get_ports {oMUXDATA[*]}] set_output_delay -min -clock DCLK -reference_pin [get_ports {oDCLK}]# # [get_ports {oMUXDATA[*]}] set_output_delay -clock_fall -add_delay -max -clock DCLK -reference_pin [get_ports {oDCLK}]# # [get_ports {oMUXDATA[*]}] set_output_delay -clock_fall -add_delay -min -clock DCLK -reference_pin [get_ports {oDCLK}]# # [get_ports {oMUXDATA[*]}] when i do the timing analysis it seems to me timequest is not considering the delay of the output clock and is relating the data arrival to the internal clock rather than the external one regardless of the -reference_pin directive. i expect that even without 90 degrees shift and with proper settings it should be possible to instruct the router to shift the output clock in a way that there's enough room for latching data at the other hand safely the reason why i don't want/can't use a PLL is that my input clock rate varies largely as data is coming frm a DVI receiver which can output between 25 and 165 MHz so there won't be a one-size-fits-all setup for the PLL that would make it work... thank you in advance for your help!
