[Gb-ccb] FPGA design

[Martin Shepherd]

On Tue, 30 Mar 2004, Brian Mason wrote:
>...
> taking such care in the documentation.  Our only major comment is that we
> think the approach of having a write-only interface to the device is a
> mistake-- this is a view that emerges from long and painful experience
> with other devices.

In the CBI Steve Padin implemented lots of write-only VME registers,
and there were no problems, since I just kept a record of what I had
sent. I don't understand the utility of having readback of values that
are never changed by the FPGA. All this would tell you was that the
EPP interface in the FPGA was keeping a record of these register
values. It wouldn't tell you whether those values were faithfully
being passed on to other components within the FPGA, nor whether those
components were actually doing anything useful with them. If you
really want to see the state of the FPGA, then I would prefer to
either prepend such info to all data packets that are sent over the
USB interface, or send a special configuration frame back at the start
of each new scan, again via the USB link.

My personal experience is that the most robust and least convoluted
way to handle control and telemetry is to have the two go via separate
dedicated channels. They usually have very different timing and
bandwidth requirements, and thus benefit from using appropriately
different link types, and any contention between the two can either be
completely avoided, by separating them physically, or optimally
avoided by using separate channels of a well-established protocol
implemented by somebody else (such as TCPIP). Otherwise you end up
with sticky problems to work around, such as a reset control packet
never making it, because the FPGA has got into a mode where it is
continuously sending data too fast for the available bandwidth.

> minor comments and questions:
>
> -Is there a plan to load the FPGA program?

Originally I was going to look into doing this, over the USB link, but
my recollection from our last telecon, was that after Tim said that we
wouldn't need FPGA "personalities", it was settled that the FPGAs
would not be loadable in situ, but rather loaded from EEPROMs that
would be programmed in the lab. I'm not sure how this is done, so I
was hoping that you would be able to copy whatever GB usually does for
loading FPGAs from EEPROMs. If you want me to look into how this is
done, tell me, and I'll start researching it.

> -page 10, item 1: suggests that a software command starts a new scan.
> Really I suspect the software command "primes" the state generator, which
> starts the scan on 1PPS-- is this correct?

For a new observing scan, yes. For an intra-scan, my recollection was
that GB didn't want to have to wait for a 1PPS, so an intra-scan would
start as soon as the previous integration completed.

> -Are the resistors backwards in fig2.1 ? (30.9 vs 18.7 Ohms)

No, I got this completely wrong. Sorry about that. For some reason I
worked out values that would place the peak of the 4V 1PPS pulse at
the mid-point of the 3.3V input range. I'll fix this.

> -we need to check if the 10 MHz signal is a square wave or a sine wave, we
> think it's the latter.

Okay. I didn't know what interface to use here, since I have no info
on the clock signal, so I just duplicated the (lamentably incorrect)
1PPS input divider.  So I guess I need to find some way to square-up
the clock signal, as well as get the levels right.

> -Fig 2.1-- we might find a 3.3V driver and thus omit 74LCX125 (we'll look
> into that one)

That would be good.

> -In figure 1.1-- the 74LCX125 will not properly drive the CLK input, which
> requires CMOS logic levels as opposed to TTL logic levels

The 74LCX125 actually is a CMOS device. Unfortunately, while the
data-sheet says that the inputs and outputs are 5V tolerant, and Vcc
can be up to 7V, no information is given for the output levels when
Vcc > 3.6V. This device just happened to be the only device that I
could find in Mouser's catalog. If you have any other suggestions for
this and the other 3.3V <-> 5V drivers, I would welcome them.

> -Fig 1.1, top integrator-- drawing goof-- phase and clock lines swapped

Thanks. The "drop" line was also swapped.

> -fig 1.1-- the FIFO isn't *really* a FIFO (just terminology... it's a
> "parallel in, serial out").

Is it still called serial-out if the output is 16-bits wide, and is
the acronym for "Parallel In, Serial Out" PISO?

> -Page 7, discussion of the physical interconnection scheme: no specific
> issues just now, but we will want to think about this as we get in to the
> layout.

Thanks. This just shows how I am visualizing my design in the broader
context of the instrument, so it is just a suggestion, and a heads-up
that if something significantly different is chosen, then I may need
to change the FPGA interconnections to suit.

Martin