Complications of the IBM technology in the 1130 - 2

At just the right moment in time, when I realized that my skills in electrical circuits and electronics were woefully inadequate to the task ahead, Anant Agarwal at MIT was just launching his MITx educational initiative, beginning with a pilot course based upon the MIT 6002 course he teaches as the foundational EE course for MIT undergrads - Circuits and Electronics.
I joined that inaugural course of what has become EDx, expanding to a joint effort of MIT and Harvard under Dr. Agarwal's leadership. It was a great experience, often straining my very rusty math skills and forcing me learn new skills, for while I had done basic calculus years ago, I had to rapidly learn enough about matrix math, differential equation solving and other needed techniques to keep up with the class.  

It was exactly what I needed, developing enough skill in both analog and digital circuit design that I was able to dive into this project and take on whatever need be done. I only wish I had learned this material when I was young - I would have had so much more success with all the projects and hobby activities I undertook over the years armed only with ohms law and some rudimentary awareness of electronics. 

I was now able to understand what was occurring inside the SLT modules and in the 1130 machine. This wasn't the last hurdle, however, by a long shot. I will have to dive into a couple of technical subjects to properly communicate the basis of the new difficulties and complications. 

Modern digital design strongly favors, almost insists upon designs that are clock synchronous - that a single master clock signal is used to control each change of state in the machine. Often, logical conditions (signals) must be used to determine whether a given state is turned on or what value should be output by a circuit. Synchronous designs need only ensure that the necessary signals have arrived sufficiently ahead of the 'tick' of the clock and will remain stable for a safety margin after that tick, then implement the state change or new data value exactly at the tick of the clock. 

Alternative asynchronous design approaches, where the various signals are combined states change as soon as conditions align, can suffer from many problems. If one signal arrives early or late, the wrong value or new state might be implemented before all the intended conditions are in place. The output might waver between correct and incorrect values, short term signals might trigger changes that are undesired (glitches), and a successful async design needs careful attention to knowing and controlling the timing and duration of every involved signal. 

The 1130 and 360 systems may have a system clock, but it  is not used for synchronous logic. Rather, signals trigger a change of a flip flop as soon as they arrive. If conditions must be combined to determine what change to make, they must arrive at the proper time to avoid all the timing issues I discussed above. 

At many places in the theory of operations manual, this is alluded to by comments such as "a slight overlap of I-cycle FFs may occur" or "the gates remain active, because of circuit delays, beyond the end of . . .". With clock synchronous designs, all the signals needed to determine the next cycle must be in place before the clock tick, but in the 360 era designs they can trigger the change whenever they arrive even partway into a cycle. 

This would make it quite difficult to convert the design of the 1130 to a clock synchronous one, as some signals may not exist when they are needed. Possibly they could be created by a different set of logic so that they occur early enough to be used, but this is never universally true. 

The next difficulty pertains to the choice of technology to build my 1130 - an FPGA. FPGAs are particularly unsuited to asynchronous designs and anyone designing logic for FPGAs learns that clock synchronous logic is almost essential for proper machine operation. The heart of an FPGA is the look up table, where all the input signals are used to address a set of values that become the output signals. The design does not use AND, OR and other gates, it instead codes the values for outputs that would be produced from some set of logic gates and uses the look up table to implement it. The design tools render a logic design into values to be loaded into the lookup tables (thus making it field programmable) and the implementation of given design may change each time the design is touched because the design tools makes different choices and assigns different locations for the lookup tables inside the FPGA chip. 

What this means is that the timing delay for a signal is not well controllable by the designer. Further, techniques that are used to introduce delays using traditional gates are barely feasible with an FPGA.
If you wanted to build a 360 or 1130, the last technology you would consider would be an FPGA. 

Between the strangely behaving logic technology, async design practices and unsuitability of FPGA for async and timing dependent purposes, this project was going to be much more work than it appeared when I began.

No comments:

Post a Comment