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

> On another point, there are three pins left on Port C according to
> Phil's block diagram [Wow, by the way]; should they allow control of the
> FPGA Configuration Mode from the FX2, or will we always need to fiddle
> jumpers? I would think that pull ups/downs for a default mode [AS gets
> my vote] that the FX2 could programmatically override would be possible
> without too much trouble.

I think the configuration mode should be set by jumpers.  I think
Altera recommends pulling these "hard" up or down - not via series
resistors to ground or VDD.  Anyway, I would like to reserve the three
pins on port C to be user definable as to what they do with the FPGA. 
One use would be to serially communicate configuration commands to the
FPGA using EP0  or EP1 so it would not have to be passed over the
FIFOs.  For example, if the FPGA is streaming audio data to the FX2's
FIFOs it would be nice to be able to send configuration commands (such
as: change audio rate) to the FPGA without passing then over that
interface.

> And a few more. Phil commented that he figured the FX2 would essentially
> always be loaded via USB at turn-on, hence the I2C EEPROM wouldn't be
> needed.

I meant that this would be the most common scenario.  We will need the
I2C EEPROM for the VID/PID/DID at the very least so I would expect
that the EEPROM will always be populated.

> True in a lot of scenarios, and it could normally be unpopulated
> like the Xylo, but there have been some messages going by figuring to
> have a DSP engine in the Atlas box so, once firmware/configurations were
> downloaded, the PC was no longer needed. [Not sure what these folks have
> in mind for an interface, but a beacon might not need much of one.] That
> led me to conclude that somebody will want to take a stand-alone Atlas
> box out on Field Day without the PC. _Then_ you probably need the I2C
> EEPROM.

I plan on this happening...definitely...

> On JTAG driven by Cyclone rather than FX2. I hadn't thought of that. If
> it works, that should be fine, however, according to the Cyclone Device
> Handbook, the JTAG pins are not available in User Mode; I haven't caught
> up with the Cyclone II manual, so don't know the status there. If the
> pins are unavailable in User Mode, then what? Connect the Atlas JTAG to
> general purpose I/O pins on the Cyclone? Multiple JTAG chains ok with
> everybody?

I did not mean that the JTAG pins on the FPGA would be used to program
the other JTAG devices - you can't do that as you have already figured
out.  I meant implementing the JTAG programming in the FPGA using I/O.

> And one last bit. What do we intend to do about a USB VID/DID (Vendor
> ID/Device ID) pair? As Phil points out, even though the FX2 by necessity
> will come up with one if nothing else is done, that pair belongs to
> Cypress and their manual explicitly states it is _not_ to be used for
> "production" devices. One of the I2C EEPROM's jobs is to supply a
> different one. Official IDs can be had from www.usb.org, but at a price
> of about $2000 as far as I can see. Presumably we'd only need one VID
> for all the projects we do, but that's still a lot of money from my
> perspective.

There are different ways of handling this... none of which involves
paying a fee.

> Done for this round. Sorry if this is all nit-picking, but it seems like
> the optimal time for picking nits.
>
>
>         Chris - AE6VK
>

73 de Phil N8VB

 1144446331.0