Been a little distracted. Has everyone who's interested puzzled out the circuits?
The inverter and the NAND get should have been real easy.
The flip-flop may have been tricky, but I think the hint should have been enough.
Was sick for most of the week, and there is the meet-up this weekend, but after that, I'll get cranking on explanations again. Just wanted to see if people are still interested.
Not planning too far ahead, but whats left for our little design is the actual circuits (crude-ones) to implement the bus traffic specified earlier. May have one more generic post on memories and multiplexers before that.
After that, I was think of using a more complicated example program that "polls" the switch bank...which would then segue well into the creation of interrupts (and we could go over an abstract implementation of those).
Then I was thinking, we could go over the concepts of "timing" and "clocking" in more detail in order to introduce the motivation for "pipelining." Once we "pipeline" then we can introduce the concepts of "hazards," and various ways to handle them, and to a light intro to "precise interrupts".
Then there are two possible tracks we could follow:
1) Stay focused on the processor and cover things like super-scalar architectures leading to out-of-order execution (where we need to return to precise interrupts) and we revisit precise interrupts. That has a whole bunch of stuff, like the Tomasulo algorithm/instruction scheduling, branch prediction/error recovery, register renaming, and a whole bunch of other stuff. Then there are vector processors (or vector instructions), stream processesors, and heterogeneous processors like CELL, and various GPUs (nVidia's Tesla is the likely candidate). Then there is the VLIW and EPIC type instructions sets as well. After which we can go on to 2) not having to worry about returning to the guts of a processor too often.
2) The other path is to step away from the processor itself for a little, and take a more system level view where we look at work-loads and benchmarking, and deciding what architectural improvements are actually worth doing for particular work-loads, memory hierarchies, caching, paging, segmentation, snooping and directories, etc. We'll Look at virtual-machines, offloading, and parallel processing in a lot of different models (SMP/CMP shared memory vs. message passing), and the various techniques and traps programmers can fall into when using multiple processors. Cover reliability, availability, bandwidth, and latency of clusters. Look at some basic compiler techniques, and evaluate parallelism in general from an abstract perspective. This gives adequate context for understanding the trade-offs we do when we cover the things in path 1). This is my preferred path.
Anyway, someone let me know if their still interested (breaks have a way of making people lose interest). It does take me some time, so I'd rather not post to the void.
__________________
sloan+ Rxua|I|; primary Inquisitive; R(82%)L(52%)U(62%)A(54%)I(86%)
CTO of IPTN (see Maverick's Sig.) and member of Maverick's Biker Club.
Accept the past. Live for the present. Look forward to the future.
My Blog
I linked some of your blogs; if you feel that is inappropriate, please let me know.
|