Diary:First design steps (2004)

From TriPU

02.12.2004

Still going slow :( I made some research to refine my VHDL models, the register part has yet to be acquired to the new schematics (zero write control and more registers). Probably triphoenix.de soon will move to another server that will allow me to add CVS support for my VHDL code as I'm on different locations where I want to edit the code (university has great resources on VHDL), also the VHDL code will be available online then :)

21.11.2004

Had to write a presentation about geographic information systems (university) and took the weekend off, sorry ;)

10.11.2004

Yes, I'm still here :) During the last days Dieter from http://people.freenet.de/dieter.02 sent me some interesting mails, currently we're discussing some of the TriPU design concepts and this gives me quite fresh and interesting input. You might wanna read his article on ALU design, I really like the idea with the multiplexer logic unit and the two-stage ALU (logic-unit + ALU) would make even a pipeline a possible thing. I have to consider these ideas with myself on the next train ride :) But the ALU is a thing that really caught my interest and will probably be implemented, thanks to Dieter for this really nice design :)

01.11.2004

Heya. Got some input on the construction bit from Andrew Holme http://www.holmea.demon.co.uk . He recommended some sort of wiring pen which allows to construct boards with magnet wire much faster than my current technique. Although these pen systems are quite expensive, this is a serious consideration and probably the way I will choose next. Only problem for now is ordering it, because the first shop I found only takes credit cards and I don't have one :) But equipped with a name for the thing I'll go hunting :> Anyway, many thanks to Andrew for this tip, will probably save me a lot of time :)

I also got some other mails about TriPU and am happy to find that some people are actually following the project :D Feel free to sign the Guest book or drop me some mail (address on the Main Page) if you feel like it :)

27.10.2004

Here we go. Currently I'm planning the control unit. If there's any regular reader she will remember that I wanted to have a sort of microcode cache, i.e. although microcode comes into the system through an EEPROM it will be used out of an SRAM. The problem with EEPROM is the time, EEPROMS are much too slow for what I target as clock cycle. So I have to design some sort of startup system which copies the EEPROM into the SRAM. Another advantage of this idea is that I can use only one EEPROM and copy it into several (atm up to 8) SRAMs, so I have up to 64 microcode bits for now. Of course this requires some logic that makes sure the system doesn't run while the microcode is copied, also the process of copying must not drive any control logic in the system. I think I have a working idea, of course I have to simulate it first etc. :) But anyway if you want to find out of the dark area of TriPU design, this is how it's done:

Another thing on my mind is etching. Working with magnet wire is a real tedious task and looking at some of the future boards I really hate the idea of wiring up all the stuff manually. So I'm currently looking into etching some boards at home, if anyone has a helpful link or anything, feel free to write a mail to tripu (at) triphoenix (dot) de :)

That's it for today.

24.10.2004

I'm back, babe :) Finally all moving stuff is done, university has started again and I have some time for TriPU, yeehaw.

Today I started by re-designing parts of the decoder and the I/O address circuit. As written before I discovered the beauty of the multiplexers and used some of them. You'll see that the decoder now sports 7 MUXes, three of them selecting a register address, the other four selecting one of the imm24 or imm8 fields to put on the data bus. In my opinion this creates a much cleaner design and reduces the number of lines that have to be driven by the control unit.

A similar change occured in the I/O address unit. The MAR register is now decoupled from it's tristate driver function on the I/O address bus. The upper row still contains the program counter (PC), the middle one has the memory address register (MAR) on the left and tristates on the right to read the value of PC back to the data bus. The lower row now contains 6 MUXes which select if the PC or the MAR should be used as the I/O address.

Both changes ensure, that the I/O address always will be driven with some value. Devices on the bus have to look for a request signal anyway and this way I can avoid high-impedance inputs on the address bus.

All the schematics on the page are updated and from now on updates will come more frequently again as I have the time for it now :)

29.09.2004

I'm _really_ sorry I still don't have any new information :( Fact is that I'll be moving in 3 days and these things take time. After I've settled in I finally will have the time to work on TriPU again :)

19.09.2004

Just a little blip I'm afraid, still got some things to do involving PIC microcontrollers, but wanted to give a little message, I will continue on TriPU asap :)

10.09.2004

Sorry for the long break, a lot work besides the TriPU atm :) Anyway I just redesigned the decoder a bit (schematics will follow), it now uses a multiplexer for the register decoding part. This is possible because the register bus has to be driven at any time anyway, also it saves chips and control signals (thus µROM).

Also the clock generation should be digitalized soon.

26.08.2004

Some hard thinking for today. First of all I think I should start writing some microarchitecture documentation. I don't know IF anyone is reading this, but if there is someone, she will probably have some problems understanding the schematics, because they're not documented well. I really should start some documentation there...

Another issue for today was clock generation. I thought a bit about it and consulted a newsgroup for some help (thanks to the helpful people at de.sci.electronics ;) The basic idea to create a clock involves a capacitor, a resistor and an inverter. Basically you put the capacitor at the inevrter's input and connect the output via the resistor back to the input. Assuming the inverter will start with a low input, it will output high and load the capacitor on the input via the resistor. When the capacitor reaches the voltage level for "high", the inverter will output low and drain the capacitor via the resistor and so on.

To make this clock variable in a fairly large range (I want to create clocks between 1Hz and roughly 10MHz, from debugging to the limits :) I will have to use four different capacitors and a logarithmic potentiometer (logarithmic because it will give a smoother reaction in frequency). The circuit will start with only a very small capacitor on the input (creating a range from 100kHz to 10MHz) and allows to switch some bigger capacitors on the input, allowing 4 different ranges, alltogether spanning round about 0.98Hz to 9.8MHz which should be enough :)

I also designed a little frequency counter which should allow to display the current clock frequence. It's a quite simple construction: A large counter is hooked up to the clock and counts impulses. Another counter creates two immediate impulses every second, the first saves the counter value in a register, the second clears the counter. The register itself is connected to LED drivers and finally seven LED 7-segment-displays which hopefully will display the clock frequency :)

For this construction I started to care about appereance as most of this board will be visible through a possible case, so it should look a bit "cool" :)

Schematics for all of this will follow, as pictures of constructing it :) TriPhoenix out.

23.08.2004

As promised there's a bunch of updated Schematics :)

20.08.2004

Although not at home right now I finished the I/O address part and the decoder in eagle, schematics will follow. Also I reordered the ALU schematics to make it a bit more readable. Finally I started some conventions about signal naming (it seem slike I did it another way on EVERY schematic...), they'll be somewhere on the page soon, too.

Another thing I did today to find some replacements. I always used 74LS254 for drivers because of their nicer pin assignment (i.e. all pins of a byte in a row), but their transceivers and therefore able to drive in both directions. This is not what they should do (in fact I always pulled the direction pin to high) and gives a false impression. I found a replacement for them, the 74LS541. Almost identical in pin assignment (the direction pin is replaced by another enable pin) they're a great replacement. I changed the schematics, too. Also you will notice that the A/B/flags register on the ALU interface are now 74LS377 which are D-flipflops with an enable pin. This seems to me like a much cleaner design as the clock alone won't make the flipflop store the value which probably could be unstable at that point.

Timing was another topic I spent some thoughts today, as the microcode sequencer still has to be developed. My current design plan looks like this: the microcode sequencer should work on the falling edge of the clock which should allow signals to settle down while all other logic should react on a rising edge. Getting the correct timing will be horrible :)

19.08.2004

Most of the PC/MAR-registers and interface to I/O address is done in the computer, I'll have to add some counting tomorrow (for the PC) and check it (as I still have to check the new register design) but it looks good :) After that I'll have to digitalize the decoder (strainghtforward) and finally design the control unit which will probably be the most complicated part as there's little symmetrie in it if any (unlike the ALU for example). Stay tuned :)

18.08.2004

Instruction encoding is now in the wiki, enjoy :) I tried to keep it as simple as possible, resulting in some holes but that shouldn't be a problem as the vast majority of opcodes is still available (starting with 11). Besides that I tried to arrange the fields so that decoding wouldn't require much complicated logic. As you may notice the register field contains 6 bits, making register up to no. 63 available. That's right I doubled the registers :) Reason for this was some thinking and talking about addressing which will be done with 3 registers per address and space (24 bit address space). I decided to double the register count thus creating space for some more pointers in a register window. The SRAM had enough space for another 4k registers and it was a minor modification to the register board which will be redone anyway. Speaking of that I redesigned it, leaving all the LEDs out of the schematics as they aren't really a part of the design. I still have to logic check the new layout as it contains some logic to prevent overwriting of register g0 which will be loaded with zero on reset and then contain a zero that cannot be overwritten. Besides that I now use a multiplexer insteam of a driver and pulldown resistors after the addition stage because I had some trouble with pulldown resistors on the TIL test board and want to avoid being hit by this again :) Anyway a multiplexer seems a much more clean design to me. That's it for today I think :)

14.08.2004

I'm back, baby. Exams passed and continuing :) I finished the X bus, finally. Buses are somewhat nasty, it starts off quite nice, you build small loops in the magnet wire, sold the loop to the pin and so on. But the wires on the bus are adding up and since it should look nice, I packed them one on another. This builds up to quite some height difference when soldering the 8th bit, which makes 16 wires on the same path. Anyway finished this one and already thinking about not stacking up the A and B bus :) Heres a picture, notice the X bus on the bottom:

06.08.2004

Nothing fancy for today, only soldered the remaining connectors on the core board and did some more of the X bus. Buses really are painful, gotta avoid them in the future ;)

05.08.2004

Some work done today :) Recently I found the reason for my problems with magnet wire, temperature. My old soldering iron doesn't seem to get to full heat and is not able to melt the magnet wire's coating. So I got a new one which can go up to 450°C. 320 are enough anyway for melting the coating :) Although I have to get used to the bigger tip and the much more heated grip (really warm ;) I made a success today. Soldering with magnet wire is now almost as easy as soldering normal wires. So I finished all internal connections on the ALU core, as you can see:

If you look closely you'll notice something in the lower left corner. This in fact is the connector for the X bus to the ALU interface board. I had a little accident down there, don't look too close ;) Anyway I already connected X0 as a sort of proof of concept. After experimenting how to connect the A/B/X-buses on this board I came up with daisy-chaining (A-->B, B-->C, C-->D...). In fact the whole chain is made of one wire which is soldered every "station". Seems to work quite nice and is the easiest thing to do because soldering two distinct wires is a pain in the ass ;) Anyway that's it for today, currently thinking about the unpack-and-init-chircuit for the microcode :)

04.08.2004

Not much for today. Just adding some thought which actually come from a friend called BoTas (at least in the web ;). I talked to him about the microcode timing problem and he suggested downloading the EEPROMs into nic fast SRAMs with 15ns and run from there. Actuelly this idea is great because I can pack the microcode in the expensive EEPROMs and only have to program one big EEPROM. This will require some additional logic but is a nice solution to the problem. Besides that why not thank at this place for some motivational support I received from BoTas as well as some spare parts he had lying around which will get a place in TriPU. That's it for today :)

03.08.2004

Some various stuff today. Although I shouldn't be doing this and learn for my exam, I did some work. I though a lot about the microcode section of the control unit which is the last big part to design for the core. For testing I will need to use rewriteable ROMs, probably EEPROMs. Unfortunaly these have a very high latency, like 150ns. This would be the slowest part of TriPU and really influence the maximum clock rate because the control unit is kinda necessary for every step. I hope I can replace the EEPROMs for some kind of PROM with much lower latency once the microcode has been determined stable.

I also spent some thoughts about the reister. It's somewhat ugly to have registers with 70ns latency when the whole main memory has 70ns latency. So I looked for alternatives and found a SRAM with 15ns latency, and it's even pin compatible with my old SRAM, wohoo. So I stormed to the next supplier and got me one of these. Unpacking it I noticed that although it has 28 pins, it isn't as broad as 28-pin-chips use to be. So pin compatible, but not socket compatible. I wanted to rebuild the register board anyway...

Finally I thought about debugging. Since I cannot afford a logic analyzer I thought up an alternative. I spotted some TIL311 (the LED display with hex decoder) on Ebay and hopefully will get them. Then I can build some of them on every important position (register window, ALU input/output, microcode counter etc.), on sockets so I can remove them anytime I want. I never tested the five ones I bought from Ebay before so I thought why not spend soem hours building a little testbed for TIL311s (they're old after all). After some very stupid mistakes I finally got everything working (pulldown with 4.7k resistors doesn't really work as 4.7k pullup does :), so here's a little picture:

01.08.2004

Apparently I'm back :) I did some reconverting of the wiki, it's now a MediaWiki, the system also used by WikiPedia. During my holidays I did a lot of planning, not much soldering though. I designed the instruction set as well as parts of the control unit, info will probably soon be available online (atm exams and never enough time to learn ;)

13.07.2004

Another update, probably the last one for about a week as I'm going away for that long. Anyway, continued soldering, grounding is complete. Also I started the "internal" buses between each calculation unit and its driver. Addition and logical and are internally connected. The board still looks very clean as the pictures indicate. I also somewhat improved my technique for soldering magnet wire but still some are going very easy and some take me some time. Gotta work on that :-)

11.07.2004 later on

I couldn't resist starting some soldering. The new magnet wire proved much more clean and much more beasty than the wire before. It took me quite a while to get it on the board, the solder just won't stick on the magnet wire. Anyway While connecting the VCC lines I'm starting to get used to this wire so probably more wires next time. Another decision was to melt the ALU down from three boards to two. I'm putting all the "core" parts on one board now, i.e. everything that "calculates" (all the gates/adders plus bus drivers). I'm using transceivers with hard-wired direction pin on this board to avoid the nasty pinout on the 74241s, otherwise they would have been as good. So, the core is started and the top looks clean as usual: But the back comes out more cleanly even in this early phase: As stated before, if I get used to this new wiring I'll re-do the register board to avoid the clutter of wires and my problem with the sockets (__never__ do back-to-back sockets, most ICs are somewhat longer than the socket, just long enough that it won't fit anymore ;-)). Enough for today. Cheers.

11.07.2004

More progress :-) In order to build a debug board I was looking for a solution to display hex values on a 7 segment display. Although not produced anymore I got hold to some of these little things:

I got 5 of them on ebay, hopefully they'll work. On another front I finished the VHDL simulation for the register board and it seems to work correct. Exact timing simulation was worth the work because I found a minor glitch in the overflow detection when counting down. But first some simulation images showing read and write to the registers, counting up as well:

At the moment I'm using Symphony EDA's free edition, which seems to be running quite nice under LInux but switches to a painfully slow simulation mode, because it's the free edition ;-) Anyway, here's the glitch:

As you can see, the lower part of the register window count counts before the second one. This is due to signal propagation, the second cout down signal is low some time __after__ the first one, resulting in some time between the digits counting down. I hope this won't be a problem as the overflow signal is low for only a short time. If I check the overflow synchronous to some clock, this should be avoidable.

08.07.2004

Small update. To make this page accessible for more people (if anyone reads it ;-) ) I will continue everything in English. The old content will be translated as well. I probably found a new technique for creating the boards. Instead of the old insulated wire I'll start using magnet wire (I hope thats the right word :-) A copper wire with a very thin insulation, german word Kupferlackdraht), which probably allows me to create the boards much faster (no removing of insulation anymore) and more clearly. The register board will probably be redone which also solves my problem with the back-to-back IC sockets.

05.07.2004

Much done today :) Yesterday a package from Reichelt arrived, containing many nice ALU parts, which are hopefully forming the ALU soon ;) BEsides that I finally got to put the ALU schematics in eagle, it's available in schematics with a quite big image. This is necessary, the board will probably contain over 30 ICs.

02.07.2004

VHDL simulation is running. Except for the memory the register board is simulatable. The design seems to be fine :) I also sent out another order for electronic parts to build the ALU board, digital schematics follow soon :)