[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xylo-SDR] Architecture review

Hello all,

After going back and reading what I wrote yesterday I could see how
someone could conclude that I have gone FPGA-mad... putting FPGAs
everywhere!  Bill and Phil did a better job of summing it up than I
did.  I do not advocate putting a FPGA on every single board... for
example, the sound card replacement board certainly does not need it's
own FPGA.  I just don't want us to lock ourselves out of having that

There are the main things that concern me:

1.  We cannot expect the FGPA in the FPGA/USB board to handle *all*
functions that a FPGA would be needed or desirable for on the plug-in
boards.   The main function of that board is backplane/USB
communications.  It is our link to the PC.  It can handle a lot of the
other stuff we want... except for things like the LTC2208 board where
it would be highly desirable to have a separate FPGA on that board.  I
have nothing against Cecil's idea of allowing there to be a
daughtercard type of interface on the FPGA/USB board...the more
options the better...

2. We will have to be very careful about putting too many high speed
clock signals on the backplane without taking extra care like
converting them to LVDS or something.  I agree that the I2S signals
should not cause too much of a problem.   I don't think I would want
to pass the 16 bit bus from the LTC2208 over the backplane though...
it would be more desirable to get the data rates down to the
equivalent of the I2S signals before passing them over the backplane. 
We would have to look at it, but it might be possible to convert the
downconverted samples into I2S signals in the LTC2208 on-board FPGA
and use the same code in the FPGA/USB board's FPGA to get that data
back to the PC as in the sound card replacement board.

3.  We should not lock ourselves into a definition of the backplane
bus that is too specific.  I like Lyle's suggestion that we have
something like user1, user2, etc... that can be user defined per
application or project.  It will take some more thought...

73 de Phil N8VB