[Gb-ccb] FPGA choice and configuration

[Tim Pearson]

The biggest outstanding issue on the CCB design is that we have still
not identified which FPGAs to use, or how many, or how to interface
them to the computer. Until this is settled we cannot proceed with
board layout or FPGA programming. Martin is working on this now, but
other input would be welcome.  My understanding of the issues involved
is the following:

1. We haven't been able to identify a development board with a USB
interface that would meet our requirements. The CESYS board mentioned at
our telecon has a USB 2.0 interface that would probably be fast
enough, but it is (apparently) extremely difficult to use. (Martin's
comments on this are included below).

2. This is driving us to go back to Martin's original idea of laying
out one or more FPGAs on our own circuit board, with our own USB
interface chip. Martin is the process of acquiring a test setup for
the USB interface chip he proposed in an earlier message.

(a) A single FPGA does not provide enough I/O pins unless we go for a
ball-grid array, which we are reluctant to do. Multiplexing the ADCs
might allow us to use fewer I/O pins but is an added complication.

(b) We can probably do it with 2, 4, or 5 FPGAs on a single board,
with one serving as a master handling the USB communications. We need
to check the pin count. It is possible that the master FPGA could be a
packaged development board, but that would complicate the
interconnects between master and slaves.

(c) Using 4 identical FPGAs on separate boards allows for good
modularity, as in Randy's proposal, but it would require
synchronization (I think we now agree that this would be possible via
1 PPS and 10 MHz). The computer would have to handle 4 USB
connections, which might not work under USB 1.1, and the USB protocol
would have to include timing to establish synchronization.

Of these options, we currently favor (b) and Martin is trying  to
come up with a concrete proposal, but if you are pursuing other options
or think that we should, please let me know.

An aside: to minimize the pin count, we are assuming that the 2 least
significant bits from each ADC will not be passed to the FPGA, even in
dump mode (unless we find ourselves with a surfeit of pins). Let me
know if this is unacceptable.

We need more discussion via e-mail (we'll try to minimize the flaming!)
and probably another telecon.

- Tim


Martin's comments on the CESYS USB interface:

*  I have been reading documentation on the Cypress USB interface that
   is used by the FPGA development board. The stuff available on
   Cesys' web-site is dominated by documentation of Windows
   software. As far as I can see, they don't give any specifics about
   the FPGA interface to the USB module. I ended up going to Cypress
   semicondutor's web-site, to look at the documentation of the USB
   module itself, separate from the FPGA board.

   It appears that to use this interface, I would not only have to
   program the FPGA to talk to the Cypress USB interface module, but
   also write specific firmware for the 8051 microproccessor within
   the Cypress USB module, and write a specific USB 2.0 device driver.
   This is clearly orders of magnitude more complicated than the
   simple FIFO to virtual-serial-port interface that I was going to
   use before.

*  It turns out that the Cypress USB interface module that this board
   uses is the same as the USB interface of an external USB 24-bit
   soundcard that I use with my laptop. This was a pain in the neck to
   get working.  The problem is that the Cypress USB interface does
   something unusual (they patented the technique, so probably nobody
   else dares do anything similar). Whenever devices that use this
   module are newly plugged in to the USB bus, the Cypress USB module
   does the following.

   A. It identifies itself to the USB host controller as a simple USB
      peripheral with little functionality.

   B. The device driver on the host is then expected to send the
      Cypress module its firmware. This is a 200K file for my audio
      card.

   C. The Cypress USB module then disconnects itself from the USB bus,
      then immediately reconnects itself, this time identifying itself
      as a different USB device, with specifics taken from the new
      firmware.

   On my laptop, under RedHat, I managed to get this to work using
   free software, and a copy of the firmware file, but it takes 15
   seconds for the above process to complete, and after a reboot, it
   only works if I manually unplug it then replug it in. If I leave
   the device plugged in at boot time. Probably the boot-time poll of
   the USB bus occurs before the host's USB interface is fully
   initialized, so the immediate disconnect and reconnect confuses
   it. Other than manually unplugging and replugging in the device
   after each boot, I haven't found a solution for this problem.  We
   may have similar problems with the CCB if we use this development
   board.

--
Timothy J. Pearson
Astronomy Dept 105-24, Caltech, Pasadena, California 91125, USA
Internet:    tjp at astro.caltech.edu
Telephone:   +1 626 395-4980    FAX: +1 626 568-9352