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