Anyone interested in an Altera DE1 to 68000 socket adapter?

[Shadowfire]

It was measured after the ferrite bead, before being fed into Fat Agnus.

Anyways, the holiday weekend left me with a decent amount of time to work on the VHDL aspects of it. The fitter and assembler are throwing no errors, the design is constrained, and it is assembling correctly per timing constraints.

Likewise, I have the testbench up and running in Modelsim, and almost everything seems to be running as expected. I've had to make some changes per the design advisor for dealing with clock domain crossing (never done synchronous design with clock domain crossing before), and that has broken a few things, but the next time I get a chunk of time I expect those problems to fall, too. Quartus/Timequest reports fmax of the 68000 interface to be 29.95mhz on the slow timing model (which is constrained with all setup & hold times), so running at x4 (28mhz) might be fine. It currently reports a fmax of 251mhz on the Wishbone bus, but at the moment it is only running a simple internal SRAM slave on a point-to-point interface. Too early to tell what the final clock speeds will be like after everything else is implemented.

[aperez]

I'm interested in a board-set; I own an Altera DE2. Have you nailed down final pricing yet? Have you considered a final run in China? I have an associate who could likely have them made in SE asia. PM me if interested.

[Shadowfire]

I'm still shaking out all the problems. Had an issue with the zener diodes I was using, and the fact that "5V0" on the DE1 schematic diagram doesn't actually mean 5V (it means closer to 4.6V because of schottkey diodes and the current flowing thru them), and now adding an external PLL to the circuit. I gotta go the external PLL route to make the board work with 0 wait states on any 68000 based system - using the CDAC signal limits it to Amiga systems. So, gonna need to spin a new VBOARD (with new voltage supply, PLL, and external clock hookups) after I have everything settled.

Looks like I'll be using two of the 12 "spare" I/O lines (read as: down to 10 spares) to drive the multiplier selection inputs of a Cirrus Logic CS2300-02 PLL, sampling the clock signal from the CLK pin of the 68000 (after it runs through the bus switch), feeding it through the CS2300-02, and running a mini-coaxial cable from the CS2300-02 to the EXT_CLOCK input on the DE1. The CS2300-02 supports x1, x2, x4, and x8 clock multiplication, and should track the CLK signal reliably, so should allow usage of the board in all standard 68000 clock signal speeds. The "68000 slave socket to Wishbone" VHDL is nearing completion, but will be a bit later now since I need to order more parts (PLL & associated hardware) and tack the PLL onto the current board.

Aperez, I will contact you with details once I have everything settled.

[Shadowfire]

Uploaded with ImageShack.us

Here's a run with ModelSim, (emulating the PLL module I need to install) showing 0 wait states. The primary clock is @ 6.94Mhz, 68000 state machine is clocked @ 27.7Mhz, and the Wishbone bus is clocked @ 50.0Mhz. With a single cycle response from the SRAM module on the wishbone bus, the 68000 cycles terminate with 0 wait states, and all timings seem to be OK. This shows a word (16-bit) read, followed by a byte (8-bit) write and then another 16-bit read from internal SRAM (coming off the heels of a power on reset).

[alexh]

Nice Modelsim shot... you work for an ASIC company?

[Shadowfire]

No, it's Modelsim-Altera starter edition (free edition). I never used Modelsim before, up until about 4 weeks ago. I'm also running Quartus2 9.1 web (free edition) for the fitter & timing analyzer. To tell you the truth, the whole FPGA/ASIC thing is new to me, I've been hitting books to learn this stuff, I'm primarily a software kind of guy.

[Shadowfire]

68000 bus accesses are now done, all lines are tristating / open-collector outputs as needed for the interface to the socket, and all timing seems to be in order there (at least, according to ModelSim.)

The Vboard voltage regulator issues should be all set, I did a bit of poking around with SPICE, and the VCC for the quickswitches should be set between 4.25V & 4.35V for all expected values of the Altera board's 5V0 output (5V0 determined to possibly range from 4.30V - 4.95V based on the 7805A and schottkey diode on the development kit, with my board showing 4.625V on 5V0, and a resulting 4.295V on the Quickswitch VCC rail). No additional external power supply will be needed.

Next up, is ensuring that the Wishbone state machine output conforms to the Wishbone spec, and getting the PLL ordered and attached to the VBoard.

[Hewitson]

Resonator??

Were you not able to get a crystal of a suitable frequency?

[Shadowfire]

Hewitson,

The external PLL is needed to get a 4x clock *synchronized to the 68000 bus clock* inside the FPGA. All system accesses to motherboard resources operate on 68000 bus cycles, using the 68000 bus clock, and I need to respect those timings. An external resonator would not be synchronized to anything.

I am using the existing 50mhz crystal on the dev board to clock the Wishbone bus. The Wishbone bus is completely asynchronous to the 68000 bus, so I can run it at any clock I can get with the internal PLL and fitter timings.

[Shadowfire]

Just a little status update. My oscilloscope decided to go on the fritz, and (amazingly enough) was fixed with a firmware update. My original plan was to tack on the PLL to the Vboard - this was a no-go, since the 3 foot SMA cable (1) attenuated the signal, a lot, and (2) had SEVERE reflections of the 3rd harmonic of the 28MHZ clock signal, to the point of being entirely unusable. This seems to be because either the PLL is creating a triangle wave (or possibly, the slew rate is faster than my scope can track).

In any event, I decided to tack the PLL onto the Iboard instead and use a 6 inch cable to the DE1. I had some time due to labor day weekend to work on it.


As you can see, the PLL signal is actually usable now, with no measurable (by my scope, anyways) harmonic distortion. Here's how the hacked together PLL setup looks:

[Shadowfire]

VERSION 0.1 - Altera DE1 to 68000 bus interface board. Schematic files and VHDL are in The Zone.
-------
I-board: plugs into DE1, converts expansion signals into signal/ground/signal/ground... for routing through 40 conductor ribbon cables. The current setup is designed around 3 foot ribbon cables. It also houses a PLL for multiplication of the 68000's clock, since the internal PLL's don't run with inputs <10Mhz. Use a six inch 50-ohm SMA cable to feed the PLL's output into the EXT_CLOCK input on the DE1.

V-board: plugs into the 68000 socket under test. Performs 5V <-> 3.3V conversion via IDT Quickswitch IC's and an onboard voltage regulator. I have spec'ed out Samtec round headers for the plug, beware that these will spread out most 68000 sockets pins and you may need to replace them if you wish to use a thin-legged IC in the socket again.

VHDL: Quartus2 archive, used Q2 v9.1sp1 to compile. Contains the VHDL for the FPGA. It currently implements the 68000 signals as a slave to the system. The FPGA has a 68K state machine to monitor the 68000's bus for address accesses to $200000 - $27FFFF and routes those requests over to the wishbone bus state machine. The wishbone state machine performs the Wishbone Master read or write request, and feeds any response back to the 68K state machine, which completes the bus cycle. There is also a test bench for use with Modelsim Altera, Starter edition, which shows the read/write cycles. Currently, the Wishbone bus is clocked at 50Mhz from the external DE1 crystal, but the entire system is designed to allow the Wishbone bus to run completely asynchronous to the 68000's bus. There is only one slave device on the Wishbone bus, an internal SRAM module, 32-bits wide x 2 addresses (8 bytes) with 8-bit granularity. Be advised that cycle delay (via XRDY*) is NOT supported in this release, you will need to add this functionality if your wishbone devices are "slow" to respond.

I was pleasantly surprised that the thing actually worked the *first time* I hooked it up live to hardware! I used a machine language monitor to verify that the SRAM shows up in the Amiga's memory space and that individual bytes can be written/read.

This pretty much concludes the public portion of my project. The hardware is very flexible and should be able to plug into any 68000 system with a socketed DIP processor. I could not find any significant ringing on any signal lines, and over/undershoot on the 28mhz clock appears to be < 200 mV. You should be able to hang any Wishbone devices you want on the internal bus, provided they can deal with 8 or 16 bit transfers.

I plan on making a 68000 "master" (i.e. processor-style instead of slave-style) interface but there is no time frame on when that will be completed.

[billt]

I'm interested in one. Will pinouts be available for the middle connector? I may want to try making an 86pin A2000 CPU slot/A500 sideslot as well, and a 68K IC socket to complement your 68K plug. (wouldn't it be interesting to plug an old accelerator into your Minimig?!)

Originally Posted by Shadowfire

I'm getting ready to spin a pair of custom board to allow the Altera DE1 dev board to plug into a 68000 socket (as present on the A500/A2000).

[Shadowfire]

All of the schematics & vhdl have been posted to the Zone. See http://eab.abime.net/faq.php?faq=vb_...ezone_faq_item for zone access.

[Shadowfire]

Another holiday, and some more time to work on the project. Worked on the SRAM controller a bit, and made a simple test bench.


Of course, at this time only writes are confirmed working, but I couldn't help installing the module into the bus bridge and seeing how things are working out on the wishbone bus.


Still a lot of debug to do, but the framework seems to be OK.
OTOH, I've been doing a bit of reading up on asynchronous circuits and it seems that it will require quite a bit of manual fitting to get glitch-free input when the number of inputs to a function exceed the four inputs to a LUT.

[majsta]

I cant find your files on The zone ? Also why did you use Amplifiers(LT6200CS8) on first board, is that necessary? Also why did you use quickswich instead of level shifters ?

[Shadowfire]

Files have rolled off the zone, I will reupload them.

Quickswitches perform voltage level shifting (1 way, yes, but 5V CMOS has no problems with 3.3V I/O levels), have next to no propagation delay, and don't need extra I/O lines to tell them which direction (input/output) to drive the signals or tristate.

The opamp is part of the +4.3V reference voltage generation needed for the quickswitches. Due to the wide variance on the "+5V" from the DE1 PCB (theoretically, it can range from 4.45V to 5.25V - in reality, when powered by an external brick, mine puts out 4.65V) just using a regular diode to drop .7V as shown in the quickswitch datasheets would result in ~3.9V, clipping voltages to ~2.9V, and the associated reduction in noise margins on the signals. I used a zener diode with an opamp follower to power the quickswitches. This is needed to prevent the 5V I/O from destroying the FPGA.

I've not had time to work on it recently, since WoW has been destroying my life.

[majsta]

Yes i understand now.

Could someone re-upload the files to the zone, please?

[billt]

Can I buy one of these things, or are they Fab It Yourself things from the files?

[majsta]

No there is no way that this design can work. For example we have 16 bidirectional data bus signals and there is no info about MC68000 can accept 3.3v signals on data bus. Also if we look at the charts CMOS Vih is about 2.5V and Vih of LVTTL is about 2V also Vol and Voh. There is no way that this can work on this way. After research for about 20 days and 100 of manuals I can say that this can't work on this way. Here we have voltage translation just in one direction from 5V device to 3.3V device, translation to lower direction and there is no translation in upper direction. This is not problem for other signals who are unidirectional but for 16 pins of data bus this is big problem. Yes this could be made with quickswich devices but not in this way. Also using quickswich to make them real automaticly 5v to 3.3v translation and vice versa is no way to go because we will have devices who will consume additional 2.5mA for each signal, and then we will end up with 40mA for 16 pins. Also there are timing problems here where 3.3V device sends signal over quickswich to 5V device. No No No this design can't work... It is verry hard to interface 5V data bus to 3.3V.