2 Feb
2022
2 Feb
'22
10:09 a.m.
L.S.
So in the end I had little to do :) (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
On Feb 1, 2022, at 7:27 PM, Johnny Billquist <
<mailto:bqt@softjar.se>
bqt(a)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 -- <mailto:hecnet@lists.dfupdate.se>
hecnet(a)lists.dfupdate.se To unsubscribe send an email to
<mailto:hecnet-leave@lists.dfupdate.se> hecnet-leave(a)lists.dfupdate.se