[Gb-ccb] proposed CCB system design

[Martin Shepherd]

On Thu, 12 Feb 2004, Brian Mason wrote:
> all- I've posted Randy McCullough's proposed spartan-3 LC based system
>...

Tim and I have talked about this, and the following are some points
that we think need to be discussed at the telecon.

1. A biggest question at this point is how complicated the USB
   interface of the Spartan-3 development board is going to be to
   program within the FPGA, and whether the board comes with a library
   of VHDL code for simplifying this. If it doesn't, then my worry is
   that I will have to spend a lot of time wading through the USB
   standard, and write a complicated protocol-handling layer to create
   the simple FIFO-like interface that I actually want. I have sent an
   enquiry to the vendor, asking for more information, but we may not
   know much more about this until the board arrives, in a few weeks
   time.

2. Another problem is the question of how to synchronize what the 4
   FPGAs are doing at the 100ns level. Although, in principle, they
   will all be doing exactly the same thing, and should thus be in
   sync, the fact is that the lack of USB broadcast capability means
   that commands will have to be sent one at a time to each of the
   different FPGAs, so they will receive commands at different times.
   It is clearly very important that all of the FPGAs write samples
   into the same phase-switch bins, and that they all know precisely
   when the phase-switches and cal-diode control-lines are toggled.

   I don't think that this is an insurmountable problem, but it will
   complicate the FPGA programming. My preference would be mitigate
   this by adding a daisy-chain of a few control-lines between the 4
   FPGAs, such that one FPGA could act as a master, generating timing
   control signals to be used by all of the FPGAs.

3. The need for the computer to have to deal with 4 USB interfaces,
   instead of one, will complicate the device driver programming.

   Unless the daisy-chain of control-lines that I mentioned above in
   2, were adopted, and proved sufficient to configure all parameters
   in all of the FPGAs, then each command would have to be sent 4
   times, sequentially. This would increase the time pressure on
   things like cal-diode control commands, which originally were
   envisaged as being potentially sent before every new integration
   (ie. every 1ms). Sending 4 of these commands every millisecond
   could be problematic, and would probably require anticipating
   future integrations and batching many of these commands together
   into larger, less frequent packets. Given that the polling interval
   of the USB interface is 1ms, I would probably already have to do
   this, but with packets 4 times smaller than in the new scheme.

   Sending data back would also be less efficient, since a single
   block transfer in the original design, would be broken into 4
   separate sequential transfers.

4. With 4 boards instead of one, these is the issue of needing
   per-board diagnostics, and making these available to the manager.

5. The less efficient use of the USB interface would probably mandate
   the use of USB 2.0, instead of the USB 1.0 interface that I had
   planned on. Since the single-board-computer (SBC) that I selected,
   only has a USB 1 interface, this will mean that another SBC will
   have to be found.  I haven't looked recently, but in the past,
   low-power SBCs with USB-2 interfaces were hard to find. I am
   guessing that one needs a faster, more power-hungry CPU to handle
   the faster USB-2 interface.

6. The power-supply requirements will have to be changed to account
   for the splitting of the one FPGA board into 4, and the need for a
   new computer.

7. There are going to be a lot of connectors, cables and shielded
   boxes in the CCB, which translates to more things that can go
   wrong. Packaging will obviously also be more involved.

8. In Randy's diagram, the USB cable from each FPGA is shown wrapped
   around a ferrite ring. According to the USB consortium, regarding
   USB "signal quality design mistakes":

     "Most problems are the result of EMI "control" components like
      ferrite beads mounted on the signal lines. Often, these manage to
      destroy the integrity of the signal as well as make emissions
      worse."

   The above quote comes from the following URL:

    http://www.usb.org/developers/usbfaq/#sig4

   I can't see why this choke is needed, given that USB 2.0 cables are
   doubly shielded, and the cable is going from one noisy digital
   environment, to another.

9. I am similarly puzzled as to why, in addition to the shielded box
   around the analog PCB, there is also another shield box enclosing
   the combination of this box, and the Spartan-3 development
   board. On the inside of this box, is a noisy FPGA board, and on the
   outside is a noisy computer, while the analog board is safely
   isolated via its own shielded box.

   Removing this seemingly unneeded shielded box would make it easier
   to add the control-line daisy-chain that I mentioned in point 2,
   and obviously simplify the packaging.

10. I can't think of a use for the RS232 interface of the FPGAs, so I
    suggest that we don't bother providing a cable, or connectors for
    this.

11. There will probably need to be a cable connecting one of the FPGAs
    to the parallel port of the computer. This would be used for
    generating 1PPS interrupts, and depending on how I implement
    things, the end-of-integration interrupts. It would also provide
    the interrupt acknowledgement register.

Martin