I have not used it myself, but parallel transfer is potentially
even simpler than serial, as it uses a basic FIFO interface. It
looks like this:
D0-D7 (inout): Data bus.
TXE# (output): When low, data can be written to the FIFO.
RXF# (output): When low, data can be read from the FIFO.
WR# (input): Writes data to the FIFO on negedge.
RD# (input): New data byte can be read on D0-D7 after negedge.
Data output enabled while low.
Pin descriptions and timing diagrams are on page 10 and 11, here:
http://www.ftdichip.com/Documents/DataSheets/DS_FT245R_v105.pdf
I suggested this earlier...
What about one of FTDI's USB - FIFO converters? (or USB-UART)
the FIFO ones have
"Data transfer rate to 1 Megabyte / second - D2XX Direct Drivers."
or
"Data transfer rate to 300 kilobyte / second - VCP Drivers."
I am not quite sure what D2XX or VCP means, but you can get D2XX for
Mac OS X, Linux, etc.
http://www.ftdichip.com/Products/FT245R.htm
at one megabyte per second, we can transfer all 256 megabytes in
approx 4 min, 16 seconds.
...
There is also a so-called "USB to UART Switch" manufactured by Dallas/
Maxim Semiconductors
that can switch the two signals - this would be useful for having
both, but just USB would probably work.
Did people recieve this? (I just wanted to make sure these are
getting through)
Anyway, I think that a FIFO interface is easier than a serial one.
Remember, however, that we have
a 4 MILLION gate FPGA with almost nothing on it, so we don't need
an insanely optimized download
system (in terms of latency in the FPGA, since any performance gains
are destroyed by the FIFO)
unless we go with the download-on-the-fly idea proposed by Daniel
(which I rather like - more later).
Because of this, it might be more practical to use the UART, since
most computers can get cheap
USB <-> RS232 adapters instead of an FTDI solution that is a pain to
connect up. If we are planning on
soldering these ahead of time for developers, I just assume go with
the FIFO (to save us programming time),
but if people are attaching themselves it might be easier to use UART.
As for Daniel's idea:
Rather use a FIFO where the input is fed by 10x oversampled PCICLK and
output is read as fast as the transport link allows with given encoding
(transmiting changes only). It should work with a buffer for 10 samples
and you need at least half or less of the transfer rate of input,
because the signals somewhere MUST stay stable (otherwise we're talking
about 330MHz "noise" on all lines). These stable levels on input will
allow to clear the buffer, and they will occur once per PCICLK period.
I think that this makes sense. Not only does this make the program
"real time"
and therefore drastically reduce the download time, but it also
allows for greater
flexibility in capture time. Essentially an infinite buffer (the hard
drive) is on the
tracer machine, so we might as well store the signals there. The
developer must
have two computers anyway (one test with both ODG cards, one tracer),
and this
means we can essentially use both FPGAs to implement whatever
compression
we want. It is a simple matter of sending data over the UART in "real
time". The
signals are still coming in faster than we can shove them out, but as
daniel said
there is no way that 330 Mhz noise is omnipresent on the bus (at
least, I should hope not...)
Thoughts?
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
