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 Sunday, March 27, 2016 at 11:25:52 AM UTC-4, SJA wrote: > We need to interface 8 to 16 embedded USB 2.0 devices to an FPGA. >=20 > We could just use external ULPI transceivers but am wondering > what FPGAs have transceivers that are USB 2.0 compatible and if > the internal USB SIE gate count is low enough to make it cost > effective to wire the USB devices directly to the FPGA. (Would save > lots of pins ....) >=20 You'll probably find that it is not cost effective to use a full USB implem= entation inside an FPGA, unless it comes as hard logic already in the devic= e. If you use an external PHY, use something with a ULPI interface to mini= mize the pin count (12 pins if I recall correctly). If you can get by with a relatively 'slow for USB 2' speeds, you might be b= etter off using an external USB UART like this http://www.ftdichip.com/Prod= ucts/ICs/FT232R.htm from FTDI. The ones I've seen will top out at around 3= MBaud, but they are USB 2, the FPGA logic to support is trivial and you ha= ve a relatively small, simple interface to the part. Kevin JenningsArticle: 158701
Eric Smith wrote: > With Vivado 2015.4, I'm trying to add DDR3 memory to a Microblaze design. I add the Memory Interface Generator to the block diagram, and double-click on it to configure it. The windows that comes up says that "It is very important that the correct Vivado Project Options are selected", that Design Entry is set to VERILOG (sic), and "If any of these options are incorrect, please click on 'Cancel', change the Vivado Project Options, and restart MIG. However, the Vivado Project Options shows that my target language is VHDL.. What do I actually have to do to convince MIG that Design Entry is VHDL? You might want to ask this on the Xilinx forums. I know that in Vivado many cores no longer come with multi-language support, but I'm still working mainly with ISE so I'm not sure whether MIG is one of those. Basically what I'm saying is that some cores now support only Verilog and some support only VHDL. This can become a headache if you use a third-party simulator with single-language support. -- GaborArticle: 158702
KJ <kkjennings@sbcglobal.net> wrote: > You'll probably find that it is not cost effective to use a full USB > implementation inside an FPGA, unless it comes as hard logic already in > the device. If you use an external PHY, use something with a ULPI > interface to minimize the pin count (12 pins if I recall correctly). It's a bit of a headache because I'm not aware of any FPGAs with a hard USB MAC. There are commercial soft IP cores for USB, but I have no experience of them and suspect them to be large. I don't know of any FPGA vendors who provide their own USB IP. Maybe somebody does a relatively compact USB 1.1 MAC as a starting point? If you want to put the USB off-chip, there are few USB parts particularly friendly to FPGAs - most are expecting PCIe or similar. Currently we use the SAF1761 / ISP1761 but that feels like it's approaching end of line. > If you can get by with a relatively 'slow for USB 2' speeds, you might be > better off using an external USB UART like this > http://www.ftdichip.com/Products/ICs/FT232R.htm from FTDI. The ones I've > seen will top out at around 3 MBaud, but they are USB 2, the FPGA logic to > support is trivial and you have a relatively small, simple interface to > the part. Note the OP wants a USB host not a USB device part, so the above won't do. If a USB device is required, the problem is much easier: there's a variety of USB microcontrollers - the Cypress EZ-USB FX2 family (CY7C68013) is a popular choice. The other troublesome part is the software side: how much of an OS are you running on or near the FPGA? USB needs a substantial software stack, and most of the code out there for host controllers assumes a heavyweight OS. TheoArticle: 158703
SJA wrote: > We need to interface 8 to 16 embedded USB 2.0 devices to an FPGA. > > We could just use external ULPI transceivers but am wondering > what FPGAs have transceivers that are USB 2.0 compatible and if > the internal USB SIE gate count is low enough to make it cost > effective to wire the USB devices directly to the FPGA. (Would save > lots of pins ....) > > Any suggestions ? > > Xilinx Zynq parts have one USB 2.0 or 3.0 port. You'd still need to implement a hub off-chip to connect your peripherals. -- GaborArticle: 158704
GaborSzakacs <gabor@alacron.com> wrote: > Xilinx Zynq parts have one USB 2.0 or 3.0 port. You'd still need > to implement a hub off-chip to connect your peripherals. Likewise Altera's SoC parts. It does mean running Linux on the ARM for driver reasons. But that's probably the most sensible way to go if you really need an FPGA with USB host support. However the main issue is it limits you to a range of SoC silicon: there are Cyclone V and Arria V SoC parts, but no Stratix currently. Arria 10 SoC production silicon is on long lead time at the moment. TheoArticle: 158705
On 3/31/2016 6:16 AM, Theo Markettos wrote: > GaborSzakacs <gabor@alacron.com> wrote: >> Xilinx Zynq parts have one USB 2.0 or 3.0 port. You'd still need >> to implement a hub off-chip to connect your peripherals. > > Likewise Altera's SoC parts. It does mean running Linux on the ARM for > driver reasons. But that's probably the most sensible way to go if you > really need an FPGA with USB host support. > > However the main issue is it limits you to a range of SoC silicon: there are > Cyclone V and Arria V SoC parts, but no Stratix currently. Arria 10 SoC > production silicon is on long lead time at the moment. The Smart Fusion2 devices from Microsemi also support USB in hardware only requiring an external ULPI PHY. The processor is an ARM CM3 and does not require running Linux to use the USB. -- RickArticle: 158706
On Thu, 31 Mar 2016 11:16:32 +0100, Theo Markettos wrote: > GaborSzakacs <gabor@alacron.com> wrote: >> Xilinx Zynq parts have one USB 2.0 or 3.0 port. You'd still need to >> implement a hub off-chip to connect your peripherals. > > Likewise Altera's SoC parts. It does mean running Linux on the ARM for > driver reasons. But that's probably the most sensible way to go if you > really need an FPGA with USB host support. I've seen USB host software available as an add-on for embedded systems without Linux. That's the extent of my knowledge. It ought to work, and may be sensible if you just need a little dingus with USB host capabilities, and not a big machine. -- Tim Wescott Wescott Design Services http://www.wescottdesign.comArticle: 158707
Tim Wescott <seemywebsite@myfooter.really> wrote: > On Thu, 31 Mar 2016 11:16:32 +0100, Theo Markettos wrote: > > > GaborSzakacs <gabor@alacron.com> wrote: > >> Xilinx Zynq parts have one USB 2.0 or 3.0 port. You'd still need to > >> implement a hub off-chip to connect your peripherals. > > > > Likewise Altera's SoC parts. It does mean running Linux on the ARM for > > driver reasons. But that's probably the most sensible way to go if you > > really need an FPGA with USB host support. > > I've seen USB host software available as an add-on for embedded systems > without Linux. > > That's the extent of my knowledge. It ought to work, and may be sensible > if you just need a little dingus with USB host capabilities, and not a > big machine. The reason it's nontrivial is the IP cores used are typically complex, and the driver stack assumes a full-fat OS (threading, virtual memory, DMA etc). If you have a simple IP core, it's possible to write simple software. With a complex IP core it is possible to stray 'off piste' and write your own software, but that depends on the vendor providing documentation. In the case of the Synopsys core used on the Cyclone V SoC, which happens to be the same core as the Raspberry Pi, the core documentation is very confidential. A few people have reverse engineered it, but every OS I know about uses the Synopsys driver - which is 40K LOC. I didn't look into it much, but the Smartfusion OTG core rickman mentioned looks simpler and seems like a much better fit. TheoArticle: 158708
On 4/4/2016 8:24 PM, Theo Markettos wrote: > Tim Wescott <seemywebsite@myfooter.really> wrote: >> On Thu, 31 Mar 2016 11:16:32 +0100, Theo Markettos wrote: >> >>> GaborSzakacs <gabor@alacron.com> wrote: >>>> Xilinx Zynq parts have one USB 2.0 or 3.0 port. You'd still need to >>>> implement a hub off-chip to connect your peripherals. >>> >>> Likewise Altera's SoC parts. It does mean running Linux on the ARM for >>> driver reasons. But that's probably the most sensible way to go if you >>> really need an FPGA with USB host support. >> >> I've seen USB host software available as an add-on for embedded systems >> without Linux. >> >> That's the extent of my knowledge. It ought to work, and may be sensible >> if you just need a little dingus with USB host capabilities, and not a >> big machine. > > The reason it's nontrivial is the IP cores used are typically complex, and > the driver stack assumes a full-fat OS (threading, virtual memory, DMA etc). > > If you have a simple IP core, it's possible to write simple software. With > a complex IP core it is possible to stray 'off piste' and write your own > software, but that depends on the vendor providing documentation. In the > case of the Synopsys core used on the Cyclone V SoC, which happens to be the > same core as the Raspberry Pi, the core documentation is very confidential. > A few people have reverse engineered it, but every OS I know about uses the > Synopsys driver - which is 40K LOC. What confidential info in the rPi core? My understanding is that the GPU has proprietary aspects, but the core is ARM which is fully documented. Do I not understand this properly? > I didn't look into it much, but the Smartfusion OTG core rickman mentioned > looks simpler and seems like a much better fit. I can't say for sure, I have not tried working with the USB on the SmartFusion2 yet. -- RickArticle: 158709
rickman <gnuarm@gmail.com> wrote: > What confidential info in the rPi core? My understanding is that the > GPU has proprietary aspects, but the core is ARM which is fully > documented. Do I not understand this properly? We're talking peripheral IP cores. The Pi has a bunch of IP from third party vendors - Synopsys (USB), Arasan (SDHCI), maybe others (DDR2 controller?). Those are proprietary and documentation is not public. (though the SD core mostly obeys the SDHCI spec so is less of an issue) Any SoC is much more than the CPU, and it's the I/O where it always gets messy. TheoArticle: 158710
On 4/5/2016 7:07 AM, Theo Markettos wrote: > rickman <gnuarm@gmail.com> wrote: >> What confidential info in the rPi core? My understanding is that the >> GPU has proprietary aspects, but the core is ARM which is fully >> documented. Do I not understand this properly? > > We're talking peripheral IP cores. The Pi has a bunch of IP from third > party vendors - Synopsys (USB), Arasan (SDHCI), maybe others (DDR2 > controller?). Those are proprietary and documentation is not public. > (though the SD core mostly obeys the SDHCI spec so is less of an issue) > > Any SoC is much more than the CPU, and it's the I/O where it always gets > messy. I thought specifically this was about using the USB port. Are you saying the USB port on the rPi is not fully documented? Like I said, my understanding is that the only portion of the rPi processor (the original rPi, I haven't discussed the new rPi 2 or 3 processors with anyone) that is not fully documented (that means as well as anyone ever documents complex cores) is the GPU. This has been discussed widely about the rPi and I'm sure it would have been brought up if any other portions were not fully documented. -- RickArticle: 158711
Hello all. I'm looking for some information about Altera's FPGA. I have
this Cyclone V GX dev board:
https://www.altera.com/products/boards_and_kits/dev-kits/partners/kit-terasic-cyclone-v-gx-starter.html
It has a 160-pin HSMC connector, which connects using this flexible cable:
https://www.altera.com/en_US/pdfs/literature/ds/hsmc_spec.pdf
http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&No=275
I'm wondering if this connector can be used for general purpose off-board
communication for custom uses outside of connecting to other Mezzanine
boards? Could I, for example, connect some wires to the pins and signal
them independently for GPIO?
Or... is this cable interface something proprietary that only allows
interconnect between Mezzanine devices?
Best regards,
Rick C. Hodgin
Article: 158712Rick C. Hodgin wrote: > Hello all. I'm looking for some information about Altera's FPGA. I have > this Cyclone V GX dev board: > > https://www.altera.com/products/boards_and_kits/dev-kits/partners/kit-terasic-cyclone-v-gx-starter.html > > It has a 160-pin HSMC connector, which connects using this flexible cable: > > https://www.altera.com/en_US/pdfs/literature/ds/hsmc_spec.pdf > http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&No=275 > > I'm wondering if this connector can be used for general purpose off-board > communication for custom uses outside of connecting to other Mezzanine > boards? Could I, for example, connect some wires to the pins and signal > them independently for GPIO? > > Or... is this cable interface something proprietary that only allows > interconnect between Mezzanine devices? > > Best regards, > Rick C. Hodgin It's a bit of a pain as connectors go. http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=67&No=322&PartNo=1 makes a convenient breakout. You want the (M), to mate the dev kit, not the (F). -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.Article: 158713
On Tuesday, April 5, 2016 at 2:53:15 PM UTC-4, Rob Gaddi wrote: > Rick C. Hodgin wrote: > > Hello all. I'm looking for some information about Altera's FPGA. I have > > this Cyclone V GX dev board: > > > > https://www.altera.com/products/boards_and_kits/dev-kits/partners/kit-terasic-cyclone-v-gx-starter.html > > > > It has a 160-pin HSMC connector, which connects using this flexible cable: > > > > https://www.altera.com/en_US/pdfs/literature/ds/hsmc_spec.pdf > > http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&No=275 > > > > I'm wondering if this connector can be used for general purpose off-board > > communication for custom uses outside of connecting to other Mezzanine > > boards? Could I, for example, connect some wires to the pins and signal > > them independently for GPIO? > > > > Or... is this cable interface something proprietary that only allows > > interconnect between Mezzanine devices? > > It's a bit of a pain as connectors go. > http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=67&No=322&PartNo=1 makes a convenient breakout. You want the (M), to mate the dev kit, not the (F). > > -- > Rob Gaddi, Highland Technology -- www.highlandtechnology.com Thank you, Rob. That's exactly what I was looking for. Best regards, Rick C. HodginArticle: 158714
I have a desire to create an 80386 CPU in FPGA form, one which will plug in to the 132-pin socket of existing 80386 motherboard as a replacement CPU. I want to be able to provide the features of the 80386 on that machine, but through my FPGA, to then allow me to extend the ISA to include other instructions and abilities. Does anybody have an experience or advice in creating an FPGA-based CPU that connects to a real hardware device and simulates the real device's abilities? For example, the 80386 uses 5V and the Altera board I have drives 1.xV and 3.3V max, so I'd have to use a level converter. At speeds up to a max of 40 MHz, would there be any issues? Also, I'd like to create a "monitor board," which is a board with a 132- pin male socket connecting to the CPU on one side, and a 132-pin female socket on the other side to which a real 80386 CPU would connect, and then to be able to pull signals off the wires between the CPU socket and the CPU itself. I had assumed I would use opto-isolation for this, but I don't know if it would work or be best. In addition, and specific to the 80386 CPU, AMD manufactured an Am386 CPU that is 100% compatible with the Intel 80386, but it has the ability to underclock down to even 0 MHz in a standby mode (allowing it to consume only 0.001 Watts). I'm wondering if anyone has any experience underclocking an 80386 motherboard down into the KHz range, or even Hz range, and if it would still work at those slow speeds on the board? My goals in slowing down the CPU are to detect and isolate timing protocols, which I can then scale up to higher speeds once identified. In any event, any help or advice is appreciated. Thank you. Best regards, Rick C. HodginArticle: 158715
On Tuesday, April 5, 2016 at 3:03:53 PM UTC-4, Rick C. Hodgin wrote: > On Tuesday, April 5, 2016 at 2:53:15 PM UTC-4, Rob Gaddi wrote: > > Rick C. Hodgin wrote: > > > Hello all. I'm looking for some information about Altera's FPGA. I have > > > this Cyclone V GX dev board: > > > > > > https://www.altera.com/products/boards_and_kits/dev-kits/partners/kit-terasic-cyclone-v-gx-starter.html > > > > > > It has a 160-pin HSMC connector, which connects using this flexible cable: > > > > > > https://www.altera.com/en_US/pdfs/literature/ds/hsmc_spec.pdf > > > http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&No=275 > > > > > > I'm wondering if this connector can be used for general purpose off-board > > > communication for custom uses outside of connecting to other Mezzanine > > > boards? Could I, for example, connect some wires to the pins and signal > > > them independently for GPIO? > > > > > > Or... is this cable interface something proprietary that only allows > > > interconnect between Mezzanine devices? > > > > It's a bit of a pain as connectors go. > > http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=67&No=322&PartNo=1 makes a convenient breakout. You want the (M), to mate the dev kit, not the (F). > > > > -- > > Rob Gaddi, Highland Technology -- www.highlandtechnology.com > > Thank you, Rob. That's exactly what I was looking for. Ordered. Thank you again. Best regards, Rick C. HodginArticle: 158716
rickman <gnuarm@gmail.com> wrote: > I thought specifically this was about using the USB port. Are you > saying the USB port on the rPi is not fully documented? Yes. (Not publically anyway) > Like I said, my understanding is that the only portion of the rPi > processor (the original rPi, I haven't discussed the new rPi 2 or 3 > processors with anyone) that is not fully documented (that means as well > as anyone ever documents complex cores) is the GPU. That is incorrect. This is a misapprehension because most people are running Linux, and Linux has drivers for these peripherals, so they don't care. It only comes to bite you when you want to write drivers for an OS (or lack of OS) that isn't Linux. The situation with the Pi is actually somewhat better than that because a) the Arasan core is (more or less) SDHCI, which is a documented standard even if this particular core isn't. The next usual problem then relates to clocks, resets and power control which are frequently controlled external to an IP core (so not in its documentation), quite often by a pile of GPIOs in a dark corner. In this case the GPU handles those so we just use its API (config.txt or mailbox) and don't have to worry. But it's not the same as understanding what it's doing inside. Theo (who notes that ability to cut and paste random IP into an SoC frequently makes for a mess that software people have to deal with)Article: 158717
On 4/5/2016 3:15 PM, Rick C. Hodgin wrote: > I have a desire to create an 80386 CPU in FPGA form, one which will plug in > to the 132-pin socket of existing 80386 motherboard as a replacement CPU. I > want to be able to provide the features of the 80386 on that machine, but > through my FPGA, to then allow me to extend the ISA to include other > instructions and abilities. > > Does anybody have an experience or advice in creating an FPGA-based CPU that > connects to a real hardware device and simulates the real device's abilities? > > For example, the 80386 uses 5V and the Altera board I have drives 1.xV and > 3.3V max, so I'd have to use a level converter. At speeds up to a max of > 40 MHz, would there be any issues? Even at 40 MHz you will need to be tidy with your routing to keep the signals from ringing, etc. I don't know the details of the 386 chip I/O specs, but quickswitch type parts will do a good job of level shifting between 3.33 and 5 volts without adding much delay. Because the signal passes between the source and drain there is very little delay. They don't pull up to 5 volts, but 5 volt logic usually only need 2.x volts anyway. But you'll need to check the parts you are interfacing to on the mother board or just give it a wing. You can add pullups on the 5 volt side, but pullups tend to be slow. Even a few ns of added delay can cause a 386 not to work. Many of the early mobos had timing issues because of the TTL logic used. I don't think 386 mobos had chip sets in place of the TTL, did they? > Also, I'd like to create a "monitor board," which is a board with a 132- > pin male socket connecting to the CPU on one side, and a 132-pin female > socket on the other side to which a real 80386 CPU would connect, and then > to be able to pull signals off the wires between the CPU socket and the > CPU itself. I had assumed I would use opto-isolation for this, but I don't > know if it would work or be best. Opto-isolation is pretty slow compared to 40 MHz, but maybe there are faster converters these days. Why do you need isolation? > In addition, and specific to the 80386 CPU, AMD manufactured an Am386 CPU > that is 100% compatible with the Intel 80386, but it has the ability to > underclock down to even 0 MHz in a standby mode (allowing it to consume > only 0.001 Watts). I'm wondering if anyone has any experience underclocking > an 80386 motherboard down into the KHz range, or even Hz range, and if it > would still work at those slow speeds on the board? No experience, but the parts that would give trouble at slow clocks were the NMOS devices that went out long before the 386. Certainly TTL and CMOS don't normally have a problem with slow clocking. > My goals in slowing down the CPU are to detect and isolate timing protocols, > which I can then scale up to higher speeds once identified. > > In any event, any help or advice is appreciated. Thank you. I have a book somewhere on the ISA bus with timing info. ISA was never fully specified. I think there was an effort to produce a spec, but it got canned and retracted at some point. You can't even find draft versions of it now. But that was more of an 8086/80286 thing. I'm not sure the ISA bus was still mapped directly to the 386 bus. I just don't remember. -- RickArticle: 158718
On 4/5/2016 4:06 PM, Theo Markettos wrote: > rickman <gnuarm@gmail.com> wrote: >> I thought specifically this was about using the USB port. Are you >> saying the USB port on the rPi is not fully documented? > > Yes. (Not publically anyway) > >> Like I said, my understanding is that the only portion of the rPi >> processor (the original rPi, I haven't discussed the new rPi 2 or 3 >> processors with anyone) that is not fully documented (that means as well >> as anyone ever documents complex cores) is the GPU. > > That is incorrect. This is a misapprehension because most people are > running Linux, and Linux has drivers for these peripherals, so they don't > care. It only comes to bite you when you want to write drivers for an OS > (or lack of OS) that isn't Linux. The issue was open source software. The drivers for the GPU were binary. If the drives for any other part of the chip were binary I'm sure it would have come up. > The situation with the Pi is actually somewhat better than that because a) > the Arasan core is (more or less) SDHCI, which is a documented standard even > if this particular core isn't. The next usual problem then relates to > clocks, resets and power control which are frequently controlled external > to an IP core (so not in its documentation), quite often by a pile of GPIOs > in a dark corner. In this case the GPU handles those so we just use its API > (config.txt or mailbox) and don't have to worry. But it's not the same as > understanding what it's doing inside. What part of the CPU chip on the rPi is not documented in the manual? It is large and I have not read it all of course, but I'm sure I would have heard in these discussions if there were any other part than the GPU that was driven by closed source code. > Theo > (who notes that ability to cut and paste random IP into an SoC frequently > makes for a mess that software people have to deal with) > -- RickArticle: 158719
On Tuesday, April 5, 2016 at 4:13:28 PM UTC-4, rickman wrote:
> On 4/5/2016 3:15 PM, Rick C. Hodgin wrote:
> > In addition, and specific to the 80386 CPU, AMD manufactured an Am386 CPU
> > that is 100% compatible with the Intel 80386, but it has the ability to
> > underclock down to even 0 MHz in a standby mode (allowing it to consume
> > only 0.001 Watts). I'm wondering if anyone has any experience underclocking
> > an 80386 motherboard down into the KHz range, or even Hz range, and if it
> > would still work at those slow speeds on the board?
>
> No experience, but the parts that would give trouble at slow clocks were
> the NMOS devices that went out long before the 386. Certainly TTL and
> CMOS don't normally have a problem with slow clocking.
I assume the entire system is clocked off the single source? So, would it
be as simple as removing the crystal circuit and replacing it with a soft
circuit operating at the same frequency driven from an FPGA output? And
then taking the FPGA output and bringing it down slowly to underclock the
system?
I have two standard 80386 motherboards, and one 80386 motherboard with an
expansion socket. I also have an 80486 motherboard with an i80486DX, and
two Pentium motherboards, 33 MHz and 60 MHz I believe.
Here's an online image I found which matches the 80386 I'm interested in
underlcocking:
http://www.armanax.com/placa-base-m321-rev-2-5.html
It has an 80 MHz timing circuit, as the clock speed for the 80386s were
always double-pumped.
I want to get a case, power supply, VGA and MDA setup on it. I have a
custom 80386 OS I wrote that I'll use for bootup and testing (loads
from a floppy disk). I would write a simple test algorithm that does
some screen output, processes keystrokes, mouse movement, etc., and
have that test running as it's underclocked... assuming I'm on the
right path.
Best regards,
Rick C. Hodgin
Article: 158720On Tuesday, April 5, 2016 at 4:13:28 PM UTC-4, rickman wrote: > On 4/5/2016 3:15 PM, Rick C. Hodgin wrote: > > I have a desire to create an 80386 CPU in FPGA form, one which will plug in > > to the 132-pin socket of existing 80386 motherboard as a replacement CPU. I > > want to be able to provide the features of the 80386 on that machine, but > > through my FPGA, to then allow me to extend the ISA to include other > > instructions and abilities. > > > > Does anybody have an experience or advice in creating an FPGA-based CPU that > > connects to a real hardware device and simulates the real device's abilities? > > > > For example, the 80386 uses 5V and the Altera board I have drives 1.xV and > > 3.3V max, so I'd have to use a level converter. At speeds up to a max of > > 40 MHz, would there be any issues? > > Even at 40 MHz you will need to be tidy with your routing to keep the > signals from ringing, etc. If I can get the machine underclocked, I'd like to bring it down into the low KHz or even Hz range if possible, but something 100 KHz or lower at least. I envision the Cyclone V GX being mounted a couple inches above the 80386 socket. I would use the HSMC to GPIO port to connect to the CPU socket. I had considered at first using the co-processor socket and emulating the 80387 ISA at first. I may still do that, but regardless, there are only 90 pins that are active on the 80386, and 64 of those are direct address and data pins, with another 20 being control pins for when those lines are active, and in what mode they're active. There really isn't much logic involved in hooking up an 80386, which is why I'm attempting this project. To be honest, I wouldn't even mind dipping back down to a 4.77 MHz 8086 system and starting there as part of the ISA I'll support for the 80386 contains a full 8086 subset. > I don't know the details of the 386 chip I/O > specs, but quickswitch type parts will do a good job of level shifting > between 3.33 and 5 volts without adding much delay. Because the signal > passes between the source and drain there is very little delay. They > don't pull up to 5 volts, but 5 volt logic usually only need 2.x volts > anyway. But you'll need to check the parts you are interfacing to on > the mother board or just give it a wing. You can add pullups on the 5 > volt side, but pullups tend to be slow. Even a few ns of added delay > can cause a 386 not to work. Many of the early mobos had timing issues > because of the TTL logic used. Excellent information, thank you. > I don't think 386 mobos had chip sets in place of the TTL, did they? Not originally, but later on. These motherboards were manufactured in the early 90s, and came with Am386 CPUs manufactured in 91 or 92. I believe the boards I have had switched to chip sets by then. > > Also, I'd like to create a "monitor board," which is a board with a 132- > > pin male socket connecting to the CPU on one side, and a 132-pin female > > socket on the other side to which a real 80386 CPU would connect, and then > > to be able to pull signals off the wires between the CPU socket and the > > CPU itself. I had assumed I would use opto-isolation for this, but I don't > > know if it would work or be best. > > Opto-isolation is pretty slow compared to 40 MHz, but maybe there are > faster converters these days. Why do you need isolation? I may not need it. However, when I was working on stepper motors back in the mid-90s, I believe we used them to maintain a low power draw on the circuits we were monitoring. > > In addition, and specific to the 80386 CPU, AMD manufactured an Am386 CPU > > that is 100% compatible with the Intel 80386, but it has the ability to > > underclock down to even 0 MHz in a standby mode (allowing it to consume > > only 0.001 Watts). I'm wondering if anyone has any experience underclocking > > an 80386 motherboard down into the KHz range, or even Hz range, and if it > > would still work at those slow speeds on the board? > > No experience, but the parts that would give trouble at slow clocks were > the NMOS devices that went out long before the 386. Certainly TTL and > CMOS don't normally have a problem with slow clocking. From what I've read, Intel's 80386 CPUs would not clock below 10 MHz well. But AMD's would clock down to any clock speed including 0 MHz. It's why I've wanted to try to target these systems which came with the Am386 CPU, for their underclocking abilities. > > My goals in slowing down the CPU are to detect and isolate timing protocols, > > which I can then scale up to higher speeds once identified. > > > > In any event, any help or advice is appreciated. Thank you. > > I have a book somewhere on the ISA bus with timing info. ISA was never > fully specified. I think there was an effort to produce a spec, but it > got canned and retracted at some point. You can't even find draft > versions of it now. But that was more of an 8086/80286 thing. I'm not > sure the ISA bus was still mapped directly to the 386 bus. I just don't > remember. IIRC, it operated at 4.77 MHz for 8-bit bus, and 6 MHz or 8 MHz for the 16-bit bus. I don't know if that speed is required, or if it's the standard clock speed when the system was operating at its normal clock speed as would be setup by early BIOS during boot. I assume once it boots up, the entire system can be overclocked or underclocked by altering the frequency emitted by the clock circuit, and the whole system would rise and fall in relative speed parity. Just a guess though. Best regards, Rick C. HodginArticle: 158721
On 4/5/2016 5:11 PM, Rick C. Hodgin wrote: > On Tuesday, April 5, 2016 at 4:13:28 PM UTC-4, rickman wrote: >> On 4/5/2016 3:15 PM, Rick C. Hodgin wrote: >>> I have a desire to create an 80386 CPU in FPGA form, one which will plug in >>> to the 132-pin socket of existing 80386 motherboard as a replacement CPU. I >>> want to be able to provide the features of the 80386 on that machine, but >>> through my FPGA, to then allow me to extend the ISA to include other >>> instructions and abilities. >>> >>> Does anybody have an experience or advice in creating an FPGA-based CPU that >>> connects to a real hardware device and simulates the real device's abilities? >>> >>> For example, the 80386 uses 5V and the Altera board I have drives 1.xV and >>> 3.3V max, so I'd have to use a level converter. At speeds up to a max of >>> 40 MHz, would there be any issues? >> >> Even at 40 MHz you will need to be tidy with your routing to keep the >> signals from ringing, etc. > > If I can get the machine underclocked, I'd like to bring it down into the > low KHz or even Hz range if possible, but something 100 KHz or lower at > least. Running with a slow clock doesn't assure a lack of problems from edge rates. The edges usually are still just as fast and that is what creates problems. > I envision the Cyclone V GX being mounted a couple inches above the 80386 > socket. I would use the HSMC to GPIO port to connect to the CPU socket. I don't know about the HSMC port, but I don't think you need anything special for a 40 MHz interface. > I had considered at first using the co-processor socket and emulating the > 80387 ISA at first. I may still do that, but regardless, there are only > 90 pins that are active on the 80386, and 64 of those are direct address > and data pins, with another 20 being control pins for when those lines > are active, and in what mode they're active. > > There really isn't much logic involved in hooking up an 80386, which is > why I'm attempting this project. > > To be honest, I wouldn't even mind dipping back down to a 4.77 MHz 8086 > system and starting there as part of the ISA I'll support for the 80386 > contains a full 8086 subset. > >> I don't know the details of the 386 chip I/O >> specs, but quickswitch type parts will do a good job of level shifting >> between 3.33 and 5 volts without adding much delay. Because the signal >> passes between the source and drain there is very little delay. They >> don't pull up to 5 volts, but 5 volt logic usually only need 2.x volts >> anyway. But you'll need to check the parts you are interfacing to on >> the mother board or just give it a wing. You can add pullups on the 5 >> volt side, but pullups tend to be slow. Even a few ns of added delay >> can cause a 386 not to work. Many of the early mobos had timing issues >> because of the TTL logic used. > > Excellent information, thank you. > >> I don't think 386 mobos had chip sets in place of the TTL, did they? > > Not originally, but later on. These motherboards were manufactured in > the early 90s, and came with Am386 CPUs manufactured in 91 or 92. I > believe the boards I have had switched to chip sets by then. I recall that because there was no "standard" for the design of the motherboard other than what IBM had done, there were some differences between the various chip sets. In those days they *were* chip sets as the whole shebang didn't end up in one chip like was used later and still called a "chip set". lol >>> Also, I'd like to create a "monitor board," which is a board with a 132- >>> pin male socket connecting to the CPU on one side, and a 132-pin female >>> socket on the other side to which a real 80386 CPU would connect, and then >>> to be able to pull signals off the wires between the CPU socket and the >>> CPU itself. I had assumed I would use opto-isolation for this, but I don't >>> know if it would work or be best. >> >> Opto-isolation is pretty slow compared to 40 MHz, but maybe there are >> faster converters these days. Why do you need isolation? > > I may not need it. However, when I was working on stepper motors back > in the mid-90s, I believe we used them to maintain a low power draw on > the circuits we were monitoring. Optos are the opposite of low power draw on busses. Enough current is required to drive an LED on the sensing side. Optos are typically used to provide isolation from circuits that can have ground swings or otherwise be noisy or have high voltage spikes, like motor circuits. >>> In addition, and specific to the 80386 CPU, AMD manufactured an Am386 CPU >>> that is 100% compatible with the Intel 80386, but it has the ability to >>> underclock down to even 0 MHz in a standby mode (allowing it to consume >>> only 0.001 Watts). I'm wondering if anyone has any experience underclocking >>> an 80386 motherboard down into the KHz range, or even Hz range, and if it >>> would still work at those slow speeds on the board? >> >> No experience, but the parts that would give trouble at slow clocks were >> the NMOS devices that went out long before the 386. Certainly TTL and >> CMOS don't normally have a problem with slow clocking. > > From what I've read, Intel's 80386 CPUs would not clock below 10 MHz well. > But AMD's would clock down to any clock speed including 0 MHz. It's why > I've wanted to try to target these systems which came with the Am386 CPU, > for their underclocking abilities. I've forgotten more than I knew, lol. That may be accurate. I know the original NMOS circuits used dynamic circuits where values were remembered on capacitance and so had minimum clock rates. Maybe even on CMOS designs they did the same thing. >>> My goals in slowing down the CPU are to detect and isolate timing protocols, >>> which I can then scale up to higher speeds once identified. >>> >>> In any event, any help or advice is appreciated. Thank you. >> >> I have a book somewhere on the ISA bus with timing info. ISA was never >> fully specified. I think there was an effort to produce a spec, but it >> got canned and retracted at some point. You can't even find draft >> versions of it now. But that was more of an 8086/80286 thing. I'm not >> sure the ISA bus was still mapped directly to the 386 bus. I just don't >> remember. > > IIRC, it operated at 4.77 MHz for 8-bit bus, and 6 MHz or 8 MHz for the > 16-bit bus. I don't know if that speed is required, or if it's the > standard clock speed when the system was operating at its normal clock > speed as would be setup by early BIOS during boot. I assume once it boots > up, the entire system can be overclocked or underclocked by altering the > frequency emitted by the clock circuit, and the whole system would rise > and fall in relative speed parity. Just a guess though. It's not actually a synchronous bus. Everything is timed by the read and write strobes with some other signals helping to control data directions on buffers. It started with the 8088 I/O bus controls and remained compatible I believe, but I'm not sure. If you don't mind stretching the cycles a bit it can be run synchronously. I'll see if I can find that book. -- RickArticle: 158722
On Tuesday, April 5, 2016 at 9:22:32 PM UTC-4, rickman wrote: > On 4/5/2016 5:11 PM, Rick C. Hodgin wrote: > > On Tuesday, April 5, 2016 at 4:13:28 PM UTC-4, rickman wrote: > >> On 4/5/2016 3:15 PM, Rick C. Hodgin wrote: > >>> I have a desire to create an 80386 CPU in FPGA form, one which will plug in > >>> to the 132-pin socket of existing 80386 motherboard as a replacement CPU. I > >>> want to be able to provide the features of the 80386 on that machine, but > >>> through my FPGA, to then allow me to extend the ISA to include other > >>> instructions and abilities. > >>> > >>> Does anybody have an experience or advice in creating an FPGA-based CPU that > >>> connects to a real hardware device and simulates the real device's abilities? > >>> > >>> For example, the 80386 uses 5V and the Altera board I have drives 1.xV and > >>> 3.3V max, so I'd have to use a level converter. At speeds up to a max of > >>> 40 MHz, would there be any issues? > >> > >> Even at 40 MHz you will need to be tidy with your routing to keep the > >> signals from ringing, etc. > > > > If I can get the machine underclocked, I'd like to bring it down into the > > low KHz or even Hz range if possible, but something 100 KHz or lower at > > least. > > Running with a slow clock doesn't assure a lack of problems from edge > rates. The edges usually are still just as fast and that is what > creates problems. > > > > I envision the Cyclone V GX being mounted a couple inches above the 80386 > > socket. I would use the HSMC to GPIO port to connect to the CPU socket. > > I don't know about the HSMC port, but I don't think you need anything > special for a 40 MHz interface. > > > > I had considered at first using the co-processor socket and emulating the > > 80387 ISA at first. I may still do that, but regardless, there are only > > 90 pins that are active on the 80386, and 64 of those are direct address > > and data pins, with another 20 being control pins for when those lines > > are active, and in what mode they're active. > > > > There really isn't much logic involved in hooking up an 80386, which is > > why I'm attempting this project. > > > > To be honest, I wouldn't even mind dipping back down to a 4.77 MHz 8086 > > system and starting there as part of the ISA I'll support for the 80386 > > contains a full 8086 subset. > > > >> I don't know the details of the 386 chip I/O > >> specs, but quickswitch type parts will do a good job of level shifting > >> between 3.33 and 5 volts without adding much delay. Because the signal > >> passes between the source and drain there is very little delay. They > >> don't pull up to 5 volts, but 5 volt logic usually only need 2.x volts > >> anyway. But you'll need to check the parts you are interfacing to on > >> the mother board or just give it a wing. You can add pullups on the 5 > >> volt side, but pullups tend to be slow. Even a few ns of added delay > >> can cause a 386 not to work. Many of the early mobos had timing issues > >> because of the TTL logic used. > > > > Excellent information, thank you. > > > >> I don't think 386 mobos had chip sets in place of the TTL, did they? > > > > Not originally, but later on. These motherboards were manufactured in > > the early 90s, and came with Am386 CPUs manufactured in 91 or 92. I > > believe the boards I have had switched to chip sets by then. > > I recall that because there was no "standard" for the design of the > motherboard other than what IBM had done, there were some differences > between the various chip sets. In those days they *were* chip sets as > the whole shebang didn't end up in one chip like was used later and > still called a "chip set". lol > > > >>> Also, I'd like to create a "monitor board," which is a board with a 132- > >>> pin male socket connecting to the CPU on one side, and a 132-pin female > >>> socket on the other side to which a real 80386 CPU would connect, and then > >>> to be able to pull signals off the wires between the CPU socket and the > >>> CPU itself. I had assumed I would use opto-isolation for this, but I don't > >>> know if it would work or be best. > >> > >> Opto-isolation is pretty slow compared to 40 MHz, but maybe there are > >> faster converters these days. Why do you need isolation? > > > > I may not need it. However, when I was working on stepper motors back > > in the mid-90s, I believe we used them to maintain a low power draw on > > the circuits we were monitoring. > > Optos are the opposite of low power draw on busses. Enough current is > required to drive an LED on the sensing side. Optos are typically used > to provide isolation from circuits that can have ground swings or > otherwise be noisy or have high voltage spikes, like motor circuits. > > > >>> In addition, and specific to the 80386 CPU, AMD manufactured an Am386 CPU > >>> that is 100% compatible with the Intel 80386, but it has the ability to > >>> underclock down to even 0 MHz in a standby mode (allowing it to consume > >>> only 0.001 Watts). I'm wondering if anyone has any experience underclocking > >>> an 80386 motherboard down into the KHz range, or even Hz range, and if it > >>> would still work at those slow speeds on the board? > >> > >> No experience, but the parts that would give trouble at slow clocks were > >> the NMOS devices that went out long before the 386. Certainly TTL and > >> CMOS don't normally have a problem with slow clocking. > > > > From what I've read, Intel's 80386 CPUs would not clock below 10 MHz well. > > But AMD's would clock down to any clock speed including 0 MHz. It's why > > I've wanted to try to target these systems which came with the Am386 CPU, > > for their underclocking abilities. > > I've forgotten more than I knew, lol. That may be accurate. I know the > original NMOS circuits used dynamic circuits where values were > remembered on capacitance and so had minimum clock rates. Maybe even on > CMOS designs they did the same thing. > > > >>> My goals in slowing down the CPU are to detect and isolate timing protocols, > >>> which I can then scale up to higher speeds once identified. > >>> > >>> In any event, any help or advice is appreciated. Thank you. > >> > >> I have a book somewhere on the ISA bus with timing info. ISA was never > >> fully specified. I think there was an effort to produce a spec, but it > >> got canned and retracted at some point. You can't even find draft > >> versions of it now. But that was more of an 8086/80286 thing. I'm not > >> sure the ISA bus was still mapped directly to the 386 bus. I just don't > >> remember. > > > > IIRC, it operated at 4.77 MHz for 8-bit bus, and 6 MHz or 8 MHz for the > > 16-bit bus. I don't know if that speed is required, or if it's the > > standard clock speed when the system was operating at its normal clock > > speed as would be setup by early BIOS during boot. I assume once it boots > > up, the entire system can be overclocked or underclocked by altering the > > frequency emitted by the clock circuit, and the whole system would rise > > and fall in relative speed parity. Just a guess though. > > It's not actually a synchronous bus. Everything is timed by the read > and write strobes with some other signals helping to control data > directions on buffers. It started with the 8088 I/O bus controls and > remained compatible I believe, but I'm not sure. If you don't mind > stretching the cycles a bit it can be run synchronously. I'll see if I > can find that book. > > -- > > Rick Alright ... suppose I target this from another angle. What if I take the CPU completely off the 80386 motherboard, and create a custom socket connected to my FPGA, and I provide it with everything it requires? The Am386 CPUs operated at speeds from 0 MHz to 40 MHz. Since they can actually clock at any speed, I could take the CPU completely away from the peculiar and bizarre 80386 motherboard design, and instead provide the facilities which basically allow the FPGA to be its motherboard, feeding it whatever it's required. Possible? BTW, if I haven't said so you, I greatly appreciate your assistance and advice. It is very kind of you to help me in this way, and much, very much appreciated. Best regards, Rick C. HodginArticle: 158723
On 4/5/2016 10:47 PM, Rick C. Hodgin wrote: > > Alright ... suppose I target this from another angle. What if I take > the CPU completely off the 80386 motherboard, and create a custom socket > connected to my FPGA, and I provide it with everything it requires? > > The Am386 CPUs operated at speeds from 0 MHz to 40 MHz. Since they can > actually clock at any speed, I could take the CPU completely away from the peculiar and bizarre 80386 motherboard design, and instead provide the > facilities which basically allow the FPGA to be its motherboard, feeding > it whatever it's required. > > Possible? Sure. Booting one of these things may be a bit complicated, but not likely any worse than booting a modern high end ARM processor. Likely a lot easier. > BTW, if I haven't said so you, I greatly appreciate your assistance and > advice. It is very kind of you to help me in this way, and much, very > much appreciated. No problem. This an interesting if not mysterious project. -- RickArticle: 158724
On 05/04/16 21:15, Rick C. Hodgin wrote: > I have a desire to create an 80386 CPU in FPGA form, one which will plug in > to the 132-pin socket of existing 80386 motherboard as a replacement CPU. I > want to be able to provide the features of the 80386 on that machine, but > through my FPGA, to then allow me to extend the ISA to include other > instructions and abilities. > > Does anybody have an experience or advice in creating an FPGA-based CPU that > connects to a real hardware device and simulates the real device's abilities? > > For example, the 80386 uses 5V and the Altera board I have drives 1.xV and > 3.3V max, so I'd have to use a level converter. At speeds up to a max of > 40 MHz, would there be any issues? > > Also, I'd like to create a "monitor board," which is a board with a 132- > pin male socket connecting to the CPU on one side, and a 132-pin female > socket on the other side to which a real 80386 CPU would connect, and then > to be able to pull signals off the wires between the CPU socket and the > CPU itself. I had assumed I would use opto-isolation for this, but I don't > know if it would work or be best. > > In addition, and specific to the 80386 CPU, AMD manufactured an Am386 CPU > that is 100% compatible with the Intel 80386, but it has the ability to > underclock down to even 0 MHz in a standby mode (allowing it to consume > only 0.001 Watts). I'm wondering if anyone has any experience underclocking > an 80386 motherboard down into the KHz range, or even Hz range, and if it > would still work at those slow speeds on the board? > > My goals in slowing down the CPU are to detect and isolate timing protocols, > which I can then scale up to higher speeds once identified. > > In any event, any help or advice is appreciated. Thank you. > > Best regards, > Rick C. Hodgin > If you plan to slow down the CPU by slowing down the FPGA clock be careful: FPGAs like clean and relatively fast edges and some slow generators don't work well. Pere
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