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 wrote: > [snip] Watch the videos, Rick. Best regards, Rick C. HodginArticle: 158826
Hi Everyone, I want to know what are the challenges in data science and cloud computing which are being faced today and can be solved with FPGAs.Article: 158827
On 23.04.2016 11:08, Prasad Pandit wrote: > Hi Everyone, > > I want to know what are the challenges in data science and cloud computing which are being faced today and can be solved with FPGAs. > Hi. I want to know what are the challenges in agriculture which are being faced today and can be solved with a shovel. GeneArticle: 158828
On 23/04/2016 09:08, Prasad Pandit wrote: > Hi Everyone, > > I want to know what are the challenges in data science and cloud computing which are being faced today and can be solved with FPGAs. > Sounds like a homework question to me, i.e. I have been asked to write about/prepare a presentation on FPGA's in Data Science and Cloud Computing. Rather than try and get us to do all the work why not google it and if there are things in the results you do not understand, or applications you think are missing, then come and ask about them. Of course of you read the marketing then the FPGA is the answer to every question... DaveArticle: 158829
Hi, I found it useful to be able to control my IPbus ( https://svnweb.cern.ch/trac/cactus ) connected logic from an AXI4 master. It may be used e.g. for testing or for porting the design to the ARM equipped FPGA (Zynq of Cyclone 5?). Of course in the latter case the next step should be writing an IPbus Control Hub for ARM, working as the AXI master... At the moment I have written a very simple bridge, allowing you to control your IPbus compatible logic from an AXI master. As AXI uses the byte addresses and IPbus uses word addresses, the AXI address is shifted right by 2 bits (divided by 4). As IPbus does not support single byte accesses, the bridge allows only accesses to the whole word (you'll get bus error if you try to access a single byte, two or three bytes in the word). This implementation wraps your IPbus controlled logic as "slaves" entity. Of course if it has additional ports except of the IPbus, you must add necessary ports in the axil2ipb entity and connect them. This is a first attempt to write such a bridge. It has not been tested very thoroughly, so don't be surprised if something works incorrectly. You use it on your own risk! This is a PUBLIC DOMAIN code (according to Creative Commons CC0 license) so it is published without any warranty. (Anyway I hope, that somebody may found it useful). The sources may be found at https://svnweb.cern.ch/trac/cactus/ticket/1876 or on the alt.sources group: https://groups.google.com/forum/#!topic/alt.sources/b2DpVU4A5Yo With best regards, WojtekArticle: 158830
The thread on spinning a 386 in an FPGA made me think about the FPGA boards available. I know you can find boards that are inexpensive and you can find FPGA boards that have support for processor oriented devices like RAM, Flash, Ethernet, etc. But is there any overlap between these requirements? I figured it should be practical to produce a board with SDRAM, a NAND Flash chip and the minimum interface needed for a few interfaces, Ethernet, USB 3.0, HDMI and maybe SATA so that any processor you can envision could be prototyped in the FPGA and communicate with the real world. Does this board exist? -- RickArticle: 158831
rickman <gnuarm@gmail.com> wrote: > I figured it should be practical to produce a board with SDRAM, a NAND > Flash chip and the minimum interface needed for a few interfaces, > Ethernet, USB 3.0, HDMI and maybe SATA so that any processor you can > envision could be prototyped in the FPGA and communicate with the real > world. This is something I'm doing at the moment. We do have a (somewhat heavyweight) processor which is constrained by its I/O. Altera's Cyclone V SoC parts have an ARM side and an FPGA side, joined by cache-coherent bridges. On the ARM side are various hard peripherals (micro SD, 1G ethernet, USB, DDR3). It's possible to configure the bridges so that the FPGA can look over the wall at the ARM-side peripherals, and so the FPGA can map ARM-side peripherals into its own Avalon/AXI memory space. This is more efficient than external chips, because there are not many external chips for driving these kinds of embedded interfaces (most separate-package USB/SD/SATA controllers would speak PCIe, which isn't what you want) However, once you have that setup you probably want to run the driver stack on ARM Linux (drivers for things like USB being a pain, see our previous conversation) and provide a more abstract interface to the FPGA - for example a simple block device rather than dealing with the Synopsys USB controller and USB mass storage. Then you can get away with a much more minimal software overhead on the FPGA. The cheapest Cyclone V SoC board, the DE0-Nano-SoC is $99, though the FPGA isn't very big: http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=167&No=941 On the Arria 10 (and Stratix 10) the ARM and FPGA are more integrated, so you can access the peripherals from either side. But there's no cheap Arria 10 as yet. There are also no Stratix IV/V parts with ARMs on them. I don't know if Zynq can do something similar - anyone have more experience with Xilinx-land? TheoArticle: 158832
On Mon, 25 Apr 2016 19:14:22 +0100, Theo Markettos wrote: > rickman <gnuarm@gmail.com> wrote: >> I figured it should be practical to produce a board with SDRAM, a NAND >> Flash chip and the minimum interface needed for a few interfaces, >> Ethernet, USB 3.0, HDMI and maybe SATA so that any processor you can >> envision could be prototyped in the FPGA and communicate with the real >> world. > > This is something I'm doing at the moment. We do have a (somewhat > heavyweight) processor which is constrained by its I/O. > > Altera's Cyclone V SoC parts have an ARM side and an FPGA side, joined > by cache-coherent bridges. On the ARM side are various hard peripherals > (micro SD, 1G ethernet, USB, DDR3). It's possible to configure the > bridges so that the FPGA can look over the wall at the ARM-side > peripherals, and so the FPGA can map ARM-side peripherals into its own > Avalon/AXI memory space. > > This is more efficient than external chips, because there are not many > external chips for driving these kinds of embedded interfaces (most > separate-package USB/SD/SATA controllers would speak PCIe, which isn't > what you want) > > However, once you have that setup you probably want to run the driver > stack on ARM Linux (drivers for things like USB being a pain, see our > previous conversation) and provide a more abstract interface to the FPGA > - for example a simple block device rather than dealing with the > Synopsys USB controller and USB mass storage. Then you can get away > with a much more minimal software overhead on the FPGA. > > The cheapest Cyclone V SoC board, the DE0-Nano-SoC is $99, though the > FPGA isn't very big: > http://www.terasic.com.tw/cgi-bin/page/archive.pl? Language=English&CategoryNo=167&No=941 > > On the Arria 10 (and Stratix 10) the ARM and FPGA are more integrated, > so you can access the peripherals from either side. But there's no > cheap Arria 10 as yet. There are also no Stratix IV/V parts with ARMs > on them. > > I don't know if Zynq can do something similar - anyone have more > experience with Xilinx-land? Here's one in a familiar form factor at about the same price: <http://www.trenz-electronic.de/products/fpga-boards/trenz-electronic/te0726-zynq.html> It has some odd design decisions though - the Ethernet goes through a USB to Ethernet adapter, rather than using the native controller. (I guess one can take the "Pi-compatibility" thing too seriously.) Regards, AllanArticle: 158833
On 4/25/2016 6:27 PM, Allan Herriman wrote: > On Mon, 25 Apr 2016 19:14:22 +0100, Theo Markettos wrote: > >> rickman <gnuarm@gmail.com> wrote: >>> I figured it should be practical to produce a board with SDRAM, a NAND >>> Flash chip and the minimum interface needed for a few interfaces, >>> Ethernet, USB 3.0, HDMI and maybe SATA so that any processor you can >>> envision could be prototyped in the FPGA and communicate with the real >>> world. >> >> This is something I'm doing at the moment. We do have a (somewhat >> heavyweight) processor which is constrained by its I/O. >> >> Altera's Cyclone V SoC parts have an ARM side and an FPGA side, joined >> by cache-coherent bridges. On the ARM side are various hard peripherals >> (micro SD, 1G ethernet, USB, DDR3). It's possible to configure the >> bridges so that the FPGA can look over the wall at the ARM-side >> peripherals, and so the FPGA can map ARM-side peripherals into its own >> Avalon/AXI memory space. >> >> This is more efficient than external chips, because there are not many >> external chips for driving these kinds of embedded interfaces (most >> separate-package USB/SD/SATA controllers would speak PCIe, which isn't >> what you want) >> >> However, once you have that setup you probably want to run the driver >> stack on ARM Linux (drivers for things like USB being a pain, see our >> previous conversation) and provide a more abstract interface to the FPGA >> - for example a simple block device rather than dealing with the >> Synopsys USB controller and USB mass storage. Then you can get away >> with a much more minimal software overhead on the FPGA. >> >> The cheapest Cyclone V SoC board, the DE0-Nano-SoC is $99, though the >> FPGA isn't very big: >> http://www.terasic.com.tw/cgi-bin/page/archive.pl? > Language=English&CategoryNo=167&No=941 >> >> On the Arria 10 (and Stratix 10) the ARM and FPGA are more integrated, >> so you can access the peripherals from either side. But there's no >> cheap Arria 10 as yet. There are also no Stratix IV/V parts with ARMs >> on them. >> >> I don't know if Zynq can do something similar - anyone have more >> experience with Xilinx-land? > > Here's one in a familiar form factor at about the same price: > <http://www.trenz-electronic.de/products/fpga-boards/trenz-electronic/te0726-zynq.html> > > It has some odd design decisions though - the Ethernet goes through > a USB to Ethernet adapter, rather than using the native controller. > (I guess one can take the "Pi-compatibility" thing too seriously.) Interesting board. That is an odd decision though. Won't the kernel need to be recompiled for this compared to the rPi? So why worry with making the Ethernet driver compatible? -- Rick CArticle: 158834
On Mon, 25 Apr 2016 21:18:18 -0400, rickman wrote: > On 4/25/2016 6:27 PM, Allan Herriman wrote: >> On Mon, 25 Apr 2016 19:14:22 +0100, Theo Markettos wrote: >> >>> rickman <gnuarm@gmail.com> wrote: >>>> I figured it should be practical to produce a board with SDRAM, a NAND >>>> Flash chip and the minimum interface needed for a few interfaces, >>>> Ethernet, USB 3.0, HDMI and maybe SATA so that any processor you can >>>> envision could be prototyped in the FPGA and communicate with the real >>>> world. >>> >>> This is something I'm doing at the moment. We do have a (somewhat >>> heavyweight) processor which is constrained by its I/O. >>> >>> Altera's Cyclone V SoC parts have an ARM side and an FPGA side, joined >>> by cache-coherent bridges. On the ARM side are various hard peripherals >>> (micro SD, 1G ethernet, USB, DDR3). It's possible to configure the >>> bridges so that the FPGA can look over the wall at the ARM-side >>> peripherals, and so the FPGA can map ARM-side peripherals into its own >>> Avalon/AXI memory space. >>> >>> This is more efficient than external chips, because there are not many >>> external chips for driving these kinds of embedded interfaces (most >>> separate-package USB/SD/SATA controllers would speak PCIe, which isn't >>> what you want) >>> >>> However, once you have that setup you probably want to run the driver >>> stack on ARM Linux (drivers for things like USB being a pain, see our >>> previous conversation) and provide a more abstract interface to the FPGA >>> - for example a simple block device rather than dealing with the >>> Synopsys USB controller and USB mass storage. Then you can get away >>> with a much more minimal software overhead on the FPGA. >>> >>> The cheapest Cyclone V SoC board, the DE0-Nano-SoC is $99, though the >>> FPGA isn't very big: >>> http://www.terasic.com.tw/cgi-bin/page/archive.pl? >> Language=English&CategoryNo=167&No=941 >>> >>> On the Arria 10 (and Stratix 10) the ARM and FPGA are more integrated, >>> so you can access the peripherals from either side. But there's no >>> cheap Arria 10 as yet. There are also no Stratix IV/V parts with ARMs >>> on them. >>> >>> I don't know if Zynq can do something similar - anyone have more >>> experience with Xilinx-land? >> >> Here's one in a familiar form factor at about the same price: >> <http://www.trenz-electronic.de/products/fpga-boards/trenz-electronic/ te0726-zynq.html> >> >> It has some odd design decisions though - the Ethernet goes through >> a USB to Ethernet adapter, rather than using the native controller. >> (I guess one can take the "Pi-compatibility" thing too seriously.) > > Interesting board. That is an odd decision though. Won't the kernel > need to be recompiled for this compared to the rPi? So why worry with > making the Ethernet driver compatible? I was joking about the Pi compatibility. I don't expect that this board would be running a distro like Raspbian. It's hard to know the designer's intent. For all I know, he chose to forgo the native Gb Ethernet interface because there wasn't enough room for a PHY (and its power supply), although looking at the block diagram, it seems more likely that he wanted to reserve the pins for GPIOs (I assume the 53 MIO pins are shared between the bootflash, USB, UART, SDCard and the GPIO). Regards, AllanArticle: 158835
On Tue, 26 Apr 2016 10:57:34 +0000, Allan Herriman wrote: > On Mon, 25 Apr 2016 21:18:18 -0400, rickman wrote: > >> On 4/25/2016 6:27 PM, Allan Herriman wrote: >>> On Mon, 25 Apr 2016 19:14:22 +0100, Theo Markettos wrote: >>> >>>> rickman <gnuarm@gmail.com> wrote: >>>>> I figured it should be practical to produce a board with SDRAM, a > NAND >>>>> Flash chip and the minimum interface needed for a few interfaces, >>>>> Ethernet, USB 3.0, HDMI and maybe SATA so that any processor you can >>>>> envision could be prototyped in the FPGA and communicate with the > real >>>>> world. >>>> >>>> This is something I'm doing at the moment. We do have a (somewhat >>>> heavyweight) processor which is constrained by its I/O. >>>> >>>> Altera's Cyclone V SoC parts have an ARM side and an FPGA side, >>>> joined by cache-coherent bridges. On the ARM side are various hard > peripherals >>>> (micro SD, 1G ethernet, USB, DDR3). It's possible to configure the >>>> bridges so that the FPGA can look over the wall at the ARM-side >>>> peripherals, and so the FPGA can map ARM-side peripherals into its >>>> own Avalon/AXI memory space. >>>> >>>> This is more efficient than external chips, because there are not >>>> many external chips for driving these kinds of embedded interfaces >>>> (most separate-package USB/SD/SATA controllers would speak PCIe, >>>> which isn't what you want) >>>> >>>> However, once you have that setup you probably want to run the driver >>>> stack on ARM Linux (drivers for things like USB being a pain, see our >>>> previous conversation) and provide a more abstract interface to the > FPGA >>>> - for example a simple block device rather than dealing with the >>>> Synopsys USB controller and USB mass storage. Then you can get away >>>> with a much more minimal software overhead on the FPGA. >>>> >>>> The cheapest Cyclone V SoC board, the DE0-Nano-SoC is $99, though the >>>> FPGA isn't very big: >>>> http://www.terasic.com.tw/cgi-bin/page/archive.pl? >>> Language=English&CategoryNo=167&No=941 >>>> >>>> On the Arria 10 (and Stratix 10) the ARM and FPGA are more >>>> integrated, >>>> so you can access the peripherals from either side. But there's no >>>> cheap Arria 10 as yet. There are also no Stratix IV/V parts with >>>> ARMs on them. >>>> >>>> I don't know if Zynq can do something similar - anyone have more >>>> experience with Xilinx-land? >>> >>> Here's one in a familiar form factor at about the same price: >>> <http://www.trenz-electronic.de/products/fpga-boards/trenz-electronic/ > te0726-zynq.html> >>> >>> It has some odd design decisions though - the Ethernet goes through a >>> USB to Ethernet adapter, rather than using the native controller. (I >>> guess one can take the "Pi-compatibility" thing too seriously.) >> >> Interesting board. That is an odd decision though. Won't the kernel >> need to be recompiled for this compared to the rPi? So why worry with >> making the Ethernet driver compatible? > > I was joking about the Pi compatibility. I don't expect that this board > would be running a distro like Raspbian. > > It's hard to know the designer's intent. For all I know, he chose to > forgo the native Gb Ethernet interface because there wasn't enough room > for a PHY (and its power supply), although looking at the block diagram, > it seems more likely that he wanted to reserve the pins for GPIOs (I > assume the 53 MIO pins are shared between the bootflash, USB, UART, > SDCard and the GPIO). I should have looked at the schematic instead of the block diagram. The GPIOs are connected to Bank 34 (on the PL, not the PS), and the 53 MIO pins on the PS are used for I2C, USB, SDCard, QSPI (bootflash) and some GPIO connected to a MACHX02 CPLD. It seems the designer simply ran out of MIO pins and wasn't able to fit in Ethernet (although this could have been run through the EMIO to PL pins). On Zynq designs of mine, I've managed to fit in USB, bootflash, SDCard, Ethernet, UARTs, I2C and some GPIO on the MIO, and a second Ethernet port via EMIO and PL pins. Regards, AllanArticle: 158836
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 I have been in contact with Amanda from their sales department. They are unwilling to sell me a single board with hardware interface because I am not a company, and do not / will not have volume throughput. However, I have also found out they sell a Soft x86 IP Core which is for Altera FPGAs, so I am finding out if they will sell me a copy of that core or not, and how much it costs. Now, off to pray... :-) Best regards, Rick C. HodginArticle: 158837
On 26.04.2016 16:11, Rick C. Hodgin wrote: >> http://www.forcetechnologies.co.uk/downloads/x86-Processor-Recreation > > I have been in contact with Amanda from their sales department. They are > unwilling to sell me a single board with hardware interface because I am > not a company, and do not / will not have volume throughput. Why don't you tell them that you maybe will order 10k boards, but first you need a free demo board. > Now, off to pray... :-) That doesn't help. Don't pray but lie if you want a board.Article: 158838
Prasad Pandit <prasadp4009@gmail.com> writes: > I want to know what are the challenges in data science and cloud > computing which are being faced today and can be solved with FPGAs. The main challenge with respect to FPGA/ASIC in data science and machine learning today is to fight the misconception that solving the problem require a GPU and floating point support. //Petter -- .sig removed by request.Article: 158839
Sorry for the long latency guys, I don't have much time in the day for myself, so Usenet often suffers. :) On Sat, 09 Apr 2016 10:42:23 -0400, rickman wrote: > On 4/9/2016 6:00 AM, Aleksandar Kuktin wrote: >> On Wed, 06 Apr 2016 13:38:19 -0700, Rick C. Hodgin wrote: >> I designed and implemented a 16-bit soft CPU from scratch, and I can >> tell you it's seriously difficult to make it work. Right now, I'm >> hacking a 32- >> bit CPU (aeMB, to be very specific) and interfacing it to a SoC I plan >> to publish eventually and again, it's seriously difficult to make it >> work. > > 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. I find difficulty in producing a design that is simultaneously low- latency, high speed and feature-full. To obtain low latency, you really can't use registers as much as you would like, and instead have to shift a lot of the logic into gates (pure asynchronous logic). However, if you do that, you quickly add up a too long chain of gates that can not be run at high clock rates. Finally, if you get both of these, you probably won't have enough wiggle room left over for features. Right now, with what I'm currently working on, I have a blessing in that I don't have to run the circuit very fast so I can get away with three- gate deep logic, maybe even four gate deep. But if I were going for break- neck speeds, I would be constrained to logic two LUT4 gates deep. Only so many features can be crammed into a design made with that. :) >> If you add a bit to the word or address size, you are not just doubling >> the CPUs capabilities, you are also doubling the number, size and scope >> of problems you have to deal with. > > ??? My CPU design did not specify the data size, only the instruction > size. I didn't have a problem adjusting the data size to suit my > application. I suppose you can parameterize the data size, and later change the definition of the parameter to suit. The problem - for me - is the underlying result which still needs to fit in the real world. This may have something to do with the way I cram as much "stuff" into a chip as I can. It was only here that I learned you should consider your chip "full" when it start reaching 80% utilization. For me, over 95% is common. Adding a single bit to a round number can throw the synthesis results way out of optimum. Adding one more can make the gate chain too long to fit into a clock cycle. Changing the clock period can be impossible because the design could have several other interlocking clocks. And on and on. For example - I discovered that the synthesis tool I used (Lattices synthesizer) would produce a sub-optimal result if a unit - say a module - had even a single odd-sized register. Changing the register sizes to even numbers makes synthesis much better, even if it does throw away a bit. >>>> Does simulation count? :D >>> >>> Yes. Also in emulation, as by a real FPGA product, but one which does >>> not plug into a socket, but is its own entire creation. Here's an >>> Aleksander who created a 486 SX CPU (it has not integrated FPU): >>> >>> https://github.com/alfikpl/ao486 >> >> Verily, I shall review this. I'm starting to get the impression that >> all the stuff I'm making on my own has already been solved, but hasn't >> been advertised. I'm working on my dream computer, but these solved >> systems constantly keep popping up. Maybe all of it has already been >> solved? > > Exactly what is your dream computer? A device whose design can fit in my head, that is transparent and serviceable on all levels, free(-as-in-freedom), secure and usable for real-world tasks. I should probably put "usable" at the top of the list. :) Right now, that would mean a FPGA-implemented FOSH SoC that is self- contained. That means, which can regenerate the images and binaries of itself, by itself (so you don't need a second computer for that).Article: 158840
On 5/1/2016 2:24 PM, Aleksandar Kuktin wrote: > Sorry for the long latency guys, I don't have much time in the day for > myself, so Usenet often suffers. :) > > On Sat, 09 Apr 2016 10:42:23 -0400, rickman wrote: > >> On 4/9/2016 6:00 AM, Aleksandar Kuktin wrote: >>> On Wed, 06 Apr 2016 13:38:19 -0700, Rick C. Hodgin wrote: > >>> I designed and implemented a 16-bit soft CPU from scratch, and I can >>> tell you it's seriously difficult to make it work. Right now, I'm >>> hacking a 32- >>> bit CPU (aeMB, to be very specific) and interfacing it to a SoC I plan >>> to publish eventually and again, it's seriously difficult to make it >>> work. >> >> 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. > > I find difficulty in producing a design that is simultaneously low- > latency, high speed and feature-full. To obtain low latency, you really > can't use registers as much as you would like, and instead have to shift > a lot of the logic into gates (pure asynchronous logic). However, if you > do that, you quickly add up a too long chain of gates that can not be run > at high clock rates. Finally, if you get both of these, you probably > won't have enough wiggle room left over for features. > > Right now, with what I'm currently working on, I have a blessing in that > I don't have to run the circuit very fast so I can get away with three- > gate deep logic, maybe even four gate deep. But if I were going for break- > neck speeds, I would be constrained to logic two LUT4 gates deep. Only so > many features can be crammed into a design made with that. :) Maybe I don't know what you mean by fast and not fast. Got some numbers? >>> If you add a bit to the word or address size, you are not just doubling >>> the CPUs capabilities, you are also doubling the number, size and scope >>> of problems you have to deal with. >> >> ??? My CPU design did not specify the data size, only the instruction >> size. I didn't have a problem adjusting the data size to suit my >> application. > > I suppose you can parameterize the data size, and later change the > definition of the parameter to suit. Not just parameters, but the instruction format doesn't care. Literals are built up in 7 bit chunks from an 8 bit instruction or 8 bit chunks with a 9 bit instruction since many FPGAs have memory and multipliers 9 bit wide multiples. The data path has no restrictions on width. > The problem - for me - is the underlying result which still needs to fit > in the real world. This may have something to do with the way I cram as > much "stuff" into a chip as I can. It was only here that I learned you > should consider your chip "full" when it start reaching 80% utilization. > For me, over 95% is common. I'm not sure how that related to CPU designs. It has to be a very complex CPU to not fit in any but the very smallest FPGAs. My CPU was about 600 LUTs which is not uncommon for MISC. > Adding a single bit to a round number can throw the synthesis results way > out of optimum. Adding one more can make the gate chain too long to fit > into a clock cycle. Changing the clock period can be impossible because > the design could have several other interlocking clocks. And on and on. Now you are way outside the issues of CPU design. Now you are in the design of your application. > For example - I discovered that the synthesis tool I used (Lattices > synthesizer) would produce a sub-optimal result if a unit - say a module > - had even a single odd-sized register. Changing the register sizes to > even numbers makes synthesis much better, even if it does throw away a > bit. What was suboptimal about a register? What sort of unit? >>>>> Does simulation count? :D >>>> >>>> Yes. Also in emulation, as by a real FPGA product, but one which does >>>> not plug into a socket, but is its own entire creation. Here's an >>>> Aleksander who created a 486 SX CPU (it has not integrated FPU): >>>> >>>> https://github.com/alfikpl/ao486 >>> >>> Verily, I shall review this. I'm starting to get the impression that >>> all the stuff I'm making on my own has already been solved, but hasn't >>> been advertised. I'm working on my dream computer, but these solved >>> systems constantly keep popping up. Maybe all of it has already been >>> solved? >> >> Exactly what is your dream computer? > > A device whose design can fit in my head, that is transparent and > serviceable on all levels, free(-as-in-freedom), secure and usable for > real-world tasks. I should probably put "usable" at the top of the > list. :) > > Right now, that would mean a FPGA-implemented FOSH SoC that is self- > contained. That means, which can regenerate the images and binaries of > itself, by itself (so you don't need a second computer for that). I thought there was already a CPU design like that. RISC-V Does that not fit your description? Check out this page for ideas... http://www.lowrisc.org/ -- Rick CArticle: 158841
I am searching for some Xilinx programmer software for the HW-130 unit from around 1996-2000. Looking the the DOS version. The filename was HW130.ZIP Also looking for the 16-bit windows version HW130W.ZIP. Thank you for any help you can offer!Article: 158842
On 5/3/2016 2:23 PM, Tim Regeant wrote: > I am searching for some Xilinx programmer software for the HW-130 unit > from around 1996-2000. > > Looking the the DOS version. The filename was HW130.ZIP > > Also looking for the 16-bit windows version HW130W.ZIP. > > Thank you for any help you can offer! I have software from that era along with a license key. I could get it to you. -- Rick CArticle: 158843
On 5/3/2016 2:32 PM, rickman wrote: > On 5/3/2016 2:23 PM, Tim Regeant wrote: >> I am searching for some Xilinx programmer software for the HW-130 unit >> from around 1996-2000. >> >> Looking the the DOS version. The filename was HW130.ZIP >> >> Also looking for the 16-bit windows version HW130W.ZIP. >> >> Thank you for any help you can offer! > > I have software from that era along with a license key. I could get it > to you. > Sure, shoot me an email. Thanks.Article: 158844
On Tuesday, May 3, 2016 at 2:50:26 PM UTC-4, Tim Regeant wrote: > On 5/3/2016 2:32 PM, rickman wrote: > > On 5/3/2016 2:23 PM, Tim Regeant wrote: > >> I am searching for some Xilinx programmer software for the HW-130 unit > >> from around 1996-2000. > >> > >> Looking the the DOS version. The filename was HW130.ZIP > >> Also looking for the 16-bit windows version HW130W.ZIP. > >> Thank you for any help you can offer! > > > > I have software from that era along with a license key. I could get it > > to you. > > Sure, shoot me an email. Thanks. Make sure it's legal. Some companies maintain licensing restrictions even on obsolete products. Best regards, Rick C. HodginArticle: 158845
Hi, I have added support for "Block Design" components to my vextproj project. There is also a simple demo added, running on the Z-Turn board (http://www.myirtech.com/list.asp?id=502). The demo compiles the bitstream from the project built using the EPRJ files. Additionally the demo allows you to compile Linux with the appropriate device driver and test program, using the Buildroot environment. With best regards, WojtekArticle: 158846
W dniu =C5=9Broda, 4 maja 2016 18:55:44 UTC+2 u=C5=BCytkownik wza...@gmail.= com napisa=C5=82: > Hi, > I have added support for "Block Design" components to my vextproj project= . > There is also a simple demo added, running on the Z-Turn board (http://ww= w.myirtech.com/list.asp?id=3D502).=20 > The demo compiles the bitstream from the project built using the EPRJ fil= es. > Additionally the demo allows you to compile Linux with the appropriate de= vice driver and test program, using the Buildroot environment. >=20 > With best regards, > Wojtek Of course the project is still at https://github.com/wzab/vextprojArticle: 158847
Does Xilinx still make a Matlab (not Simulink) -to-gates tool? I don't thi= nk so, but I was just wondering. Not that I'm looking for one; I was just = wondering. In theory, it would be nice, since I model most things in Matla= b before writing Verilog, but such tools usually aren't great at optimizing= .Article: 158848
W dniu pi=C4=85tek, 6 maja 2016 01:35:04 UTC+2 u=C5=BCytkownik Kevin Neilso= n napisa=C5=82: > Does Xilinx still make a Matlab (not Simulink) -to-gates tool? I don't t= hink so, but I was just wondering. Not that I'm looking for one; I was jus= t wondering. In theory, it would be nice, since I model most things in Mat= lab before writing Verilog, but such tools usually aren't great at optimizi= ng. Do you mean Xilinx System Generator? I think, here you can find more info about its current state. http://www.xilinx.com/products/design-tools/vivado/integration/sysgen.html http://www.xilinx.com/support/documentation-navigation/design-hubs/dh0014-v= ivado-system-generator-hub.html With best regard, WojtekArticle: 158849
I meant *code* conversion, not Simulink (schematic) conversion.
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