2 Feb
2022
2 Feb
'22
1 p.m.
@Johhny:
Funny that is, I only see KG11 involvement in the traces in the Xmit header parts, not in
any Rcv header parts for the data packets, so it seems (for the Dup11 at least) complete
receive packet is checked in Dup11.
By the way, in which (CEX?) module in the listings on fiche does one find the crc support
with/without KG11?
Thanks for your analysis which clarified a lot.
Reindert
-----Original Message-----
From: Johnny Billquist [mailto:bqt@softjar.se]
Sent: Wednesday, 02 February, 2022 12:29
To: R. Voorhorst <R.Voorhorst(a)swabhawat.com>om>; 'The Hobbyist DECnet mailing
list' <hecnet(a)lists.dfupdate.se>
Subject: [HECnet] Re: KG11 emulation probably defective -->solved (by Paul as it is)
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
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to
hecnet-leave(a)lists.dfupdate.se
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>