Prev: interfacing lcd to spartan3a dsp 1800
Next: Xilinx tools in Windows or Linux - Suggestions
From: Rob Gaddi on 27 Jun 2008 19:57
Tom wrote:
> 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

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.

--
Rob Gaddi, Highland Technology
Email address is currently out of order
From: Tom on 27 Jun 2008 21:44
On Jun 28, 8:57 am, Rob Gaddi <rga...(a)technologyhighland.com> wrote:
> 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
From: MikeWhy on 28 Jun 2008 23:56
"Tom" <tom.derham(a)gmail.com> wrote in message
news:f656be07-d2be-4844-9c96-3feec6b44be6(a)y22g2000prd.googlegroups.com...
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).

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


From: Tom on 29 Jun 2008 01:03
On Jun 29, 12:56 pm, "MikeWhy" <boat042-nos...(a)yahoo.com> wrote:
> 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.

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
16x faster clock to estimate the best sample point for each bit.

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

From: Peter Alfke on 29 Jun 2008 17:55
On Jun 28, 10:03 pm, Tom <tom.der...(a)gmail.com> wrote:
> On Jun 29, 12:56 pm, "MikeWhy" <boat042-nos...(a)yahoo.com> wrote:
>
> > 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.
>
> 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
> 16x faster clock to estimate the best sample point for each bit.
>
> 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

Was this the dumbest thread ever?
Maybe we should just stop answering when the OP refuses to give a
coherent answer.
Peter Alfke
First  |  Prev  | 
Pages: 1 2 3
Prev: interfacing lcd to spartan3a dsp 1800
Next: Xilinx tools in Windows or Linux - Suggestions