--- Quote Start ---
We have a design with a processor connected to the FPGA using standard address, data and control signals. This processor uses an internal clock of 200 MHz to control these signals and we have a 200 MHz clock inside the FPGA. However, we do not have physical access to the internal processor clock so we have no direct timing relationship between the two clocks. Because Timequest requires clock relationships to analyze timing, what is the correct method to implement the design and analyze timing?
It would seem that because we don’t know relationship between the internal processor clock and the FPGA clock we have a problem establishing IO delays and other timing relationships with the processor. Do all the signals need to be treated as asynchronous and suffer the penalty of a 2-clock synchronizer?
We have read a number or forum entries that have some relation to this subject. We also followed the Rysc “Timequest User Guide” which is very good but doesn’t seem to cover this situation. It seems like this would be a common problem but I have not seen examples on the topic. Any advice or ideas that might address this situation would be greatly appreciated.
--- Quote End ---
Since you have signals but no clock known to fpga then all signals to and from processors have to be viewed as asynchronous transfer.
for single bit signals like rd/wr you can just pass them through two stage registers.
for address and data(multibit) you need two stage registers as well but additionally and to avoid the skew window as they cross clock domains, you need to delay
their rfd/wr signals before applying them. For example you need to delay rd/wr signals one or more clocks relative to address/data to avoid skew area then use the delayed rd/wr to sample address/data.
The use of dc fifo may not offer advantage as you only have one clock.
Honored Contributor
