9

I've been trying to figure out how the sequence of microcode instructions as described in the schematics and ROM listing in the PDP-11/40 (KD11-A Processor) relates to the timings given in Appendix C of the Handbook, but I can't make the two match. If I just add up the time for the microinstructions, the result is always lower than it should be.

Example 1: JMP (Mode 1), 1.80 us nominal

  Cycle  Bus Microcode
  -----  --- ---------
  140 ns  +  FET00/01/02
  140 ns     FET03
  200 ns     FET04
  140 ns     FET05
  200 ns     JMP00
  140 ns     JMP04
  200 ns     JMP12
  140 ns     JMP13
-----    ---
1.30  us, 1  Bus Cycle

Example 2: JMP (Mode 2), 2.10 us nominal

  Cycle  Bus Microcode
  -----  --- ---------
  140 ns  +  FET00/01/02
  140 ns     FET03
  200 ns     FET04
  140 ns     FET05
  300 ns     JMP01
  200 ns     JMP02
  140 ns     JMP04
  200 ns     JMP12
  140 ns     JMP13
-----    ---
1.60  us, 1  Bus Cycle

Example 3: JMP (Mode 3), 2.30 us nominal

  Cycle  Bus Microcode
  -----  --- ---------
  140 ns  +  FET00/01/02
  140 ns     FET03
  200 ns     FET04
  140 ns     FET05
  300 ns  +  JMP05
  140 ns     JMP11
  200 ns     JMP12
  140 ns     JMP13
-----    ---
1.40  us, 2  Bus Cycles

I know about the three possible clock cycles (140/200/300 ns). I know that the clocks are turned off for a Unibus cycle and turned on again at completion of the cycle, but I get varying length for the bus cycles, if these intervals are what is what is missing.

So: Given the sequence microinstructions for a command as described here, how can I derive the time necessary to complete a macroinstructions?

(The Processor Manual explains the microcode signals, among other things).

| improve this question | |
  • IMHO listing the three URLS of the manuals directly is less confusing than hiding them in the text - anyone who'll dive into this will likely just download all three. – dirkt Apr 16 '17 at 13:32
3

It looks like the bus cycles account for the difference. Treat a bus cycle as something in the neighborhood of 450-500 ns and treat the rest as rounding error. If you want a firmer guess at the bus cycle time you will need to consult the documentation for the common memory boards that shipped with the 11/40 and see exactly how long they took to fulfill memory read/write requests.

The amount of time required for the full instruction includes bus access time; bus time is not deducted from instruction time. This means that actual instruction execution times will vary depending on the speed of your memory, and the values printed in the processor manual should be considered "par" values you can expect with the default memory that DEC was shipping at that time.

| improve this answer | |
  • I already had this idea, but: why does Appendix C use differing bus cycle lengths? That makes no sense. I'd expect them to use one particular length, as "average" or "par". And the timing just gets more confused if you look at more examples. Also, the docs say explicitely "clock is turned on again at end of Unibus cycle, or when CLKOFF executes, whatever happens later", so I'm not sure this is only for Unibus cycles on slow devices. Therefore, I'm pretty sure I'm missing something else. – dirkt Apr 16 '17 at 17:09
  • It's possible that bus cycles are different lengths because the amount they overlap with microcode cycles varies depending on the micro-instruction. But I suspect that the actual reason for the discrepancy is simply rounding error. It could even have been a typo. You can't expect these numbers to be exact because they weren't intended to be exact -- the document even says that you can expect timings to vary by up to 10% in either direction. The values are intended to be used to help programmers estimate performance, not help engineers build cycle-exact 11/40 replicas. – Ken Gober Apr 17 '17 at 2:57
  • 2
    Also keep in mind, in the 11/40 all memory cycles are Unibus cycles and different memories ran at different speeds. It would not be unheard of for an 11/40 to have different regions of memory to run at different speeds. Also, memory was not always in the CPU cabinet, sometimes it was in an expansion cabinet which meant extra Unibus latency. In the face of this kind of uncertainty, nobody expected the documented timings to be exact. The Unibus was a true asynchronous bus, it wasn't like a modern PC bus with a clock, handling slow devices by inserting exact integer numbers of wait states. – Ken Gober Apr 17 '17 at 3:17
  • Agree with all of above. Also note that the instruction timings in Appendix C were only specified to within +/- 10%. – Burt_Harris Oct 13 '18 at 20:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.