Using Timequest to Analyze Processor Bus Interface

[Altera_Forum]

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.

[Altera_Forum]

--- 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.

[Altera_Forum]

Hi Kaz, 

Thanks for the response but I was hoping this wouldn't be the answer. I presume that in your description above, we need standard 2 flop synchronizer for address and data. I was thinking that maybe a pipelined compare and decode might do the trick for address but that might still be susceptible to metastability. Thoughts?

[Altera_Forum]

--- Quote Start ---  Hi Kaz, Thanks for the response but I was hoping this wouldn't be the answer. I presume that in your description above, we need standard 2 flop synchronizer for address and data. I was thinking that maybe a pipelined compare and decode might do the trick for address but that might still be susceptible to metastability. Thoughts?  --- Quote End ---    I really don't see any other solution. two stage is tiny resource in many fpgas. you will need two registers + 1 delay for rd signal. registers for address and data synchronisers and a third set for addres/data to enable sampling on rd.  For wr and wrdata to processor that is not fpga responsibility but processor's and I don't see what you can do here apart from slowing down transfers.  So in principle this interface is asynchronous and reminds me of RS232 ...etc. which need its own protocol on either side.

[Altera_Forum]

--- Quote Start ---  Hi Kaz, Thanks for the response but I was hoping this wouldn't be the answer. I presume that in your description above, we need standard 2 flop synchronizer for address and data. I was thinking that maybe a pipelined compare and decode might do the trick for address but that might still be susceptible to metastability. Thoughts?  --- Quote End ---    Typically for a bus like this (address and data timing related to some control signal) a two stage synchronizer is only required on the 'master' bus cycle control signal that is asserted to start (ie, falling edge) and to end (ie, rising edge) a bus transaction. Address/data/mode are then specified with a known setup before cycle start, and hold after cycle end that allows only a signal rank of registers to be used to capture valid address/data/etc.

[Altera_Forum]

--- Quote Start ---  We have a design with a processor connected to the FPGA using standard address, data and control signals...  --- Quote End ---    What control signals do you have available?

[Altera_Forum]

Chip select, rd/wr strobe

[Altera_Forum]

--- Quote Start ---  Chip select, rd/wr strobe  --- Quote End ---    indeed not too much to work with.