Alan,
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
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.
--Rick