Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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. HodginArticle: 158726
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. HodginArticle: 158727
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. HodginArticle: 158728
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. HodginArticle: 158729
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: 158730On 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. HodginArticle: 158731
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. -- RickArticle: 158732
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. HodginArticle: 158733
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: 158734On 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 -- RickArticle: 158735
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. -- RickArticle: 158736
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. -- RickArticle: 158737
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
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? :DArticle: 158739
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. -- RickArticle: 158740
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
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: 158742On 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. -- RickArticle: 158743
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. HodginArticle: 158744
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. JonArticle: 158745
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. JonArticle: 158746
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
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: 158748On 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? -- RickArticle: 158749
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:
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