Oops, 68040 pin error

Thanks to Michal V, who pointed out that line D29 should be E16, and not F16. Now I have to see what I assigned to F16 since that's the address pin A9. I've had the parts for this sitting on my desk for over 6 months, and I haven't done much because of other semiconductor work, which took a lot longer than expected. 14nm takes up your work days, and your evenings. I hope to get a chance to get back to this project soon. Thanks again Michal V!

Google, things are around forever, right?

When I started on this project, two things happened:
1) I knew it'd take longer than I expect, but it's been way to long.
2) I figured that since #1 is true, I'd put everything into google code because it'd be around forever.

#2 turned out to not be true: as Google Code is shutting down.
This this reason, I wrote my own exporter/importer and I have moved my work locally to my servers. If anyone wants to take a look at what I'm doing, let me know and I'll attached a snapshot.

Parts ordered!

The board components have all been ordered!
Now to just wait and find time to get things together.

Now to make packages.

I have a whole bunch of packages to make: TSSOP-48, TSSOP-8, TSSOP-16 and then all of the odd ones for the power supply. I hate the fact that I will not be up clocking the device, but I just cannot find good ICs for it. I might revisit this after I get the board laid out.

dead bug/live bug

I was not careful when looking at the 68040 documentation and the pinout is from the bottom. I need to update my sockets accordingly. I flipped things but I need to get things on grid. Initial changes as revision 44.

Working toward the layout.

This project has enjoyed undocumented bursts of work over the past few months. I have 15 minute bursts between DRC/LVS on my circuits. I'm trying to assemble my final part list so I can get an order in and make sure my footprints work. Revision 43 is in SVN.

How the NeXT Nitro Board worked.

I have designed what is basically a Nitro board for a NeXT; however, I am unable to get any of the parts that I would need to produce it.

From a schematic perspective, the important line is the TA line, which is the transfer acknowledge. The PCLK and the BCLK of the 68040 from the system does not affect the bus transfer, because the TA line is the slave acknowledge.

Consider a 68040 that is operating at 40MHz that is generated from the system PCLK. You attach a 40MHz cache between the MCU and the slower bus. You can use the cache as flow control for write-thru transfers where you complete the cache write and then mask the /TA line from the CPU with logic; however, you end up having to stall the MCU via the TA line until the read completes at the PCLK rate due to the slave ICs.

If I could get either TAG ICs or a 5v FPGA, the implementation would be fairly straight forward. I just cannot seem to get 5v parts anymore.

I wish I knew what the controller was doing

I designed a memory cache for the NeXT 68040; however, I really don't know if it will be useful because I do not know how the NeXT handles the bus. I have no way of knowing how many transfers are burst or synchronous, and how the controller is handling the TBI, TCI pins. (these are tied together) For these reasons, I'm going to shelve my cache for now and focus on getting the 68060 working.

SRAM cache looks like a possibility.

I am still looking at the system issues, but it looks like it is possible to get an external cache on the NeXT in the same way that the Nitro did. There are a few things that I am still looking into, such as if I can do some bus overclocking (relative to the NeXT bus). I found a document called the "MC68040 Designer's Handbook" that has an example cache scheme. Mine is a little different; however, it's good to know that my notes aligned with what Motorola did.

Handbook is in as of SVN rev 37.

exploding scope...

As most projects do, they explode in scope once you start thinking more about them. Once I decided that I could have a unified 040/060 socket, I then realized that I could add a cache. The issue is keeping the cost down; however, having 4 megs of cache on a system with 16-megs of memory would be a significant speedup. I will need to look at the cache flushing policies for NeXTStep.

unified socket.

I've been working so that I can reuse the 68060 board with 68040s. It will require soldering some resistors, but I believe that I can get it to work. I need to make the 68040 not be multiplexed because I want to keep the level shifters that will just shift 5V to 5V.

The two issues that I need to resolve is how to handle BCLK and /CDIS. I need to keep /CDIS high during reset so that it does not multiplex the bus. I will just use external logic to multiplex. I guess that I can just have a BCLK line waving around and making noise, but I would rather not. After I handle /CDIS, I will finish the clock circuit.

unified footprint for 040/060

I happen to have 40MHz 68040. I realized that with a few changes to the clock circuit, and adding a bypass, I can make my adapter also take a 68040 with the PCLK line at a higher speed. I will be modifying the schematics to reflect this change. It basically costs nothing as far as space.

I broke KiCad, and it won't compile

I didn't actually break KiCad, but my old Mac died that had it. The PC that I was using that had it just also died. All of this happened in time for my new mac to arrive, Japanese keyboard and all. （マクの日本語の入力がすごく好き）

I've been trying to get KiCad to compile, to no avail. I will have to put this off until I'm in a place where I get better 20k/sec in a few weeks. I have a windows xp disk around here somewhere, so I might just put it in vitualbox if I can find the install media.

Sockets started!

I've started on the foot prints for the ICs. You really don't realize how many pins 179 is until you go and actually make a socket.

Getting the board into the socket... somehow.

I knew that finding someway to get a 179-pin board to board adapter was going to be difficult, but it seems to be impossible. I expect that if this works, there will be a total of 10 of these ever produced as a maximum, so I cannot really pay for tooling. I did find a bunch of little pins:
mill-max: 3117-2-00-21-00-00-08-0
I am not thrilled with the prospect of soldering 179 of them, aligned correctly, to the bottom of each board; however, that is what probably will happen.

The schematics are functionally complete.

It's nice when a project gets to point where there's a transition. The schematics for the NeXTretro are in SVN as of revision 27.(https://code.google.com/p/nextretro/)

There have been significant changes to the schematics; therefore, my previous posts regarding wiring are pretty much incorrect. The 68060 and 68040 have some pins with different behavior. The key pin is the /BG line, which is Bus Grant. That line determines which pins are which direction, and which ones are tri-stated.

/BR	/BG	/BB	notes
A	N	x	bidirectional lines inputs, so /TS /BB can be sampled
x	A	x	bidirectional lines outputs

This is the first system that I have every had to retrofit, and there are a few curiosities on the NeXT slab. First of all, the interrupt lines are all disabled on the 68040, and the snooping is disabled. The NeXT support ICs must do some sort of DMA through bus arbitration. I have tried to support all scenarios in the schematics, and I feel pretty good about them. A difference between the 68040 and the 68060 are the R/W line and the /TA line, as they are bidirectional on the 68040, and I use the R/W as if it was an 040.

The list of things to do now are as follows:

• Get a NeXT slab. First of all, the interrupt lines are all disabled on the 68040, and the snooping is disabled. The NeXT to get physical measurements for layout.
• Look at the software and see how many times the PTEST instruction shows up, and if I can modify the code to address it. I might have to disassemble and remake a ROM
• The schematics have a complete power block, but I need to revisit it for parts availability.
• The clock circuit is currently tied to the 25MHz bus; however, I have a circuit in my notes to make a clock multiplier so that I can get a 60MHz 060 on a 25Mhz bus.

All sorted out and ready to revisit the NeXTretro schematic!

The figure from the 68060 manual has a few typos, which I have corrected.

The signal updates are justified by:
TTx: 68060 Section 2.3.1, three state signals
/TA: 68060 Section 2.5.1, /TA is an input; whereas on the 68040 (sec 5.4.3) , it is tri-state, bidirectional signal

Excluding the clock, and power, here's what has to happen to make the 68060 act like a 68040.
1) /SNOOP held high, to mimic the SCx wiring on the 040.
2) /CLA is held high.
3) /BTT is held high so that the 060 acts as an 040.
4) /IPLx is held high so that there are no interrupts.
5) /AVEC is held high and disabled.
6) /TRA is GND and asserted for 040-style bus termination.

Excluding the address and data lines, the total are as follows:
input: 13
output: 9
bi-directional: 4

The 040 on the NeXT does not use the /TIP signal, but I will use that for my bus mux logic with the /TA signal. I will have a pull-up to /BB and use /BB and /BG to drive my outputs (060 section 2.7.2)

It looks like I am ready to revisit the schematics.

Tracking down typos.

My "interface" illustration:

And, I need to check TT0 and TA between the 040 and 060. TIP will be used for my select logic to set direction. All-in-all, outside of my "flow of conscience" posts, it's all coming together.

I have been checking all of my work for pin conditions. I have created a pin set illustration for the signals that are not floating below.

/IPLx: No interrupt requests (68040 manual table 8-3), pull-up, no other connections.
/AVEC: No auto vector (7.5.1.2) pull-up, no other connections.
/DLE: No data latch enable (5.11) pull-up high, no other connections.
SCx: No snooping (table 4.1) tied to gnd, no other connections.

/LOCK and /LOCKE are pulled high, but I think this is because of a reset state for the external ICs.

NeXT 68040 configuration

I've added the NeXT slab schematics to SVN. I've been trying to figure out why the LOCK and LOCKE lines would need pullup resistors if they bus never goes tristate. I think that it may be due to the other NeXT chipsets. I currently have a huge slew of glue logic that I am trying to minimize.

The pullup lines from the NeXT are in the following illustration.

The SIZ lines and R/W does not have pullups, so the only thing that makes sense is that the NeXT proprietary chipset does cause the 68040 to tristate the lines. I will have to look into this, because SC1,0 are both to GND.