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@lists.dfupdate.se>
Subject: [HECnet] Re: KG11 emulation probably defective -->some first results

> On Feb 1, 2022, at 7:27 PM, Johnny Billquist <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@lists.dfupdate.se To unsubscribe send an email to hecnet-leave@lists.dfupdate.se