Gentlemen,
-
I apologize for the long silence on VSI, but I had some wait to hear from everyone regarding the 11 May 2000 draft VSI-H proposal.  Following is the status of replies from the VSI committee members:
-
Wayne Cannon - approve
Brent Carlson - approve
Dick Ferris - approve, with minor corrections and updates
Dave Graham - approve
Nori Kawaguchi - neither approve nor disapprove
Tetsuro Kondo - approve
Sergei Pogrebenko - approve
Misha Popov - no response
Jon Romney - approve, with suggestions
Ralph Spencer - approve, with suggestions
Alan Whitney - approve
-
As you can see, the 'vote' is 9 approve, 1 neither approve nor disapprove, and 1 no-response.
-
Included below are all the e-mail responses I received from VSI committee members regarding the 11 May 2000 draft so that you may read them yourself.  I have included my own comments within square brackets '[...]' within the body of these e-mails to indicate my response to various suggestions, almost all of which were good.  The attached updated VSI-H proposal has been updated accordingly and I ask that you review the e-mails and the corresponding updates in the specification.  Unless I hear any voices of disapproval before 14 July, I will assume implicit approval of these updates.  Furthermore, given the strong majority for 'approval' , I suggest that (assuming approval of the updates) that we declare the VSI-H standard as 'approved' and distribute it to the world.  Please let me know if this is not acceptable.
-
As usual, the updated VSI-H is attached in both pdf and postscript format.
-
Thanks to all of you for your hard work on VSI-H.  I feel it is a significant achievement of which we should be justly proud.
-
Regards, Alan
-
--------------
The responses (in order received):
--------------
From Dick Ferris (ATNF/CSIRO):
-
X-Authentication-Warning: venice.tip.CSIRO.AU: dferris owned process doing -bs
Date: Mon, 15 May 2000 12:26:59 +1000 (EST)
From: Dick Ferris <Dick.Ferris@atnf.csiro.au>
X-Sender: dferris@venice.tip.CSIRO.AU
To: "Alan R. Whitney" <awhitney@haystack.mit.edu>
Subject: Re: Proposed VSI-H specification
-
Hi Alan,
That looks fine.
Nothing to note but a couple of typos.
p.1 TOC "15. Glossary"
The two sections are now 15.1 and 15.2
p.9 footnote 3
""... footnote *in* Section 13.4"
p.17 Section 12.3, item #1
a stray "f" at the end of the line.
-
[All fixed - ARW]
-
Cheers,
Dick
-
The following e-mail was also received a few days later from Dick with useful suggestions which have been incorporated:
-
X-Authentication-Warning: venice.tip.CSIRO.AU: dferris owned process doing -bs
Date: Thu, 25 May 2000 18:58:18 +1000 (EST)
From: Dick Ferris <Dick.Ferris@atnf.csiro.au>
X-Sender: dferris@venice.tip.CSIRO.AU
To: "Alan R. Whitney" <arw@dopey.haystack.edu>
Subject: VSI-H: Unused Pins
-
Hi Alan,
12.1.6 Cable Specs
Notes:
1. Ground unused pins ..... (page 15)
This note was originally attached to the MDR-14 (Timing Interface)
connector but in the present layout could be understood to apply to the
MDR-80 (Data Interface) as well. For instance a B-compliant DIM with only
16 input channels would dutifully ground pins 41 to 72, thereby causing
some discomfort to the driver chips in any 32 channel DAS connected to it.
We could make it explicit to the MDR-14, and talk about 'undefined' rather
than 'unused' pins, and insert a new Note 2. to cover 'unimplemented' pins
(in any interface), vis:
2. Input lines should be terminated normally even if a circuit is
not implemented. This provides proper loads for all drivers,
and avoids problems due to resonances in floating wires in the cable.
-
The current Note 2 is overarching and the notes as a whole would read
better if it was presented first, and it adopted a generic tense. Also,
the statement "Standard cable lengths...." is really a specification and
should precede the Notes.
I suggest we rearrange things as follows:
...
...
7. Rated frequencies ....
Standard cable lengths....
Notes:
1. Cable assemblies comprise n-pair screened ....
2. All input lines ....
3. MDR-14 only. Ground undefined pins ....
-
In References on page 23 the LVDS home page might be a better reference
for Nat Semi, vis: http://www.national.com/appinfo/lvds/
This contains direct links to LVDS-specific application notes, data sheets
etc, including a new version of the LVDS Owners Manual/User Guide, parts
of which have been extensively revised.
Cheers,
Dick
-
[All done - ARW]

---------------------From Kondo-san (Kashima):
-
-Authentication-Warning: ns1.crl.go.jp: Host crlgw1 [133.243.18.250] claimed to be crlgw1.crl.go.jp
From: "Tetsuro Kondo" <kondo@crl.go.jp>
To: "Alan R. Whitney" <awhitney@haystack.mit.edu>
Subject: Re: Proposed VSI-H specification
Date: Mon, 22 May 2000 16:49:03 +0900
X-Mailer: Microsoft Outlook Express 5.00.2014.211

Dear Alan,
We, Kashima VLBI group read the final draft carefully
and we concluded that i t seems to be OK.
Best regards,
Tetsuro Kondo + Kashima VLBI group
-
---------------
From Brent Carlson (DRAO):
-
Date: Tue, 23 May 2000 10:40:31 -0700
From: B Carlson <Brent.Carlson@hia.nrc.ca>
Organization: National Research Council of Canada
X-Mailer: Mozilla 4.5 [en] (WinNT; U)
X-Accept-Language: en
To: "Alan R. Whitney" <awhitney@haystack.mit.edu>
Subject: Re: VSI-H specification approval - IMPORTANT!
-
Hi Alan:
I have had a chance to do a detailed read of the proposed VSI-H spec dated
11 May 2000. It looks very good to me--I especially like the mechanism that
has been chosen for synchronization of the DOM to the DPS. It looks very solid
to
me. I just want to point out two things that have come up in my work on a
proposed correlator and digital phasing system for the Expansion VLA:
1. GORE makes an 80-pin MDR cable that could be used for the VSI-H. The cost
for each cable is a few hundred dollars but it is capable of better than 1 Gbps
on each 40 twin-ax lines up to several meters in length. Each twin-ax cable is
individually shielded and jacketed. We use these twin-ax cables in our current
correlator at 1 Gbps--although not in the 80-pin MDR format.
2. The digital phasing subsystem we are proposing for the EVLA could produce
data at sample rates up to 256 Ms/s (128 MHz bandwidth). Is it possible to
include this rate in the VSI-H as an option? Or, better yet, allow rates > 128
Ms/s in doubling factors. Otherwise, some demultiplexing of data onto the bit
streams would be required. If the GORE cable is used it could certainly
support the 256 Ms/s bit rate. Note that the digital phasing subsystem would
allow rates lower than 256 Ms/s to be generated if necessary.
Good work on the specification and, "I approve" the spec.
Cheers,
Brent Carlson
DRAO--Penticton.
-
[Reference added for GORE cables - ARW]
-----------------
From Dave Graham (MPI):
-
From: David Graham <p062gra@mpifr-bonn.mpg.de>
Subject: Re: VSI-H specification
To: awhitney@haystack.mit.edu (Alan R. Whitney)
Date: Wed, 24 May 2000 15:31:36 +0200 (MEST)
X-Mailer: ELM [version 2.4ME+ PL39 (25)]
-
Hi Alan,
I am sure you have everything of significance in the document,
therefore I will shout loudly 'YEA' and understand the details later.
regards,
dave
-
-----------------------
From Sergei Pogrebenko (JIVE):
-
Date: Thu, 25 May 2000 15:56:19 +0200
From: Sergei Pogrebenko <pogrebenko@jive.nl>
Organization: Stichting ASTRON
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
To: "Alan R. Whitney" <awhitney@haystack.mit.edu>
Subject: Re: VSI-H specification
-
Dear Alan,
I approve the draft.
That's a good spec.
Best regards,
Sergei
-
--------------------------
From Ralph Spencer (Jodrell):
-
Date: Fri, 26 May 2000 14:16:21 +0100 (BST)
From: Ralph Spencer <res@jb.man.ac.uk>
X-Sender: res@cautha
To: "Alan R. Whitney" <awhitney@haystack.mit.edu>
Subject: Re: VSI-H specification
-
Dear Alan,
I've had a good look at the spec. and it looks a nice piece of work -
Congratulations to all involved as it must have been difficult to design
and write such a general thing.
-
The only criticism I have is the there are many abreviations which the
glossary doen't address - I would like to see a much more comprehensive
list - and placed at the front after the contents list so that it becomes
more obvious to the reader (our theses are always done that way).
[I have added more entries to the glossary, but decided to keep it at the
back since it involved a lot of renumbering work which I am too lazy to do - ARW]
A sentence to say that the format of data to be sent on the transmission
medium on the output of the DIM and input of the DOM is not specified as
it will depend on the application would be useful in say sect 2 or 5. [Done - ARW]
The document has come at the right time for me as I am preparing the final
report for the EVN optical fibre feasibility study -- is there an
appropriate way to refer to the VSI-H spec. so that say someone from
Brussels could get hold of it?
-
Cheers
Ralph
-
------------------------
From Jon Romney (NRAO):
-
Date: Tue, 30 May 2000 17:55:41 -0600 (MDT)
From: Jon Romney <jromney@aoc.nrao.edu>
To: awhitney@haystack.mit.edu
Subject: Re: VSI-H specification
Cc: gpeck@zia.aoc.nrao.edu
X-Sun-Charset: US-ASCII
-
Hi, Alan. I have (finally) had the opportunity to go over the "final draft"
VSI-H specification with George Peck. Our review was generally quite favor-
able, but we did encounter a few points where we had either suggestions for
improvements in the text, which I sent to you by e-mail last Thursday, or
more substantive concerns, which we discussed with you in a brief telecon on
Friday.
-
Appreciating your policy of distributing everyone's comments to the entire
group, I'm writing here to put all our recent input into a single message
which you can send out.
-
First, here again are our textual suggestions, which we expect won't require
any discussion --
-
-- While it's good to have the specific exceptions for Level B compliance
listed early on in the document, a reader unfamiliar with the document will
find many of these confusing. We suggest including a forward reference for
each to the section where it is discussed. [Done - ARW]
-- In Section 6, and many places subsequently, "transmission media" is used
in singular constructions. Correct Latin grammar would require "medium" here,
which also sounds right to my ear. A global replacement might be dangerous,
though; in at least one place, Section 14.2, the plural usage is correct. [Done-ARW]
-- We would like to see, somewhere, a statement that the DIM must be able to
select either 1PPS or ALT1PPS. In the recent global telecon, it was pointed
out that Figure 1 shows a switch in the DIM, but this doesn't seem adequate
documentation. An appropriate sentence could be added either in Section 7.1,
where ALT1PPS is introduced under "Other I/O Signals", or in the Notes in Sec-
tion 10.1. [Done - ARW]
-- We would also like to see the possible pass-through of PVALID by the DTS
to QVALID, as discussed in Section 14.3, mentioned as an option in the des-
cription of QVALID in Section 8.1. To us, this seems to be a more likely app-
lication than the pulsar-gating function which does appear in Section 8.1.
[Done - ARW]
-- "LVDS" will be unfamiliar to many readers. We suggest adding a note to
Table 1 in Section 10.1, pointing to the description in Section 12.1. Then
in that latter section, expand the acronym at the very beginning, and move
the reference to the basic LVDS spec above the enumeration of the three inter-
faces. [Done - ARW]
-- Note 2 at the end of Section 10.4 is not strictly complete. If the speed-
up factor can *ever* be different from unity, it must be specified no matter
what its value. Just change "is operating" to "can operate". [Done - ARW]
-- In Table 9 in Section 12.1, GND on pins 7..14 says "(see Notes)". But we
couldn't find the relevant note. [Fixed - ARW]
-- We suggest moving Section 14.4 to precede Section 14.2 (and renumbering
appropriately. As the order stands, you have a discussion of a minor feature
of media translation appearing before the main event. [Done - ARW]
-- Many of the labels to Figures 3 and 4 mutilated in our copies of the docu-
ment: all the voltage levels on the right side, and the time intervals below
the shaded eye pattern in Figure 4. [Done - ARW]
-
And then, these points summarize our input on some more substantive issues,
factoring in the results of our brief discussion --
-
-- Item 3 in the definition of Level B compliance in Section 4 is confusing,
in that it may be interpreted to refer to one end or the other of the full
range of f_CLOCK. In fact, it appears to mean something more general, like
"incomplete support of the full specified range of f_CLOCK". We suggested
that this phrase be used instead. [I agree. Done - ARW]
-- In Section 7.1, 'BSIR' deviates from the usage which is almost standard
everywhere else in the document, with uppercase names denoting either modules
in the block diagram (DAS, DOM, etc.) or signals (CLOCK, ALT1PPS, QDATA, etc.)
and frequencies being denoted by 'f' with a subscript, like 'f_CLOCK'. The
meaning of 'BSIR' makes it appropriate to use the latter convention. We sug-
gested calling it 'f_BSI'. Everything just said applies as well to 'RBSIR',
which we suggest changing to 'f_RBSI', in Section 8.1.  [Done - ARW]
-- Note 3 in Section 7.3 appeared, to us, to indicate that the DTS *should
not* do any internal (de-)multiplexing, a subject which we all felt the VSI-H
spec should not address at all. The literal meaning of the text does not say
this, we recognize, but the implication was there largely because we couldn't
think of any other reason for this note's existence. In fact, it apparently
was aimed at (de-)multiplexing to/from bit rates above 32 MHz. We asked that
this aspect of the (de-)multiplexing be mentioned specifically in the note,
and that a second sentence state explicitly that the DTS designer is free to
implement any multiplexing scheme that faithfully transmits the input 32-MHz
bit streams to the output. Similar considerations apply in reverse for Note
2 in section 8.5. [Note 3 Section 7.3 modified - ARW]
-- A serious ambiguity occurs between the "Reconstructed Observe Time" (ROT)
mentioned as Input timing signal 2 in Section 8.1, and the "Requested Observe
Time" (also ROT) of Section 8.2. Our discussion concluded that the latter
was the correct ROT, and that "Reconstructed" should be changed to "Requested"
in 8.1. [fixed - ARW]
-- The first sentence of Section 8.3 seems unnecessarily restrictive: "The
DOM must be able to reproduce data at the same rate at which it was accepted
into the DIM." If we're permitting speed-up and/or slow-down on reproduce,
why must a unit speed-up factor be required? A DTS that doesn't reproduce at
the input rate may be unacceptable for some applications, but equally so a
DTS that doesn't support twofold speed-up may be unacceptable in others. You
agreed to delete the first sentence and rewrite the second as necessary to
lead off the paragraph. [I agree. Modified - ARW]
-- We took issue with the joint setting of the ROT clock and the bit offset
in Section 8.4. There are cases where one might wish to set either one and
leave the other undisturbed, and it seems safer not to have to reset the un-
changed value. We all agreed that separate set commands were acceptable. In
the case where one does want to change both, it's necessary to ensure that
both are set on the same 1PPS tick, but the existing language appears to me
to allow this. You agreed to rewrite this section accordingly. [Modified
as suggested - ARW]
-- The reference, in Note 3 of Section 10.1, to the "operating point in Ta-
ble 2" confused us a bit. I suggested that it might be clearer to say that
"k is determined by the relevant cell in Table 2", or something along those
lines. [Done - ARW]
-
That's it. Thanks for the opportunity to provide our somewhat belated input.
Jon Romney
-
---------------------

From Kawaguchi-san (NAO):
-
X-Sender: kawagu@hotaka.mtk.nao.ac.jp
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1-J
Date: Mon, 05 Jun 2000 14:10:04 +0900
To: awhitney@haystack.mit.edu
From: KAWAGUCHI <kawagu@hotaka.mtk.nao.ac.jp>
Subject: VSI-H compliance from VERA terminal
Cc: kawagu@hotaka.mtk.nao.ac.jp, kondo@crl.go.jp
-
Dear A.R. Whitney,
I am sorry for my long silence to your e-mail messages and a
final draft of VSI-H specifications dated on May 11, 2000.
The reason is that I have to do many technical discussions
with engineers who are now designing the VERA terminal
approved budgetary in the last year.
I tried my best efforts to accomodate the design to the new
VSI-H specifications especially on the time code transfer via the
P/Q "ASCII" data line but not approved. It is almost impossible
to change the specification without paying penalty of adding
extra developping costs. I am very unhappy with this result but
still have a hope to use the P/Q data in future. Tentatively
I am proposing the engineers a compromise plan to use the MDR14-
pin connector to transfer the IRIG-B serial format.
I am now preparing a document titled "The VERA 1-Gbps terminal
level-B compatible with the VSI-H specifications" and show you
soon later.
Nori Kawaguchi
-
------------------------
From Wayne Cannon (Crestech/SGL)
-
From: Wayne Cannon <wayne@sgl.crestech.ca>
Subject: Re: VSI-H
To: "Alan R. Whitney" <awhitney@haystack.mit.edu>
Date: Thu, 15 Jun 2000 13:50:40 -0400 (EDT)
CC: Bernard Williams <bernard@sgl.crestech.ca>,
Sasha Novikov <sasha@sgl.crestech.ca>,
Paul Newby <paul@sgl.crestech.ca>, Bryan Feir <bryan@sgl.crestech.ca>,
Georg Feil <georg@sgl.crestech.ca>,
Virginia Roznovan <virginia@sgl.crestech.ca>,
Rex Persaud <rex@sgl.crestech.ca>,
Laurie Geddes <laurie@sgl.crestech.ca>
X-Mailer: ELM [version 2.4ME+ PL76 (25)]
-
Dear Alan:
After a lengthy period of mulling over further comment on or criticisms of the
Proposed VLBI Standard Interface Hardware (VSI-H) Specificaton from the
engineering designers at SGL we have generated none.
You should regard this message as a statement of support of the proposed
document from the VLBI group at the Space Geodynamics Laboratory (SGL)
including (in alphabetical order)
Cannon, Wayne
Feil, Georg
Feir, Bryan
Kirby, Bill
Newby, Paul
Novikov, Alexander (Sasha)
-
Best wishes,
Wayne
-
-------------------------------
No response from Misha Popov (ASC)