[Gb-ccb] FPGA choice and configuration

[Randy McCullough]

Tim Pearson wrote:

>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
>_______________________________________________
>gb-ccb mailing list
>gb-ccb at listmgr.cv.nrao.edu
>http://listmgr.cv.nrao.edu/mailman/listinfo/gb-ccb
>
>  
>
Martin,

Can you please provide part number(s) for the original USB interface
device(s) you've been considering?

Thanks!

Randy