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
rickman <gnuarm@gmail.com> wrote: > I expect trying to get anything remotely like a critical mass is > virtually impossible. There is an open source chip similar in size and > capability to the ARM processors called RISC-V that is getting wide > attention and will produce a chip soon. RISC-V is an architecture, and various chips have been produced. It's also getting embedded in other products (eg as a tiny part of some other SoC). My colleagues at LowRISC: http://www.lowrisc.org/ are working on a fully open-source SoC based on the RISC-V architecture - ie open source at the Verilog design level, including peripheral IP. They still face many challenges, including the need to use proprietary ASIC tools and hard macros (eg memory generators). Their initial run is aimed for a multi-platform wafer service. > >>> 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. > > > > Oh, ok. There is an argument that the i386 has the largest software stack, so an i386 will have the most compatibility. However, that is changing. The Linux kernel doesn't support the i386 any more. Many binaries end up using MMX, SSE and so on, so won't work on an i386. Other operating systems are more platform agnostic (eg Android runs on ARM, x86, MIPS and others). Maybe that doesn't matter to you, but the question is not just what is the best choice now, but what might be when the you hope to be finished. One useful feature of RISC-V is they have ISA subsets: the base RV32I subset is quite small, and then features like 64 bit, floating point, etc are extra. That means the instruction requirements of software are made explicit. > It will never be possible to include an ARM ISA unless a license fee is > paid. I recall some years back a student produced an HDL version of an > ARM 7TDMI. ARM spoke to him and the core was withdrawn. He also got a > job with them. Win/win ARMv2 (ARM with 26 bit addressing) is now out of patent, so it's possible to implement it licence-free, and it has been: https://en.wikipedia.org/wiki/Amber_(processor_core) That is one thing in favour of the i386 against newer architectures: it is now out of patent, so Intel can't sue you for making one. > I'm surprised that you say it is hard to make it work. Do you mean it > is hard to build all the infrastructure? I have designed my own CPUs > before and found that part easy. It is creating the software support > that is hard, or at least a lot of work. I use Forth which helps make > things easier. We've also designed our own 64-bit CPUs, with our own ISA extensions. Multicore and cache coherency were a significant effort, likewise we spend a lot of effort on testing. Software is indeed a lot of work, though using the maximum of pre-existing software helps. > > At any rate, this implementation is an absolute MONSTER, clocking in at > > 36k gates (and providing a passe 30 MHz of x86). Just how the fuck am I > > supposed to fit that in a sane chip? You know, the ones for which you can > > get synthesizers for free, instead of paying several thousand dollars for > > them. This is the tricky question about the 'homebrew silicon fab' question. I think there's an interesting space for the 'artisanal semiconductor fab', that makes old chips relatively cheaply and allows users to get closer to the process. Some universities have that kind of facility, but often not intended for even medium volume manufacturing. But a general democratisation of fab technology could be an interesting space. You'd think that using new techniques on an old process would make life easier, just like people can make marble sculpture with CNC machines instead of hammers. What hits you, however, is lack of Moore's law. Let's say you have a 3 micron fab. You might only have two metal layers. You just can't get many transistors on that chip, and you can't wire them very well. The tools aren't optimised for that kind of environment, and will waste space trying to deal with layer limitations. You also can't fit much memory, and you can't deal with modern interfaces (no USB for you) or modern off-chip DRAM. You'd end up with 1970s style hand design, albeit with a fancy GUI rather than plastic tapes, connected to 1970s peripherals. Maybe you can deal with some of those by careful choice of off-chip components (eg everything is SRAM, not DDR4) and others by die stacking a commodity small-process interface die on top of your large-process die. Maybe the 'artisanal' producer makes the coarse-grained silicon interposer, and then stacks commodity dice from other vendors on it - like hobbyists make and assemble PCBs today. It does, however, require an ecosystem set up for that. TheoArticle: 158801
On 4/10/2016 2:26 PM, Theo Markettos wrote: > rickman <gnuarm@gmail.com> wrote: >> I expect trying to get anything remotely like a critical mass is >> virtually impossible. There is an open source chip similar in size and >> capability to the ARM processors called RISC-V that is getting wide >> attention and will produce a chip soon. > > RISC-V is an architecture, and various chips have been produced. It's also > getting embedded in other products (eg as a tiny part of some other SoC). > > My colleagues at LowRISC: > http://www.lowrisc.org/ > > are working on a fully open-source SoC based on the RISC-V architecture - ie > open source at the Verilog design level, including peripheral IP. They > still face many challenges, including the need to use proprietary > ASIC tools and hard macros (eg memory generators). Their initial run is > aimed for a multi-platform wafer service. > >>>>> 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. >>> >>> Oh, ok. > > There is an argument that the i386 has the largest software stack, so an > i386 will have the most compatibility. However, that is changing. The > Linux kernel doesn't support the i386 any more. Many binaries end up using > MMX, SSE and so on, so won't work on an i386. Other operating systems are > more platform agnostic (eg Android runs on ARM, x86, MIPS and others). > > Maybe that doesn't matter to you, but the question is not just what is the > best choice now, but what might be when the you hope to be finished. > > One useful feature of RISC-V is they have ISA subsets: the base RV32I subset > is quite small, and then features like 64 bit, floating point, etc are > extra. That means the instruction requirements of software are made > explicit. > >> It will never be possible to include an ARM ISA unless a license fee is >> paid. I recall some years back a student produced an HDL version of an >> ARM 7TDMI. ARM spoke to him and the core was withdrawn. He also got a >> job with them. Win/win > > ARMv2 (ARM with 26 bit addressing) is now out of patent, so it's possible to > implement it licence-free, and it has been: > https://en.wikipedia.org/wiki/Amber_(processor_core) > > That is one thing in favour of the i386 against newer architectures: it is > now out of patent, so Intel can't sue you for making one. I don't think the restriction was ever patent based. It was a matter of microcode copyright. That is why AMD had to use cleanrooms to generate a spec for all subsequent CPUs they desired to copy. That gets around copyright. So the 386 doesn't have an advantage over other x86 processors in terms of IP protection while it does have an advantage over patent protected designs. >> I'm surprised that you say it is hard to make it work. Do you mean it >> is hard to build all the infrastructure? I have designed my own CPUs >> before and found that part easy. It is creating the software support >> that is hard, or at least a lot of work. I use Forth which helps make >> things easier. > > We've also designed our own 64-bit CPUs, with our own ISA extensions. > Multicore and cache coherency were a significant effort, likewise we spend a > lot of effort on testing. > > Software is indeed a lot of work, though using the maximum of pre-existing > software helps. > >>> At any rate, this implementation is an absolute MONSTER, clocking in at >>> 36k gates (and providing a passe 30 MHz of x86). Just how the fuck am I >>> supposed to fit that in a sane chip? You know, the ones for which you can >>> get synthesizers for free, instead of paying several thousand dollars for >>> them. > > This is the tricky question about the 'homebrew silicon fab' question. > > I think there's an interesting space for the 'artisanal semiconductor fab', > that makes old chips relatively cheaply and allows users to get closer to > the process. Some universities have that kind of facility, but often not > intended for even medium volume manufacturing. But a general > democratisation of fab technology could be an interesting space. I would like to see an open source effort for FPGAs. I think the big roadblock would be the fab, but maybe it's more of a seed money issue since wafers can be bought for a reasonable price. A *very* small startup created an array CPU on a shoestring a few years ago. They have run a second batch of chips, so they must be selling them to someone. It's just a question of proving a market exists and coming up with the startup funding. http://www.greenarraychips.com/ -- RickArticle: 158802
Rick C. Hodgin wrote: > Rick C. Hodgin wrote: > > Rob Gaddi wrote: > > > 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. Received. Fits the board like it was made for it. :-) Best regards, Rick C. HodginArticle: 158803
rickman wrote: > I think you are better off not using the FPGA eval board and just > making your own board with the 386 and the FPGA. The adapters > and cables are going to add a lot of capacitance and noise > to your signals. Why mess with the added complexity? I'll need enough capacity to simulate my ISA, as well as drive the Am386. They will more or less execute together, with off-device debugging signals to control operations. Would the capacitance be an issue at a few hundred KHz max? I plan to make the custom Am386 plug straight in to the three GPIO ports. Best regards, Rick C. HodginArticle: 158804
On Mon, 11 Apr 2016 11:12:04 -0700, Rick C. Hodgin wrote: > rickman wrote: >> I think you are better off not using the FPGA eval board and just >> making your own board with the 386 and the FPGA. The adapters and >> cables are going to add a lot of capacitance and noise to your signals. >> Why mess with the added complexity? > > I'll need enough capacity to simulate my ISA, as well as drive the > Am386. They will more or less execute together, with off-device > debugging signals to control operations. > > Would the capacitance be an issue at a few hundred KHz max? I plan to > make the custom Am386 plug straight in to the three GPIO ports. > > Best regards, > Rick C. Hodgin You may need to slow down the Cyclone IO edges. If memory serves the V has sub ns rise times. Your cable and 386 input cap will help limit that some. Of course pay close attention to the setup and hold times the 386 is going to require. At one time PLX had local bus to pci chips. I have not checked on them lately. They got bought by Avago some time back. They may only do PCIe now. -- Chisolm Republic of TexasArticle: 158805
Rick C. Hodgin wrote: > Rick C. Hodgin wrote: >> Rick C. Hodgin wrote: >> > Rob Gaddi wrote: >> > > 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. > > Received. Fits the board like it was made for it. :-) > > Best regards, > Rick C. Hodgin I'm glad all the research effort I put in of looking over at the stack of same sitting on the corner of my desk and writing down the number from the box came in handy. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.Article: 158806
On 4/11/2016 2:12 PM, Rick C. Hodgin wrote: > rickman wrote: >> I think you are better off not using the FPGA eval board and just >> making your own board with the 386 and the FPGA. The adapters >> and cables are going to add a lot of capacitance and noise >> to your signals. Why mess with the added complexity? > > I'll need enough capacity to simulate my ISA, as well as drive the Am386. They will more or less execute together, with off-device debugging signals to control operations. > > Would the capacitance be an issue at a few hundred KHz max? I plan to make the custom Am386 plug straight in to the three GPIO ports. You won't have trouble with lines that are essentially data lines, you don't care if they ring. The trouble will be with clock like lines. That will include the actual clock and potentially the read/write strobes depending on how you implement the interface circuit. More importantly, you may have trouble with ground bounce. I've put my scope on the far end of disk drive ribbon cables before and the noise on the ground can be horrendous. The issue is not the clock rate, it is the edge rate. You can configure the FPGA for slower edge rates, but you can't do anything about the 386 edge rates. Running 100+ signal lines over a ribbon cable is just not a good idea unless you use differential signalling. You may get away with it, you may not. Since you are building a custom board anyway, why not just include the FPGA? The other way to do this is to use a set of bidirectional latches/buffers and let the FPGA access the interface via a simple serial interface using LVDS signalling. The FPGA already includes this functionallity. You just need to add a few interface chips to the 386 board along with your quickswitch devices. -- RickArticle: 158807
Rob Gaddi wrote: > I'm glad all the research effort I put in of looking over at the > stack of same sitting on the corner of my desk and writing down the > number from the box came in handy. Me too! :-) Nonetheless, and regardless of how trivial the effort was, it got me exactly what I needed, and it was/is appreciated. Best regards, Rick C. HodginArticle: 158808
rickman wrote: > The issue is not the clock rate, it is the edge rate. You can configure > the FPGA for slower edge rates, but you can't do anything about the > 386 edge rates. Running 100+ signal lines over a ribbon cable is just not > a good idea unless you use differential signalling. You may get > away with it, you may not. Since you are building a custom board > anyway, why not just include the FPGA? The board I intend to build will have three female mates to the three male GPIO interface ports on the HSMC adapter card. It will plug straight into it. No ribbon cables. Just a direct connection. As I understand it, the level shifters will introduce a delay, which should not be an issue at much slower clock rates. I do intend to build a direct coupling board. I could envision also a second FPGA on it for some purpose. Not sure what that would be, but I could see it. BTW, my goals are not to have 30 year old technology, but rather to start somewhere. I am familiar with 386, it is ubiquitous, and it's easily extensible. I look forward to LibSF 386-x40 coming to life. Best regards, Rick C. HodginArticle: 158809
On 4/11/2016 5:23 PM, Rick C. Hodgin wrote: > rickman wrote: >> The issue is not the clock rate, it is the edge rate. You can configure >> the FPGA for slower edge rates, but you can't do anything about the >> 386 edge rates. Running 100+ signal lines over a ribbon cable is just not >> a good idea unless you use differential signalling. You may get >> away with it, you may not. Since you are building a custom board >> anyway, why not just include the FPGA? > > The board I intend to build will have three female mates to the > three male GPIO interface ports on the HSMC adapter card. It will > plug straight into it. No ribbon cables. Just a direct connection. That's better, but the issue is as much the length as it is how the connection is made. I suppose there will be many ground connections on all of the sockets? Signal integrity is key. > As I understand it, the level shifters will introduce a delay, which should > not be an issue at much slower clock rates. If you use the quickswitch parts you get less than a nanosecond delay. They aren't buffers, they are transmission gates that limit the voltage range on the 3.3 volt side. > I do intend to build a direct coupling board. I could envision also a > second FPGA on it for some purpose. Not sure what that would be, but > I could see it. Lol, if you don't know the purpose, that's not very good vision. Try focusing on the things you can see clearly. Normally a goal is in mind, then the path is selected to reach a number of smaller goals on the way to the main goal. You seem to be plotting a path without clear objectives. > BTW, my goals are not to have 30 year old technology, but rather to > start somewhere. I am familiar with 386, it is ubiquitous, and it's > easily extensible. > > I look forward to LibSF 386-x40 coming to life. Good luck. -- RickArticle: 158810
rickman wrote:
> > I do intend to build a direct coupling board. I could envision also a
> > second FPGA on it for some purpose. Not sure what that would be, but
> > I could see it.
>
> Lol, if you don't know the purpose, that's not very good vision.
I don't know the purpose because it's your suggestion. Mine is to
use my dev board. It's been my plan all along. It's why I bought it,
for my LibSF 386-x40 CPU design.
> Try focusing on the things you can see clearly. Normally a goal is in
> mind, then the path is selected to reach a number of smaller
> goals on the way to the main goal.
Ah:
https://github.com/RickCHodgin/libsf/tree/master/li386/oppie
http://www.libsf.org/li386/indexmain.html
https://m.facebook.com/groups/726083540851343?view=info
> You seem to be plotting a path without clear objectives.
You seem to see things incorrectly, and always disparaging toward me.
Best regards,
Rick C. Hodgin
Article: 158811rickman <gnuarm@gmail.com> wrote: > That's better, but the issue is as much the length as it is how the > connection is made. I suppose there will be many ground connections on > all of the sockets? Signal integrity is key. Assuming this is the standard Altera/Terasic 40 way pinout, there aren't. There's two ground, one 3.3V and one 5V per socket, at roughly 1/3 2/3 positioning. The rest is GPIO. You might get away with purposefully grounding some GPIOs at the other end, but if Rick needs ~100 IOs there aren't many to play with. Each socket has (if I remember) 34 I/Os and two clock inputs. On the other hand, we get away with driving 40MHz video signals over ribbon cable with that connector so there is some leeway. YMMV of course. TheoArticle: 158812
On 4/11/2016 7:13 PM, Rick C. Hodgin wrote: > rickman wrote: >>> I do intend to build a direct coupling board. I could envision also a >>> second FPGA on it for some purpose. Not sure what that would be, but >>> I could see it. >> >> Lol, if you don't know the purpose, that's not very good vision. > > I don't know the purpose because it's your suggestion. Mine is to > use my dev board. It's been my plan all along. It's why I bought it, > for my LibSF 386-x40 CPU design. > >> Try focusing on the things you can see clearly. Normally a goal is in >> mind, then the path is selected to reach a number of smaller >> goals on the way to the main goal. > > Ah: > > https://github.com/RickCHodgin/libsf/tree/master/li386/oppie > http://www.libsf.org/li386/indexmain.html > https://m.facebook.com/groups/726083540851343?view=info > >> You seem to be plotting a path without clear objectives. > > You seem to see things incorrectly, and always disparaging toward me. That's the second time you have indicated you don't appreciate my comments. I will refrain from posting. -- RickArticle: 158813
rickman wrote: > I will refrain from posting. My loss. Best regards, Rick C. HodginArticle: 158814
Theo Markettos wrote: > ... if Rick needs ~100 IOs there aren't many to play with. Each socket > has (if I remember) 34 I/Os and two clock inputs. I need 92 GPIO pins. The remaining 40 are Vcc, Vss, or not connected. Best regards, Rick C. HodginArticle: 158815
On Monday, April 11, 2016 at 8:44:07 PM UTC-4, Rick C. Hodgin wrote:
> Theo Markettos wrote:
> > ... if Rick needs ~100 IOs there aren't many to play with. Each socket
> > has (if I remember) 34 I/Os and two clock inputs.
>
> I need 92 GPIO pins. The remaining 40 are Vcc, Vss, or not connected.
I began studying the 80386 data sheets last night. There are only 19 control
pins which will be used in a 32-bit bus implementation that does not support
address pipelining. And only 16 if a math-coprocessor is not used. And only
14 if there isn't an arbitrated system bus. The rest are 30 address pins, 32
data pins, and either Vcc, Vss, or not connected.
Of those 14 pins:
1 is the clock signal
4 are address byte enablers (32-bit writes, 1 pin
per byte to read 8-bit, 16-bit, 24-bit, or 32-bit)
4 define the bus cycle definition
2 defines the bus control operation
2 define interrupt, non-maskable interrupt
1 is reset
It is an incredibly simple design. The Intel 80386 manuals also define
timing for their 20 MHz to 33 MHz parts. I'm assuming the Am386 would
follow similar protocols.
Edge timing appears to be 4 ns, so that will need slowed. The rest
would seem to fall within the clock cycle timing, but requires a certain
amount of time to pass before the data on the pins is valid, typically
in 20 or less ns, and often 4, 6, or 7 or more ns.
Best regards,
Rick C. Hodgin
Article: 158816I've tried to open the product search in the CPLD product category several times in the last few days. I wanted to know if they'd axe any of that product line. It (script?) did not complete loading. Sometimes I'd get the progress indicator (blue dots, never completing), sometimes I got a maintenance notice. Is this happening to anyone else or is perhaps my system misconfigured?Article: 158817
On 4/14/2016 10:53 AM, Johann Klammer wrote: > I've tried to open the product search in the CPLD product category several > times in the last few days. I wanted to know if they'd axe any of that product line. > It (script?) did not complete loading. Sometimes I'd get the progress indicator > (blue dots, never completing), sometimes I got a maintenance notice. > Is this happening to anyone else or is perhaps my system misconfigured? Got a link? -- RickArticle: 158818
On 4/14/2016 12:16 PM, rickman wrote: > On 4/14/2016 10:53 AM, Johann Klammer wrote: >> I've tried to open the product search in the CPLD product category >> several >> times in the last few days. I wanted to know if they'd axe any of that >> product line. >> It (script?) did not complete loading. Sometimes I'd get the progress >> indicator >> (blue dots, never completing), sometimes I got a maintenance notice. >> Is this happening to anyone else or is perhaps my system misconfigured? > > Got a link? I got Atmel mixed up with Altera. I forgot Atmel made programmable logic. lol Yes, I see the same thing. Under some other sections the Product Search does the same thing. Under MCUs it loads normally. -- RickArticle: 158819
Johann Klammer wrote: > I've tried to open the product search in the CPLD product category several > times in the last few days. I wanted to know if they'd axe any of that product line. > It (script?) did not complete loading. Sometimes I'd get the progress indicator > (blue dots, never completing), sometimes I got a maintenance notice. > Is this happening to anyone else or is perhaps my system misconfigured? > Might have changed since your initial post, but I see: Maintenance Notice The page you have requested is temporarily not available. Please check back later. We are sorry for any inconvenience. If you go back to the page later, be sure to clear your browser's cache. -- GaborArticle: 158820
On Tuesday, April 5, 2016 at 3:15:38 PM UTC-4, 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.
Well much to my surprise, I was watching CPU-related videos today and
I came across this video:
https://www.youtube.com/watch?v=y0WEx0Gwk1E&t=4m22s
Beginning around 4:22 it shows the very type of board I was looking to
create to plug in to an existing 80386 system and monitor its signals.
Does anyone have one of these types boards on their shelf from back in
the day?
Best regards,
Rick C. Hodgin
Article: 158821On 16.04.2016 16:58, Rick C. Hodgin wrote: > On Tuesday, April 5, 2016 at 3:15:38 PM UTC-4, 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. > Does anyone have one of these types boards on their shelf from back in > the day? http://www.forcetechnologies.co.uk/news/replacement-for-intel-processors-in-high-reliability-long-life-systems http://www.forcetechnologies.co.uk/downloads/x86-Processor-Recreation But I doubt that a complete 386 will fit into a FPGA.Article: 158822
On Saturday, April 16, 2016 at 11:31:21 AM UTC-4, Herbert Kleebauer wrote:
> On 16.04.2016 16:58, Rick C. Hodgin wrote:
> > On Tuesday, April 5, 2016 at 3:15:38 PM UTC-4, 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.
>
> > Does anyone have one of these types boards on their shelf from back in
> > the day?
>
>
> http://www.forcetechnologies.co.uk/news/replacement-for-intel-processors-in-high-reliability-long-life-systems
> http://www.forcetechnologies.co.uk/downloads/x86-Processor-Recreation
How exciting! :-)
> But I doubt that a complete 386 will fit into a FPGA.
A man named Aleksander Osman has created a full 486SX CPU in an Altera
FPGA (Terasic DE2-115 only, and it does not have an FPU):
https://github.com/alfikpl/ao486
It is comprised of:
Unit Cells M9K
---------------- ----- ---
ao486SX CPU 36517 47
floppy 1514 2
hdd 2071 17
nios2 1056 3
onchip for nios2 0 32
pc_dma 848 0
pic 388 0
pit 667 0
ps2 742 2
rtc 783 1
sound 37131 29
vga 2534 260
-------------------------------
Total: 84,251 393
After compiling with Quartus II:
-----[ Start ]----
Fitter Status : Successful - Sun Mar 30 21:00:13 2014
Quartus II 64-Bit Version : 13.1.0 Build 162 10/23/2013 SJ Web Edition
Revision Name : soc
Top-level Entity Name : soc
Family : Cyclone IV E
Device : EP4CE115F29C7
Timing Models : Final
Total logic elements : 91,256 / 114,480 ( 80 % )
Total combinational functions : 86,811 / 114,480 ( 76 % )
Dedicated logic registers : 26,746 / 114,480 ( 23 % )
Total registers : 26865
Total pins : 108 / 529 ( 20 % )
Total virtual pins : 0
Total memory bits : 2,993,408 / 3,981,312 ( 75 % )
Embedded Multiplier 9-bit elements : 44 / 532 ( 8 % )
Total PLLs : 1 / 4 ( 25 % )
-----[ End ]----
Runs at 39 MHz. Boots and runs:
Microsoft MS-DOS version 6.22
Microsoft Windows for Workgroups 3.11
Microsoft Windows 95
Linux 3.13.1
Best regards,
Rick C. Hodgin
Article: 158823I have been looking at the various options for VHDL obfuscators. I have tried all of the free programs that I could find and was left unimpressed. I also has similar unimpressive results with a demo version of a commercial program. The best results were from some test code run through the VISENGI commercial program, but they do not have a demo version, so I can't make a full evaluation. Before I make the final decision, does anyone have positive (or negative) experiences to relate about VHDL obfuscators in general and the VISENGI obfuscator in particular? Thanks, Chris JohnsonArticle: 158824
On 21/04/2016 14:27, email.crj@gmail.com wrote: > I have been looking at the various options for VHDL obfuscators. I have tried all of the free programs that I could find and was left unimpressed. I also has similar unimpressive results with a demo version of a commercial program. > > The best results were from some test code run through the VISENGI commercial program, but they do not have a demo version, so I can't make a full evaluation. > > Before I make the final decision, does anyone have positive (or negative) experiences to relate about VHDL obfuscators in general and the VISENGI obfuscator in particular? > > Thanks, > Chris Johnson > Hi Chris, Personally I would bother with obfuscation as it is relative easy to de-obfuscate the code even if they change the signal names through each port map. If you really want to obfuscate your RTL then I would suggest getting hold of a synthesis tool that can write out an RTL netlist (like Leonardo Spectrum). You can then target a very simple device like a CPLD which doesn't have any complex modgens. You won't get better obfuscation than a netlist full of gates and FF's. You could also look into VHDL2008 encryption which is OK for simulation but a different story if you want reach the bitstream, Good luck, Hans www.ht-lab.com
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