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

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


Unless I am mistaken you are going to get quotes on an "ALPHA" board. This
might be a lil expensive but I don't think too many will 'jump ship' when
you come back with a quote of $100 for 20 - 50 boards. If everyone wants to
jump ship and go back to individual project boards with the FPGA on each
board, then lets just go our own ways. This 'project' system being developed
has already seen, the best of the best giving ideas which have been GREAT!
WE are producing a development system NOT an end product. Call it the Pilot
Plant of FPGA. Indeed, what Phil_C is suggesting is just what he compained
about with GNU or other. No FlExIbIlItY!

Someone seems to have thrown a 'firecracker' into the crowd. Lets get back
to conversation, and give us enough general purpose SMX or other connectors
off the front to satisfy at least the initial project descriptions with RF!.


-----Original Message-----
From: xylo-sdr-bounces@lists.ae5k.us [mailto:xylo-sdr-bounces@lists.ae5k.us]
On Behalf Of Leon Heller
Sent: Friday, January 20, 2006 11:55 AM
To: Xylo-SDR Discussion
Subject: Re: [Xylo-SDR] FPGA pin names in schematic - Some thoughts...

----- Original Message ----- 
From: "Philip Covington" <p.covington@gmail.com>
To: "Xylo-SDR Discussion" <xylo-sdr@lists.ae5k.us>
Sent: Friday, January 20, 2006 4:27 PM
Subject: Re: [Xylo-SDR] FPGA pin names in schematic - Some thoughts...

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

I was thinking along those lines, myself. With the FPGA costing $15 or so, 
compared to $115 for the ADC, it makes a lot of sense.

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

Fine by me. I'll continue with the daughter-board idea, as the additional 
cost will be minimal and it won't take up much space.

73, Leon 

Xylo-SDR mailing list
To post msg: Xylo-SDR@ae5k.us
Subscription help: http://lists.ae5k.us/listinfo.cgi/xylo-sdr-ae5k.us
Xylo-SDR web page: http://xylo-sdr.ae5k.us
Forum pages: http://www.hamsdr.com/hamsdrforum/
Archives: http://lists.ae5k.us/pipermail/xylo-sdr-ae5k.us/