[hpsdr] [FPGA_USB] Review/Comments FPGA_USB Board - April 5, 2006

[Philip Covington]

Hi Chris,


On 4/7/06, Christopher T. Day <CTDay at lbl.gov> wrote:

> You've used Ports B & D of the FX2 for the 16-bit data interface to the
> USB internal FIFOs. Port A is naturally used as the FIFO control
> interface in either Slave FIFO or GPIF Master FX2 modes. That leaves
> Port C unassigned in my head so far; I haven't worked out what you've
> done with it.

Port C is used for the configuration of the FPGA.

> [The things I've been thinking about have been driven by allowing as
> wide a variety of boot/load/in-circuit-programming options as reasonable
> for maximum reuse of the layout.]
>
> I think I've spotted at least the following connectors and chips that
> could be involved in boot/load/in-circuit-programming:
>
> 1) USB through which the FX2 can load itself from a PC with no further
> on-board support.

Yes, that is the purpose of port C.  The FPGA can be programmed from
the PC via the FX2.

> 2) An I2C EEPROM that the FX2 can boot from directly _if_ the EEPROM is
> already loaded with proper code.

The EEPROM allows enumeration with your own VID/DID.  Also, the
firmware for the FX2 can be downloaded to the EEPROM and the FX2 will
then start up without having to have the PC download its firmware over
USB.

> 3) Since you have the 128-pin version of the FX2, we could in principle
> add a RAM to the FX2's unused address and data buses. If the RAM
> contained proper code, the FX2 could boot and run from it after
> something like a USB bus reset. [Should/can we provide unpopulated pads
> for such a RAM chip for the FX2? I know a similar chip has been
> suggested in the past for the Cyclone.]

I have mixed feelings about the external RAM for the FX2.  The "A"
version contains 16 k of internal RAM.  I would think that most of the
functionality of the board will come from the FPGA and not the FX2. 
In that case I don't see the need for additional RAM.  I used the 128
pin version of the chip because it is usually in stock where the 56
and 100 pin versions vary in availability.  Right now the external RAM
is not used... but I could be convinced (with a good argument) to add
support for it so it could be optionally populated on the board.

> Given appropriate load files on the USB host, we could use 1) to program
> the I2C EEPROM over the I2C bus, or the RAM on the FX2 memory bus, so 1)
> gets us to 2) and 3).
>
> I think that takes care of booting the FX2.

I think that most of the time the firmware will be downloaded to the
FX2 when it enumerates.  I have not found much use for storing the
firmware on board since the FX2's primary use is USB which implies
that it is connected to a PC that can download the firmware.

> For the Cyclone II, I think I see two Altera ByteBlaster connectors, one
> connected to the FPGA's JTAG chain and one connected to its
> configuration port. Also on that port is a serial EEPROM. And you have
> jumpers to select any of the Cyclone's configuration modes.

Yes, I wanted to allow JTAG and ByteBlaster II programming.   I could
simplify the JTAG connector by using something other than the 10 pin
header for it.

> 4) Given appropriate PC software and adapter hardware, the Cyclone could
> be configured directly through its JTAG chain. Using these pins
> overrides anything the jumpers say anyway.

That is true, but if you are using JTAG the mode pins have to be tied
either high or low - they can't be left floating.

> 5) Given a configuration already in the serial EEPROM and the jumpers in
> Active Serial (AS) mode, the Cyclone will configure itself from the
> EEPROM.

Yes.

> 6) Given appropriate PC software and adapter hardware, the jumpers set
> for Passive Serial (PS) mode and the second Altera ByteBlaster
> connector, the PC code can manipulate the nCONFIG line (and a couple
> more that escape me at the moment) to load the Cyclone directly over its
> configuration bus.

Yes.

> 7) Given the same setup as 6) and a different manipulation of the
> nCONFIG and related lines, the PC code can instead program the serial
> EEPROM, setting things up for 5) to be usable.

Yes.

> On the more obscure side, there are:
>
> 8) Given an appropriate initial configuration in the Cyclone, from one
> of the methods above, the Cyclone could drive its configuration bus to
> back-program the serial EEPROM. Altera provides such an initial
> configuration. Data for the back-program could come through the
> FX2/Cyclone connections otherwise used for the FIFOs during normal
> running.

Port C of the FX2 are connected to the configuration pins.  Instead of
the above method, it might be possible to arrange to directly program
the configuration EEPROM from the FX2 through port C.

> 9) Since the Cyclone is on the I2C bus, if it had some way to get hold
> of code, it could program the I2C EEPROM. Again, the Cyclone could get
> the info over the nominal FIFO interface from the FX2, but that seems
> silly since the FX2 could program the I2C device directly.

Yep, I'd rather the FX2 take care of it.

> That's probably more than enough for a developer for this board.
> However, what about users? What about other Atlas boards on the same
> motherboard?

I have though about putting a bus switch on the X and Y BUS
connections of the FPGA to the Altas.  That way we could isolate the
FPGA_USB board from the Atlas bus if needed.  But could we not do that
already by tristating the FPGA I/O lines for the X and Y bus
connections?

> I assume that a user has a PC and USB interface at least for configuring
> things even if his Atlas system becomes a free-standing radio after
> configuration. The hardware he initially bought may have come with
> firmware/configurations already in the EEPROMs (do we do that?), but
> what about field upgrades? I don't presume the user has or wants to buy
> a ByteBlaster.

I built a ByteBlaster in about 20 minutes with a single 74LS244 and
some resistors.  That is  one possibility.  There are ByteBlaster
clones that sell for $25-$50.  But all such firmware upgrades should
be possible though the USB connection only.

> Given 1) - 3), this is not a problem for the FX2, but is more
> problematic for the Cyclone. There would need to be - and I haven't yet
> spotted - a path from the FX2 to either the JTAG chain or the Cyclone's
> configuration bus. [I'd prefer both, but I think I've run out of FX2
> pins.] For this one board, the best answer I've seen is to use Port C to
> run the Cyclone's configuration bus. This is what the USRP does, as I
> understand it. That's at least four of the Port C lines. If the FX2
> should be as fully capable of in-circuit-programming as the PC with
> special hardware, then maybe we should consider using more of Port C to
> fiddle the nCONFIG lines and the Configuration Mode Select lines. That
> would pretty much use up the FX2's major I/O connections.

This is exactly what the schematic does.  It uses port C since port E
is not bit addressable.

> But the other problem is how to in-circuit-program other boards on an
> Atlas motherboard, especially if you're a user? Well, another board
> might boot off a local I2C EEPROM. [How do we define the I2C address
> space, by the way? Its pins A0, A1 and A2 on the I2C memory which looks
> to be hardwired in Phil's schematic. Jumpers, maybe? Something similar
> on other boards?] That I2C EEPROM could at least in principle be
> programmed via the USB through the FX2's I2C interface if the I2C bus is
> carried on the backplane. It's only two wires and is not one of the
> daisy chains. Good idea? Bad?

I think this is partly why Lyle suggested the daisy chain on the bus -
to be able to put together a JTAG chain.

As far as the I2C EEPROM for the FX2, the particular A0, A1, A2
connections are required by the FX2 - you don't have any choice in
that.  Either all the other devices connected to the FX2's I2C bus
have to deal with that or we need to leave the I2C bus of the FX2
isolated and do I2C in the FPGA.

> Another possibility would be to send the JTAG chain across the backplane
> and use part of the Port C lines to drive the JTAG chain. Since I run
> out of FX2 pins at this point, it looks to me like something would have
> to give, i.e. loss of all possible configuration modes of the local FPGA
> via the configuration bus from the FX2. But in return, barring protocol
> incompatibilities among chips, anything JTAG programmable on any Atlas
> board could - at least in principle - be programmed/configured through
> the single Lionheart USB interface with no extra hardware.

Don't forget that the daisy chain bus is also connected to the FPGA
which could be programmed to program other JTAG devices on the Atlas
bus.

> I presume that developers of other Atlas bus boards would include
> simpler direct ByteBlaster or similar connectors for their own use.
>
> Ok, I've exhausted everybody's patience with belaboring the obvious.
> Sorry, but I had to get it all off my chest.
>
> Disclaimer: I'm only suggesting that we look into laying out the traces
> that would _allow_ these possibilities while we have the chance, not
> that we need to implement them all right away or even ever.

Understood and appreciated...

>         Chris - AE6VK

73 de Phil N8VB

 1144418662.0