Lab 08 - Wiring ALU, Shifter, Interrupt

Summary

1. I wired in the ALU and Shifter.
2. The Interrupt was interesting to build, but I initially misunderstood the basic asynchronous concept of the interrupt.
3. I wrote several variations of test programs for playing with the operations of the CAPC processor.

ALU Wiring: Connecting the timing and operations of each hard-coded function

I decided early that I didn't want to 'cheat' and use gates with 0 time to wire up the unit. I'll go into detail about how this affected the wiring later. Most of the ALU's wiring functions were no harder to connect than the earlier operations like JMP, INJ, SDG... However, after adding in a few more of the operations, I realized that I was going to need to be able to OR some operations a lot. Specifically things like SEND the IR Operand, and LOAD MAR. Given my desire to not use devices with a time of 0, I realized I was going to need a different solution to get past an OR-8. (LOAD MAR required an OR-12). The solution to this was to create a new primitive device in LogicWorks 4. The 'ultimate' test program I ran this week was to execute Professor Hasegawa's Self Correcting Code adder.

Wiring the ALU

• I didn't want to have 'trees' of delay 1 OR gates slowing down the execution of my instructions. The solution was to lay out my logic in a two plate model and used the larger OR primitives to tie repeat calls to an operation together.
• As seen below, (at the top) each instruction comes from the decoder and gets combined with specific timing sub-cycles in order to execute an operation. At the bottom, the calls to specific operations are OR'd back together and sent on to the target.
  Note a couple of operations that were earlier part of SC 0 or SC 2 were moved over here to reduce the delay that was introduced by OR'ing further down the line (top left).

Wiring and Timing for ADD

Add is the slowest function that the ALU performs.
• My initial ALU used the adder we built in Comp 211. This adder was a write-off as it took far too long to perform a 16 bit operation.
• I revised my adder to have a worst case scenario of 2 time units per bit.
• Thus for a 16 bit add operation, FFFF + 0001 will take 32 units to complete.
• This is still more than a sub-cycle, and as a result I built my self a test-bed to confirm exactly how long was required for the adder.
  Download my ALU test-bed.
• My notes from within the ALU Test-bed.

  Add Process:
  SC3: SD IR + LD MAR
  SC4: SD MBR + LDY
  SC5: SDG + LDX
  SC6: ADD + LDZ
  SC7: SDZ + LDG
  What to do with carry?
  
  Also, what is the required
  delay time for a full add opperation.
  
  First Carry is d3
  Successive Carry's are d2
  16 carry's in total =
      3 + 15*2 = 33
  
  LD X req's
      SC5 + D3 + LDX(D2) = 5.05
  
  ADD req's
      5.05 + .33/.20 = 6.18
  
  UNIshift0 req's delay 2
     ergo LDZ after
      6.18 + 2 = SC6 + D20
  Plus the internal time needed to
  propigate the signal from the
  registers to the 3-state output
  
  This is dangerous as the delay
  now overlaps SubCycle 7
  
  So this should yields FFFF + 0001 = 0000
  but at SC6 + 19 we get 8000
  Thus, LDZ must happen on SC7 with some extra delay to let the add operation complete.
  

Creating new Primitive Types in LogicWorks 4

To create a new primitive type:
• File
• New
• Device Symbol
  Notice, we haven't created the logic for our device yet.

Draw the device as you want it to appear:
• Important: When adding pins to a primitive device, the last pin must be set to output in 'Pin Function'.

Define your object's primitive type:
• Select Object->Subcircuit and Part Type
• Choose the primitive type for your object (as shown below)
  
• Save the new device into your library.
• Test your new device.



Interrupt

The current iteration of my interupt instruction works. However it is not correct in its implementation as I didn't think about the fact that interupt, by its very nature, is an asynchronous event.
• As I was coding the interupt as an instruction, as opposed to an event, I found I had six operations to perform, and only five sub-cycles to perform them in.
• The result is called slicing.
  I took three subcycles, and decreased the length of their 'pulse' to 5 units with a delta-5 leading edge trigger. This allows me to perform two operations in one full sub-cycle.
  
• I'll be revisiting this. The interrupt is going to need an interrupt flip-flop similar to the run flip-flop used for the HLT instruction.
• Also, my comment about the MAR showing XXX is out of date. By removing that last stage of send MBR & Load PC to the next sub-cycle, the MAR remains clean.

Program

The cool application that I ran this week is Dr. Hasegawa's Self Correcting Code Adder
• The adder iterates through a list of data by loading that data into the GReg.
• When the GReg contains a value where bit 15 is high (like 8000 or FFFF), then the program will terminate.
• I added one special condition in my program to allow me to test a few of my other functions include my 'programmed interrupt'.

  6018 9008 1020 7020 6021 1000 7000 A000
  0010 F000 F000 F000 F000 F000 F000 FFFF
  0000 6022 7000 6023 7020 C000 F000 F000
  0010 0011 0012 8000 0014 0015 0016 8000
  0000 0001 6018 0000 F000 F000 F000 F000
  602B 77F0 A02C 0000 A011 F000 F000 FFFF
  XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX
  

• I also modified this from the example Dr. Hasegawa gave us in class.
  • Instead of incrementing the add function, I'm incrementing the LDG function at 000.
    6018->6019->6020->...
  • Then I copy the sum into a special field for the sum: LDG 020 (7020)
  • This allows me to calculate a sum, without modifying the final result with my high flag bit.