Re: [Xylo-SDR] FPGA pin names in schematic - Some thoughts...

[Philip Covington <p.covington@gmail.com>]

On 1/20/06, KD5NWA <kd5nwa@cox.net> wrote:
>  Phil has been looking at that, maybe he can tell us what he thinking on the
> subject.
>
>  I think you need a DAC and a elliptical filter. you may want to look at the
> DDS-60 board, it has all the components all figured out for the filter and
> amplifier, except the DAC part
>
>  Phil Harman, or anybody please chime in so Leon can put it in before making
> a prototype.
>
>  We have been discussing how to make a cleaner DDS, and it requires a high
> precision Sine table with as many as 32K to 64K entries. If we use the
> internal RAM to hold those values, it being very fast, we might need RAM on
> the outside for use in buffers, etc. By the way, how wide is the RAM that
> you have put in? A lot of the boards that have RAM have one chip that is 16
> bits wide, so every 10 ns you can pull out a 16 bit precision number to feed
> the DAC or FX2. If the internal RAM is not big enough then we are going to
> need to use the external RAM and it needs to be 16 bit wide to minimize the
> number of fetches.
>
>  This where a second precision optional clock device besides the 24.4xx MHz
> comes in feeding a clock input pin, you want the DDS STATE clock as high as
> the RAM will tolerate, if we use internal RAM for the Sine table, our clock
> could be in the 200MHz range, which would give better resolution and lower
> spurs.

Some thoughts:

I think that the FPGA/USB board should be kept as generic as possible
with no end-use specific components on the board.  Maybe instead we
should be thinking about putting another FPGA on the application
specific boards and use the FPGA/USB board as the bus controller/USB
comm board only.  By putting dedicated signals on the bus, we narrow
our options in the future.   I think that the BUS/USB COMMs (the
FPGA/USB) board should only define generic signals like IO1, IO2,
IO3... and maybe some specific lines to be used as clocks to drive the
communications over the bus to/from the application specific plug-in
boards.

Looking at the LTC2208 board, it would be advantageous to have its own
FPGA.  That way, the data rates are reduced on the LTC2208 board
before they are passed on to the BUS/USB COMMs board.  Putting high
speed digital lines or clocks on the bus is asking for trouble unless
we were to use LVDS signals (this might be a possible solution since
many FPGAs can be configured for LVDS outputs).  The other problem is
that when you have multiple clocks (for example 20 MHz and  48 MHz
derived from two different clock sources) coming in to something like
an ADC board you can have problems with the clocks beating together...
the beat note is seen as a spurious signal on the ADC output.  It is
better to derive the 20 MHz clock from the 48 MHz clock (on the
plug-in board) so they are synchronous.  The LTC2208 board will have
to have it's own 130 MHz encode clock.

For the high precision DDS board that Cecil is talking about, the DAC
will probably be on a plug-in board.  Having huge look up tables in
the FPGA will quickly limit resources available for other parts of an
application.  It would be better to put another specific FPGA on the
DDS/DAC board to handle this.  If external RAM is needed it could be
then put on this board also.

For less demanding application specific plug-in boards a CPLD could be
used on board.

Basically what I am proposing is:

1. We have a BUS/USB COMMs board to handle communications over the bus
and to/from USB.  The main function of this board is to control the
bus and handle communications over the bus.  This would be a Cyclone
II - Cypress FX2 based board like what Leon is designing.  It could
take on other roles as LE space permits.

2. Since the Cyclone II can do LVDS, maybe we should be looking at
having only LVDS signals on the motherboard bus.  This would require
that we either use a LVDS capable FPGA/CPLD or a LVDS
serializer/deserializer chip on each plug in board to talk to this
bus.

3.  The only clock signals on the bus are for driving the bus
communications.  All other clocks needed for the plug-in boards are
generated locally on that board or use SMA/SMB connectors to jump to
other plug-in boards.

4. In certain applications the requirement for a FPGA/CPLD or LVDS
serializer/deserializer could be relaxed and the BUS/USB COMMs board
could be reconfigured (after all it is a FPGA) to give single ended
signals... such as the I2S signals for comms with the audio ADCs and
DACs.

Comments?

73 de Phil N8VB