Prev: interfacing lcd to spartan3a dsp 1800
Next: Xilinx tools in Windows or Linux - Suggestions
From: Tom on 26 Jun 2008 18:55
On Jun 26, 6:36 pm, Heinrich <Heinr...(a)myweb.com> wrote:
> 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
From: Heinrich on 27 Jun 2008 09:11

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

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.
From: Tom on 27 Jun 2008 09:30
On Jun 27, 10:11 pm, Heinrich <Heinr...(a)myweb.com> wrote:
> > 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.
>
> 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.

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
From: Heinrich on 27 Jun 2008 13:08

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

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 :)
From: Tom on 27 Jun 2008 18:46
On Jun 28, 2:08 am, Heinrich <Heinr...(a)myweb.com> wrote:
> 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 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
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: interfacing lcd to spartan3a dsp 1800
Next: Xilinx tools in Windows or Linux - Suggestions