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
It can be useful. Thank you. Claude Sylvain Electro-Technica inc. "Kolja Sulimma" <news@sulimma.de> wrote in message news:4413e11b$0$12924$9b4e6d93@newsread4.arcor-online.net... > Claude Sylvain schrieb: > >> b) Build a custom program to read, interpret and program the .svf file >> into >> the PROM, using the Microblaze CPU. > > There is a GPL licensed SVF player available: > https://ssl.keshi.org/projects/logic/trac.fcgi/browser/openwince/current/jtag/README.svf > > Kolja SulimmaArticle: 98526
I got a Linux distro from www.grml.org, and have the 8.1 webpack working on it. This is a small distro, and I think it should be possible to make one CD with Linux and webpack as auto-run, but I only installed on harddisk (from CD would be too slow for me). Interesting is that I did not get the Xilinx GUI working in the install, likely because I changed some stuff in grml, (removed X.org x server and changed to XFree). I moved to grml after I got pissed at all the ever increasing bloat from Suse10. And yes I have the Redhat fedora too as many disks, but this grml is only one CD. So, as all characters in the Xilinx EULA were unreadable, I figured right click button for NO on every question, and it installed itself anyways, so I am free of Eula ;-) Thank you X. Anyways, I copied some libs, (all .so), to /usr/local/lib/xilinx/, added that path to /etc/ld.so.conf, then ran ldconfig. Did export of XILINX from the zhs shell to env, and hey I can do the whole project from scripts. (Without GUI). The impact did not like my X3 par port cable , downloaded 2.6 drivers from X website, still no go. As the digilent lab board I use here at home to test, uses a par port cable with JTAG, started writing jtag code, then found Mr Usselman already did that for us. But his did not work on my system, because I did not have the par port modules and device. So I rewrote his program for direct IO to the parport. You can find it here (if you use digilent digilab board): ftp://panteltje.com/pub/p3j.c Compile with gcc -Wall -O2 -o p3j p3j.c tested on gcc-2.95, gcc-3.3, and gcc-4.0 (yes grml has all these). Thank you Rudolf Usselmann. Nothing is tested very much, maybe more later.Article: 98527
"Antti Lukats" <antti@openchip.org> wrote in message news:duv3bt$f4k$1@online.de... > "Claude Sylvain" <claudesylvain@sympatico.ca> schrieb im Newsbeitrag > news:5%DQf.5551$xM2.463864@news20.bellglobal.com... >>I already found the BSDL description of the XCF02S PROM >>(http://www.xilinx.com/xlnx/xil_sw_updates_display.jsp?BV_UseBVCookie=yes&update=bsdl&software=PROMs). >> >> But, I was not knowing anything about SVF files. That was the missing chain >> ! >> >> Based on what I read in xapp503 >> (http://www.xilinx.com/bvdocs/appnotes/xapp503.pdf), the steps I will have >> to do are: >> >> a) Convert the .bit configuration file to an .svf file, using iMPACT. >> >> b) Build a custom program to read, interpret and program the .svf file >> into the PROM, using the Microblaze CPU. >> >> >> I don't still know the time it takes to program a PROM row. Maybe it is in >> the XCS02S BSDL file, and I have missed it. Nervertless, it can be optained >> by doing iterative test. >> >> >> Thank you for your help. That's exactly the information I want. >> >> Claude Sylvain >> Electro-Technica inc. >> > > the timing is in SVF file if you look at it :) > converting BIT to SVF makes real LARGE files, > you are better to convert to XSVF, or depending your > application just look at the SVF and implement the logic from there > it isnt so complicated. most of the problems I had were related to > special features of the XCF08P (parallel mode options) for XCF02s > there should not be much magic required > > Antti > I think that it will need some time to assimilate all the knowledge necessary to make this job done. But, I have no time constraint on this task, so it is not a problem. Thank you again. Claude Sylvain Electro-Technica inc.Article: 98528
"Antti Lukats" <antti@openchip.org> wrote in message news:duv3bt$f4k$1@online.de... > "Claude Sylvain" <claudesylvain@sympatico.ca> schrieb im Newsbeitrag > news:5%DQf.5551$xM2.463864@news20.bellglobal.com... > > the timing is in SVF file if you look at it :) > converting BIT to SVF makes real LARGE files, > you are better to convert to XSVF, or depending your > application just look at the SVF and implement the logic from there > it isnt so complicated. most of the problems I had were related to > special features of the XCF08P (parallel mode options) for XCF02s > there should not be much magic required > > Antti > Maybe the simpliest way to get the job done is to make a .svf file converter that convert a .svf file (that describe JTAG operation to program a PROM) in term of PROM row content; and use the row programming algorythm included in xapp544 to program each PROM row. This way the file that hold PROM information to program appear exactly the same as a "standard" EPROM file that can be in S-Record or Intel Hex format. This kind of file can be easily uploaded from an host computer to the Microblaze CPU. Claude Sylvain Electro-Technica inc.Article: 98529
I'm wondering why there are so few messages about LEON [1] in this group. LEON looks like a very solid design (used by the ESA) and it is available in a GPL version. Could be a vendor independent replacement of NIOS/MicroBlaze with a path to an ASIC. The configuration is done via a simple Tcl/Tk script and the Makefile contains several targets. Works out-of-the-box for available tragets. Adaption to a new FPGA board [2] took me a few (some) hours - not so bad. What's your experience? Martin [1] http://www.gaisler.com/cms4_5_3/index.php?option=com_content&task=view&id=13&Itemid=53 [2] http://www.jopdesign.com/nios.jspArticle: 98530
hi, I suggest you to see the XST user guide 8.1i (page 93) for more details, there they say because of the reset, your shift register can't be synthetised as Lut configured as shift register .Article: 98531
"Claude Sylvain" <claudesylvain@sympatico.ca> schrieb im Newsbeitrag news:Z0YQf.121$ng.22466@news20.bellglobal.com... > > "Antti Lukats" <antti@openchip.org> wrote in message > news:duv3bt$f4k$1@online.de... >> "Claude Sylvain" <claudesylvain@sympatico.ca> schrieb im Newsbeitrag >> news:5%DQf.5551$xM2.463864@news20.bellglobal.com... >> >> the timing is in SVF file if you look at it :) >> converting BIT to SVF makes real LARGE files, >> you are better to convert to XSVF, or depending your >> application just look at the SVF and implement the logic from there >> it isnt so complicated. most of the problems I had were related to >> special features of the XCF08P (parallel mode options) for XCF02s >> there should not be much magic required >> >> Antti >> > > Maybe the simpliest way to get the job done is to make a .svf file > converter that convert a .svf file (that describe JTAG operation to > program a PROM) in term of PROM row content; and use the row programming > algorythm included in xapp544 to program each PROM row. > > This way the file that hold PROM information to program appear exactly the > same as a "standard" EPROM file that can be in S-Record or Intel Hex > format. This kind of file can be easily uploaded from an host computer to > the Microblaze CPU. > > > Claude Sylvain > Electro-Technica inc. > there is no need for that, just program the .BIT file into the PROM, then write your own data after the bitstream data, no need to convert to svf anttiArticle: 98532
"Martin Schoeberl" <mschoebe@mail.tuwien.ac.at> schrieb im Newsbeitrag news:441451f8$0$11610$3b214f66@tunews.univie.ac.at... > I'm wondering why there are so few messages about LEON [1] > in this group. LEON looks like a very solid design (used > by the ESA) and it is available in a GPL version. > Could be a vendor independent replacement of NIOS/MicroBlaze > with a path to an ASIC. > The configuration is done via a simple Tcl/Tk script and > the Makefile contains several targets. Works out-of-the-box > for available tragets. Adaption to a new FPGA board [2] took > me a few (some) hours - not so bad. > > What's your experience? > > Martin > 2 hours is correct, that what it usually takes to port LEON to new hardware. and the best thing is the LEON system can run FULL MMU enabled linux in spartan3 or any other low cost FPGA! AnttiArticle: 98533
In the early 'sixties, there was the "torsional delay line" memory: A long (>20 m) piece of wire, rolled up and carefully suspended in a box, with transducers at either end that kicked a twist into the wire and sensed it at the other end. The wire materiel was such that the temperature coefficient of the sound-wave propagation speed exactly compensated the expansion of the wire length. We (Sweda Cash Registers in Sweden) tried to put all the memory for a whole cash register in there (15000 bits). It is amazing how creative one can get when storage is that scarce... But we eventually gave up. (And I moved to the US in '66...) Peter AlfkeArticle: 98534
Is it possible to use it without SRAM and only with SDRAM ? "Antti Lukats" <antti@openchip.org> wrote in message news:dv1lus$iaa$1@online.de... > "Martin Schoeberl" <mschoebe@mail.tuwien.ac.at> schrieb im Newsbeitrag > news:441451f8$0$11610$3b214f66@tunews.univie.ac.at... >> I'm wondering why there are so few messages about LEON [1] >> in this group. LEON looks like a very solid design (used >> by the ESA) and it is available in a GPL version. >> Could be a vendor independent replacement of NIOS/MicroBlaze >> with a path to an ASIC. >> The configuration is done via a simple Tcl/Tk script and >> the Makefile contains several targets. Works out-of-the-box >> for available tragets. Adaption to a new FPGA board [2] took >> me a few (some) hours - not so bad. >> >> What's your experience? >> >> Martin >> > > 2 hours is correct, that what it usually takes to port LEON to new > hardware. > > and the best thing is the LEON system can run FULL MMU enabled linux > in spartan3 or any other low cost FPGA! > > Antti >Article: 98535
"Jerome" <nospam@nospam.fr> schrieb im Newsbeitrag news:44145fdd$0$13024$626a54ce@news.free.fr... > Is it possible to use it without SRAM and only with SDRAM ? > well you need some initialized memory unless you are loading the sdram over jtag debugger basically, yes if you have means to load your application or bootloader into sdram there si no need for any other memories anttiArticle: 98536
In article <441451f8$0$11610$3b214f66@tunews.univie.ac.at>, "Martin Schoeberl" <mschoebe@mail.tuwien.ac.at> wrote: > I'm wondering why there are so few messages about LEON [1] > in this group. LEON looks like a very solid design (used > by the ESA) and it is available in a GPL version. > Could be a vendor independent replacement of NIOS/MicroBlaze > with a path to an ASIC. > The configuration is done via a simple Tcl/Tk script and > the Makefile contains several targets. Works out-of-the-box > for available tragets. Adaption to a new FPGA board [2] took > me a few (some) hours - not so bad. > > What's your experience? > > Martin > > > [1] > http://www.gaisler.com/cms4_5_3/index.php?option=com_content&task=view&id=13&I > temid=53 > > [2] http://www.jopdesign.com/nios.jsp its got its own ( yahoo based ) news group. And yes, its pretty cool.Article: 98537
Peter, Or, how about the mercury column? Again, storing bits by whacking the one end of a box filled with merury, and sensing it at the other end? My favorite is the drum memory for the GR15 tube computer: each instruction had the address of the next one. That way it didn't matter what order they were in. In fact dropping the deck of cards, and mixing them up sped up execution (a crude but effective interleave). AustinArticle: 98538
Eric Smith wrote: > metal <nospam@spaam.edu> writes: > >> agree 100% >> >> it is the FPGA makers who are awkward; not the supply voltage. >> >> imho, fpga makers have dropped the ball, by totally ignoring the >> enormous markets of various mixed-signal products; where 5v is VERY >> common...along with generally noisy environments. >> >> I have always been amazed that not a single fpga-maker has made a line >> of small-to-medium sized parts targeted not for blazing speed and >> monster computing functions; but rather, for 5v I/O, all >> Schmitt-trigger inputs, and very low cost. >> >> Imho, such a line would sell like hotcakes. Instead of hard-silicon >> MAC's and such, where are the hard-silicon counter/timer modules, etc. >> ?? >> >> I'd love to be able to buy a $5 part with 64 or 128 flops, and a hard >> block of 8 timer/counters (hardly any chip area in modern silicon). >> I've got =dozens= of apps for such a part. >> >> In any case, it's not the users who are mistaken about 5v; but rather, >> the fpga-makers...who are ignoring the -reality- of -ongoing demand- >> for it, instead of embracing it via a profitable targeted >> product-line. >> >> just m-h-o as one of those pesky 5v users, of course... <g> > > A good MAC is fairly complicated, and as a soft MAC takes up lots of > FPGA real estate, so it makes sense to stick one or two on the die of > larger parts since it's then a fairly small percentage of the part. Not > all the customers benefit, but some benefit a lot, and the others aren't > penalized much. > > But counter-timers don't take up much room in an FPGA, so if you go to > hardwiring those, you don't gain anything, and you lose tons of flexibility. > Inevitably the features of the hardwired timer-counter would never be quite > what you need for any given design. There would be only a small penalty, > but it would be borne by all customers. Very few would get any advantage, > and the advantage would be very modest. The cost/benefit analysis is > much worse than with a MAC. > > If you want them to build some other hardwired logic into their FPGAs, you'll > need to come up with a *much* better example than that. How about speed ? However, what metal was talking about, is a CPLD, not a FPGA. He is looking at the bottom end of the spectrum. Some vendors currently come close : Atmel have low power, 5V parts in the ATF150x series. Xilinx have the CoolRunner2, with the larger ones having a divider chain, but not 5V. but right now, no one has the twin features of 5V Drive and Schmitt Pins. -jgArticle: 98539
Eric Smith wrote: > "Antti" <Antti.Lukats@xilant.com> writes: > >>nice accident ! >>at least we know that number 5 isnt skipped in the Virtex roadmap ;) > > > Assuming that the Marketing department doesn't rename it before offical > introduction. Things like that sometimes happen. > > Presumably the Virtex 5 (or whatever it's going to be called) is the > 65 nm part mentioned in a recent Xilinx press release. Would make sense. > What I'd like to see on the roadmap would be some very-low-leakage > Spartan parts, for use in battery powered devices. They wouldn't need > to be anywhere near as fast as the Spartan 2, nor as dense. Maybe it > could be done with thick oxide in 180, 250, or perhaps even 350 nm. > Gotta do soemthing with all that excess fab capacity in older processes; > might as well make low-leakage FPGAs. :-) I have a sample on the bench that draws 2.4uA, but it is not a Spartan FPGA... :) -jgArticle: 98540
Jim Granville wrote: > Eric Smith wrote: > >> "Antti" <Antti.Lukats@xilant.com> writes: >> >>> nice accident ! >>> at least we know that number 5 isnt skipped in the Virtex roadmap ;) >> >> >> >> Assuming that the Marketing department doesn't rename it before offical >> introduction. Things like that sometimes happen. >> >> Presumably the Virtex 5 (or whatever it's going to be called) is the >> 65 nm part mentioned in a recent Xilinx press release. > > > Would make sense. > >> What I'd like to see on the roadmap would be some very-low-leakage >> Spartan parts, for use in battery powered devices. They wouldn't need >> to be anywhere near as fast as the Spartan 2, nor as dense. Maybe it >> could be done with thick oxide in 180, 250, or perhaps even 350 nm. >> Gotta do soemthing with all that excess fab capacity in older processes; >> might as well make low-leakage FPGAs. :-) > > > I have a sample on the bench that draws 2.4uA, but it is not a Spartan > FPGA... :) I doubt anyone would be confused, but just in case, no, this is _not_ a Virtex-5 sample... -jgArticle: 98541
Ok but my concern is about R/W cycles assuming i want to use SDRAM for code execution or data storage. Acessing SRAM is only 2 cycles (adr / data ) But for SDRAM , event with smart sdram controller , it will take more , no ? "Antti Lukats" <antti@openchip.org> wrote in message news:dv1neh$l35$1@online.de... > "Jerome" <nospam@nospam.fr> schrieb im Newsbeitrag > news:44145fdd$0$13024$626a54ce@news.free.fr... >> Is it possible to use it without SRAM and only with SDRAM ? >> > > well you need some initialized memory unless you are loading the sdram > over jtag debugger > > basically, yes if you have means to load your application or bootloader > into sdram > there si no need for any other memories > > antti >Article: 98542
"Antti Lukats" <antti@openchip.org> wrote in message news:dv1lqv$i60$1@online.de... > "Claude Sylvain" <claudesylvain@sympatico.ca> schrieb im Newsbeitrag > news:Z0YQf.121$ng.22466@news20.bellglobal.com... >> >> Maybe the simpliest way to get the job done is to make a .svf file converter >> that convert a .svf file (that describe JTAG operation to program a PROM) in >> term of PROM row content; and use the row programming algorythm included in >> xapp544 to program each PROM row. >> >> This way the file that hold PROM information to program appear exactly the >> same as a "standard" EPROM file that can be in S-Record or Intel Hex format. >> This kind of file can be easily uploaded from an host computer to the >> Microblaze CPU. >> >> >> Claude Sylvain >> Electro-Technica inc. >> > > there is no need for that, just program the .BIT file into the PROM, then > write your own data after the bitstream data, no need to convert to svf > > antti > > Oh! ok. So simple, that I forgot that it can be done like that. But it is not really the truth. Some days ago, I read the first row on an XCF02S PROM, using xapp544 source code, and compare the values with the one found in the corresponding "download.bit" file. Unfortunately, the values did not match. Meaning that the "download.bit" file did not contain the "memory equivalent" of the PROM. Maybe I done something wrong when doing this test !? Maybe some simple translation have to be made. Like inverting row bits, or something like that. I will look for that. Thank you again. Claude Sylvain Electro-Technica inc.Article: 98543
"Jerome" <nospam@nospam.fr> schrieb im Newsbeitrag news:44147254$0$13020$626a54ce@news.free.fr... > Ok but my concern is about R/W cycles assuming i want to use SDRAM for > code execution or data storage. > Acessing SRAM is only 2 cycles (adr / data ) > But for SDRAM , event with smart sdram controller , it will take more , no > ? > > "Antti Lukats" <antti@openchip.org> wrote in message > news:dv1neh$l35$1@online.de... >> "Jerome" <nospam@nospam.fr> schrieb im Newsbeitrag >> news:44145fdd$0$13024$626a54ce@news.free.fr... >>> Is it possible to use it without SRAM and only with SDRAM ? >>> >> >> well you need some initialized memory unless you are loading the sdram >> over jtag debugger >> >> basically, yes if you have means to load your application or bootloader >> into sdram >> there si no need for any other memories >> >> antti >> > > thats almost always so that ext(sdram) accesses are way slower cache helps to re-gain some cycles and improves performance but as sw is getting larger and doesnt fit into onchip memory so there are no options to use of sdram so if you can use BRAMs for cache only anttiArticle: 98544
Martin Schoeberl wrote: > I'm wondering why there are so few messages about LEON [1] > in this group. LEON looks like a very solid design (used > by the ESA) and it is available in a GPL version. > Could be a vendor independent replacement of NIOS/MicroBlaze > with a path to an ASIC. > The configuration is done via a simple Tcl/Tk script and > the Makefile contains several targets. Works out-of-the-box > for available tragets. Adaption to a new FPGA board [2] took > me a few (some) hours - not so bad. > > What's your experience? I keep meaning to try it, seeing as I share my first name with it. 8-) LeonArticle: 98545
Hello, Is that possible to make a multi write ports RAM(eg, a 512by32 RAM with several read ports and several write ports) in FPGA by using distributed RAM or block RAM? It is easy to implment a multi read ports, one write port RAM in FPGA by usign the dual port block RAM. But it seems it is impossible to implement a multi write ports RAM by usign distribute or block RAM. Using D flip flop to implement the multi ports RAM will costs too much resource. Is there any suggestion to implement the multi write ports RAM in FPGA? Thanks a lot.Article: 98546
fpga wrote: > Hello, > Is that possible to make a multi write ports RAM in FPGA by using > distributed RAM or block RAM? It seems impossible to me. But using D > flip flop to implement the multi ports RAM will costs too much resouce. > Is there any suggestion to implement the multi write ports RAM in FPGA? > Thanks a lot. Xilinx has dual ported block RAM. In which both ports (I believe) can do simultaneous writes. If you want more ports than that then you may have to use time multiplexing. -------------------------------------------------------------------------------------------------------------- I am an EE student looking for summer employment in Toronto, Canada area If you have any openings please contact me at isaacb[AT]rogers[DOT]com.Article: 98547
The mercury delay lines were earlier, and were used only in "mainframes" of that day. Who wants to have a pot full of mercury sloshing around in a cash register? But this was before environmental concerns, when leaded gasoline was the best thing ever... Did anybody mention the Williams tube? A CRT where you wrote to and read from the tube face. It got killed by the early core memories, which in turn lived much longer than anybody had expected. Non-volatile storage with destructive read-out, just the opposite of SRAM nowadays. Peter PeterArticle: 98548
Good catch, Isaac, you beat me to it. Yes, BlockRAMs can write from both ports simultaneously, and the write enable input can change from write to read on every clock tick. Interestingly, ever write also performs a read of the same location, either read-before-write or write-before-read. The former is more useful. For additional ports, use time multiplexing. Peter AlfkeArticle: 98549
"Claude Sylvain" <claudesylvain@sympatico.ca> schrieb im Newsbeitrag news:Iq_Qf.488$ng.39085@news20.bellglobal.com... > > "Antti Lukats" <antti@openchip.org> wrote in message > news:dv1lqv$i60$1@online.de... >> "Claude Sylvain" <claudesylvain@sympatico.ca> schrieb im Newsbeitrag >> news:Z0YQf.121$ng.22466@news20.bellglobal.com... >>> >>> Maybe the simpliest way to get the job done is to make a .svf file >>> converter that convert a .svf file (that describe JTAG operation to >>> program a PROM) in term of PROM row content; and use the row programming >>> algorythm included in xapp544 to program each PROM row. >>> >>> This way the file that hold PROM information to program appear exactly >>> the same as a "standard" EPROM file that can be in S-Record or Intel Hex >>> format. This kind of file can be easily uploaded from an host computer >>> to the Microblaze CPU. >>> >>> >>> Claude Sylvain >>> Electro-Technica inc. >>> >> >> there is no need for that, just program the .BIT file into the PROM, then >> write your own data after the bitstream data, no need to convert to svf >> >> antti >> > Oh! ok. > > So simple, that I forgot that it can be done like that. > > But it is not really the truth. Some days ago, I read the first row on an > XCF02S PROM, using xapp544 source code, and compare the values with the > one found in the corresponding "download.bit" file. Unfortunately, the > values did not match. Meaning that the "download.bit" file did not > contain the "memory equivalent" of the PROM. > > Maybe I done something wrong when doing this test !? > Maybe some simple translation have to be made. Like inverting row bits, > or something like that. > > I will look for that. > > > Thank you again. > > Claude Sylvain > Electro-Technica inc. if you read first locations - raw data !! out of xcf0xs that holds a valid bitstream then you must see ff ff ff ff 99 66 aa 55 or something alike the bit order may be reversed in the bytes I said .bit file, well a bit file can be programmed as is, eg included the text header as it want hurt, but you may strip anything before the ff ff ff ff < xapp544 tries to use the free platform flash area as read-write eeprom so it adds some special flags to rows to mark then free or dirty, if you are looking for bitstream data then you need to check the plain raw readback data from platform flash, it really really does containt the bitstream with no magic applied, you can consider the platfrom flash as normal serial memory that can be read and written using custom jtag instructions antti
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