Though the 68020 based MIDI020 computer is a workable design, it suffers from a few problems:

• The main one is the board is not 100% reliable. Very occasionally it will fail to start. I’ve tried to diagnose this problem but without success
• I can only run the processor at half the rated speed, 12.5MHz if the SIMM slot is used
• The expansion slots have a few problems which I could bodge around:
  • I neglected pull-ups on the /WAIT and /BERR lines – which means unless all four slots have cards inserted the signal can’t be used.
  • Also the interrupt acknowledgement line is shared across all slots, which makes it pretty much useless as glue logic would always be needed on the card to make use of it.
• I was never particularly happy with the board routing and layout; there is far too much dead space.
• Finally, the bodge wires are a minor issue, though the way the SIMM slot is limited to a 8MB stick is annoying.

I thought I might be onto the answer as to why MIDI020 will occasionally fail to start when I realised I was using a switching regulator rated for only 500mA, a SR05S05 (PDF) instead of 1A which I had assumed. I’ve seen the board draw 450mA, occasionally more, and it seemed possible the board was shutting down when the current draw exceeded what the regulator could handle. Unfortunately taking out the regulator and powering the board directly from the bench PSU outputting 5V seemed to make no difference. It also seems I can reduce the current draw by upping the input voltage: at 7V the board draws around 400 to 450mA, but at 9V only 220mA is drawn, at least according to my bench PSU. None the less, to err on the side of caution I will use a 2A regulator on the next board.

All this, but especially the limited clock speed, mean it’s time to move onwards and upwards.

The specification for a 68030 (PDF) based computer is as follows:

• A core “glue” that can master the 32 bit buses
• A 68030 with a 68882 (PDF), both running at their stated maximum speed (40 MHz for the parts I have)
• 512M x 16 flashes in the form of 2 x SST39SF040 (PDF) in PLCC32
• 2 x 72 pin SIMM slots
• A SC26C94 (PDF) QUART with the usual arrangements of four serial ports:
  • Two on RJ45
  • One for my Amiga 600 keyboard
  • And a TTL header for debug and the bring-up
• Onboard Ethernet using a RTL8019AS (PDF)
• A PS/2 port for keyboard and mouse
• The same expansion slots as MIDI020 but with a few issues corrected; existing cards like the video card should be usable without being re-spun
• I2C bus with:
  • DS13057 (PDF) RTC
  • LM75A (PDF) temperature sensor
  • PCA9544APW (PDF) four way expansion slot bus multiplexer
• IDE header
• A P7805-2000-S (PDF) 2A 5V potted switching regulator attached to a barrel jack

The I2C power meter, a INA226 (PDF) on MIDI020, has been dropped as it wasn’t particularly useful after all, and as it turned out it complicated the board routing.

The big question is: what programmable logic part should be used?

After toatling up the pin requirements I came to the conclusion that without going down the BGA (Ball Grid Array) route a 240 pin QFP part would be required. This is principally because of the 32 bit address and data buses, necessary so it can act as a bus master. Another requirement of the FPGA is it needs to support the needed logic at a fast enough speed to support the 40MHz operation of the processor. Like other ICs, and it remains current practice in the semiconductor industry, each Flex 10K was released in various “speed grades“; this is the last number after a dash in the part number, eg. EPF10K20TC144-4, which is the part used on the MIDI020 board. The speed grades range from -1 to -4, where -4 are the slowest parts.

In terms of the expected maximum frequency supported by a particular logic design, the tools (Quartus in this case) provide some indication of this in the form of the timing report. I must admit that I don’t know anywhere near as much about the various timing parameters as I should, but it seems clear that a comparison of the stated maximum frequency of a particular design implemented on a selection of different FPGAs would give a relative indication of the actual maximum usable speed of the board for a particular FPGA.

Here’s the top of the report from MIDI020’s EPF10K20:

Thus Quartus is reporting an fMax of 38.61Mhz. This should be fast enough for the 25Mhz 68020, and it’s possible the problems I’m seeing running the board are elsewhere. But other things give me reason to doubt the performance of this FPGA.

The Flex 10K is made in 240 pin QFP at various logic densities and speed grades, and it is possible without actually owning a particular part to get a timing report for any part supported by Quartus. Using the existing MIDI020 VHDL design as a rough guide:

1. EPF10K20TC144-4 (as used on MIDI020) : 38.61Mhz
2. EPF10K30RC240-3 : 46.08MHz
3. EPF10K20RC240-3 : 48.54MHz
4. EPF10K70RC240-2 : 48.54MHz

I am still not completely certain that the FPGA used on MIDI020  is causing reliability issues because it is not of a sufficient speed grade, but it is limiting what can be done with the design. Just adding trivial code to the design causes the board to fail to start.

While the EPF10K70RC240-2 looks promising it has a reported fMax of only around 10MHz more. This is disappointing considering the speed grade goes from -4 down to -2. It’s not clear that I’d be able run a board with a similar design as used on MIDI020 at 40MHz, but it seems unlikely. In addition this part is prohibitively expensive from my usual supplier, UTSource.net.

Interestingly the Flex 10K was made in a 3.3V (2.5V internally) variant, called the Flex 10KE (PDF). This seems to be a “redo” of the 5V Flex 10K in what would have been a more modern fabrication technology, a kind of stop gap between the Flex 10K and the Cyclone (PDF) FPGA family which followed it in the early 2000s. One advantageous, for this project, thing about the 10KE is they are 5V tolerant. No inline resistor is needed, which is the case on the early Cyclone parts.

Some Flex 10KE also contain PLLs. These are marked with an X after the speed grade. Confusingly, if a PLL is not present it is referred to without the X, and either with a speed grade alone or the speed grade followed by an N.

The datasheet states the IO compatibility in the following table:

In terms of output voltage things are more complicated. The datasheet states the output voltages as:

• Voh (Minimum) : 2.4V
• Vol (Maximum) : 0.45V

This is of no use for CMOS parts, such as 74HC series logic, but acceptable for TTL logic, including the 74HCT series. This is because the Vih on 74HC logic, when supplied at 5V, is close to 4V – the FPGA running at 3.3V on its IO drivers will not be able to generate a high enough voltage.

In order to determine if I could use a 3.3V Flex 10KE FPGA in a 5V computer board I had to examine the datasheet of every part on the board to see if it could deal with the lower output levels of the 3.3V Flex 10KE.

Here’s a summary of this data for the key ICs:

1. MC68030 – Vih (Minimum) : 2V, Vil (Maximum) : 0.8V
2. 72 pin SIMM – Vih (Minimum) : 2.4V, Vil (Maximum) : 0.8V
3. RTL8019AS – Vih (Minimum) : 2V, Vil (Maximum) : 0.8V

For anyone interested the full spreadsheet is in my Google drive account.

The upshot of this is it should be possible to use a Flex 10KE FPGA. One consequence is I’ll need to switch from using 74HC logic parts to 74HCT parts, for things like the expansion bus drivers.

I’m a little concerned about the decreased noise immunity inherent in 3.3V parts driving 5V parts. Hopefully everything will be ok.

The Flex 10KE parts have one key advantage, that makes the inconvenience of dealing with multi voltage levels worthwhile: they are much faster.

Here’s some more fMax values for some Flex 10KE parts:

1. EPF10K100EQC240-3 : 55.25 MHz
2. EPF10K100EQC240-2 : 76.92 MHz
3. EPF10K130EQC240-1 : 91.74 MHz

That’s more like it. The logic elements for the bottom FPGA, 4,992, are probably sufficient to implement a moderately complicated processor like a 68000. Wanting something smaller, in terms of logic, I purchased some EPF10K50EQC240-2 off of eBay, but frustratingly they are not usable by my version of Quartus (9.0sp2) despite being mentioned in the datasheet. Unfortunately I didn’t check before buying them.

I actually spent some time pulling Quartus apart to try to figure out why they were not showing in the device drop down. The part is referenced in a few different configuration files. I even tried looking for earlier versions of Quartus and managed to turn up a copy of 8.0 on archive.org but it didn’t support any EPF1050E parts either. It’s very peculiar since the InstallShield installer for 9.0sp2 even lists these parts in the component selection screen. I can only think it is a part made for a custom version of Quartus, perhaps for one specific Altera customer, and the eBay seller I bought some off just happened to have some.

In the end I bought 5 EPF10K130EQC240-1N off my favorite seller, UTSource.net.

I was anxious to check the leads on these massive QFP parts, but they look fine. Unfortunately the EPF10K50s (I have 3 altogether) can never be used.

Now onto a description of the schematic. For brevity this schematic will be described in terms of the differences with the MIDI020 schematic previously documented here.

First up is the top level page. Because I find the alternative confusing, simple global labels are used to link the sheets together. The top level contains links to the rest of the sheets, as well as the PCB mounting holes. For the first time ever, the mounting holes will be grounded.

Next, the QUART. I have switched out the SC16C654 (PDF), which I’ve been using since the MAXI09, for a SC26C94 (PDF). This is another quad channel part in a slightly smaller 52 pin PLCC package. The main reason for this change, beside being a bit bored of using the ‘654, is this part has a timer; in fact it has two of them. Whilst I can implement whatever timers I like in the FPGA, it’s nice to have some “for free”. On the downside, the FIFOs are smaller (8 vs 64 characters) but that’s fine. Note that the /IACK pin, used for outputting an interrupt vector when requested by the processor, and the /DACK pin, used to halt the processor if the QUART is taking a long time to process an operation, are both routed to the FPGA. The previous part did not have either pin.

Next, the 68030 processor and 68882 maths coprocessor. This is all very similar to the MIDI020, though the 68030 has more control lines then the 68020. Some more obscure 030 pins are not used, including the /STATUS and /REFILL lines, which are used by in circuit debuggers. Amongst the new signals, relative to the 020, are /STERM and /CIIN which are used for bulk loading of the onboard caches, something I want to play with at some point. An additional header is provided to disable the onboard MMU.

Next up are the two 512KB flashes, SST39SF040 (PDF). Nothing new here. Like the MIDI020, bring up will be assisted by the expansion card with two 512M x 8 SRAM; no SRAM are on the MAXI030 board.

Power next. A P7805-2000-S (PDF) 2A 5V potted switching regulator is used. This replaces the SR05S05 (PDF) 500mA regulators that I’ve previously used in my computers. I’m concerned that 1 A (a 1 A version of the SR05S05 is available) will not be enough current on a fully loaded board, but simultaneously I didn’t like MIDI020’s work around for this problem, which was a hard disk Molex connector. This new regulator is slightly larger then a SR05S05 but still roughly within a 7805-sytle footprint.

The EPF10K130EQC240-1N requires 2.5V and 3.3V rails, which are provided by AZ1117 (PDF) regulators, as used on the graphics card I previously built.

This sheet also contains the FPGA power connections and decoupling caps. I’ve gone a bit over the top; there are 10 on each rail.

The FPGA configuration section shows one change necessitated by the comparatively large EPF10K130E: two EPC2 (PDF) are required to hold the design for a single part. This makes use of the /CASC (cascade) output pin to link two EPC2 config flashes together. This is required because a EPC2 stores only 1,696,680 bits of configuration data, yet a EPF10K130E can require 1,838,360 bits of storage. Annoyingly, this would have been avoided if the EPF10K50E could have been used. In terms of the Quartus software, it will generate multiple .pof files, which can be programmed into each EPC2 via the JTAG chain, which consists of the two config flashes followed by the FPGA.

Next, IDE. One difference here is the inline resistors have been removed on the basis that they shouldn’t really be needed. Certainly the Amiga 1200 schematic, which I’ve used as a guide for such things, does not show them used. The 74HCT245 (PDF) buffers have been retained from MIDI020 however.

One other change is the DMA pins (‘REQ and ‘ACK) have been connected up. This should allow experimentation with DMA transfers. This requires IDE-specific read and write lines as well, since the IDE port will write as the memory reads (for example), making it four pins dedicated just to this function.

Next the SIMM section. Two slots makes this a fairly crowded schematic sheet.

The big difference to the MIDI020 SIMM arrangement is that the SIMM address inputs will be generated directly from the FPGA using a mux implemented in programmable logic, instead of it being generated by external mux ICs. The advantage in doing this is that mapping from processor address to SIMM address is set by programmable logic instead of being hard wired. The disadvantage is many more pins: 12 instead of 1 previously, which was the mux IC control signal.

The two slots are selected by the use of independently wired RAS lines. This is because, for some reason, the 72 pin SIMM wiring does not include a separate Chip Select line.

This means a total of 25 FPGA pins are dedicated over to the two SIMM slots.

Next the I2C section. There is almost nothing to see here; the arrangement is basically the same as the MIDI020 setup, except that the current sensing IC has been removed.

The “other IO” section contains only the PS/2 port. Note that the data and clock pins are 3.3V since they are attached directly to the FPGA, but VHDL code will tristate the pins when a high value is required, and they will be pulled up to 5V by resistors.

The expansion slot pinout is almost unchanged. This is deliberate because I want to use the cards I’ve already designed for MIDI020 on this board. There are some subtle differences though:

1. There is no longer a “master clock” output, since the board has only one clock, the MPU (and FPGA) clock
2. The /IACK pin is now “per slot” instead of being global, which means the FPGA can automatically assert it based on which slot’s interrupt line has been signaled, which means no on-card glue will be required to utilise this signal

The expansion buffers are almost unchanged relative to MIDI020, except for the additions of the buffering of the per-slot /IACK line generated by the FPGA and the pullups for the /WAIT and /BERR lines.

The Ethernet section is very similar to the one used on the expansion card I previously produced. There are some fixes for issues I discovered however, and the serial EEPROM has been omitted.

Lastly the FPGA IO pins themselves, possibly the most interesting section of the schematic.

The full 32 bit address and data buses are attached, 64 pins just for those. This is more then the 59 available on the EPF10K10 in PLCC84, which was used on my first computer which included a Flex 10K, MAXI09.

The FPGA is attached to all except the not particularly useful 030 control signals, as mentioned above.

Unlike MIDI020, the processor (and copro) will both be clocked by the same oscillator as the FPGA. This should be using a 40MHz oscillator can, but I may start off with something more predestination as getting many simultaneous captures on the Saleae 16 logic analyzer at high speeds is difficult.

The remainder of the connections are made up of the following, as hinted to by the schematic sheets above:

• The usual Chip Select and interrupt lines
• /DACK and /IACK for the QUART
• A positive logic RESET signal which is used by both the QUART and the  Ethernet controller
• Expansion slot control lines
• I2C bus:
  • Including the temperature alert signal which was omitted from MIDI020
• The RTL8019AS control signals
• The PS/2 lines
• The IDE interface control lines, including the ones required by the DMA functionality
• A buzzer and user controlled LED output, because every computer needs these
• A 5 pin user header, which will mostly be for the bring up but could be useful later as well

Out of the 189 IO pins available, only 12 are not used.

Next, then, the daunting job of laying out the board. This was to be my first board with proper 32 bit wide buses, and I wasn’t looking forward to it at all.

I started with trying out some different component placements. The trickiest areas of the board were obvious: the PLCC socketted flashes and 68882, along with the PGA 68030. The expansion cards were laid out the same way as in MIDI020, with the address and data buffers along the ends of the DIN 41612 connectors, and the remaining buffers and other expansion slot related ICs down the edge of the first slot.

I2C bused ICs went on the right hand edge, with the RTC and CR2032 battery holder in the bottom right corner.

I decided to put the processor and coprocessor along the bottom right corner, with the SIMM and its buffers and resistors at the bottom of the board. The FPGA would of course be in the middle of the board, with the many connections down to the SIMM being directly routed on the front of the board without any vias.

The IDE header was placed near the power jack at the top left near the socketted flashes; the thinking being that both these parts needed 16 bits of the databus.

External connectors, and the related ICs, were placed along the top left of the board, top left corner to top middle, next to the expansion slots:

1. Power jack
2. Ethernet
3. RJ11 keyboard
4. Dual RJ45 UARTs
5. PS/2 mouse and keyboard

The result was something like this, prior to any routing and any additional adjustments:

The next task was trace routing. In the end this took about two weeks, mostly in the evenings. The general approach was to route the buses first, starting with the traces down to the SIMM from the FPGA. The back of the board was used for joining up the vertical “slices” of buses, with the wide 32 bit databus snaking across from the expansion connector buffers to the IDE interface.

The layout was entirely done with the following grids:

• For component placement a 25mil grid was used
• For trace routing a 2.5mil grid was used

Push routing (video) was not used, and the result is, I think, much cleaner because of it.

Traces, as before, are 6 mil wide. A 2.5mil grid allows 6mil wide traces to be packed with 6.5mils between them, nearly the limit of JCLPCB‘s 6 mil clearance on their standard service. I had to shrink the vias slightly compared to the MIDI020 board; they are made with 9 mil holes and 18mil diameter pads.

Perhaps the trickiest area was routing the address buses into the FPGA from the processor, and then on to the PLCC flashes. This involved routing these buses behind the FPGA, which somewhat compromised the placement of the decoupling capacitors at the back of the board.

The power rails were slightly interesting. The internal Vcc layer is predominantly for the 5V power rail, but underneath the FPGA are concentric squares for 3.3V and 2.5V. A further wide trace run takes 3.3V underneath the JTAG header and config flash components.

In summary, I’m very happy with this board routing exercise. Considering I wasn’t really expecting a good result, based on MIDI020’s board layout which I was never happy with, I’m delighted. I suspect the experience gained from laying out the video card helped.

Here’s a picture of the top and bottom layers:

One other nice thing is this board is only a fraction wider then the MIDI020 board, whilst being a little shorter. The dimensions are 9.425 inches by 6.525 inches.

And of course, the 3D view:

And the back:

There remains a few tasks to do before I order the boards.

First and foremost, the board’s name is missing from the silkscreen. Since it is a bus mastering design, I’ve decided to call it MAXI030.

Then I need to once and for all sort out the RJ11 socket footprint used by the keyboard connector so I don’t have to drill out the plastic mounting holes, which I’ve had to do with the last three boards that used this footprint.

Next I need to do a paper print of the board design and dry fit a few parts. Though most of the parts have been used on the MIDI020 board, a few are new, like the HCT logic.

I also need to gather up the parts in a project box to make sure I have everything required by the board.

Lastly I want to start on the VHDL project for the FPGA design. The starting point will of course be the MIDI020 FPGA design, but verifying that Quartus is happy with the pinning used by the schematic will go a long way towards ensuring I haven’t made an error producing the schematic symbol for the EPF10K130E FPGA which, at this stage, would be a bit of a nightmare…