My comments to those of: Koyama-san and Kondo-san ... My comments are prefaced

with an "o" leading character.


> ------------------------------------------------------------------------


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


o This seems like the only method of gaining universal acceptance of VSI-H,

o so yes: agreed.


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

> 8.3),

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

> a

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

> sentence.


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


o I favor this GENERALIZED delay setting capability as being OPTIONAL, with

o its details being left presently unspecified in the VSI-H.  Further, I agree

o that the most common use of the delay offset capability is that for a fixed

o offset, and I would be ok with this being a REQUIRED capability. However,

o as I have noted to at least Alan in the recent past, I would recommend

o that the delay capability (at least the fixed offset capability) be

o also included in the DIM as well as the DOM. The primary use is to include

o "station clock offsets" in the DTS data time-stamps. Alan has agreed to

o include this is the revised VSI draft.


o I note that a GENERALIZED delay setting capability has been included in

o the S2 and has been very successful. It is (symmetrically) included in

o both "DIM" and "DOM" because the identical control circuitry is used for

o both DIM and DOM within the same physical module. Its use in the S2 DIM is

o for FIXED "station clock offsets" only. Its use in the S2 DOM/DPS is for

o "COARSE" delay setting during a correlation session and (very similar to the

o MkIII and VLBA systems) is intended ONLY to maintain data within a delay

o window defined by the size of a REQUIRED "fine-delay FIFO" in the DPS delay

o handler.  The absolute delay offset from the DPS 1PPS reference may be

o updated once per control-1PPS tick. Because the DPS is responsible for the

o "fine delay" function, no communication is required between the DOM and

o the DPS regarding the precise epoch of "bit shifts". I favor this type of

o implementation in the DOM, although as noted this may be categorized as

o an OPTIONAL capability.


> ------------------------------------------------------------------------


> 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

> lines.


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

> VSI-H.


o This "reversed channel function" might have been my original suggestion;

o as you know, I was never in favor of the arbitrary decision to enforce

o uni-directional flow on a given interface, and agreed only to achieve

o agreement. I only note that, in support of the optional "reversed channel"

o functionality, the designer should be able to provide the reversed channel

o capability ONLY if this capability can be "switched off" to conform to

o the specification. This is readily implemented using (bi-directional)

o TRANSCEIVER chips instead of (uni-directional) DRIVER/RECEIVER chips.

o Yes, this introduces some complexity, but is more in line with many

o present-day and future systems. I am of the opinion that this optional

o "reversed channel" capability should not be precluded from the specification.