送信者: Alan R. Whitney 宛先: Wayne Cannon ; Brent Carlson ; Dick Ferris ; Dave Graham ; Nori Kawaguchi ; Tetsuro Kondo ; Sergei Pogrebenko ; Misha Popov ; Jon Romney ; Ralph Spencer ; Alan Whitney 件名 : VSI-H status; final draft 日時 : 2000年6月25日 3:05 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 X-Sender: dferris@venice.tip.CSIRO.AU To: "Alan R. Whitney" 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 X-Sender: dferris@venice.tip.CSIRO.AU To: "Alan R. Whitney" 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" To: "Alan R. Whitney" 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 Organization: National Research Council of Canada X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en To: "Alan R. Whitney" 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 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 Organization: Stichting ASTRON X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en To: "Alan R. Whitney" 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 X-Sender: res@cautha To: "Alan R. Whitney" 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 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 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 Subject: Re: VSI-H To: "Alan R. Whitney" Date: Thu, 15 Jun 2000 13:50:40 -0400 (EDT) CC: Bernard Williams , Sasha Novikov , Paul Newby , Bryan Feir , Georg Feil , Virginia Roznovan , Rex Persaud , Laurie Geddes 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)