Dear Alan and Colleagues,


We are very sorry not to have responded to your mail.

We have discussed about proposed changes in the current draft for

VSI standard and about comments from Dick Ferris dated on March 13

and 31. Members from Kashima, CRL (Tetsuro Kondo, Junichi Nakajima,

Mamoru Sekido, Yasuhiro Koyama, and others) and Noriyuki Kawaguchi

from NAO participated in the discussions. I will summarize our

comments in the following message.


Sincerely Yours,


Yasuhiro Koyama and Tetsuro Kondo




Response to the e-message from Alan Whitney on 18 February 2000.


> 1. Two levels of VSI-H compliance have been established (see Section

> 4).  Level A is for systems that are fully-compliant with all VSI-H base

> specifications.  Level B compliance allows certain exceptions and makes it

> easier for existing designs to be accommodated to the Level B compliance

> standard.


We support this proposal.


> 2. An optional delay capability is specified for the DOM (see Section


> and is a bit different than explained in the 9 Feb notes.  The capability

> could be powerful and useful.  In order to make it generally useful, it is

> necessary to bring the ROT1PPS out from the DOM, and I have added this

> signal to the DOM output.  Please read Sections 8.3 and 15.2 to gain an

> understanding of this proposal. HOWEVER, it has been pointed out that

> unless ALL DTS's have this capability, there is no interchange ability at

> the correlators, which is a major goal of VSI.  Furthermore, there may be


> fair amount of correlator-specific stuff (particularly software) that has

> to be backed into a DTS to make it connectable to any given correlator. So

> I'm of two minds on including the delay in the current VSI spec at

> all.  Note that the delay capability can always be added as a separate

> module attached to the DOM output and that is where it probably

> belongs.  It may be appropriate at some time to write a separate spec for

> the delay module.  What do you think?


>From the draft specification and the e-mail message, it seems like

the amount of delay has to be changed during a scan. In this

case, however, the correlator has to control exact timing of

the bit level changes of the delay. It is necessary because fringe

rotators in the correlator have to be controlled at the exact timing

with the delay bit jumps. Our Giga-bit VLBI Correlator

at Kashima is using an external delay buffer unit and we carefully

designed the timing between the control signal from the correlator

and the behavior of the delay buffer unit. Unless we define the

control signal and the timing in the VSI specification, it will

be impossible to expect inter-compatibility between independently

designed DOMs with different realizations of the delay capability.


On the other hand, a fixed delay capability during a scan is

necessary in many existing correlator designs because there aren't

enough length of buffer memories in the correlators. Therefore, we

propose to replace the sentence "This capability is most usefully

implemented with the capability to precisely track a delay mode (a

set of spline coefficients, for example) to minimize or eliminate

model-based delay adjustments in the DPS" with the following



"The amount of delay adjustments should be commanded through the

Control Interface before the ROT clock is set. The delay stays

constant until the ROT clock is set again with another value of the

delay. The actual delay in the reproduced data stream may not be

precisely identical to the commanded delay, but the difference

between these two values have to be reported by DOMs through the

Control Interface."


> 3. A new proposal for an optional validity/bit-stream indicator has been

> added in Section 10.5.  This proposal adds no new wires and is completely

> backwards compatible to the base VSI-H specification.  Comments are



The proposal is acceptable as far as this function does not affect

the operations of correlator systems which is not designed for the

validity/bit-stream indicator. We propose to include a switching

capability to turn off the validity indicator by adding the following

sentence in the VSI-H specification.


"If the DIM and DOM are designed to support the validity per

bit-stream capability, each module should also has an ability

to turn off the capability. "


> 4. The TVG generator schematic has been slightly updated, with the

> assistance of Will Aldrich, to be consistent with the normal DTS timing

> constraints.  See Section 14.


We have no comments.


> 5.  The LVDS timing specs are still a bit tentative.  Dick Ferris has

> agreed to review and comment.  Anyone else is also welcome, of course.


We have no comments.




Minor comments on the "Draft VLBI Standard Hardware Interface

Specification - VSI-H (9 February 2000)"


(1) 8.4 Example of DOM Operation (P.6) 3.


delay option if implemented -> delay option is implemented

the PVALID signal is asserted logical 'true' -> the QVALID ...


(2) Table 6


VALID should be QVALID.


(2) Table 9


Tch max values should be 0.6Tc not 0.5Tc?

Negative signs are missing for Tcq min values.


(3) 16.2 Signals


The signal level for the ALT1PPS should be LVDS not TTL.




Comments on "Comments on 9th Feb Draft" by Dick Ferris (31 March 2000)


2. Proposed New Items


Item(2c.1) Reversed Channels Function


We strongly disagree with the reverse channel implementation from

the following reasons.


(1) If a future correlator at some place is designed to use the

QSPC/QSPD lines to control the synchronization between the DOMs,

it will not support other DOMs which are not implemented the

QSPC/QSPD lines. In this case, the correlator can support a part

of DOMs and will not accept other party's DOMs. We should encourage

the DPS designers to use the DPS1PPS and DPSCLOCK lines in the

MDR14 cables to control the DOMs to allow all DOMs can be connected

to the DPS. To maintain the interchangeability between VSI-H

modules, we should limit the use of undefined or undocumented



(2) There are 4 pairs of unused lines in the MDR14 connector. If

any reversed direction signals are truly necessary in the future

expansions for the VSI-H specification, we can use these lines.

If we do not have any unused lines in the MDR80 interface, it will

limit our flexibility in the possible future revisions for the



Items (2c.2) and (2c.3)


We strongly disagree with these proposals with the same reasons

described above.


Item(2d) Proposal for P/QData Format


We understand the importance to define the data format to be

carried over the P/QData line, but we feel this item will be an

issue to be defined in the VSI-S. We think it is natural to express

the data in the syntax proposed in (2d.2), but discussions will be

required among wider community. We have to discuss further in the

process to define VSI-S specifications and it will take long time.

We think VSI-H should not step in this part now.




Comments on "VSI Interconnect Hardware Specifications" by Dick Ferris

(13 March 2000)


1) Table 1


We disagree with the newly proposed pin allocation in table 1 which

is not commonly employed in the differential connection. The pin

allocation is optimized only for a particular LSI chip of LVDS387/389.

Original pin allocation described in Table 10 of the "Draft VLBI

Standard ...." is common. We already started manufacturing

prototype VSI components based on the current draft and there is no

problem at present.


2) VSI Cable Specifications


The specifications of the cables are defined very much in detail, but

there is no descriptions about the measurement methods. If these

characteristics are to be defined, the measurement methods have to be

defined too. Especially, the crosstalk and the impedance measurements

are sensitive to the measurement condition. Detailed technical issues

concerning the hardware designs should be continuously discussed

as a form of technical reports. Will Aldrich introduced us a nice

candidate for the VSI cable at the Haystack meeting. We propose

that an interested working group to measure the characteristics

of the cable as the first example.


3) VSI Receiver Specification


It is defined that "the Line Receiver will fail-safe to state 1 when

disconnected". This is an internal matter of each system and it does

not affect any of the functions of the VSI modules. Strange

behaviors are not preferable, but the state while the line is

disconnected is not important.