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

[Christopher T. Day]

Phil,

I've only had a chance to glance at your schematic. Here are a few
questions maybe you can just answer outright. I'm enumerating things to
see if I have a full list.

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.

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

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

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

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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?

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.

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.


	Chris - AE6VK



 1144388432.0