Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 158725

Article: 158725
Subject: Re: Using an FPGA to drive the 80386 CPU on a real motherboard
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Wed, 6 Apr 2016 05:20:32 -0700 (PDT)
Links: << >>  << T >>  << A >>
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

Article: 158726
Subject: Re: Using an FPGA to drive the 80386 CPU on a real motherboard
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Wed, 6 Apr 2016 05:24:25 -0700 (PDT)
Links: << >>  << T >>  << A >>
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

Article: 158727
Subject: Re: Using an FPGA to drive the 80386 CPU on a real motherboard
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Wed, 6 Apr 2016 05:53:33 -0700 (PDT)
Links: << >>  << T >>  << A >>
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

Article: 158728
Subject: Re: Using an FPGA to drive the 80386 CPU on a real motherboard
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Wed, 6 Apr 2016 05:54:35 -0700 (PDT)
Links: << >>  << T >>  << A >>
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

Article: 158729
Subject: Re: Using an FPGA to drive the 80386 CPU on a real motherboard
From: rickman <gnuarm@gmail.com>
Date: Wed, 6 Apr 2016 11:51:15 -0400
Links: << >>  << T >>  << A >>
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

Article: 158730
Subject: Re: Using an FPGA to drive the 80386 CPU on a real motherboard
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Wed, 6 Apr 2016 09:08:03 -0700 (PDT)
Links: << >>  << T >>  << A >>
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

Article: 158731
Subject: Re: Using an FPGA to drive the 80386 CPU on a real motherboard
From: rickman <gnuarm@gmail.com>
Date: Wed, 6 Apr 2016 12:38:43 -0400
Links: << >>  << T >>  << A >>
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.

-- 

Rick

Article: 158732
Subject: Re: Using an FPGA to drive the 80386 CPU on a real motherboard
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Wed, 6 Apr 2016 09:45:10 -0700 (PDT)
Links: << >>  << T >>  << A >>
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

Article: 158733
Subject: Re: Using an FPGA to drive the 80386 CPU on a real motherboard
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Wed, 6 Apr 2016 10:37:08 -0700 (PDT)
Links: << >>  << T >>  << A >>
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

Article: 158734
Subject: Re: Using an FPGA to drive the 80386 CPU on a real motherboard
From: rickman <gnuarm@gmail.com>
Date: Wed, 6 Apr 2016 14:43:15 -0400
Links: << >>  << T >>  << A >>
On 4/6/2016 12:45 PM, Rick C. Hodgin wrote:
> 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. :-)

I am in Maryland, VA and WV near Charlestown.  I do a lot of my 
electronic thinking in VA.  I asked google how far it is to Indiana and 
it said 630 miles to an arbitrary point north of Indianapolis.

I doubt a trip is really necessary.  We can exchange emails.  gnuarm dot 
2007 at arius dot com

-- 

Rick

Article: 158735
Subject: Re: Using an FPGA to drive the 80386 CPU on a real motherboard
From: rickman <gnuarm@gmail.com>
Date: Wed, 6 Apr 2016 14:44:37 -0400
Links: << >>  << T >>  << A >>
On 4/6/2016 1:37 PM, Rick C. Hodgin wrote:
> 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

I have a similar one with the iCE40LP1K chip which is lower power and 
less speed.

-- 

Rick

Article: 158736
Subject: Re: Using an FPGA to drive the 80386 CPU on a real motherboard
From: rickman <gnuarm@gmail.com>
Date: Wed, 6 Apr 2016 14:46:45 -0400
Links: << >>  << T >>  << A >>
On 4/6/2016 1:37 PM, Rick C. Hodgin wrote:
> 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

I started a thread in comp.arch.embedded about PCB makers.  You may also 
need assembly help too.  Many FPGAs are BGA which can be tricky to 
assemble at home.

-- 

Rick

Article: 158737
Subject: Re: Using an FPGA to drive the 80386 CPU on a real motherboard
From: Aleksandar Kuktin <akuktin@gmail.com>
Date: Wed, 6 Apr 2016 19:00:43 +0000 (UTC)
Links: << >>  << T >>  << A >>
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....

Article: 158738
Subject: Re: Using an FPGA to drive the 80386 CPU on a real motherboard
From: Aleksandar Kuktin <akuktin@gmail.com>
Date: Wed, 6 Apr 2016 19:07:49 +0000 (UTC)
Links: << >>  << T >>  << A >>
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? :D

Article: 158739
Subject: Re: Using an FPGA to drive the 80386 CPU on a real motherboard
From: rickman <gnuarm@gmail.com>
Date: Wed, 6 Apr 2016 15:10:27 -0400
Links: << >>  << T >>  << A >>
On 4/6/2016 3:00 PM, 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...

You need to go much further back in time to an era where CPUs were just 
CPUs and *everything* had to be done by the motherboard.  The CPU has a 
simple bus and doesn't actually know about your memory.  But you are 
right that the mobo may not be happy clocked at 2 Hz.


>> 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. :)

Check again.  I think Rick Hodgin posted the exact count at some point, 
but it is not hundreds of pins.  Also, they are on 0.1 inch centers (pin 
grid array, right?) so you can use easy to find machined pin strips. 
0.24 square posts won't cut it, but the smaller diameter pins are 
available too.


> 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....

Reminds me of how they used to do hardware emulation in combination with 
simulation.  The simulator would run one cycle and then stimulate the 
hardware to get the result.  This would be factored into the simulation 
and the next cycle would run.  The hardware would then be rebooted and 
two cycles of stimulus would be applied and the result captured. 
Lather, rinse, repeat ad nauseam.

-- 

Rick

Article: 158740
Subject: Re: Using an FPGA to drive the 80386 CPU on a real motherboard
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Wed, 6 Apr 2016 13:19:27 -0700 (PDT)
Links: << >>  << T >>  << A >>
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

Article: 158741
Subject: Re: Using an FPGA to drive the 80386 CPU on a real motherboard
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Wed, 6 Apr 2016 13:38:19 -0700 (PDT)
Links: << >>  << T >>  << A >>
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? :D

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

Article: 158742
Subject: Re: Using an FPGA to drive the 80386 CPU on a real motherboard
From: rickman <gnuarm@gmail.com>
Date: Wed, 6 Apr 2016 16:38:19 -0400
Links: << >>  << T >>  << A >>
On 4/6/2016 4:19 PM, Rick C. Hodgin wrote:
> 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.

That jogged a recollection.  Once the internal speeds got faster they 
added phase locked loops to use a slow external clock and a faster 
internal clock.  These are no longer compatible with slow clocking.

Same is true of FPGAs if you use the internal PLL.  It will be fairly 
simple to generate a variable speed clock to drive the CPU with.  Then 
the FPGA can either work at that same rate, or resync the interface to a 
fast internal clock which does not change rate.  It all depends on what 
you are doing with the data once you get it and what your other 
interfaces are.

-- 

Rick

Article: 158743
Subject: Re: Using an FPGA to drive the 80386 CPU on a real motherboard
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Wed, 6 Apr 2016 13:41:52 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Wednesday, April 6, 2016 at 4:38:20 PM UTC-4, rickman wrote:
> On 4/6/2016 4:19 PM, Rick C. Hodgin wrote:
> > 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.
> 
> That jogged a recollection.  Once the internal speeds got faster they 
> added phase locked loops to use a slow external clock and a faster 
> internal clock.  These are no longer compatible with slow clocking.

I believe that occurred on the 80486 and the DX/2, DX/3 (un-released),
and DX/4 models.

The 80387 co-processor has the ability to run dual clocks internally,
which are governed in the range of 14:10 (I believe), but they don't
have to run faster.  They can be locked and always run at the same
speed.

> Same is true of FPGAs if you use the internal PLL.  It will be fairly 
> simple to generate a variable speed clock to drive the CPU with.  Then 
> the FPGA can either work at that same rate, or resync the interface to a 
> fast internal clock which does not change rate.  It all depends on what 
> you are doing with the data once you get it and what your other 
> interfaces are.

I had the idea that I would use the simulated clock output for an input
trigger back into the FPGA for doing all monitoring/sampling.

Best regards,
Rick C. Hodgin

Article: 158744
Subject: Re: Using an FPGA to drive the 80386 CPU on a real motherboard
From: Jon Elson <jmelson@wustl.edu>
Date: Wed, 06 Apr 2016 16:05:05 -0500
Links: << >>  << T >>  << A >>
rickman wrote:


> 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.
> 
Xilinx also has he Spartan 3AN (N for non-volatile).  For a couple extra 
bucks, you can get get the flash memory built in.  Otherwise, their Spartan 
3 family will download from a fariety of serial PROMS with no additional 
circuitry.  I've been using SST serial EPROMS for some time, they are 
something like $0.80 which seems pretty amazing.  They don't make them in 
DIP, however, so I have to make a little board about fingernail size so I 
can plug them in to the board.

Jon

Article: 158745
Subject: Re: Using an FPGA to drive the 80386 CPU on a real motherboard
From: Jon Elson <jmelson@wustl.edu>
Date: Wed, 06 Apr 2016 16:27:13 -0500
Links: << >>  << T >>  << A >>
Rick C. Hodgin wrote:


> 
> 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.
OH, MY!!!  Call out the men in the white coats!  While some people have 
actually made transistors and even very SIMPLE ICs at home, when you get 
into more complex stuff, it starts to get real hard!  Intel's version of the 
'386 had 275,000 transistors!  Do you have the software tools to simulate 
the timing on such a chip?  And, of course, all 275,000 of those transistors 
have to work!  

I occasionally make PC boards in my basement, and I have some professional-
grade machinery to use, such as a laser photoplotter, Kepro dry film 
laminator and Kepro etcher.  I still have problems with yield, and have to 
touch up the boards to make them work.  I can't IMAGINE how much harder that 
could get with 275,000 transistors on Silicon!  Uhhh, maybe you might try to 
get a single FF to work, first.  How are you going to make the masks?  Have 
you ever worked with Arsine, DiBorane, Phosphine and similar gases?


> 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.
Ah, well, this is different.  Let the fabs deal with the deadly gases, clean 
room environment, maks making, etc.

I've been working on projects which make chips through the MOSIS service.  
This is NOT cheap, by any means.  We use the very old AMI C5N process, now 
provided to MOSIS through ON Semi.  It is a .5 um process.  A small chip we 
made was fabbed by them on a multi-project wafer for about $18,000.  I doubt 
your 80386 would fit in that size.  They charge by the square mm.  Their 
multi-project wafer system combines 20 or more different designs onto one 
reticle, and then they dice up the chips for the different users.  A larger 
project ended up running about $44000, but we got more instances of the chip 
for that than the standard order of only 40 chips.

Jon

Article: 158746
Subject: Re: Using an FPGA to drive the 80386 CPU on a real motherboard
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Wed, 6 Apr 2016 14:49:08 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Wednesday, April 6, 2016 at 5:45:12 PM UTC-4, Rick C. Hodgin wrote:
> I figured the CPUs I'd make would cost $1,000 each in the early samples,
> with an anticipated 50 to 100 CPU minimum, but that if I am able to create
> the industry I'm hoping to create (people who are willing to buy CPUs that
> are wrought of love, more than high-speed bells and whistles, looking to
> them as a utility to augment man's existence, rather than as a whizz bang
> eye candy newest fad ("gotta have the $12K iPhone 6 because my $10K iPhone
> 5 is just so last year") kind of thing).

...then the need for larger runs would be there and the price would go down.

Best regards,
Rick C. Hodgin

Article: 158747
Subject: Re: Using an FPGA to drive the 80386 CPU on a real motherboard
From: Jon Elson <elson@pico-systems.com>
Date: Wed, 06 Apr 2016 22:40:30 -0500
Links: << >>  << T >>  << A >>
Rick C. Hodgin wrote:


> 
> I figured the CPUs I'd make would cost $1,000 each in the early samples,
OK, the MOSIS standard order is for 40 parts.  So, that's $40K each 
revision.  Unless you are truly brilliant, it is going to take a BUNCH of 
respins of the part to get anything working.
> with an anticipated 50 to 100 CPU minimum, but that if I am able to create
> the industry I'm hoping to create (people who are willing to buy CPUs that
> are wrought of love, more than high-speed bells and whistles, looking to
> them as a utility to augment man's existence, rather than as a whizz bang
> eye candy newest fad ("gotta have the $12K iPhone 6 because my $10K iPhone
> 5 is just so last year") kind of thing).

Uhhh, I can imagine there will be at LEAST 5 customers for this.  How many 
shirts do you have?  Because you are certainly going to lose your shirt on 
this project!

Jon

Article: 158748
Subject: Re: Using an FPGA to drive the 80386 CPU on a real motherboard
From: rickman <gnuarm@gmail.com>
Date: Thu, 7 Apr 2016 02:40:21 -0400
Links: << >>  << T >>  << A >>
On 4/6/2016 5:05 PM, Jon Elson wrote:
> rickman wrote:
>
>
>> 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.
>>
> Xilinx also has he Spartan 3AN (N for non-volatile).  For a couple extra
> bucks, you can get get the flash memory built in.  Otherwise, their Spartan
> 3 family will download from a fariety of serial PROMS with no additional
> circuitry.  I've been using SST serial EPROMS for some time, they are
> something like $0.80 which seems pretty amazing.  They don't make them in
> DIP, however, so I have to make a little board about fingernail size so I
> can plug them in to the board.

Serial flash parts use extra board space and are a PITA to design in so 
you can program on the board.  The serial configuration of Xilinx parts 
is also rather slow in comparison to the boot time of a internal flash 
FPGA.  I believe it is something like two orders of magnitude faster. 
The Spartan 3AN is a bit of a joke in some respects, but if you are 
using Xilinx parts I guess that is what you get.  If it were a good 
idea, why do they only do that on the 10 year old Spartan 3A line?

-- 

Rick

Article: 158749
Subject: Re: Using an FPGA to drive the 80386 CPU on a real motherboard
From: rickman <gnuarm@gmail.com>
Date: Thu, 7 Apr 2016 02:42:24 -0400
Links: << >>  << T >>  << A >>
On 4/6/2016 4:41 PM, Rick C. Hodgin wrote:
> On Wednesday, April 6, 2016 at 4:38:20 PM UTC-4, rickman wrote:
>> On 4/6/2016 4:19 PM, Rick C. Hodgin wrote:
>>> 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.
>>
>> That jogged a recollection.  Once the internal speeds got faster they
>> added phase locked loops to use a slow external clock and a faster
>> internal clock.  These are no longer compatible with slow clocking.
>
> I believe that occurred on the 80486 and the DX/2, DX/3 (un-released),
> and DX/4 models.
>
> The 80387 co-processor has the ability to run dual clocks internally,
> which are governed in the range of 14:10 (I believe), but they don't
> have to run faster.  They can be locked and always run at the same
> speed.
>
>> Same is true of FPGAs if you use the internal PLL.  It will be fairly
>> simple to generate a variable speed clock to drive the CPU with.  Then
>> the FPGA can either work at that same rate, or resync the interface to a
>> fast internal clock which does not change rate.  It all depends on what
>> you are doing with the data once you get it and what your other
>> interfaces are.
>
> I had the idea that I would use the simulated clock output for an input
> trigger back into the FPGA for doing all monitoring/sampling.

If you are plugged into the mobo, I don't think you can source the 
clock.  That would work ok if the FPGA is emulating the mobo.

-- 

Rick



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search