100MHz TTL 6502: Here we go!

[Drass]

ttlworks wrote:

I vote for the alternative mix, and for having 2.5V and 3.3V polygons on one PCB layer if possible.

Yes, agreed. If feasible this may be the preferred approach.

Quote:

Drass, it would be helpful if you could post a more detailed block diagram of the CPU.

Yes, agreed. I’ll try to do that. Some good suggestions on process Dieter. Thank you.

[Drass]

joanlluch wrote:

I am curious about what are you using for your instruction decoder. It looks to me that the typical ROMs are totally out of specs for your speed requirements, so what are you using instead?

Yes, ROM is out of the question. It’s a choice between using GALs or Decode RAM. The time-critical bit is to figure out the Addressing Mode of the opcode so we can know which registers are to be loaded into the next pipeline stage. I am using a 32-bit wide RAM for microcode and quickly running out of control bits. A second microcode RAM would tilt the decision since I will have lots of spare control bits there. I might as well use them for decoding the opcode. An advantage of using RAM is that it will then be much easier to accommodate alternate instruction-sets (more on that later).

Quote:

(It would also be great if at some time you eventually post a CPU diagram showing the modules you listed for your critical path calculations)

Yes, agreed ... it’s on my To Do list.

Quote:

I'm intrigued about self modifying code in relation to your cpu implementation, because I suppose that it is only problematic if it happens to an instruction that is already in the pipeline, which should be relatively rare in real life code. So maybe it can generally be ignored (?). How this subject fits in your pipelined processor?, are you supporting this in some way?

Remember that this is a microinstruction pipeline so the issue does not arise. Self-modifying code is a real nuisance in an instruction pipeline, where the pipeline has to be flushed if self-modifying code is detected. For a more detailed description of a 6502 instruction pipeline, see this thread.. That design is a closer analogue to a traditional RISC pipeline, and self-modifying code was a problem (not only in the Dormann suite but also with FORTH and BASIC. I chose to add NOPs into the instruction stream manually rather than instrument the pipeline to detect self-modifying code).

Edit: Here is a relevant post on the thread that you might find interesting. It specifically discusses Self-Modifying Code (SMC).

[Drass]

Bil Herd wrote:

Simply put, traces that align directly with the row of the glass fibers will have a different impedance than the trace that experiences alternating bundles of fibers.

I chose 7628 FR4 because I understand it is better suited to impedance controlled PCBs for exactly this reason. (As with everything else, though, it’s just something I read so I may be completely off-base ).

Quote:

Drass: once we have a PCB layout, maybe it would be a good idea that you nicely/politely ask Bil Herd if he could take a look at it...

Great idea ... he might find a 100MHz TTL 6502 sufficiently “are-you-out-of-your-mind” crazy to be interesting!

[GARTHWILSON]

Drass wrote:

One question: is it practical to use solder paste and stencils when there are components on both the top and bottom layers? How do you keep the bottom components from falling off or shifting when heating the boards?

I'll add to what Arlet said. Besides the matter of surface tension keeping already-soldered parts from falling off the bottom, if you're going to solder it by hand, you probably won't be getting the other side quite hot enough to melt. Before doing our first design with parts of both sides a couple of years ago (where it wasn't just a few parts that could be added by hand on the bottom later), I asked one of our suppliers about it. I believe what they used to do in the early years was to put a tiny drop of epoxy under the part to keep it from falling off when turned upside down and the solder was re-melted when doing the second side; but they said what they do now is to use a different solder that melts at a different temperature; then the first side is done with the higher-temperature solder, so when it's turned over to do the second side, the solder used on the first side doesn't quite melt.

Quote:

Quote:

When you can't put vias under pads, they take more board space. If you're going to solder this by hand, there may be no problem with putting vias in the pads.

Yes, thanks for mentioning it. It may come very handy in this project. (I think Arlet may have made the same suggestion for the C74-6502 but I was too much of a noob to venture it).

Pololu and DirtyPCBs and probably many other companies as well offer a solderpaste-stencil-making service. I haven't tried them, but the other engineer who used to work at our company did, and was rather pleased. He only did a very small but dense board, for a switching regulator with the controller IC in a tiny MAX-10 package. You'll have to decide if it's worth it though, because I believe solderpaste is quite expensive and its shelf life is very short. If you only do one or two pieces, it might be worth it to do by hand, not just for this reason but because it also lets you put vias in the pads. I cannot speak from experience on the stencils. I put vias in the pads in the 4Mx8 10ns 5V SRAM memory modules I supply, since I knew I wasn't going to have enough sales volume to pay the set-up cost for automated assembly.

If price is no object, they can make vias down to .002" now, with a laser. I have no idea how they can get that plated through when the board thickness is thirty times the hole diameter! You still need a pad around the via though, at least on the layers that connect to it. The pads on non-connecting layers can be eliminated, possibly saving some space.

As for the 50Ω transmission lines, the precise characteristic impedance won't really matter if the load is not even remotely matched to the line. To match it, you would have to have terminations, and they take board space too, enlarging the board, making the lines longer. I don't know at what point it's worth it, or if your ICs can even drive such a heavy load. You probably might as well keep the traces down to whatever minimum width the board manufacturer can make without charging more than you want to pay (I've seen down to .002", and that was almost 30 years ago!), and then take advantage of the fact that that will let you make a smaller board with shorter connections. I think about these things but again have not had an occasion (so far) to go to this extent.

Dr. Howard Johnson goes into this stuff and a lot more in his book "High Speed Digital Design: A Handbook of Black Magic." Most of the information is available in his archived articles. These articles appeared as a column in one of the industry magazines and I cut them out and kept them in those years when they were being published. The book goes into more of the math though.

This is some rather extreme stuff, but a 100MHz TTL 6502 is definitely getting there.

[Arlet]

GARTHWILSON wrote:

If price is no object, they can make vias down to .002" now, with a laser. I have no idea how they can get that plated through when the board thickness is thirty times the hole diameter!

Microvias are typically depth limited. They can only go from outside layer to first inner layer, and that layer needs to be very thin. I've used them once time for a project (for small BGA with 0.4 mm pitch)

I suppose they could also go from inner to inner, if these are opposite sides of same physical board layer.

[Drass]

Arlet wrote:

Maybe insert a small diode between the 3.3V net and 2.5V pin ?

Thanks for this idea Arlet. (I had to ask Dr Jefyll to help me understand it but I get it now). There seem to be several good options for dealing with the dual-supply so I think I’ll stop worrying about it for now. Thanks!

[Drass]

GARTHWILSON wrote:

As for the 50Ω transmission lines, the precise characteristic impedance won't really matter if the load is not even remotely matched to the line. To match it, you would have to have terminations, and they take board space too, enlarging the board, making the lines longer. I don't know at what point it's worth it, or if your ICs can even drive such a heavy load. You probably might as well keep the traces down to whatever minimum width the board manufacturer can make without charging more than you want to pay (I've seen down to .002", and that was almost 30 years ago!), and then take advantage of the fact that that will let you make a smaller board with shorter connections.

Thanks for this good advice Garth. In fact, I don’t yet know whether or where we might see transmission lines in the layout. With luck I can keep the number of signal traces that require termination down to a minimum and be more cavalier with the rest.

[Arlet]

If you choose to use a diode to drop the voltage, make sure you place your decoupling capacitors after the diode, near the 2.5V IC pin.

[Drass]

Rather than creating a detailed block diagram, I thought I might simply publish the Logisim file. It has the significant advantage of being already complete and accurate -- two important things that a detailed block diagram currently lacks!

For those that do not have Logisim, I have include here a png image which can be zoomed into to reveal all the CPU circuitry:

For those that do have Logisim, I am using Logisim "Evolution". When you load the C74-100 circuit file, you will be greeted by the following:

To set the CPU running the Dormann Test Suite:

1. Right click on the RAM module and select "Load Memory Image"
2. Load the file "Test_6502_RAM_Image" included in the attached zip file
3. Set the RDY and BE pins to "1"
4. Start the clock
5. Press the "RES" button.

The Dormann test suite will begin to execute. You can then navigate to the "6502" module to watch the CPU execution up close. Of course you can also type your own program into RAM, point the RESET vector in high memory to it and press the RES button.

You will find the following files the attached zip file:

• C74-100 Critical Path (V1).pdf -- a detailed listing of all signal paths through the CPU with estimated tpd
• C74-100 Decoder Values (V1).pdf -- a table showing the encoding used for both microinstruction and instruction decoding
• C74-100 V1.circ -- the Logisim file
• Test_6502_RAM_Image

Disclaimer: Please consider all this material in draft form and subject to change without notice. The main objective for this model is to test out the ideas. As such, implementation details may differ materially from what is contained herein.

As always, I would be happy to answer any questions or provide any additional explanations.

Cheers for now,
Drass

EDIT: Added link to Logisim Evolution

[joanlluch]

Hi Drass,

Drass wrote:

For those that do have Logisim, I am using Logisim "Evolution". When you load the C74-100 circuit file, you will be greeted by the following:

It looks very professionaly done and works very well.

Maybe it needs to be clarified that this is intended to run on Kevin Wash "Logisim Evolution" fork, a.k.a Logisim Holy Cross Edition; unless I am using a wrong version, it actually does not load on the mainstream reds-heig version. Just in case you were not aware of it, the Holy Cross edition also features the File Viewer component, which when properly formatted, allows you to visually display the assembly source file, with the currently fetched instruction highlighted. I really love that.

From your simulation I learned that it is a lot more effective (read faster) to just build the model out of native logisim components, than attempting to emulate 74xx ics down to logic gates as I've been doing so far. Btw, I like the D.IN, D.OUT trick to get memory out of the 6502 subcircuit.

[Drass]

joanlluch wrote:

it is a lot more effective (read faster) to just build the model out of native logisim components, than attempting to emulate 74xx ics down to logic gates as I've been doing so far.

Definitely, but you do need to keep the 7400 series ICs in mind as well. In this case I’ve marked various Logisim components with the 7400 series equivalents I intend to use. I’m also careful to reflect the correct pinouts. For example, I put inverters in front of inputs which I know are active-low on the 7400 series ICs but are active-high in Logisim. That keeps the logic straight from the start.

[joanlluch]

Drass wrote:

but you do need to keep the 7400 series ICs in mind as well. In this case I’ve marked various Logisim components with the 7400 series equivalents I intend to use. I’m also careful to reflect the correct pinouts. For example, I put inverters in front of inputs which I know are active-low on the 7400 series ICs but are active-high in Logisim. That keeps the logic straight from the start.

yes, I saw that. Since I already had many 74xx ics modelled in sub circuit boxes I just have now replaced their down-to-logical-gates implementations by native logisim components at the bottom level, and it’s definitely much faster. The the same higher level boxes still remain though. That makes the model look closer to the schematic in general, but it looses the sense of digital diagram that you get by using the native components right at the top level.

[joanlluch]

Btw, I don’t quite get how you perform the sbc function in the model. That should require the negation of one of the ALU inputs and I was curious about how that would add to the FET adder propagation delay. I’ve been looking for XOR gates at one of the ALU inputs but I can’t see them. Please can you elaborate on this?

[Drass]

joanlluch wrote:

Btw, I don’t quite get how you perform the sbc function in the model.

It’s pipelined. The operand is inverted in the prior cycle. If you look toward the bottom of the Register File you will see two paths from DB to the ALUB input bus. One has an inverter on it and the other does not. SBC loads the inverted operand into ALUB whereas ADC loads the operand as is. The ALU itself does a simple ADD in either case.

[Drass]

joanlluch wrote:

Since I already had many 74xx ics modelled in sub circuit boxes I just have now replaced their down-to-logical-gates implementations by native logisim components at the bottom level, and it’s definitely much faster.

Nice. You end up with something closer to a schematic then, which is wise. I expect you minimize transcription errors when finally making schematics. (The C74-6502 had a couple of such errors which required patching the PCBs as a result. It’s much too easy to make these mistakes when you’re dealing with thousands of connections. The whole thing might have been avoided with your approach).