Using an FPGA to drive the 80386 CPU on a real motherboard

[Rick C. Hodgin]

I have a desire to create an 80386 CPU in FPGA form, one which will plug in
to the 132-pin socket of existing 80386 motherboard as a replacement CPU. I
want to be able to provide the features of the 80386 on that machine, but
through my FPGA, to then allow me to extend the ISA to include other
instructions and abilities.

Does anybody have an experience or advice in creating an FPGA-based CPU that
connects to a real hardware device and simulates the real device's abilities?

For example, the 80386 uses 5V and the Altera board I have drives 1.xV and
3.3V max, so I'd have to use a level converter. At speeds up to a max of
40 MHz, would there be any issues?

Also, I'd like to create a "monitor board," which is a board with a 132-
pin male socket connecting to the CPU on one side, and a 132-pin female
socket on the other side to which a real 80386 CPU would connect, and then
to be able to pull signals off the wires between the CPU socket and the
CPU itself. I had assumed I would use opto-isolation for this, but I don't
know if it would work or be best.

In addition, and specific to the 80386 CPU, AMD manufactured an Am386 CPU
that is 100% compatible with the Intel 80386, but it has the ability to
underclock down to even 0 MHz in a standby mode (allowing it to consume
only 0.001 Watts). I'm wondering if anyone has any experience underclocking
an 80386 motherboard down into the KHz range, or even Hz range, and if it
would still work at those slow speeds on the board?

My goals in slowing down the CPU are to detect and isolate timing protocols,
which I can then scale up to higher speeds once identified.

In any event, any help or advice is appreciated. Thank you.

Best regards,
Rick C. Hodgin

 

[Rick C. Hodgin]

On Tuesday, April 5, 2016 at 4:13:28 PM UTC-4, rickman wrote:

On 4/5/2016 3:15 PM, Rick C. Hodgin wrote:
In addition, and specific to the 80386 CPU, AMD manufactured an Am386 CPU
that is 100% compatible with the Intel 80386, but it has the ability to
underclock down to even 0 MHz in a standby mode (allowing it to consume
only 0.001 Watts). I'm wondering if anyone has any experience underclocking
an 80386 motherboard down into the KHz range, or even Hz range, and if it
would still work at those slow speeds on the board?

No experience, but the parts that would give trouble at slow clocks were
the NMOS devices that went out long before the 386. Certainly TTL and
CMOS don't normally have a problem with slow clocking.

I assume the entire system is clocked off the single source? So, would it
be as simple as removing the crystal circuit and replacing it with a soft
circuit operating at the same frequency driven from an FPGA output? And
then taking the FPGA output and bringing it down slowly to underclock the
system?

I have two standard 80386 motherboards, and one 80386 motherboard with an
expansion socket. I also have an 80486 motherboard with an i80486DX, and
two Pentium motherboards, 33 MHz and 60 MHz I believe.

Here's an online image I found which matches the 80386 I'm interested in
underlcocking:

http://www.armanax.com/placa-base-m321-rev-2-5.html

It has an 80 MHz timing circuit, as the clock speed for the 80386s were
always double-pumped.

I want to get a case, power supply, VGA and MDA setup on it. I have a
custom 80386 OS I wrote that I'll use for bootup and testing (loads
from a floppy disk). I would write a simple test algorithm that does
some screen output, processes keystrokes, mouse movement, etc., and
have that test running as it's underclocked... assuming I'm on the
right path.

Best regards,
Rick C. Hodgin

 

[Rick C. Hodgin]

On Tuesday, April 5, 2016 at 4:13:28 PM UTC-4, rickman wrote:

On 4/5/2016 3:15 PM, Rick C. Hodgin wrote:
I have a desire to create an 80386 CPU in FPGA form, one which will plug in
to the 132-pin socket of existing 80386 motherboard as a replacement CPU. I
want to be able to provide the features of the 80386 on that machine, but
through my FPGA, to then allow me to extend the ISA to include other
instructions and abilities.

Does anybody have an experience or advice in creating an FPGA-based CPU that
connects to a real hardware device and simulates the real device's abilities?

For example, the 80386 uses 5V and the Altera board I have drives 1.xV and
3.3V max, so I'd have to use a level converter. At speeds up to a max of
40 MHz, would there be any issues?

Even at 40 MHz you will need to be tidy with your routing to keep the
signals from ringing, etc.

If I can get the machine underclocked, I'd like to bring it down into the
low KHz or even Hz range if possible, but something 100 KHz or lower at
least.

I envision the Cyclone V GX being mounted a couple inches above the 80386
socket. I would use the HSMC to GPIO port to connect to the CPU socket.

I had considered at first using the co-processor socket and emulating the
80387 ISA at first. I may still do that, but regardless, there are only
90 pins that are active on the 80386, and 64 of those are direct address
and data pins, with another 20 being control pins for when those lines
are active, and in what mode they're active.

There really isn't much logic involved in hooking up an 80386, which is
why I'm attempting this project.

To be honest, I wouldn't even mind dipping back down to a 4.77 MHz 8086
system and starting there as part of the ISA I'll support for the 80386
contains a full 8086 subset.

I don't know the details of the 386 chip I/O
specs, but quickswitch type parts will do a good job of level shifting
between 3.33 and 5 volts without adding much delay. Because the signal
passes between the source and drain there is very little delay. They
don't pull up to 5 volts, but 5 volt logic usually only need 2.x volts
anyway. But you'll need to check the parts you are interfacing to on
the mother board or just give it a wing. You can add pullups on the 5
volt side, but pullups tend to be slow. Even a few ns of added delay
can cause a 386 not to work. Many of the early mobos had timing issues
because of the TTL logic used.

Excellent information, thank you.

> I don't think 386 mobos had chip sets in place of the TTL, did they?

Not originally, but later on. These motherboards were manufactured in
the early 90s, and came with Am386 CPUs manufactured in 91 or 92. I
believe the boards I have had switched to chip sets by then.

Also, I'd like to create a "monitor board," which is a board with a 132-
pin male socket connecting to the CPU on one side, and a 132-pin female
socket on the other side to which a real 80386 CPU would connect, and then
to be able to pull signals off the wires between the CPU socket and the
CPU itself. I had assumed I would use opto-isolation for this, but I don't
know if it would work or be best.

Opto-isolation is pretty slow compared to 40 MHz, but maybe there are
faster converters these days. Why do you need isolation?

I may not need it. However, when I was working on stepper motors back
in the mid-90s, I believe we used them to maintain a low power draw on
the circuits we were monitoring.

In addition, and specific to the 80386 CPU, AMD manufactured an Am386 CPU
that is 100% compatible with the Intel 80386, but it has the ability to
underclock down to even 0 MHz in a standby mode (allowing it to consume
only 0.001 Watts). I'm wondering if anyone has any experience underclocking
an 80386 motherboard down into the KHz range, or even Hz range, and if it
would still work at those slow speeds on the board?

No experience, but the parts that would give trouble at slow clocks were
the NMOS devices that went out long before the 386. Certainly TTL and
CMOS don't normally have a problem with slow clocking.

From what I've read, Intel's 80386 CPUs would not clock below 10 MHz well.
But AMD's would clock down to any clock speed including 0 MHz. It's why
I've wanted to try to target these systems which came with the Am386 CPU,
for their underclocking abilities.

My goals in slowing down the CPU are to detect and isolate timing protocols,
which I can then scale up to higher speeds once identified.

In any event, any help or advice is appreciated. Thank you.

I have a book somewhere on the ISA bus with timing info. ISA was never
fully specified. I think there was an effort to produce a spec, but it
got canned and retracted at some point. You can't even find draft
versions of it now. But that was more of an 8086/80286 thing. I'm not
sure the ISA bus was still mapped directly to the 386 bus. I just don't
remember.

IIRC, it operated at 4.77 MHz for 8-bit bus, and 6 MHz or 8 MHz for the
16-bit bus. I don't know if that speed is required, or if it's the
standard clock speed when the system was operating at its normal clock
speed as would be setup by early BIOS during boot. I assume once it boots
up, the entire system can be overclocked or underclocked by altering the
frequency emitted by the clock circuit, and the whole system would rise
and fall in relative speed parity. Just a guess though.

Best regards,
Rick C. Hodgin

 

[rickman]

On 4/5/2016 3:15 PM, Rick C. Hodgin wrote:

I have a desire to create an 80386 CPU in FPGA form, one which will plug in
to the 132-pin socket of existing 80386 motherboard as a replacement CPU. I
want to be able to provide the features of the 80386 on that machine, but
through my FPGA, to then allow me to extend the ISA to include other
instructions and abilities.

Does anybody have an experience or advice in creating an FPGA-based CPU that
connects to a real hardware device and simulates the real device's abilities?

For example, the 80386 uses 5V and the Altera board I have drives 1.xV and
3.3V max, so I'd have to use a level converter. At speeds up to a max of
40 MHz, would there be any issues?

Even at 40 MHz you will need to be tidy with your routing to keep the
signals from ringing, etc. I don't know the details of the 386 chip I/O
specs, but quickswitch type parts will do a good job of level shifting
between 3.33 and 5 volts without adding much delay. Because the signal
passes between the source and drain there is very little delay. They
don't pull up to 5 volts, but 5 volt logic usually only need 2.x volts
anyway. But you'll need to check the parts you are interfacing to on
the mother board or just give it a wing. You can add pullups on the 5
volt side, but pullups tend to be slow. Even a few ns of added delay
can cause a 386 not to work. Many of the early mobos had timing issues
because of the TTL logic used. I don't think 386 mobos had chip sets in
place of the TTL, did they?

Also, I'd like to create a "monitor board," which is a board with a 132-
pin male socket connecting to the CPU on one side, and a 132-pin female
socket on the other side to which a real 80386 CPU would connect, and then
to be able to pull signals off the wires between the CPU socket and the
CPU itself. I had assumed I would use opto-isolation for this, but I don't
know if it would work or be best.

Opto-isolation is pretty slow compared to 40 MHz, but maybe there are
faster converters these days. Why do you need isolation?

In addition, and specific to the 80386 CPU, AMD manufactured an Am386 CPU
that is 100% compatible with the Intel 80386, but it has the ability to
underclock down to even 0 MHz in a standby mode (allowing it to consume
only 0.001 Watts). I'm wondering if anyone has any experience underclocking
an 80386 motherboard down into the KHz range, or even Hz range, and if it
would still work at those slow speeds on the board?

No experience, but the parts that would give trouble at slow clocks were
the NMOS devices that went out long before the 386. Certainly TTL and
CMOS don't normally have a problem with slow clocking.

My goals in slowing down the CPU are to detect and isolate timing protocols,
which I can then scale up to higher speeds once identified.

In any event, any help or advice is appreciated. Thank you.

I have a book somewhere on the ISA bus with timing info. ISA was never
fully specified. I think there was an effort to produce a spec, but it
got canned and retracted at some point. You can't even find draft
versions of it now. But that was more of an 8086/80286 thing. I'm not
sure the ISA bus was still mapped directly to the 386 bus. I just don't
remember.

--

Rick

 

[Rick C. Hodgin]

On Tuesday, April 5, 2016 at 9:22:32 PM UTC-4, rickman wrote:

On 4/5/2016 5:11 PM, Rick C. Hodgin wrote:
On Tuesday, April 5, 2016 at 4:13:28 PM UTC-4, rickman wrote:
On 4/5/2016 3:15 PM, Rick C. Hodgin wrote:
I have a desire to create an 80386 CPU in FPGA form, one which will plug in
to the 132-pin socket of existing 80386 motherboard as a replacement CPU. I
want to be able to provide the features of the 80386 on that machine, but
through my FPGA, to then allow me to extend the ISA to include other
instructions and abilities.

Does anybody have an experience or advice in creating an FPGA-based CPU that
connects to a real hardware device and simulates the real device's abilities?

For example, the 80386 uses 5V and the Altera board I have drives 1.xV and
3.3V max, so I'd have to use a level converter. At speeds up to a max of
40 MHz, would there be any issues?

Even at 40 MHz you will need to be tidy with your routing to keep the
signals from ringing, etc.

If I can get the machine underclocked, I'd like to bring it down into the
low KHz or even Hz range if possible, but something 100 KHz or lower at
least.

Running with a slow clock doesn't assure a lack of problems from edge
rates. The edges usually are still just as fast and that is what
creates problems.


I envision the Cyclone V GX being mounted a couple inches above the 80386
socket. I would use the HSMC to GPIO port to connect to the CPU socket.

I don't know about the HSMC port, but I don't think you need anything
special for a 40 MHz interface.


I had considered at first using the co-processor socket and emulating the
80387 ISA at first. I may still do that, but regardless, there are only
90 pins that are active on the 80386, and 64 of those are direct address
and data pins, with another 20 being control pins for when those lines
are active, and in what mode they're active.

There really isn't much logic involved in hooking up an 80386, which is
why I'm attempting this project.

To be honest, I wouldn't even mind dipping back down to a 4.77 MHz 8086
system and starting there as part of the ISA I'll support for the 80386
contains a full 8086 subset.

I don't know the details of the 386 chip I/O
specs, but quickswitch type parts will do a good job of level shifting
between 3.33 and 5 volts without adding much delay. Because the signal
passes between the source and drain there is very little delay. They
don't pull up to 5 volts, but 5 volt logic usually only need 2.x volts
anyway. But you'll need to check the parts you are interfacing to on
the mother board or just give it a wing. You can add pullups on the 5
volt side, but pullups tend to be slow. Even a few ns of added delay
can cause a 386 not to work. Many of the early mobos had timing issues
because of the TTL logic used.

Excellent information, thank you.

I don't think 386 mobos had chip sets in place of the TTL, did they?

Not originally, but later on. These motherboards were manufactured in
the early 90s, and came with Am386 CPUs manufactured in 91 or 92. I
believe the boards I have had switched to chip sets by then.

I recall that because there was no "standard" for the design of the
motherboard other than what IBM had done, there were some differences
between the various chip sets. In those days they *were* chip sets as
the whole shebang didn't end up in one chip like was used later and
still called a "chip set". lol


Also, I'd like to create a "monitor board," which is a board with a 132-
pin male socket connecting to the CPU on one side, and a 132-pin female
socket on the other side to which a real 80386 CPU would connect, and then
to be able to pull signals off the wires between the CPU socket and the
CPU itself. I had assumed I would use opto-isolation for this, but I don't
know if it would work or be best.

Opto-isolation is pretty slow compared to 40 MHz, but maybe there are
faster converters these days. Why do you need isolation?

I may not need it. However, when I was working on stepper motors back
in the mid-90s, I believe we used them to maintain a low power draw on
the circuits we were monitoring.

Optos are the opposite of low power draw on busses. Enough current is
required to drive an LED on the sensing side. Optos are typically used
to provide isolation from circuits that can have ground swings or
otherwise be noisy or have high voltage spikes, like motor circuits.


In addition, and specific to the 80386 CPU, AMD manufactured an Am386 CPU
that is 100% compatible with the Intel 80386, but it has the ability to
underclock down to even 0 MHz in a standby mode (allowing it to consume
only 0.001 Watts). I'm wondering if anyone has any experience underclocking
an 80386 motherboard down into the KHz range, or even Hz range, and if it
would still work at those slow speeds on the board?

No experience, but the parts that would give trouble at slow clocks were
the NMOS devices that went out long before the 386. Certainly TTL and
CMOS don't normally have a problem with slow clocking.

From what I've read, Intel's 80386 CPUs would not clock below 10 MHz well.
But AMD's would clock down to any clock speed including 0 MHz. It's why
I've wanted to try to target these systems which came with the Am386 CPU,
for their underclocking abilities.

I've forgotten more than I knew, lol. That may be accurate. I know the
original NMOS circuits used dynamic circuits where values were
remembered on capacitance and so had minimum clock rates. Maybe even on
CMOS designs they did the same thing.


My goals in slowing down the CPU are to detect and isolate timing protocols,
which I can then scale up to higher speeds once identified.

In any event, any help or advice is appreciated. Thank you.

I have a book somewhere on the ISA bus with timing info. ISA was never
fully specified. I think there was an effort to produce a spec, but it
got canned and retracted at some point. You can't even find draft
versions of it now. But that was more of an 8086/80286 thing. I'm not
sure the ISA bus was still mapped directly to the 386 bus. I just don't
remember.

IIRC, it operated at 4.77 MHz for 8-bit bus, and 6 MHz or 8 MHz for the
16-bit bus. I don't know if that speed is required, or if it's the
standard clock speed when the system was operating at its normal clock
speed as would be setup by early BIOS during boot. I assume once it boots
up, the entire system can be overclocked or underclocked by altering the
frequency emitted by the clock circuit, and the whole system would rise
and fall in relative speed parity. Just a guess though.

It's not actually a synchronous bus. Everything is timed by the read
and write strobes with some other signals helping to control data
directions on buffers. It started with the 8088 I/O bus controls and
remained compatible I believe, but I'm not sure. If you don't mind
stretching the cycles a bit it can be run synchronously. I'll see if I
can find that book.

--

Rick

Alright ... suppose I target this from another angle. What if I take
the CPU completely off the 80386 motherboard, and create a custom socket
connected to my FPGA, and I provide it with everything it requires?

The Am386 CPUs operated at speeds from 0 MHz to 40 MHz. Since they can
actually clock at any speed, I could take the CPU completely away from the peculiar and bizarre 80386 motherboard design, and instead provide the
facilities which basically allow the FPGA to be its motherboard, feeding
it whatever it's required.

Possible?

BTW, if I haven't said so you, I greatly appreciate your assistance and
advice. It is very kind of you to help me in this way, and much, very
much appreciated.

Best regards,
Rick C. Hodgin

 

[rickman]

On 4/5/2016 5:11 PM, Rick C. Hodgin wrote:

On Tuesday, April 5, 2016 at 4:13:28 PM UTC-4, rickman wrote:
On 4/5/2016 3:15 PM, Rick C. Hodgin wrote:
I have a desire to create an 80386 CPU in FPGA form, one which will plug in
to the 132-pin socket of existing 80386 motherboard as a replacement CPU. I
want to be able to provide the features of the 80386 on that machine, but
through my FPGA, to then allow me to extend the ISA to include other
instructions and abilities.

Does anybody have an experience or advice in creating an FPGA-based CPU that
connects to a real hardware device and simulates the real device's abilities?

For example, the 80386 uses 5V and the Altera board I have drives 1.xV and
3.3V max, so I'd have to use a level converter. At speeds up to a max of
40 MHz, would there be any issues?

Even at 40 MHz you will need to be tidy with your routing to keep the
signals from ringing, etc.

If I can get the machine underclocked, I'd like to bring it down into the
low KHz or even Hz range if possible, but something 100 KHz or lower at
least.

Running with a slow clock doesn't assure a lack of problems from edge
rates. The edges usually are still just as fast and that is what
creates problems.

I envision the Cyclone V GX being mounted a couple inches above the 80386
socket. I would use the HSMC to GPIO port to connect to the CPU socket.

I don't know about the HSMC port, but I don't think you need anything
special for a 40 MHz interface.

I had considered at first using the co-processor socket and emulating the
80387 ISA at first. I may still do that, but regardless, there are only
90 pins that are active on the 80386, and 64 of those are direct address
and data pins, with another 20 being control pins for when those lines
are active, and in what mode they're active.

There really isn't much logic involved in hooking up an 80386, which is
why I'm attempting this project.

To be honest, I wouldn't even mind dipping back down to a 4.77 MHz 8086
system and starting there as part of the ISA I'll support for the 80386
contains a full 8086 subset.

I don't know the details of the 386 chip I/O
specs, but quickswitch type parts will do a good job of level shifting
between 3.33 and 5 volts without adding much delay. Because the signal
passes between the source and drain there is very little delay. They
don't pull up to 5 volts, but 5 volt logic usually only need 2.x volts
anyway. But you'll need to check the parts you are interfacing to on
the mother board or just give it a wing. You can add pullups on the 5
volt side, but pullups tend to be slow. Even a few ns of added delay
can cause a 386 not to work. Many of the early mobos had timing issues
because of the TTL logic used.

Excellent information, thank you.

I don't think 386 mobos had chip sets in place of the TTL, did they?

Not originally, but later on. These motherboards were manufactured in
the early 90s, and came with Am386 CPUs manufactured in 91 or 92. I
believe the boards I have had switched to chip sets by then.

I recall that because there was no "standard" for the design of the
motherboard other than what IBM had done, there were some differences
between the various chip sets. In those days they *were* chip sets as
the whole shebang didn't end up in one chip like was used later and
still called a "chip set". lol

Also, I'd like to create a "monitor board," which is a board with a 132-
pin male socket connecting to the CPU on one side, and a 132-pin female
socket on the other side to which a real 80386 CPU would connect, and then
to be able to pull signals off the wires between the CPU socket and the
CPU itself. I had assumed I would use opto-isolation for this, but I don't
know if it would work or be best.

Opto-isolation is pretty slow compared to 40 MHz, but maybe there are
faster converters these days. Why do you need isolation?

I may not need it. However, when I was working on stepper motors back
in the mid-90s, I believe we used them to maintain a low power draw on
the circuits we were monitoring.

Optos are the opposite of low power draw on busses. Enough current is
required to drive an LED on the sensing side. Optos are typically used
to provide isolation from circuits that can have ground swings or
otherwise be noisy or have high voltage spikes, like motor circuits.

In addition, and specific to the 80386 CPU, AMD manufactured an Am386 CPU
that is 100% compatible with the Intel 80386, but it has the ability to
underclock down to even 0 MHz in a standby mode (allowing it to consume
only 0.001 Watts). I'm wondering if anyone has any experience underclocking
an 80386 motherboard down into the KHz range, or even Hz range, and if it
would still work at those slow speeds on the board?

No experience, but the parts that would give trouble at slow clocks were
the NMOS devices that went out long before the 386. Certainly TTL and
CMOS don't normally have a problem with slow clocking.

From what I've read, Intel's 80386 CPUs would not clock below 10 MHz well.
But AMD's would clock down to any clock speed including 0 MHz. It's why
I've wanted to try to target these systems which came with the Am386 CPU,
for their underclocking abilities.

I've forgotten more than I knew, lol. That may be accurate. I know the
original NMOS circuits used dynamic circuits where values were
remembered on capacitance and so had minimum clock rates. Maybe even on
CMOS designs they did the same thing.

My goals in slowing down the CPU are to detect and isolate timing protocols,
which I can then scale up to higher speeds once identified.

In any event, any help or advice is appreciated. Thank you.

I have a book somewhere on the ISA bus with timing info. ISA was never
fully specified. I think there was an effort to produce a spec, but it
got canned and retracted at some point. You can't even find draft
versions of it now. But that was more of an 8086/80286 thing. I'm not
sure the ISA bus was still mapped directly to the 386 bus. I just don't
remember.

IIRC, it operated at 4.77 MHz for 8-bit bus, and 6 MHz or 8 MHz for the
16-bit bus. I don't know if that speed is required, or if it's the
standard clock speed when the system was operating at its normal clock
speed as would be setup by early BIOS during boot. I assume once it boots
up, the entire system can be overclocked or underclocked by altering the
frequency emitted by the clock circuit, and the whole system would rise
and fall in relative speed parity. Just a guess though.

It's not actually a synchronous bus. Everything is timed by the read
and write strobes with some other signals helping to control data
directions on buffers. It started with the 8088 I/O bus controls and
remained compatible I believe, but I'm not sure. If you don't mind
stretching the cycles a bit it can be run synchronously. I'll see if I
can find that book.

--

Rick

 

[rickman]

On 4/5/2016 10:47 PM, Rick C. Hodgin wrote:

Alright ... suppose I target this from another angle. What if I take
the CPU completely off the 80386 motherboard, and create a custom socket
connected to my FPGA, and I provide it with everything it requires?

The Am386 CPUs operated at speeds from 0 MHz to 40 MHz. Since they can
actually clock at any speed, I could take the CPU completely away from the peculiar and bizarre 80386 motherboard design, and instead provide the
facilities which basically allow the FPGA to be its motherboard, feeding
it whatever it's required.

Possible?

Sure. Booting one of these things may be a bit complicated, but not
likely any worse than booting a modern high end ARM processor. Likely a
lot easier.

BTW, if I haven't said so you, I greatly appreciate your assistance and
advice. It is very kind of you to help me in this way, and much, very
much appreciated.

No problem. This an interesting if not mysterious project.

--

Rick

 

[Rick C. Hodgin]

On Wednesday, April 6, 2016 at 12:35:43 AM UTC-4, rickman wrote:

On 4/5/2016 10:47 PM, Rick C. Hodgin wrote:

Alright ... suppose I target this from another angle. What if I take
the CPU completely off the 80386 motherboard, and create a custom socket
connected to my FPGA, and I provide it with everything it requires?

The Am386 CPUs operated at speeds from 0 MHz to 40 MHz. Since they can
actually clock at any speed, I could take the CPU completely away from the peculiar and bizarre 80386 motherboard design, and instead provide the
facilities which basically allow the FPGA to be its motherboard, feeding
it whatever it's required.

Possible?

Sure. Booting one of these things may be a bit complicated, but not
likely any worse than booting a modern high end ARM processor. Likely a
lot easier.

Agreed. The 80386 manuals document the power-on state, and provided I
setup the SRAM emulation to point to the correct addresses with proper
80386 binary code, it should start processing away like gangbusters.

My next step is to construct the board that has the 132-pin socket, and
the mated ports for the GPIO cables that the HSMC-to-GPIO board has.

Do you have any particular recommendation as to where I should go to get
the board manufactured? I've seen a host of online services where you
either use their tools, or provide a black-and-white bitmap for each
layer outlining the vias, pin locations, and wires, along with scaling
info.

BTW, if I haven't said so you, I greatly appreciate your assistance and
advice. It is very kind of you to help me in this way, and much, very
much appreciated.

No problem. This an interesting if not mysterious project.

I don't want to spend a lot of time trying to get it to work, but if
I can, it would be really nice to be able to have my CPU side-by-side with
a real-world product, able to test out compatibility.

And if it works, then for my ARM-based ISA, I would do something similar
with a slower ARM core, something also around 32 MHz or so.

Best regards,
Rick C. Hodgin

 

[Rick C. Hodgin]

On Wednesday, April 6, 2016 at 8:16:26 AM UTC-4, o pere o wrote:

If you plan to slow down the CPU by slowing down the FPGA clock be
careful: FPGAs like clean and relatively fast edges and some slow
generators don't work well.

I plan on using the FPGA clock as it is, and then creating logic within
the FPGA to drive a pin high and low which produces the simulated clock
signal at a speed I can vary.

Since the Am386 can operate at a wide range of frequencies, I'll start
out at a 2 Hz clock and see what happens.

Best regards,
Rick C. Hodgin

 

[Rick C. Hodgin]

On Wednesday, April 6, 2016 at 8:20:35 AM UTC-4, Rick C. Hodgin wrote:

My next step is to construct the board that has the 132-pin socket, and
the mated ports for the GPIO cables that the HSMC-to-GPIO board has.

And the level converters and any debug ports or vias for the scope.

Best regards,
Rick C. Hodgin

 

[Rick C. Hodgin]

On Tuesday, April 5, 2016 at 9:22:32 PM UTC-4, rickman wrote:

On 4/5/2016 5:11 PM, Rick C. Hodgin wrote:
On Tuesday, April 5, 2016 at 4:13:28 PM UTC-4, rickman wrote:
Opto-isolation is pretty slow compared to 40 MHz, but maybe there are
faster converters these days. Why do you need isolation?

I may not need it. However, when I was working on stepper motors back
in the mid-90s, I believe we used them to maintain a low power draw on
the circuits we were monitoring.

Optos are the opposite of low power draw on busses. Enough current is
required to drive an LED on the sensing side. Optos are typically used
to provide isolation from circuits that can have ground swings or
otherwise be noisy or have high voltage spikes, like motor circuits.

Got it. Makes perfect sense.

Best regards,
Rick C. Hodgin

 

[Rick C. Hodgin]

On Wednesday, April 6, 2016 at 11:51:16 AM UTC-4, rickman wrote:

On 4/6/2016 8:20 AM, Rick C. Hodgin wrote:
I don't want to spend a lot of time trying to get it to work, but if
I can, it would be really nice to be able to have my CPU side-by-side with
a real-world product, able to test out compatibility.

You should be able to design one board with an FPGA, a 386 socket and a
386 plug which will work for any of the three things you have talked
about doing, emulating the mobo with your FPGA, emulating the 386 with
your FPGA and monitoring the 386 in a real mobo with the FPGA.

386 Chip
____________
++++++++++++ FPGA
============== _____________
|||||||||||| ,,,,,,,,,,,,,
=================================================== PCB
||||||||||||
Plugs into 386 Mobo

When emulating the 386 unplug it from the socket. When emulating the
mobo, unplug from the mobo. When monitoring the 386 in operation plug
in the 386 and plug the board into the mobo.

If you aren't in a hurry, I can help you with the PCB design. I can use
this as a learning tool to come up to speed with KiCAD which I've been
meaning to do.

I think this sounds like a great solution. I've never programmed an
FPGA outside of the dev board and dev environment (Quartus), so I have
no idea how I'd program the on-board FPGA as you indicate. If it's
possible, your design looks amazing.

How is the FPGA programmed when it's not on a dev board? Is it that
certain pins feed into its programming mechanism, and those would be
wired to a usb port we'd add to the board for that purpose?

Best regards,
Rick C. Hodgin

 

[o pere o]

On 05/04/16 21:15, Rick C. Hodgin wrote:

I have a desire to create an 80386 CPU in FPGA form, one which will plug in
to the 132-pin socket of existing 80386 motherboard as a replacement CPU. I
want to be able to provide the features of the 80386 on that machine, but
through my FPGA, to then allow me to extend the ISA to include other
instructions and abilities.

Does anybody have an experience or advice in creating an FPGA-based CPU that
connects to a real hardware device and simulates the real device's abilities?

For example, the 80386 uses 5V and the Altera board I have drives 1.xV and
3.3V max, so I'd have to use a level converter. At speeds up to a max of
40 MHz, would there be any issues?

Also, I'd like to create a "monitor board," which is a board with a 132-
pin male socket connecting to the CPU on one side, and a 132-pin female
socket on the other side to which a real 80386 CPU would connect, and then
to be able to pull signals off the wires between the CPU socket and the
CPU itself. I had assumed I would use opto-isolation for this, but I don't
know if it would work or be best.

In addition, and specific to the 80386 CPU, AMD manufactured an Am386 CPU
that is 100% compatible with the Intel 80386, but it has the ability to
underclock down to even 0 MHz in a standby mode (allowing it to consume
only 0.001 Watts). I'm wondering if anyone has any experience underclocking
an 80386 motherboard down into the KHz range, or even Hz range, and if it
would still work at those slow speeds on the board?

My goals in slowing down the CPU are to detect and isolate timing protocols,
which I can then scale up to higher speeds once identified.

In any event, any help or advice is appreciated. Thank you.

Best regards,
Rick C. Hodgin

If you plan to slow down the CPU by slowing down the FPGA clock be
careful: FPGAs like clean and relatively fast edges and some slow
generators don't work well.

Pere

 

[Rick C. Hodgin]

On Wednesday, April 6, 2016 at 12:38:45 PM UTC-4, rickman wrote:

On 4/6/2016 12:08 PM, Rick C. Hodgin wrote:
On Wednesday, April 6, 2016 at 11:51:16 AM UTC-4, rickman wrote:
On 4/6/2016 8:20 AM, Rick C. Hodgin wrote:
I don't want to spend a lot of time trying to get it to work, but if
I can, it would be really nice to be able to have my CPU side-by-side with
a real-world product, able to test out compatibility.

You should be able to design one board with an FPGA, a 386 socket and a
386 plug which will work for any of the three things you have talked
about doing, emulating the mobo with your FPGA, emulating the 386 with
your FPGA and monitoring the 386 in a real mobo with the FPGA.

386 Chip
____________
++++++++++++ FPGA
============== _____________
|||||||||||| ,,,,,,,,,,,,,
=================================================== PCB
||||||||||||
Plugs into 386 Mobo

When emulating the 386 unplug it from the socket. When emulating the
mobo, unplug from the mobo. When monitoring the 386 in operation plug
in the 386 and plug the board into the mobo.

If you aren't in a hurry, I can help you with the PCB design. I can use
this as a learning tool to come up to speed with KiCAD which I've been
meaning to do.

I think this sounds like a great solution. I've never programmed an
FPGA outside of the dev board and dev environment (Quartus), so I have
no idea how I'd program the on-board FPGA as you indicate. If it's
possible, your design looks amazing.

How is the FPGA programmed when it's not on a dev board? Is it that
certain pins feed into its programming mechanism, and those would be
wired to a usb port we'd add to the board for that purpose?

MCUs have a various means of programming them which often allow the use
of a simple USB port and a small chip. FPGAs have two ways of
programming... JTAG and a proprietary serial interface, each brand and
sometimes even family of FPGAs are different. The proprietary
interfaces are often very similar, but the programmers are different. I
just buy a cable from the makers and live with that. There are
"universal" cables sold on eBay but I've never tried one so I don't know
how well they work. I should as I have manufacturing needs and only
have one cable with no spares. I should either buy a new cable or try
using one of the universal ones.

If you have an eval board, it may have a chip on board to handle the
programming or it may require a cable. I have an iCEblink40 (Lattice)
eval board that uses USB. Looks like they use an AT90USB2 with custom
programming to bring up the FPGA. I bet other manufacturers do similar
things on their low end boards. If you can get the code you could copy
that, or just tie into the signals and use that programmer with your FPGA.

I like some of the Lattice chips because they have Flash. Once you
program them the programmer is no longer needed. If you are going to
use a RAM configured part you need something to program the FPGA every
time you power it up, so might as well design an MCU programmer onto
your board.

I think I asked you this before in 2014?? Do you live anywhere near
Indiana? I would be willing to drive out and spend a weekend with
you sometime on this project, listening and learning, seeing and
experiencing. I'd even be willing to buy you lunch for it.

Best regards,
Rick C. Hodgin

 

[Rick C. Hodgin]

On Wednesday, April 6, 2016 at 12:38:45 PM UTC-4, rickman wrote:

If you have an eval board, it may have a chip on board to handle the
programming or it may require a cable. I have an iCEblink40 (Lattice)
eval board that uses USB. Looks like they use an AT90USB2 with custom
programming to bring up the FPGA.

Is it this one?

http://www.digikey.com/product-detail/en/ICE40HX1K-BLINK-EVN/220-1581-ND/3198285

Best regards,
Rick C. Hodgin

 

[Aleksandar Kuktin]

On Wed, 06 Apr 2016 11:51:15 -0400, rickman wrote:

On 4/6/2016 8:20 AM, Rick C. Hodgin wrote:
On Wednesday, April 6, 2016 at 12:35:43 AM UTC-4, rickman wrote:
On 4/5/2016 10:47 PM, Rick C. Hodgin wrote:

Alright ... suppose I target this from another angle. What if I take
the CPU completely off the 80386 motherboard, and create a custom
socket connected to my FPGA, and I provide it with everything it
requires?

This is probably a much better idea.

The reason for that is that I would expect the motherboard manufacturer
probably didn't expect someone would be messing with the onboard clock.
And then they, presumably, didn't design it to handle it. It's enough for
a single component to misbehave at low frequency and the whole thing
would fail.

Doing things the other way around should be easier. I can't imagine the
CPU to be that picky about what it gets from the outside world.

Then again... if the memory controller is embedded in the CPU...

You should be able to design one board with an FPGA, a 386 socket and a
386 plug which will work for any of the three things you have talked
about doing, emulating the mobo with your FPGA, emulating the 386 with
your FPGA and monitoring the 386 in a real mobo with the FPGA.

386 Chip
____________
++++++++++++ FPGA
============== _____________
|||||||||||| ,,,,,,,,,,,,,
=================================================== PCB
||||||||||||
Plugs into 386 Mobo

When emulating the 386 unplug it from the socket. When emulating the
mobo, unplug from the mobo. When monitoring the 386 in operation plug
in the 386 and plug the board into the mobo.

Oh, ok. I was really struggling to figure out how would he mechanically
intercept the signals between the CPU and the motherboard. Although this
design still has me scratching my head about those several hundred pins
that need to be manufactured and installed (by hand?), it's much better
than what I envisioned.

If you two really build such a PCB, would you post the design here? I'd
really like to see how you route all those wires.


An innocent question: why not intercept the signals running at full
speed, storing them and transmitting them later? You probably wouldn't be
able to record a whole lot of them at once, but you record a bit, power
cycle the CPU, record a bit more, power cycle the CPU, record a bit
more....

 

[Aleksandar Kuktin]

On Tue, 05 Apr 2016 12:15:35 -0700, Rick C. Hodgin wrote:

I have a desire to create an 80386 CPU in FPGA form, one which will plug
in to the 132-pin socket of existing 80386 motherboard as a replacement
CPU.

Okay, so I'm not the only one who's into slow system design.

I want to be able to provide the features of the 80386 on that
machine, but through my FPGA, to then allow me to extend the ISA to
include other instructions and abilities.

I have to ask: why spend time hacking x86 when there are so many other,
BETTER architectures out there?

Also, why are you doing this? Is this a hobby? Work related? Starting a
new bussiness? Want to design and implement a NSA-proof PC?

Does anybody have an experience or advice in creating an FPGA-based CPU
that connects to a real hardware device and simulates the real device's
abilities?

Does simulation count?

 

[rickman]

On 4/6/2016 8:20 AM, Rick C. Hodgin wrote:

On Wednesday, April 6, 2016 at 12:35:43 AM UTC-4, rickman wrote:
On 4/5/2016 10:47 PM, Rick C. Hodgin wrote:

Alright ... suppose I target this from another angle. What if I take
the CPU completely off the 80386 motherboard, and create a custom socket
connected to my FPGA, and I provide it with everything it requires?

The Am386 CPUs operated at speeds from 0 MHz to 40 MHz. Since they can
actually clock at any speed, I could take the CPU completely away from the peculiar and bizarre 80386 motherboard design, and instead provide the
facilities which basically allow the FPGA to be its motherboard, feeding
it whatever it's required.

Possible?

Sure. Booting one of these things may be a bit complicated, but not
likely any worse than booting a modern high end ARM processor. Likely a
lot easier.

Agreed. The 80386 manuals document the power-on state, and provided I
setup the SRAM emulation to point to the correct addresses with proper
80386 binary code, it should start processing away like gangbusters.

My next step is to construct the board that has the 132-pin socket, and
the mated ports for the GPIO cables that the HSMC-to-GPIO board has.

Do you have any particular recommendation as to where I should go to get
the board manufactured? I've seen a host of online services where you
either use their tools, or provide a black-and-white bitmap for each
layer outlining the vias, pin locations, and wires, along with scaling
info.

There are a number of places to have PCBs made, but I would avoid
strongly using a bitmap graphic file to convey the design data. PCBs
are complex beasts and if you have never done a PCB design before, I
suggest you spend a lot of time learning how to do that.

I like oshpark.com, but there is also www.pcb-pool.com/

You will want to use a PCB layout package and either use Gerber file
output to have the boards built, or some fab houses will take the native
format files of the layout package. One place I found would accept many
different kinds. I think they prefer that because it is not hard to
send Gerber data that can be misinterpreted. Gerber is a lousy format
really because it was the proprietary format of one company and never
intended to be a universal tool.

BTW, if I haven't said so you, I greatly appreciate your assistance and
advice. It is very kind of you to help me in this way, and much, very
much appreciated.

No problem. This an interesting if not mysterious project.

I don't want to spend a lot of time trying to get it to work, but if
I can, it would be really nice to be able to have my CPU side-by-side with
a real-world product, able to test out compatibility.

You should be able to design one board with an FPGA, a 386 socket and a
386 plug which will work for any of the three things you have talked
about doing, emulating the mobo with your FPGA, emulating the 386 with
your FPGA and monitoring the 386 in a real mobo with the FPGA.

386 Chip
____________
++++++++++++ FPGA
============== _____________
|||||||||||| ,,,,,,,,,,,,,
=================================================== PCB
||||||||||||
Plugs into 386 Mobo

When emulating the 386 unplug it from the socket. When emulating the
mobo, unplug from the mobo. When monitoring the 386 in operation plug
in the 386 and plug the board into the mobo.

If you aren't in a hurry, I can help you with the PCB design. I can use
this as a learning tool to come up to speed with KiCAD which I've been
meaning to do.

And if it works, then for my ARM-based ISA, I would do something similar
with a slower ARM core, something also around 32 MHz or so.

Best regards,
Rick C. Hodgin

--

Rick

 

[Rick C. Hodgin]

On Wednesday, April 6, 2016 at 3:00:51 PM UTC-4, Aleksandar Kuktin wrote:

On Wed, 06 Apr 2016 11:51:15 -0400, rickman wrote:

On 4/6/2016 8:20 AM, Rick C. Hodgin wrote:
On Wednesday, April 6, 2016 at 12:35:43 AM UTC-4, rickman wrote:
On 4/5/2016 10:47 PM, Rick C. Hodgin wrote:

Alright ... suppose I target this from another angle. What if I take
the CPU completely off the 80386 motherboard, and create a custom
socket connected to my FPGA, and I provide it with everything it
requires?

This is probably a much better idea.

The reason for that is that I would expect the motherboard manufacturer
probably didn't expect someone would be messing with the onboard clock.
And then they, presumably, didn't design it to handle it. It's enough for
a single component to misbehave at low frequency and the whole thing
would fail.

Doing things the other way around should be easier. I can't imagine the
CPU to be that picky about what it gets from the outside world.

Then again... if the memory controller is embedded in the CPU...

Not on the 386 chips. The first memory controllers which appeared on
x86 CPUs came from AMD and that was on K8 I believe.

You should be able to design one board with an FPGA, a 386 socket and a
386 plug which will work for any of the three things you have talked
about doing, emulating the mobo with your FPGA, emulating the 386 with
your FPGA and monitoring the 386 in a real mobo with the FPGA.

386 Chip
____________
++++++++++++ FPGA
============== _____________
|||||||||||| ,,,,,,,,,,,,,
=================================================== PCB
||||||||||||
Plugs into 386 Mobo

When emulating the 386 unplug it from the socket. When emulating the
mobo, unplug from the mobo. When monitoring the 386 in operation plug
in the 386 and plug the board into the mobo.

Oh, ok. I was really struggling to figure out how would he mechanically
intercept the signals between the CPU and the motherboard. Although this
design still has me scratching my head about those several hundred pins
that need to be manufactured and installed (by hand?), it's much better
than what I envisioned.

If you two really build such a PCB, would you post the design here? I'd
really like to see how you route all those wires.

The 80386 used a 132-pin socket, of which 40 pins are either not connected
or only carry Vcc or Vss voltages:

http://www.electronicsurplus.com/samtec-ndas-132zsgt-h-connectors-ic-sockets-132-pin-grid-array-package-of-2

The sockets and pinouts are fairly standard, though less common these
days. I could de-solder a connector on one of the motherboards I have
for my particular application. Provided the vias were all in the right
place, it should transfer over and re-solder just fine.

An innocent question: why not intercept the signals running at full
speed, storing them and transmitting them later? You probably wouldn't be
able to record a whole lot of them at once, but you record a bit, power
cycle the CPU, record a bit more, power cycle the CPU, record a bit
more....

That was my first desire. But, once I learned about AMD's Am386's
ability to clock down to even 0 MHz and maintain its internal state
correctly, I began to think it would be easier to examine if it were
running at lower speed.

The clock signal to an 80386 is double-pumped, so a 2 Hz input clock
would cause 1 clock cycle per second.

Best regards,
Rick C. Hodgin

 

[Rick C. Hodgin]

On Wednesday, April 6, 2016 at 3:07:55 PM UTC-4, Aleksandar Kuktin wrote:

On Tue, 05 Apr 2016 12:15:35 -0700, Rick C. Hodgin wrote:

I have a desire to create an 80386 CPU in FPGA form, one which will plug
in to the 132-pin socket of existing 80386 motherboard as a replacement
CPU.

Okay, so I'm not the only one who's into slow system design.

I am not objected to having it go faster, but the faster it goes the
most expensive it is.

Okay, are you sitting down? Here goes...

My ultimate goal is to build a completely homemade CPU using my own
garage fab on 3 to 10 micron processes! Once I can get that product
working, then it can be optimized and honed to more modern processes,
with my ultimate goal coming in around those process technologies used
in the late 90s around 500 nm.

I want to be able to provide the features of the 80386 on that
machine, but through my FPGA, to then allow me to extend the ISA to
include other instructions and abilities.

I have to ask: why spend time hacking x86 when there are so many other,
BETTER architectures out there?

I have a long history on 80386. I wrote my own kernel, debuggers, etc.
It's been a relationship dating back to the late 80s.

However, one of the reasons I'm doing this is because I am extending
the ISA out to include 40-bit addresses, rather than just 32-bit,
which accesses memory in the Terabyte range, and to include a built-in
ARM ISA which allows the CPU to switch between ISAs based on branch
instructions.

Also, why are you doing this? Is this a hobby? Work related? Starting a
new bussiness? Want to design and implement a NSA-proof PC?

To be honest, I am a Christian, and I want to use the talents I was gifted
with and give the fruit of my labor back to God, and to my fellow man (and
not a pursuit of money, or proprietary IP, or patents, or other such things,
but rather an expression of love basically in giving back).

Does anybody have an experience or advice in creating an FPGA-based CPU
that connects to a real hardware device and simulates the real device's
abilities?

Does simulation count?

Yes. Also in emulation, as by a real FPGA product, but one which does not
plug into a socket, but is its own entire creation. Here's an Aleksander
who created a 486 SX CPU (it has not integrated FPU):

https://github.com/alfikpl/ao486

My goals are part of a project I'm working on called LibSF 386-x40, which
is a 40-bit extension to the 80386, and 32-bit ARM. I use a WEX register
model which extends the 32-bit registers to 40-bit registers:

https://github.com/RickCHodgin/libsf/blob/master/li386/li386-documentation/images/wex_register_mapping.png

However, in the past couple weeks I've had the idea of a pointer selector,
which operates like a segment selector, but on a specific pointer register.
When enabled, it loads an extra 8-bits into the segment register associated
with specific register, such that it then is able to reference a 4GB window
of memory within the 1 TB address space:

https://groups.google.com/d/msg/comp.arch/bcpb03mL0o0/xUBzCXDmBgAJ

These are all part of long-term plans. I'd like to have my first CPU being
shipped to a fab for real manufacturing by July 12, 2022, which I expect to
be around a 90 MHz part.

Best regards,
Rick C. Hodgin