Alan,

Comments follow:

> Gentlemen,

>      You have recently received the comments from the Japanese group on a

> number of issues.  Since then, I have received some additional comments

> from Rick Wietfeldt, which I attach below.

>      In the interests of trying to make further headway and come to a

> satisfactory conclusion on VSI-H, I propose to try to outline the areas of

> 'major' and 'minor' (in my judgment) disagreements as best I can, and then

> make a recommendation on each issue that I hope you will find

> satisfactory.   It is important to settle these issues ASAP.

> -

> 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.

> Recommendation:  Stay with 9 Feb pinout.

Agreed.

> 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.

> Recommendation:  Stay with 9 Feb draft spec.

Agreed.

I would prefer mention in the spec (a footnote will do) that designers are free

to implement a bi-directional interface provided they are easily configurable

to meet the base specification.

> 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.

> Recommendation:  I suggest that a fixed DOM delay be specified when ROT

> clock is set which will remain constant until ROT clock is set again.  This

> delay would be specified in terms of whole reconstructed-bit periods

> (either + or -).  I suggest a range of +/-R1PPS.  This would allow an

> arbitrarily large delay offset with a combination of ROT clock setting and

> delay specification.  This delay capability would be a part of the *base*

> VSI-H.  Rick has suggested also adding a delay capability to the DIM, and

> that can be optional, but it does not, in my opinion, add any real new

> capability since the DOM delay can always be adjusted for to compensate for

> any delay which has been suffered in the DIM.

See my comments in earlier emails. I still prefer the DIM DOT-clock setting

capability for reasons of symmetry and unforeseen future applications.

(One very convincing application of the usefulness of this delay setting is

documented in "http://aqua.jpl.nasa.gov/jplswc/nraodecS2tim.html" , whereby a

seemingly compatible interface between the NRAO/Green Bank SVLBI Decoder and

S2 Recorder proved woefully incompatible in a very subtle way. The solution

was to be able to set the S2's DIM DOT-clock to a fraction of the bitstream

rate. This raises another point below.)

The precision of the delay-offset setting must be specified. It should be defined

as one cycle of the interface bitstream rate. For example, if the bitstream

rate is 16 MWord/s, the delay setting precision is 1/16MHz or 62.5 ns. This

should be independent of the actual CLOCK frequency. If a precise integer

bitstream-quantized delay-offset is not specified but is "valid" i.e. GREATER

THAN the inverse bitstream rate, then I suggest that the DIM "ROUND DOWN" to the

delay of the precise inverse bitstream rate. This must be specified.

Also, if an invalid delay is specified (e.g. a delay-offset LESS THAN the

bitstream quantized delay, e.g. say 31.25 ns for a 16 MWord/s bitstream rate),

this represents an error and the delay will not be set in. We should simply

state this, and leave all other details to the VSI-S.

Note that UNLIKE THE PROPOSAL ABOVE, the S2 permits delay settings to a precision

of the input CLOCK signal, not the BITSTREAM signal, provided the CLOCK frequency

is greater than the BITSTREAM signal rate. This was designed to support potential

incompatible system interconnections. If we do this right, this will not be

required for VSI-compliant systems, therefore we should NOT include this

in the VSI specification.

> 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.

> Recommendation:  Stay with 9 Feb draft spec.  Systems with external signal

> switching are defined as Level B compliant.

Many of us (including myself as a strong advicate) feel the requirement for a

crossbar precisely at the DIM input for input bitstream reordering. This has

many advantages, not the least of which is regarding item 12 below, namely:

"Issue: Whether TVR should be able to 'untangle bit-stream mix-ups'". The

crossbar will exactly untangle bit-stream mix-ups, one of my prime reasons

for suggesting the crossbar. Furthermore, this can apply in special applications,

such as duplicating input bitstreams to send to autocorrelators and other

special applications, some diagnostic. These modes/applications have been used

frequently in S2 operations.

> 8. 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.

> Recommendation:  I propose that we remove all mention of validity per bit

> stream in the current VSI-H spec.  At some point later we may want to

> re-open the issue.

I suggest that the present discussion be maintained in the specification as

an appendix, so as to keep track of it. It should be referenced only in the

main specification.

> 10. Proposal for P/QDATA format

> Recommendation: Leave this issue for VSI-S spec

Agreed.

> 12. 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.

> Recommendation: Drop the requirement that the TVR be able to examine each

> possible bit stream for each of the 32 possible TVG sequences.  This

> capability, of course, is not prohibited, just not required.

See comment on item 4 "Bit-stream selection and re-ordering" where I note

that the DIM crossbar will untangle bit-stream mixups at a given delay. Further,

with the DIM fixed delay-offset capability, the full 32x32 correlator is

implemented "for free" (a single delay-offset provides one correlator lag for

all bitstreams). This capability is provided in the S2 and has proven invaluable

in diagnosing interface problems.

The suggestion therefore is to include the DIM crossbar and DIM fixed-delay

offset capability. As you may guess by now, I would actually prefer REQUIRED,

but OPTIONAL is probably ok.