2 Feb
2022
2 Feb
'22
12:28 p.m.
The CRC for the data is offloaded to the DUP11. If it was done in
software, it would loop in the KG11 again. Like I said, if the KG11 is
enabled, it is used everywhere.
But the fact is that the DUP11 have built-in CRC check/generation. It
would be silly to not take advantage of that. If you use some other
interfaces, more will be done in software. For example, the DU11, or
indeed any async line, such as a DL or DZ.
However, the KG11 is used both at transmit and receive time. But one
KG11 is enough, since the whole packet is checked at once, and not
piecemeal while the packet is being transmitted/received, which would
potentially cause problems if you have multiple interfaces being active
in parallel, or indeed full duplex operation.
Johnny
On 2022-02-02 10:09, R. Voorhorst wrote:
L.S.
So in the end I had little to do J (thanks Paul and Johnny), and the
updated code by Paul fixes the problem and yes, the diagnostics still
complete without complaint. A check of the engineering drawings should
verify/confirm how the pulse count is actually terminated/reset in hardware.
Johnny confirmed with the code analysis the suspicion that KG11 was
sparingly used and the bulk crc processing was probably offloaded to
either Decnet11MP software or even the Dup11 hardware crc processing
capabilities,. That makes the use of the one KG11 needed quite
superfluous. It is only used for transmission header checking so it is
interesting to see how it functions with async Decnet lines.
Second is how this error in the header check propagates to a crc check
of the data-body processed elsewhere, but both crc errors disappear with
the fix.
@Mark: do you need the another serving of the solution by Paul:
static void do_poly (int unit, t_bool step) {
if (kg_unit[unit].SR & KGSR_M_DONE)
return;
if (step)
cycleOneBit (unit);
else {
while (!(kg_unit[unit].SR & KGSR_M_DONE))
cycleOneBit (unit);
* kg_unit[unit].PULSCNT = 0; /* *** ADDED *** */*
}
}
You can attribute the solution to Paul if attribution is in order as he
ultimately found it.
Best regards,
Reindert
-----Original Message-----
From: Paul Koning [mailto:paulkoning@comcast.net]
Sent: Wednesday, 02 February, 2022 02:26
To: HECnet <hecnet(a)lists.dfupdate.se>
Subject: [HECnet] Re: KG11 emulation probably defective -->some first
results
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Feb 1, 2022, at 7:27 PM, Johnny Billquist
<bqt(a)softjar.se
<mailto:bqt@softjar.se>> wrote:
By the way, I do agree that it looks like you
spotted the problem, in
that the KG11 seems to just do a single cycle
when it should process a
word. Now you just need to figure out why it goes
wrong in that way.
:-)
Johnny
I think I see the problem, but how the KG11 diagnostic can pass at all
is quite beyond comprehension.
In the data register write, the emulation clears the DONE flag, then if
SEN (shift enable) is set, it begins the checksum update. In normal
mode (not single step) it loops on the "do a step" operation until DONE
is set again.
So far so good.
How does DONE get set? In function cycleOneBit, an internal counter
PULSCNT is compared with the count that belongs to the currently
configured mode: 6, 8, 12 or 16 depending on the polynomial. When
PULSCNT reaches the limit (more precisely, when it is >= the limit) DONE
is set.
The trouble is that PULSCNT is cleared only by reset and by status
register write. It is NOT reset at the end of a normal byte or word
operation. That means that every operation after the first one will
only do one bit, unless the host writes SR after each byte or word.
The solution seems to be to add a clear of PULSCNT after a byte or word
has been consumed:
static void do_poly (int unit, t_bool step) {
if (kg_unit[unit].SR & KGSR_M_DONE)
return;
if (step)
cycleOneBit (unit);
else {
while (!(kg_unit[unit].SR & KGSR_M_DONE))
cycleOneBit (unit);
kg_unit[unit].PULSCNT = 0; /* *** ADDED *** */
}
}
paul
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
<mailto:hecnet@lists.dfupdate.se> To unsubscribe send an email to
hecnet-leave(a)lists.dfupdate.se <mailto:hecnet-leave@lists.dfupdate.se>