Signal forwarding between FPGAs

How about timing / synchronization of the data?

Is a clock being forwarded from one FPGA to the other, to which the data is sychronized? If not, how do you expect the receiving FPGA to know when each data bit is valid?

If you want to treat the interface as asynchronous, you need an additional strobe from the tx which changes when a bit is valid, and some logic at the receiver side to sync to the receiver's internal clock to mitigate metastability issues.

-Tom

Heinrich schrieb:

Hi Heinrich. Everything looks fine, so far. But I'm still wondering what you are about to do with that code?

First thing: You have two FPGAs. So, how many IOs (regarding the above example) are in use on each FPGA? Two or four?

If it is four, and you are connecting the signals as shown in your example architecture inside one of your FPGAs you are creating a two-wire loop. This makes barely any sense, unless you just want to sense the presence or status of the other FPGA.

Or do you intend to have two signals on each fpga like this:

fpga1 fpga2

-------- ------------ | | a_out|----------------->| a_in | | b_in |

Thanks for your answer

Yes that is exactly what I am trying to do, the control FPGA is connected to a seriell Port and I wanna forward the rx and tx signals between the FPGAs so that I can also make use them on the target FPGA.

Yes, I also have and UCF File for the Target FPGA where I map the forwarded signals from the control FPGA. So hopefully its fine what I have implemented :)

Cheers,

The logic to handle the tx and rx bits is implemented on the target FPGA. So the only thing I have to do is just forward the rx bits on the Control FPGA to the target FPGA in "real-time" and all the other stuff is then done by a module on the target FPGA...

Well ok, but if you don't tell us what you've done, we can't tell you if you've done it correctly or not!

If you've got data lines only (no clock or async handshaking), you need clock transferred by some other method - either explicitly or in a way that the clock can be extracted/implied from the data stream.

-T

Yes, I just need the data lines forwarded from the control to the target FPGA. The target FPGA has an own clock so I dont need to forward this signal

Thx, H.

nal

OK, I don't want to keep saying the same thing, but are you sure the clock on the target FPGA is synchronous (coherent) with the one on the control FPGA?

Can you guarantee their relative phase? If you are using DCMs then you probably can't. If not, like I said, you need to make special efforts to cross the clock boundary correctly. I just want to make sure you are aware of this.

Regards

Tom

Thanks Tom, they have both the same clock Frequency but the phase doesnt matter as it is just some serial databits that need to be forwarded between them. So in the meantime everything works as it should :)

So if the relative phase isn't known, how does the receiving FPGA know #when# to read each data bit from the transmitting FPGA? More specifically, what happens if the receiving FPGA decides to read the value at its input pin just at the very same moment that it is being changed by the transmitting FPGA? (note: this is not good).

Worse than this, there are finite setup and hold time requirements on the receiving inputs that you have to make sure are being met for data to be read reliably - that involves knowing exactly when data is being read (i.e. the phase of the clock on which reads are done versus the incoming data timing). If you can't do that, then you need to forward some other method of saying when it is "safe" to read each bit (e.g. an async strobe). The fact it is "only" serial doesn't matter.

-T

Although, one of the questions that hasn't come up yet is how fast of a link and on what kind of FPGAs. Any modern part, if the OP is only trying to push 100Kbps or so, and just hooks the clocks on both FPGAs together and hopes that it just works, it really just will. There are all sorts of timescales for which the skew between the transmitting and receiving ends is effectively zero.

Sure, if the clock really is slow enough, and the same clock source drives both FPGAs, then there is not much to worry about. Except of course that the receiver should of course read (register) the incoming data on the opposite clock edge to the clock edge that the transmitter is using.

-Tom

So if the relative phase isn't known, how does the receiving FPGA know #when# to read each data bit from the transmitting FPGA? More specifically, what happens if the receiving FPGA decides to read the value at its input pin just at the very same moment that it is being changed by the transmitting FPGA? (note: this is not good).

======= Single ended serial clock and data lines fit the description and would have little difficulty. Also, RS232 serial works reasonably well without an explicit clock. The trick there is the serial clock is at least 16x slower than the device clock. You do your own timing, in other words, or bring it with you.

ve

Sure, as I mentioned before, if the clock can be extracted or implied from the data stream then no problem. In the case of RS232, as you say, it resynchronizes to the start bit for every byte and uses the

Since the OP didn't mention the nature of the data connection, I wanted to confirm that he was properly aware of the issues.

-T

ave

er

it

Was this the dumbest thread ever? Maybe we should just stop answering when the OP refuses to give a coherent answer. Peter Alfke