Gentlemen,
-
An updated version of the VSI-H draft is attached in both ps, pdf and Word
format (take your pick). This draft has incorporated what I feel are the
best choices on outstanding issues based on comments I have received (and
distributed) plus a a measure of my own best judgement. Any or all of
these issues are up for discussion at the 04 May 2200UT telecon.
-
Below I have relisted each of the issues and indicated how I have addressed
them in the attached draft. Your comments are, of course, welcome.
-
1. LVDS Connector Pinout
Issue: Dick Ferris has suggested a pinout different from the 9 Feb
draft document. This new suggested pinout is based on the use of a
specific LVDS device. The Japanese group have already begun
implementation of the 9 Feb pinout.
Discussion: Although Dick's is more optimal for a specific LVDS
interface device, the 9 Feb pinout has been chosen to be generically
'good' in a general engineering sense, is likely to be workable, and does
not constrain the use of future LVDS interface devices. The fact that the
Japanese group has already partially or fully implemented the 9 Feb pinout
makes a change painful.
New Draft: I have been won over by Dick's arguments in his 3 May
e-mail. Though I know this may not please everyone, I think the long term
benefits are clear. Please read Dick's e-mail carefully.
-
2. Bi-directional LVDS Signals
Issue: In his notes of 3 Mar 00, Dick Ferris has suggested the use
of reverse-channel functions. The 9 Feb draft specifies only
unidirectional signals on LVDS cables.
Discussion: The possible use of bi-directional signals on the LVDS
cables was a *major* discussion item at the Haystack meeting in late
January. In the end we agreed that the signals on each LVDS cable would
be uni-directional. That is *the* reason that DPS1PPS and DPSCLOCK are on
a separate cable to the DOM. Despite the fact that reverse-channel
signals do provide some possible advantages, I think we must stick to the
January agreement for the base VSI specification. As Rick points out in
his note below, a reverse-channel capability could still be built into the
DIM/DOM using bi-directional driver/receiver chips, but that they must be
configurable to meet the uni-directional VSI-H specification.
New Draft: I apologize that I did not fully understand Dick's proposal
to make bi-directional signals entirely optional in a manner that does not in
any way violate the uni-directional decision of the January meeting. I
have since studied his proposal much more careful, believe that it is good, and
have basically incorporated it. Please read this part of the draft very
carefully.
-
3. Delay in DOM/DIM
Issue: A delay option in the DOM was suggested in the 9 Feb draft
after some discussion at the January meeting. It was probably my fault
that it was vaguely defined, which left the issue rather unclear. Since
then, there have been various opinions expressed regarding its implementation,
and Rick suggests adding a 'delay' option to the DIM, as well.
Discussion: Adding a fixed delay capability is clearly useful to help in
the case of limited size of correlator input buffers. Anything fancier,
such as delay tracking, has very correlator-specific requirements that are very
difficult to accomodate.
New Draft: For *storage-based* DPS systems (i.e. tape, disc, any
transportable media), the required delay range is +/-0.5*ROT1PPS. Dick
points out, correctly, that for *direct-transmission* systems, the required
delay is highly dependent on antenna-location geometry and could place undo
requirements on a DTS system; I feel that, in this case, that VSI-H
mandate no delay-offset requirements and assume that the DPS will implement
whatever is necessary.
-
4. Bit-stream selection and re-ordering
Issue: We have agreed that any 2**n input bit-streams at the input
to the DIM can be selected for transmision to the DOM. In addition, we
have agreed that arbitrary bit-stream re-ordering at the DOM output is
necessary. Dick Ferris has also suggested re-ordering in the DIM.
Discussion: The benefit of re-ordering in the DIM is not clear to
me. Arbitrary bit-stream re-ordering at the DOM output is sufficient to
cover all bases. The 9 Feb draft comments that DOM-output re-ordering can
be effectively achieved in a separate box between the DOM and DPS. Dick
Ferris comments that a separate box makes it difficult to define a standard
software protocol.
New Draft: I feel the only real requirement is that any active DIM input
can be mapped to any DOM output. And that is it. How that is implemented
is up to the designer. Re-ordering at the DIM might add some features and
conveniences, but I don't think it belongs in the specification; I did
add a footnote in Section 13.4 in this regard.
-
5. LVDS Cable Specs
Issue: The detailed specification of cable is very complicated.
Discussion: Dick has done a very admirable job of creating a
creating a suggested cable spec, but the Japanese point out the difficulties of
making objective measurements of some parameters.
New Draft: I have lifted the basic cable specifications from one
of Dick's memo's and made some general remarks. There may still be a bit
of work to do here if people feel it is incomplete, misleading or inaccurate.
-
6. LVDS Electrical Specs
Recommendation: Adopt the detailed specification given by
Dick. This is more detailed and complete than the 9 Feb draft.
New Draft: Done
-
7. Validity per bit stream
Issue: The 9 Feb draft proposed a extension using bi-phase
code for validity per bit stream. Dick Ferris points out that this
introduces many complications.
New Draft: The whole validity-per-bit-stream issue has been
relegated to 'Other Notes and Comments' so that we don't forget about it, but
there is nothing in the spec about it.
-
8. Serial control port spec
Issue: The 9 Feb draft proposed is not fully internally consistent in
the specification standards.
Discussion: Dick makes the point that RS-223 is probably not the proper
spec. Count me guilty in that regard. At the January meeting we had
agreed to use RJ-45 type connectors with the pin-out specified in Table 12 with
only XON/XOFF handshaking specified. Dick points out that the specified
pinout does not follow the relevant EIA-561 standard, and that the specified
pinout is bad in terms of crosstalk when using standard CAT-5 cables. The
problem is that none of the major manufacturers (Cisco, Lantronix at least) use
the EIA-561 spec. They use the Table 12 pinout in spite of the problems
mentioned by Dick; the advantage of this pinout is that its trivial to create
either a straight-through or null modem cable by simply flipping over the RJ-45
connector on one end. Dick also suggests allowing DB-9 and DB-25 connectors
as well, plus RTS/CTS flow control.
New Draft: Consensus seems to be to adopt DB-9 rather than
RJ-45. This both eliminates any possible confusion between the RS-232 and
Ethernet connectors and puts the pin-out issue to rest (I trust!).
-
9. Proposal for P/QDATA format
Recommendation: Leave this issue for VSI-S spec
New Draft: Done
-
10. TVG
Issue: The example TVG circuit diagram may not exactly reflect TVG
intentions and may cause confusion.
Discussions: The TVG timing relationships are specified in Figure
4. If Figure 4 is used a guide along with the TVG diagram and the listing
of the first few bits of each TVG output, I hope that things will be
sufficiently clear.
New Draft: I have tried to clarify this area.
-
11. Test Vector Receiver
Issue: Whether TVR should be able to 'untangle bit-stream mix-ups'
Discussion: Dick points out that untangling bit-stream mix-ups has
no role in ordinary testing of interfaces since there is no mechanism for
bit-stream mix-ups to occur, and that a significant piece of hardware would be
necessary (in particular, a 32*32 correlator) to fully meet this
requirement. If there is a mix-up, it can be easily untangled by
examining the first few bits of each sequence and comparing against Table 13.
New Draft: No requirement, but a footnote to the effect that this
capability might be nice.
-
12. LVDS Receiver
Issue: Dick Ferris suggests that a receiver with no input should
fail-safe to logic '1'. Other suggest that the fail-safe state should
simply be a stable '0' or '1', with no preference.
New Draft: Fail-safe to logic '1', which is actually part of the
TIA/EIA-644 standard, as Dick points out.
-
13. TTL Monitor Ports
Issue: The 9Feb draft specified TTL monitor ports should be designed
to drive into 50-ohm load. Dick Ferris suggests that, if the ports are
only for occasional scope monitoring, that a better way is to use a 50-ohm
'back termination' by placing a series 50-ohm resistor on the TTL driver.
New Draft: 50-ohm back termination. We can argue about this if you
want.
-
-
There are probably some other things that I have changed and forgotten to
mention, but none major, so it would be well to read the whole draft
carefully. In a few places I have re-organized for clarity or logical
structure, but you can judge whether these changes have the intended
effect. The VSI-H document has grown to rather substantial size, as you
can see, and I hope that it does not grow any larger. As you know, I am
very anxious to get *all* of these issues settled soon and move on to other
things (VSI-S?). The longer we drag things out the less useful the VSI-H
spec will be.
-
Early next week I will e-mail the details of the 10 May telecon. Please
explode any comments you have directly to the distribution group of this e-mail
because there is little time for me to receive and explode them. We may
all have to give and take a bit to come to final agreement, and I trust that
everyone is willing to be a flexible as possible to nail this thing down and
get it done.
-
Regards and thanks, Alan