<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
Martin Shepherd wrote:<br>
<blockquote type="cite"
cite="midPine.LNX.4.58.0402131829500.12114@goblin.caltech.edu">
<pre wrap="">On Thu, 12 Feb 2004, Brian Mason wrote:
</pre>
<blockquote type="cite">
<pre wrap="">all- I've posted Randy McCullough's proposed spartan-3 LC based system
...
</pre>
</blockquote>
<pre wrap=""><!---->
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:
<a
class="moz-txt-link-freetext"
href="http://www.usb.org/developers/usbfaq/#sig4">http://www.usb.org/developers/usbfaq/#sig4</a>
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
_______________________________________________
gb-ccb mailing list
<a class="moz-txt-link-abbreviated"
href="mailto:gb-ccb@listmgr.cv.nrao.edu">gb-ccb@listmgr.cv.nrao.edu</a>
<a class="moz-txt-link-freetext"
href="http://listmgr.cv.nrao.edu/mailman/listinfo/gb-ccb">http://listmgr.cv.nrao.edu/mailman/listinfo/gb-ccb</a>
</pre>
</blockquote>
All,<br>
<br>
Martin raises some valid concerns which should be discussed during our<br>
telecon. Here, I'll attempt to address each of his concerns, one at a
time...<br>
<br>
1) Possible complication of FPGA coding vis-a-vis the implementation of
the<br>
USB interface...<br>
<br>
As pointed out in my original proposal, I share this concern.
If Memec<br>
Design doesn't provide coding in full support of this protocol
layer,
then <br>
Martin's coding task could indeed take on a <u>significantly</u>
higher
level of
<br>
complication...<br>
<br>
2) Possible synchronization issues...<br>
<br>
Here, it was felt that the four modules would be re-synchronized
and held<br>
in "lock step" via the 1PPS and 10MHz reference signals being
distributed<br>
to each. The assumption here is that the clock stability of each
module's<br>
crystal oscillator would be adequate to permit such an
implementation.<br>
I'm not sure if I fully understand Martin's perceived need for a
daisy-chain<br>
of control signals linking the four FPGA's. Given the advent of
the 1PPS<br>
and 10MHz reference signals being made available to each of the
four<br>
modules, it would seem that, within any given integration
interval, they <br>
should theoretically be capable of performing inter-module
temporal <br>
tracking to
within 1.0000001 seconds...<br>
<br>
3) Possible complication of the host computer's device driver
programming<br>
arising from the advent of four USB interfaces (through a
four-port hub)...<br>
<br>
I tend to agree on this point; however, as Martin points out, it's
highly<br>
probable that he would have to deal with this issue regardless of
the<br>
physical factorization of the circuitry involved. The basic
implication<br>
at work here would be the (probable) size of the packets
involved. <br>
Regarding the possible overhead involved in issuing four
command<br>
packets to trigger the phase switch and cal diode control lines,
it seems<br>
to me that we could simply issue only one command packet to the one<br>
module that is actually connected to implement this
functionality. The<br>
Manager would then only be required to know which one of the four
<br>
modules is currently wired and "enabled" to provide this
functionality... <br>
<br>
4) The issue of needing four diagnostics subsets due to the use of 4
FPGA's...<br>
<br>
It seems to me that this might be a moot point in that, regardless
of how<br>
the circuitry is physically factored, in order to implement full
diagnostics,<br>
there would still be a
need to deal with some number of "logical" equivalents <br>
within the FPGA's. Moreover, I feel that segmentation of the
overall system<br>
into four identical modules might actually allow for more
efficient diagnostics <br>
modes and procedures. In any event, this sort of modular approach
should <br>
greatly reduce Mean Time To Repair through module-level
replacement.<br>
<br>
5) The use of USB 2.0 vs. USB 1.0...<br>
<br>
This is absolutely correct. Indeed, my proposed factorization
<u>relies</u><br>
upon the higher bandwidth capabilities of USB 2.0 throughout. In<br>
light of Martin's inquiries to Memec Design regarding the true
nature<br>
of their purported USB 2.0 (which, based upon their response, <u>does</u>
<br>
appear to be much slower than an actual USB 2.0 implementation),<br>
this point might be a show stopper with regards to my proposal.<br>
This concern <u>definitely</u> deserves further investigation and
discussion!!!<br>
<br>
6) New power supply requirements...<br>
<br>
I don't believe that simply having 4 FPGA's will necessarily
mandate <br>
the need for larger power supplies; however, Martin's point
regarding <br>
the possible need for a more power hungry computer is quite valid
and<br>
does warrant further investigation...<br>
<br>
7) Possible impact on instrument reliability and packaging concerns
arising<br>
from a relatively large number of connectors, cables, etc....<br>
<br>
Perhaps, but the original design concept had similar problems.
This<br>
issue is certainly worthy of further discussion. However, I still
claim<br>
that the modular approach I've proposed would lend itself to
greatly<br>
simplified (and streamlined) instrument repair procedures...<br>
<br>
8) The use of a CM Choke on the USB cable...<br>
<br>
The proposed EMI device is a Common Mode Choke which is actually<br>
recommended for use in low voltage, differential signaling systems
(such<br>
as USB). The USB Implementers Forum recommends against using
ferrite<br>
beads on the <u>individual</u> lines within the USB cable.
Indeed, this sort of<br>
treatment would definitely lead to degraded signal performance and
a<br>
probable increase in radiated emissions. On the other hand, the
<u>proper</u><br>
use of a Common Mode Choke (which operates identically on all
signal<br>
lines simultaneously by removing only common mode signals), is a
proven<br>
and widely used approach for taming EMI in high speed, low voltage,<br>
differential signaling systems such as USB. The USB Implementers
Forum<br>
document titled "High Speed USB Platform Design Guidelines"
discusses<br>
the successful use of Common Mode Chokes in controlling EMI within<br>
USB 2.0 devices and cables. Further, it carries a recommendation
that <u>all</u>
<br>
USB 2.0 device designs incorporate provisions for possible
installation of <br>
CM
chokes in the event that they fail initial EMI compliance testing...<br>
<br>
9) Multiple layering of shielded enclosures...<br>
<br>
This concept derives primarily from the vision of using the
proposed <br>
four-input "Frequency Channel" module as a possible "stand alone" <br>
device in other applications. The additional layer of shielding
is thus<br>
intended to limit external EMI in such applications. Regardless,
the<br>
inner-most layer of shielding would be required to control internal<br>
EMI in an effort to preserve the integrity of the analog input
signal<br>
chains from their input connectors through their A/D's...<br>
<br>
10) The elimination of the proposed RS-232 ports on the individual<br>
"Frequency Channel" modules...<br>
<br>
As was pointed out in my original proposal, these ports were
labeled <br>
as "optional" from the outset. Here again, this functionality
derives<br>
primarily from the vision of using the proposed "Frequency
Channel"<br>
modules in other applications and, as such, isn't actually
essential for
<br>
the CCB implementation...<br>
<br>
11) A cable connecting the FPGA's to the computer's parallel port...<br>
<br>
This connection was anticipated (functionally) in my original
proposal<br>
but was depicted as being implemented (again, functionally) with
a<br>
set of cables from the 1PPS / 10MHz distribution circuitry (see
the<br>
discussion under item 2 above regarding synchronization, etc.)...<br>
<br>
It seems to me that, all other issues aside, the single overriding
concern revolves<br>
around Memec Design's actual implementation of their so-called USB 2.0
port. <br>
If they do indeed use Silicon Laboratories' CP2101 without
enhancements, then<br>
my proposed four-module configuration probably won't be feasible as
currently<br>
envisioned due to realizable bandwidth limitations...<br>
<br>
Randy <br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
</body>
</html>