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 12/2/2014 6:51 AM, Theo Markettos wrote: > rick.c.hodgin@gmail.com wrote: >> Greetings. I am new to FPGA programming. I am >> seeking to create a 40-bit 80386-like CPU core >> with a 32-bit and 64-bit FPU with 16 registers, >> a 128-bit four- and two-way 32-bit and 64-bit >> vector FPU engine with 16 registers, 60 >> additional general purpose integer registers, >> and a six stage execution pipeline. > > For a point of comparison, we have a 64-bit MIPS-like CPU core, with MMU, > L1/L2 cache, 32-bit floating point support, capability unit (32x 256-bit > registers), and a 256 bit datapath to DDR2 memory, and it runs at 100MHz in > about 80% of a Stratix IV GX230 (230K LEs). Picture and numbers on page 10 > here (the Stratix IV doesn't have hard floating point): > http://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/201406-isca2014-cheri.pdf > > This is not particularly optimised for size (or speed), and when you put > more things on the FPGA the area usage for the CPU shrinks as the tools work > harder. We're trying to make it fit in a Cyclone V SoC part > (5CSXFC6D6F31C6N) but haven't yet trimmed it down sufficiently. > > The 10 family apparently supports hard floating point: the Stratix 10 is not > available yet but the Arria 10 might be worth a look. > > The Arria family is also worth looking at from a cost per LE point of view: > according to my graph on page 2 here: > http://www.cl.cam.ac.uk/~atm26/pubs/FPL2014-ClusterInterconnect.pdf > it works out somewhat cheaper LUT-for-LUT than the Stratix parts. Nice info. You might consider using a log scale for the pricing axis. That would help spread out the low end rather than having all that data bunched into the corner. Maybe even log the size axis too. -- RickArticle: 157376
Thank you for the replies and info. I will be designing my CPU in several stages. I have the first stage designed but not debugged. Am working on that this week (Lord willing). Would it be preferable to design and test each in Quartus-II only? What about DRAM controllers? And Ethernet? I plan on using Ethernet for remote debugging during development and testing. And do I want a dev board with VGA out to make it easier? Or should I pass everything through the Ethernet port? Thank you in advance for your assistance. It is greatly appreciated. :-) Best regards, Rick C. HodginArticle: 157377
On 12/2/2014 7:58 AM, rick.c.hodgin@gmail.com wrote: > Thank you for the replies and info. > > I will be designing my CPU in several stages. I > have the first stage designed but not debugged. > Am working on that this week (Lord willing). > > Would it be preferable to design and test each > in Quartus-II only? What about DRAM controllers? > And Ethernet? I plan on using Ethernet for remote > debugging during development and testing. And > do I want a dev board with VGA out to make it > easier? Or should I pass everything through the > Ethernet port? I'm not sure what would be easier. I've never worked with Ethernet in an FPGA before. I would think you could get a VGA interface working faster than an Ethernet interface will all the software required. Are you planning to run Linux on it or will you be coding to the bare metal without an OS? Will your Ethernet interface be a full custom or are you going to use an Ethernet module that provides a serial link to your CPU? -- RickArticle: 157378
On Tuesday, December 2, 2014 8:13:23 AM UTC-5, rickman wrote:
> On 12/2/2014 7:58 AM, rick.c.hodgin@gmail.com wrote:
> > Thank you for the replies and info.
> >
> > I will be designing my CPU in several stages. I
> > have the first stage designed but not debugged.
> > Am working on that this week (Lord willing).
> >
> > Would it be preferable to design and test each
> > in Quartus-II only? What about DRAM controllers?
> > And Ethernet? I plan on using Ethernet for remote
> > debugging during development and testing. And
> > do I want a dev board with VGA out to make it
> > easier? Or should I pass everything through the
> > Ethernet port?
>
> I'm not sure what would be easier. I've never worked with Ethernet in
> an FPGA before. I would think you could get a VGA interface working
> faster than an Ethernet interface will all the software required. Are
> you planning to run Linux on it or will you be coding to the bare metal
> without an OS? Will your Ethernet interface be a full custom or are you
> going to use an Ethernet module that provides a serial link to your CPU?
I found a simple Ethernet controller on fpga4fun:
http://www.fpga4fun.com/10BASE-T.html
I plan on creating a simple buffer which receives internal pipe stage
information at each CPU clock, and then transmits that data back out in
real-time to some a port being monitored by my debugger. This will allow
me to then constantly monitor the machine state. I can also then encode
external source level single-step debugging, assembly tools, make even
program changes in real-time, etc., to complete the entire toolset.
I developed my own kernel and primitive OS back in the late 90s, early
00s. I will be using a modified version of that as the ISA I'm using
is somewhat different than the actual 80386 ISA in (except in
compatibility mode, which I will probably add last).
I'm thinking I would also like to figure out and test timing on a fixed
SVGA video mode for a 1920x1080 signal at 60 Hz, and just hard-code that
video mode and use it for everything the machine does until I can later
add other modes. And the same for a DRAM controller so I can have that
consistent and normal access to memory, Ethernet, and VGA throughout all
of my development.
Best regards,
Rick C. Hodgin
Article: 157379On Tuesday, December 2, 2014 8:36:34 AM UTC-5, Rick C. Hodgin wrote: > On Tuesday, December 2, 2014 8:13:23 AM UTC-5, rickman wrote: > > On 12/2/2014 7:58 AM, rick.c.hodgin@gmail.com wrote: > > > Thank you for the replies and info. > > > > > > I will be designing my CPU in several stages. I > > > have the first stage designed but not debugged. > > > Am working on that this week (Lord willing). > > > > > > Would it be preferable to design and test each > > > in Quartus-II only? What about DRAM controllers? > > > And Ethernet? I plan on using Ethernet for remote > > > debugging during development and testing. And > > > do I want a dev board with VGA out to make it > > > easier? Or should I pass everything through the > > > Ethernet port? > > > > I'm not sure what would be easier. I've never worked with Ethernet in > > an FPGA before. I would think you could get a VGA interface working > > faster than an Ethernet interface will all the software required. Are > > you planning to run Linux on it or will you be coding to the bare metal > > without an OS? Will your Ethernet interface be a full custom or are you > > going to use an Ethernet module that provides a serial link to your CPU? > > I found a simple Ethernet controller on fpga4fun: > http://www.fpga4fun.com/10BASE-T.html > > I plan on creating a simple buffer which receives internal pipe stage > information at each CPU clock, and then transmits that data back out in > real-time to some a port being monitored by my debugger. This will allow > me to then constantly monitor the machine state. I can also then encode > external source level single-step debugging, assembly tools, make even > program changes in real-time, etc., to complete the entire toolset. > > I developed my own kernel and primitive OS back in the late 90s, early > 00s. I will be using a modified version of that as the ISA I'm using > is somewhat different than the actual 80386 ISA in (except in > compatibility mode, which I will probably add last). > > I'm thinking I would also like to figure out and test timing on a fixed > SVGA video mode for a 1920x1080 signal at 60 Hz, and just hard-code that > video mode and use it for everything the machine does until I can later > add other modes. And the same for a DRAM controller so I can have that > consistent and normal access to memory, Ethernet, and VGA throughout all > of my development. I've since given this some additional thought and have decided I'll transmit everything over Ethernet. In this way I can create several virtual screens and simply write to memory ranges and have them be transmitted when possible. Best regards, Rick C. HodginArticle: 157380
rickman wrote: > > There is some interesting software they provide for working with Altera > FPGAs called Quartus. It will let you synthesize your designs and > measure the size. Then you can tell what size part it will fit. No > guesswork required. :) > Xilinx has similar capabilities. You can desing for an arbitrary family, then it will tell you the smalles device it will actually fit into. I only use Xilinx, but some research SEEMS to indicate to me that Xilinx devices may be a good deal cheaper than Altera. All of the rest of Rick's comments are very good, and apply equally to Xilinx. JonArticle: 157381
rickman <gnuarm@gmail.com> wrote: > Nice info. You might consider using a log scale for the pricing axis. > That would help spread out the low end rather than having all that data > bunched into the corner. Maybe even log the size axis too. I did try, but it wasn't usable in the limited space I had for the paper. Here's a larger loglog version: http://www.cl.cam.ac.uk/~atm26/ephemeral/fpga-pricing-2014-loglog.pdf TheoArticle: 157382
rickman <gnuarm@gmail.com> wrote: > On 12/2/2014 7:58 AM, rick.c.hodgin@gmail.com wrote: >> Thank you for the replies and info. (snip) >> Would it be preferable to design and test each >> in Quartus-II only? What about DRAM controllers? >> And Ethernet? I plan on using Ethernet for remote >> debugging during development and testing. And >> do I want a dev board with VGA out to make it >> easier? Or should I pass everything through the >> Ethernet port? > I'm not sure what would be easier. I've never worked with Ethernet in > an FPGA before. I would think you could get a VGA interface working > faster than an Ethernet interface will all the software required. Are > you planning to run Linux on it or will you be coding to the bare metal > without an OS? Will your Ethernet interface be a full custom or are you > going to use an Ethernet module that provides a serial link to your CPU? VGA is pretty easy, and there should be already done examples. You need row and column counters, and gates to generate the hsync and vsync. Output data from display RAM, either directly or through a character ROM. It is FPGA outputs, through resistors, and to the VGA pins. For ethernet, it is usual to put a PHY chip on board, which has the analog circuits that you can't build on an FPGA, and interface to that. For RS232, the FPGA pins go to level converters to convert to the appropriate voltages, but all the logic (UART) is in the FPGA. -- glenArticle: 157383
On Tuesday, December 2, 2014 2:57:02 PM UTC-5, glen herrmannsfeldt wrote: > VGA is pretty easy, and there should be already done examples. > You need row and column counters, and gates to generate the hsync > and vsync. Output data from display RAM, either directly or through > a character ROM. It is FPGA outputs, through resistors, and to > the VGA pins. The ao486 project on opencores.org contains a VGA controller along with other controllers. I figured I may look at those when the time comes. However, from back in my OS driver development days, I remember learning about timings for SVGA. Some of the registers driving the 3dfx voodoo3 2000 video card I was using at that time had to be programmed directly (when no driver was available). I also remember working with the HGA Hercules monochrome graphics adapter timings. I can see how it all fits together now. > For ethernet, it is usual to put a PHY chip on board, which has > the analog circuits that you can't build on an FPGA, and interface > to that. I purchased a TI PHY chip today (DP83848C 10/100 model) in a pin package that I believe will allow direct connection to the Altera dev board. I downloaded the protocol specs and it was very straight-forward. I found a better solution earlier from Silicon Labs, but I couldn't find an inexpensive connection board that didn't require something like solder masks ... so I went with TI's already-together product. For point-to-point inter-LibSF-device communication I think I'll simply invent Libernet, a simple protocol using five pins (tx-clk, tx, rx-clk, rx, and gnd) and make the communication protocol as simple as possible. I like the idea of Manchester coding, however, and may consider using that as well to keep pin count down at the expense of some logic on the sending and receiving end. > For RS232, the FPGA pins go to level converters to convert to the > appropriate voltages, but all the logic (UART) is in the FPGA. I am absolutely loving this project so far. I think it's my all-time favorite. Best regards, Rick C. HodginArticle: 157384
On 12/2/2014 2:36 PM, Jon Elson wrote: > rickman wrote: > > >> >> There is some interesting software they provide for working with Altera >> FPGAs called Quartus. It will let you synthesize your designs and >> measure the size. Then you can tell what size part it will fit. No >> guesswork required. :) >> > Xilinx has similar capabilities. You can desing for an arbitrary family, > then it will tell you the smalles device it will actually fit into. > > I only use Xilinx, but some research SEEMS to indicate to me that > Xilinx devices may be a good deal cheaper than Altera. > > All of the rest of Rick's comments are very good, and apply equally > to Xilinx. I can't seem to find it now, but someone recently posted a link to price/LUT vs size data in graph form. It gets a bit crowded at the bottom end, but appears to show there is no real price difference between the two brands. The data does include a very small number of other devices than X and A, but not enough to be useful. In fact it is interesting that the prices get very crowded at the low end jamming up the graph. I suggested that he present the data with a logarithmic Y axis or even in log-log form. Clearly competitive market forces at work. -- RickArticle: 157385
On 12/2/2014 3:15 PM, Rick C. Hodgin wrote: > On Tuesday, December 2, 2014 2:57:02 PM UTC-5, glen herrmannsfeldt wrote: >> VGA is pretty easy, and there should be already done examples. >> You need row and column counters, and gates to generate the hsync >> and vsync. Output data from display RAM, either directly or through >> a character ROM. It is FPGA outputs, through resistors, and to >> the VGA pins. > > The ao486 project on opencores.org contains a VGA controller along with > other controllers. I figured I may look at those when the time comes. > However, from back in my OS driver development days, I remember learning > about timings for SVGA. Some of the registers driving the 3dfx voodoo3 > 2000 video card I was using at that time had to be programmed directly > (when no driver was available). I also remember working with the HGA > Hercules monochrome graphics adapter timings. I can see how it all fits > together now. > >> For ethernet, it is usual to put a PHY chip on board, which has >> the analog circuits that you can't build on an FPGA, and interface >> to that. > > I purchased a TI PHY chip today (DP83848C 10/100 model) in a pin package > that I believe will allow direct connection to the Altera dev board. I > downloaded the protocol specs and it was very straight-forward. I found > a better solution earlier from Silicon Labs, but I couldn't find an > inexpensive connection board that didn't require something like solder > masks ... so I went with TI's already-together product. Why not just use an integrated PHY/MAC and save the trouble of rolling your own? How big is the device you will need? > For point-to-point inter-LibSF-device communication I think I'll simply > invent Libernet, a simple protocol using five pins (tx-clk, tx, rx-clk, > rx, and gnd) and make the communication protocol as simple as possible. > > I like the idea of Manchester coding, however, and may consider using > that as well to keep pin count down at the expense of some logic on > the sending and receiving end. Please don't roll your own serial interface. You will forever regret it I think. Why add to the huge number of existing interfaces when nearly every need has already been met by one or the other? >> For RS232, the FPGA pins go to level converters to convert to the >> appropriate voltages, but all the logic (UART) is in the FPGA. > > I am absolutely loving this project so far. I think it's my all-time > favorite. I assume it is all just for fun? -- RickArticle: 157386
On 12/2/2014 2:40 PM, Theo Markettos wrote: > rickman <gnuarm@gmail.com> wrote: >> Nice info. You might consider using a log scale for the pricing axis. >> That would help spread out the low end rather than having all that data >> bunched into the corner. Maybe even log the size axis too. > > I did try, but it wasn't usable in the limited space I had for the paper. > Here's a larger loglog version: > http://www.cl.cam.ac.uk/~atm26/ephemeral/fpga-pricing-2014-loglog.pdf There you go! Great job. Interesting how the members of a family are more evenly spaced on a log scale for size. BTW, where did you get your pricing data? One thing I have learned about FPGA pricing is that list price means nothing if you are buying any real quantity. To get a design win, especially in a new family, they will bid very aggressively. -- RickArticle: 157387
On Tuesday, December 2, 2014 5:20:17 PM UTC-5, rickman wrote: > > I purchased a TI PHY chip today (DP83848C 10/100 model) in a pin package > > that I believe will allow direct connection to the Altera dev board. I > > downloaded the protocol specs and it was very straight-forward. I found > > a better solution earlier from Silicon Labs, but I couldn't find an > > inexpensive connection board that didn't require something like solder > > masks ... so I went with TI's already-together product. > > Why not just use an integrated PHY/MAC and save the trouble of rolling > your own? How big is the device you will need? The product I bought: http://www.amazon.com/gp/product/B00KM6VNBC/ref=oh_aui_detailpage_o00_s00 > > For point-to-point inter-LibSF-device communication I think I'll simply > > invent Libernet, a simple protocol using five pins (tx-clk, tx, rx-clk, > > rx, and gnd) and make the communication protocol as simple as possible. > > > > I like the idea of Manchester coding, however, and may consider using > > that as well to keep pin count down at the expense of some logic on > > the sending and receiving end. > > Please don't roll your own serial interface. You will forever regret it > I think. Why add to the huge number of existing interfaces when nearly > every need has already been met by one or the other? Because it would work in wholly replicable logic within the FPGA, requiring nothing other than connecting up pins. FWIW, I'm talking about slow device on-motherboard communications here, and potentially some remote debugging communication across multi-CPUs through a single interface. > >> For RS232, the FPGA pins go to level converters to convert to the > >> appropriate voltages, but all the logic (UART) is in the FPGA. > > I am absolutely loving this project so far. I think it's my all-time > > favorite. > > I assume it is all just for fun? No. It is to become the foundation of a hardware and software stack I am creating that has roots in the 80386 design, but has been modified to be simpler, and has been extended out to 40-bits. Best regards, Rick C. HodginArticle: 157388
rickman <gnuarm@gmail.com> wrote: > On 12/2/2014 2:40 PM, Theo Markettos wrote: > > I did try, but it wasn't usable in the limited space I had for the paper. > > Here's a larger loglog version: > > http://www.cl.cam.ac.uk/~atm26/ephemeral/fpga-pricing-2014-loglog.pdf > > There you go! Great job. Interesting how the members of a family are > more evenly spaced on a log scale for size. > > BTW, where did you get your pricing data? One thing I have learned > about FPGA pricing is that list price means nothing if you are buying > any real quantity. To get a design win, especially in a new family, > they will bid very aggressively. Pricing data is downloaded from Digikey. There were 17000 prices in all, so to compress the dataset into something meaningful I grouped all the parts of the same number of logical elements and the same subfamily - eg Cyclone IV GX - and took the median of the price of each group. That gives some measure of the middle of the range of different packages, temperatures, speed grades etc without too many of the outliers (eg Mil Spec with crazy prices). Obviously in any real situation you should have coffee with the salesman and explain how many million you're going to buy but can't afford just yet, but there's no way to do that comparison objectively. Digikey prices aren't ideal, but they are an example of what you would pay if you want one FPGA tomorrow, and don't haggle with the salesman or commit to a lead time of 26 weeks. TheoArticle: 157389
rickman <gnuarm@gmail.com> wrote: > Why not just use an integrated PHY/MAC and save the trouble of rolling > your own? How big is the device you will need? The Altera IP for MACs is quite nice. I used the 10G MAC recently (for the paper I cited in my other post in fact) and it was a case of feed it a stream of 64 bit payload words (in an Avalon stream that does the flow control, I did this by hand in my Verilog testbench) and out pops Ethernet frames, complete with CRC. In this case I was using an SFP+ transceiver as my PHY, but an external PHY chip should work equally well. It gets a bit trickier in the multi-speed MACs, when you have to talk to the PHY from software, or when you want the MAC to also provide the buffering/interrupts/software interface etc. Having an external PHY/MAC usually means a bidirectional bus-style interface (address, data, R/-W, clock, etc) which gets annoying at high speed. Or PCIe things likewise. I don't know of any FPGAs that have integrated PHY, though there are SFP+ Direct Attach cables which are essentially PHY-less serial connections between MACs. Likewise SATA, USB3, etc wiring can be so abused. > > rx, and gnd) and make the communication protocol as simple as possible. > > > > I like the idea of Manchester coding, however, and may consider using > > that as well to keep pin count down at the expense of some logic on > > the sending and receiving end. > > Please don't roll your own serial interface. You will forever regret it > I think. Why add to the huge number of existing interfaces when nearly > every need has already been met by one or the other? Sometimes it can be handy if you're doing something different to their constraints. But at the very least keep the physical layer the same, you can still mess with the packet structure etc. You don't want to be debugging the PHY without a decent high speed test infrastructure. And obviously this is only useful if you have control of both ends of the link. TheoArticle: 157390
rickman <gnuarm@gmail.com> wrote: > I can't seem to find it now, but someone recently posted a link to > price/LUT vs size data in graph form. It gets a bit crowded at the > bottom end, but appears to show there is no real price difference > between the two brands. The data does include a very small number of > other devices than X and A, but not enough to be useful. Graphs again: http://www.cl.cam.ac.uk/~atm26/pubs/FPL2014-ClusterInterconnect.pdf (page 2) http://www.cl.cam.ac.uk/~atm26/ephemeral/fpga-pricing-2014-loglog.pdf I had data for ECP3 and Igloo 2. Most of the others that Digikey listed are either very small (<20K LEs), missing LE data in their table, or legacy products (APEX, XC4000, etc). There wasn't enough data to plot anything reasonable from those. A graph of sub-20K devices would be interesting, but it's a very different market. > In fact it is interesting that the prices get very crowded at the low > end jamming up the graph. I suggested that he present the data with a > logarithmic Y axis or even in log-log form. Clearly competitive market > forces at work. One of the interesting things to note is the pricing margin between budget and premium ranges: you pay 4-6x more per LE in a 'premium' family than in a budget range. So if you can build a system with multiple FPGAs (and we described a way to do that in the paper, which fits some applications better than others) then it can be economic to use smaller budget FPGAs rather than buy the premium FPGA. The alternative theory is that people buy budget FPGAs from Digikey, and buying premium devices requires a long chat with a salesman, so the Digikey list prices for those are mostly fiction that nobody pays. However the same trend seems to apply across all vendors. TheoArticle: 157391
On 12/2/2014 6:21 PM, Rick C. Hodgin wrote: > On Tuesday, December 2, 2014 5:20:17 PM UTC-5, rickman wrote: >>> I purchased a TI PHY chip today (DP83848C 10/100 model) in a pin package >>> that I believe will allow direct connection to the Altera dev board. I >>> downloaded the protocol specs and it was very straight-forward. I found >>> a better solution earlier from Silicon Labs, but I couldn't find an >>> inexpensive connection board that didn't require something like solder >>> masks ... so I went with TI's already-together product. >> >> Why not just use an integrated PHY/MAC and save the trouble of rolling >> your own? How big is the device you will need? > > The product I bought: > http://www.amazon.com/gp/product/B00KM6VNBC/ref=oh_aui_detailpage_o00_s00 Yes, this seems to have a PHY by TI, DP83848. The interface lists MII, RMII and SNI. >>> For point-to-point inter-LibSF-device communication I think I'll simply >>> invent Libernet, a simple protocol using five pins (tx-clk, tx, rx-clk, >>> rx, and gnd) and make the communication protocol as simple as possible. >>> >>> I like the idea of Manchester coding, however, and may consider using >>> that as well to keep pin count down at the expense of some logic on >>> the sending and receiving end. >> >> Please don't roll your own serial interface. You will forever regret it >> I think. Why add to the huge number of existing interfaces when nearly >> every need has already been met by one or the other? > > Because it would work in wholly replicable logic within the FPGA, > requiring nothing other than connecting up pins. You mean like SPI, I2C, async serial, etc, etc, etc... > FWIW, I'm talking about slow device on-motherboard communications here, > and potentially some remote debugging communication across multi-CPUs > through a single interface. You mean like SPI, I2C, async serial, etc, etc, etc... One *big* advantage to using something standard is that other devices can talk to it, not just your designs. If you get into a tough spot you can even get low cost debuggers for any of these other protocols. >>>> For RS232, the FPGA pins go to level converters to convert to the >>>> appropriate voltages, but all the logic (UART) is in the FPGA. >>> I am absolutely loving this project so far. I think it's my all-time >>> favorite. >> >> I assume it is all just for fun? > > No. It is to become the foundation of a hardware and software stack > I am creating that has roots in the 80386 design, but has been modified > to be simpler, and has been extended out to 40-bits. To what end? -- RickArticle: 157392
On Tuesday, December 2, 2014 7:51:39 PM UTC-5, rickman wrote: > On 12/2/2014 6:21 PM, Rick C. Hodgin wrote: > > Because it would work in wholly replicable logic within the FPGA, > > requiring nothing other than connecting up pins. > You mean like SPI, I2C, async serial, etc, etc, etc... I don't know of any of those other than by their names used in various technical specs I've read over time. If they work like the one I'm proposing, then what's the big deal? The protocol I would define would include a 16-bit word for the target sub- unit, a 16-bit word for the payload length, and then the payload. > > FWIW, I'm talking about slow device on-motherboard communications here, > > and potentially some remote debugging communication across multi-CPUs > > through a single interface. > > You mean like SPI, I2C, async serial, etc, etc, etc... > > One *big* advantage to using something standard is that other devices > can talk to it, not just your designs. If you get into a tough spot you > can even get low cost debuggers for any of these other protocols. I am writing my own debugger. > >>>> For RS232, the FPGA pins go to level converters to convert to the > >>>> appropriate voltages, but all the logic (UART) is in the FPGA. > >>> I am absolutely loving this project so far. I think it's my all-time > >>> favorite. > >> > >> I assume it is all just for fun? > > > > No. It is to become the foundation of a hardware and software stack > > I am creating that has roots in the 80386 design, but has been modified > > to be simpler, and has been extended out to 40-bits. > > To what end? I am a Christian. I desire to create a hardware and software stack from the ground up, one focused upon an offering of sharing and love, rather than of profits, sales goals, and proprietary hardware locks. I would also like to create the tools to produce the semiconductor products as well, which I plan to do after I get my CPU designed. I will design the layout and routing tools, and move toward manufacturing. Best regards, Rick C. HodginArticle: 157393
On 12/2/2014 9:14 PM, Rick C. Hodgin wrote: > On Tuesday, December 2, 2014 7:51:39 PM UTC-5, rickman wrote: >> On 12/2/2014 6:21 PM, Rick C. Hodgin wrote: >>> Because it would work in wholly replicable logic within the FPGA, >>> requiring nothing other than connecting up pins. >> You mean like SPI, I2C, async serial, etc, etc, etc... > > I don't know of any of those other than by their names used in > various technical specs I've read over time. If they work like > the one I'm proposing, then what's the big deal? The protocol > I would define would include a 16-bit word for the target sub- > unit, a 16-bit word for the payload length, and then the payload. I'm not sure what you are proposing. Sounds more like you are describing a software protocol. If you want to do your own thing fine, but there are times when compatibility can be useful and reinventing the wheel is seldom an advantage. >>> FWIW, I'm talking about slow device on-motherboard communications here, >>> and potentially some remote debugging communication across multi-CPUs >>> through a single interface. >> >> You mean like SPI, I2C, async serial, etc, etc, etc... >> >> One *big* advantage to using something standard is that other devices >> can talk to it, not just your designs. If you get into a tough spot you >> can even get low cost debuggers for any of these other protocols. > > I am writing my own debugger. I'm not talking about a software debugger. I'm talking about a debugger for your interface. Call it a scope then. >>>>>> For RS232, the FPGA pins go to level converters to convert to the >>>>>> appropriate voltages, but all the logic (UART) is in the FPGA. >>>>> I am absolutely loving this project so far. I think it's my all-time >>>>> favorite. >>>> >>>> I assume it is all just for fun? >>> >>> No. It is to become the foundation of a hardware and software stack >>> I am creating that has roots in the 80386 design, but has been modified >>> to be simpler, and has been extended out to 40-bits. >> >> To what end? > > I am a Christian. I desire to create a hardware and software stack > from the ground up, one focused upon an offering of sharing and love, > rather than of profits, sales goals, and proprietary hardware locks. > > I would also like to create the tools to produce the semiconductor > products as well, which I plan to do after I get my CPU designed. > I will design the layout and routing tools, and move toward > manufacturing. The fact that it is going to be open source doesn't remove it from the world of markets. What need is this satisfying? Clearly you expect others to use it. Have you made any efforts to see what others want from such devices? What if you build it and nobody comes because you built something no one wants? -- RickArticle: 157394
On Tuesday, December 2, 2014 10:10:04 PM UTC-5, rickman wrote: > On 12/2/2014 9:14 PM, Rick C. Hodgin wrote: > > On Tuesday, December 2, 2014 7:51:39 PM UTC-5, rickman wrote: > >> On 12/2/2014 6:21 PM, Rick C. Hodgin wrote: > >>> Because it would work in wholly replicable logic within the FPGA, > >>> requiring nothing other than connecting up pins. > >> You mean like SPI, I2C, async serial, etc, etc, etc... > > > > I don't know of any of those other than by their names used in > > various technical specs I've read over time. If they work like > > the one I'm proposing, then what's the big deal? The protocol > > I would define would include a 16-bit word for the target sub- > > unit, a 16-bit word for the payload length, and then the payload. > > I'm not sure what you are proposing. Sounds more like you are > describing a software protocol. If you want to do your own thing > fine, but there are times when compatibility can be useful and > reinventing the wheel is seldom an advantage. I don't understand how what I'm doing is reinventing the wheel if I am merely hooking up a few pins and using 0s and 1s in data interchange on a fixed clock. It sounds like I'm applying the most fundamental concepts of data interchange available in FPGA programming. From my point of view, employing some proprietary communications hardware and/or its software protocols of peculiar format, ones which may even require the data I would pass from one unit to another be re- formatted in some protocol-required way for transmission, and then de- coded upon receipt, seems be the more undesirable path. > >>> FWIW, I'm talking about slow device on-motherboard communications here, > >>> and potentially some remote debugging communication across multi-CPUs > >>> through a single interface. > >> You mean like SPI, I2C, async serial, etc, etc, etc... > >> > >> One *big* advantage to using something standard is that other devices > >> can talk to it, not just your designs. If you get into a tough spot you > >> can even get low cost debuggers for any of these other protocols. > > > > I am writing my own debugger. > > I'm not talking about a software debugger. I'm talking about a debugger > for your interface. Call it a scope then. I am writing a debugger which will cover these things. Whatever is going on inside the FPGA will be able to be ported out through the Ethernet into the debugger based on various register settings. I will write the debugger to understand the hardware it relates to, providing even graphical images of the data communication. From what I have seen, efforts to get the Ethernet protocol up and running should be simple and straight-forward enough. We'll see though. I'm prepared to spend as much time as it takes, posting my code so people can help me if I'm doing something incorrectly. I can also always fall back on the default connections which exist on the Altera dev board until I get it debugged. Once it's written, however, it will be available for all from that point forward. Any port of the verilog code to other devices should be doable through that TI chip. > >>>>>> For RS232, the FPGA pins go to level converters to convert to the > >>>>>> appropriate voltages, but all the logic (UART) is in the FPGA. > >>>>> I am absolutely loving this project so far. I think it's my all-time > >>>>> favorite. > >>>> > >>>> I assume it is all just for fun? > >>> > >>> No. It is to become the foundation of a hardware and software stack > >>> I am creating that has roots in the 80386 design, but has been modified > >>> to be simpler, and has been extended out to 40-bits. > >> > >> To what end? > > > > I am a Christian. I desire to create a hardware and software stack > > from the ground up, one focused upon an offering of sharing and love, > > rather than of profits, sales goals, and proprietary hardware locks. > > > > I would also like to create the tools to produce the semiconductor > > products as well, which I plan to do after I get my CPU designed. > > I will design the layout and routing tools, and move toward > > manufacturing. > > The fact that it is going to be open source doesn't remove it from the > world of markets. What need is this satisfying? Clearly you expect > others to use it. Have you made any efforts to see what others want > from such devices? It is not open source. It's in the Public Domain. I have created a license model which indicates that our responsibilities tie back to God, and not to our legal system, that my wishes are that the software remains open, and that, just as God gave us this world and instructed us on how to use it, allowing us to choose for ourselves, and warning us of the consequences if we use it in a manner contrary to His instruction, and how we are all accountable unto Him for how we use it, and how we treat one another, and for everything involved with our lives, so are we also accountable unto Him for how we honor other people's wishes with regards to offerings which stem from Him in the first place. Jesus Christ gave me the knowledge and skills I possess. I did not garner them on my own. I was endowed at birth with whatever abilities I possess. And the opportunities I've had in my life, may of which I've flatly squandered due to my own ignorance and stupidity, still all of these were a gift from Him unto me. And I now acknowledge that, and I cite that explicitly in my license. When people take my offering and use it for other ends, they are doing it to Him, and not just me, and, per His instruction (Revelation 22:10-12), I will let Him take full account of all such movements. > What if you build it and nobody comes because you built something no > one wants? It is a common mis-perception that Christians operate alone in this world. We are not alone. God is with us, living inside of our heart, our minds, continually. This is true of all born again Christians. And all such efforts given over unto God from that inner place of the changed heart, these are all known unto God, and it is He who then moves in this world, moving us to and fro, moving others to and fro, drawing us from within toward His ends as per His plans and purposes (John 3:3,6-8). Yet, if nobody comes because I built something no one wants, then I will, at the end of my time upon this Earth, stand before God and say, "I spent the last N years of my life doing everything I could for You, by name, asking for help, finding nobody to assist me, nobody to use the offerings I created using the skills and talents You gave me, yet I persisted because from within my heart I was doing it for You." It is enough to live this way for the Lord. Best regards, Rick C. HodginArticle: 157395
On 12/2/2014 10:45 PM, Rick C. Hodgin wrote: > > It is enough to live this way for the Lord. So what is guiding your technical decisions in designing this processor? For example, why 40 bits? Isn't that going to make some features of the 386 difficult or impossible to implement? -- RickArticle: 157396
On Tuesday, December 2, 2014 11:07:46 PM UTC-5, rickman wrote: > On 12/2/2014 10:45 PM, Rick C. Hodgin wrote: > > It is enough to live this way for the Lord. > > So what is guiding your technical decisions in designing this > processor? > For example, why 40 bits? Isn't that going to make some features > of the 386 difficult or impossible to implement? https://github.com/RickCHodgin/libsf/blob/master/li386/li386-documentation/images/eflags.png 40-bits takes you to 1 Terabyte. If more is needed later, the LibSF 386-x48 can be created. Best regards, Rick C. HodginArticle: 157397
On 12/2/2014 11:10 PM, Rick C. Hodgin wrote: > On Tuesday, December 2, 2014 11:07:46 PM UTC-5, rickman wrote: >> On 12/2/2014 10:45 PM, Rick C. Hodgin wrote: >>> It is enough to live this way for the Lord. >> >> So what is guiding your technical decisions in designing this >> processor? >> For example, why 40 bits? Isn't that going to make some features >> of the 386 difficult or impossible to implement? > > https://github.com/RickCHodgin/libsf/blob/master/li386/li386-documentation/images/eflags.png > > 40-bits takes you to 1 Terabyte. If more is needed later, the > LibSF 386-x48 can be created. So you have a requirement for 1 TB of address space. What are your other requirements, but more importantly, what is driving those requirements? -- RickArticle: 157398
On Tuesday, December 2, 2014 11:16:29 PM UTC-5, rickman wrote: > On 12/2/2014 11:10 PM, Rick C. Hodgin wrote: > > On Tuesday, December 2, 2014 11:07:46 PM UTC-5, rickman wrote: > >> On 12/2/2014 10:45 PM, Rick C. Hodgin wrote: > >>> It is enough to live this way for the Lord. > >> > >> So what is guiding your technical decisions in designing this > >> processor? > >> For example, why 40 bits? Isn't that going to make some features > >> of the 386 difficult or impossible to implement? > > > > https://github.com/RickCHodgin/libsf/blob/master/li386/li386-documentation/images/eflags.png > > > > 40-bits takes you to 1 Terabyte. If more is needed later, the > > LibSF 386-x48 can be created. > > So you have a requirement for 1 TB of address space. What are your > other requirements, but more importantly, what is driving those > requirements? I have no particular hardware requirements except that from the ground up it be a love offering unto the Lord. I have a background in x86 space from before I was a Christian, and I'm taking that knowledge forward, coupled with the things I've wanted or wished for in x86 space throughout my career. Ultimately I desire to have a CPU, all motherboard resources, any BIOS or firmware, the kernel, operating system, and all end-user software, be created from the LibSF offerings, with all of it being given unto the world without restriction, as a foundation or base upon which to build. I would like to be able to work with 14nm process technologies, and create CPUs that would outperform anything that exists ... but it's not the place the Lord has me. I am Rick C. Hodgin from Indiana. No riches. No skills in such things. I am waiting for others to come forward and offer up those things which they have in a similar way so that we can walk together, arm in arm, for the Lord. I believe very strongly that we could give unto the world as good or better as anything else that's out there because we'd be serving the Lord, listening to Him, doing what we do for Him, not taking shortcuts, not being pressed for quarterly fiscal deadlines, but rather being able to do it right because it's our best we desire to give. It's up to Him though. I've been working on this project for over 28 months. I haven't found anyone to help me yet, though several people have been interested at various times, none of them had the necessary C/C++ coding skills to contribute. I've contacted Christian universities, posted on forums, etc. But, I am hopeful. :-) Best regards, Rick C. HodginArticle: 157399
On 12/2/2014 11:27 PM, Rick C. Hodgin wrote: > On Tuesday, December 2, 2014 11:16:29 PM UTC-5, rickman wrote: >> On 12/2/2014 11:10 PM, Rick C. Hodgin wrote: >>> On Tuesday, December 2, 2014 11:07:46 PM UTC-5, rickman wrote: >>>> On 12/2/2014 10:45 PM, Rick C. Hodgin wrote: >>>>> It is enough to live this way for the Lord. >>>> >>>> So what is guiding your technical decisions in designing this >>>> processor? >>>> For example, why 40 bits? Isn't that going to make some features >>>> of the 386 difficult or impossible to implement? >>> >>> https://github.com/RickCHodgin/libsf/blob/master/li386/li386-documentation/images/eflags.png >>> >>> 40-bits takes you to 1 Terabyte. If more is needed later, the >>> LibSF 386-x48 can be created. >> >> So you have a requirement for 1 TB of address space. What are your >> other requirements, but more importantly, what is driving those >> requirements? > > I have no particular hardware requirements except that from the ground > up it be a love offering unto the Lord. I have a background in x86 > space from before I was a Christian, and I'm taking that knowledge > forward, coupled with the things I've wanted or wished for in x86 > space throughout my career. > > Ultimately I desire to have a CPU, all motherboard resources, any > BIOS or firmware, the kernel, operating system, and all end-user > software, be created from the LibSF offerings, with all of it being > given unto the world without restriction, as a foundation or base > upon which to build. I'm not familiar with LibSF. I assume you don't mean, "Libsf is a stack fingerprinting library" which I found on the web. > I would like to be able to work with 14nm process technologies, and > create CPUs that would outperform anything that exists ... but it's > not the place the Lord has me. I am Rick C. Hodgin from Indiana. > No riches. No skills in such things. I am waiting for others to > come forward and offer up those things which they have in a similar > way so that we can walk together, arm in arm, for the Lord. I > believe very strongly that we could give unto the world as good or > better as anything else that's out there because we'd be serving > the Lord, listening to Him, doing what we do for Him, not taking > shortcuts, not being pressed for quarterly fiscal deadlines, but > rather being able to do it right because it's our best we desire > to give. That's the part I don't understand. Here you say you are, "listening to Him", but how does that turn into defining a CPU? Why/how is the CPU you are designing any better for "Him" or anyone else than any other CPU you might design? > It's up to Him though. I've been working on this project for over > 28 months. I haven't found anyone to help me yet, though several > people have been interested at various times, none of them had the > necessary C/C++ coding skills to contribute. I've contacted > Christian universities, posted on forums, etc. But, I am hopeful. > :-) Maybe if you find a way to express the motivation and the guiding principles so that others can understand. -- 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