Re: KG11 emulation probably defective -->solved (by Paul as it is) --> rcv/xmt transmission
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>
2 Feb
2 Feb
1:25 p.m.
New subject: KG11 emulation probably defective -->solved (by Paul as it is) --> rcv/xmt transmission
Ha. You are right.
The DECnet code assumes that the CRC check on reception, by the
hardware, was over the whole packet, and not just the data part.
If the hardware signalled that a there was a CRC error, only then will
DECnet do a CRC check on the header part. And if that is ok, it will
assume it was an error in the data part.
So the CRC computation routine is in fact not called normally.
The code you are interested in would be [117,10]STCRC.MAC
But I don't know if what the fiche is generated from. If it contains the
listings, it might be [130,34]STCRC.LST
Johnny
On 2022-02-02 13:00, R. Voorhorst wrote:
@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:
--
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
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
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>
3:26 p.m.
New subject: KG11 emulation probably defective -->solved (by Paul as it is) --> rcv/xmt transmission
On Feb 2, 2022, at 7:00 AM, R. Voorhorst
<R.Voorhorst(a)swabhawat.com> wrote:
@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.
.
An interesting math detail is at work here. DDCMP defines the CRCs as covering header and
data respectively. But the CRC used has an initial value of zero and a final value also
of zero -- in other words, if you run both data and associated CRC through the CRC logic,
the result at that point is zero.
A lot of other CRCs don't work that way. In many of them the initial value is all
ones, and the final value is constant but a random-looking pattern. CRC-32 is an example
(the Ethernet CRC). I don't know enough math to say whether this is true if and only
if the initial value is non-zero.
So with the DDCMP CRC-16 behaving the way it does, you can handle the data CRC either by
operating on just the data field, or on the whole packet including both header and header
CRC; the answer is the same either way. This allows the DUP-11 to offload CRC generation
and checking without needing to know anything about DDCMP headers.
paul
824
days inactive
824
days old
2 comments
3 participants
participants (3)
-
Johnny Billquist -
Paul Koning -
R. Voorhorst