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.
-
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.
-
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.
-
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.
-
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.
Recommendation:  I suggest that the primary specification for the cable is that it must deliver proper LVDS signals (i.e. meet the detailed electrical specs) at all times and under all conditions when a compliant DOM output is connected to a compliant DIM input, which are electrically well defined.  It seems to me that, in this regard, the *only* necessary explicit cable specification is maximum pair-to-pair skew, which Dick suggests be <=0.1T.  All other cable spec, except max cable length, are implicit.   Max cable length is clearly a function of clock rate, but does not seem to be a problem up to ~20m with good cable, so I suggest that the 20m number be adopted.  Kondo-san suggests an on-going discussion and evaluation of cables, and I think this is a good idea.  I would also suggest that the work that Dick has done to specify cables is a very useful guide and be included as part of that discussion.
-
6. LVDS Receiver Specification
Issue:   
-
7. LVDS Electrical Specs
Recommendation:  Adopt the detailed specification given by Dick.  This is more detailed and complete than the 9 Feb draft.
-
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.
-
9. 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.
Recommendation:  Other than to say that the signals should be electrically EIA-232 compatible, I'm going to leave it to you guys on this one.  Please let me have your vote.
-
10. Proposal for P/QDATA format
Recommendation: Leave this issue for VSI-S spec
-
11. 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.
Recommendation:  I will try to clean up this area in the spec.
-
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.
-
I think I have covered most of the primary issues.  I know there are a few other ones but I think they will probably more or less resolve themselves once we get the above issues under control.  Please remind me if this is not true.  I would much appreciate your timely response to these issues.  We *must* converge rapidly on all these points if we are to be able to finish the VSI-H spec, which is already getting overdue.
Regards and thanks, Alan