Determine gate infrastructure

[Espeer5]

With the current implementation of gates, gates are simply functions which do not require any internal structure. However, it may be beneficial to change this to a class representation for a few reasons:

• With classes, we could simulate the CMOS layout of each gate and simulate the actual ternary gate operations
• With classes, we could probably add to a global counter with each instantiation to count the total number of gates used
• We could also assign to each gate a number of tris or 3-muxes needed per gate so that we could count the total number of features used per chip

However, there are downsides. This would be a lot slower with a much large overhead, and we would need to greatly increase the amount of logic surrounding the wordMap functions. Clearly more thinking is required to decide on an infrastructure.

[Espeer5]

As a note, whatever we do with the gates should also be done for the muxes, since those are currently implemented as functions which simply select from and pass through one out of an array of input IOBus.data arrays. If the gates are kept as simple functions, then the muxes can be also to match them, but if the gates are converted to some kind of object with a more hardware specific implementation, so too should be the muxes.

[Espeer5]

As a note, whatever we do with the gates should also be done for the muxes, since those are currently implemented as functions which simply select from and pass through one out of an array of input IOBus.data arrays. If the gates are kept as simple functions, then the muxes can be also to match them, but if the gates are converted to some kind of object with a more hardware specific implementation, so too should be the muxes.

And to add onto this, a class based definition for the muxes would allow for some kind of type checking enforcement to ensure that every mux gets data arrays passed into them to choose between and not any other kind of object to standardize the mux usage and enforce the intended architecture of the system.

[Espeer5]

I've begun to think that we should use CNTFET over MOSFET given that it is a rising technology which would make ternary more feasible. With this in mind, let's brand away from CMOS as a building block, and resolve this issue by building a representation of our gates using CNTFET. The exact infrastructure in software is yet to be determined, but we can follow the actual gate circuits given here

[Espeer5]

I've begun to think that we should use CNTFET over MOSFET given that it is a rising technology which would make ternary more feasible. With this in mind, let's brand away from CMOS as a building block, and resolve this issue by building a representation of our gates using CNTFET. The exact infrastructure in software is yet to be determined, but we can follow the actual gate circuits given here

A first pass at providing infrastructure on this sort of approach is on the branch hardware

[Espeer5]

Moving the implementation of the CNTFET structure down the road. For right now, I want to focus on extending the functionality of the simulator so that I can study the algorithmic effectiveness and syntactic niceties of the ternary system first. CNTFET can be added on the backend at a later date. Want to get more functionality setup and rolling before I return to class in the Fall.

[Espeer5]

Closing due to scoping of the project; Would rather focus on the software pipes and development of a web app to showcase the functional ALU.