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
Petter Gustad wrote: > cpandya@yahoo.com writes: > >> If there is already a ready made solution for this then that will help >> us. > > I've made a programmer that works over ethernet. I've been modifying > it over the last few years to get the cost down. I will make it into a > product if there is a demand for such a programmer. I can program > fpga's (altera and xilinx), as well as spi devices, i2c, and microchip > microcontrollers. It can also program several flash devices attached > to other processors etc which have a jtag interface. > > I use it under linux, and the benefit is that you don't need a driver > other than the network driver that is available with most (if not all) > operating systems. > > Would there be any interest in such a programmer, or will most users > want to stick with the programmers provided by the vendors? > > > Petter > Sorry, why do you need a programmer for this? Would it be possible to first write the flash memory on the fpga to load a minimal network stack that can interact with the jtag/ethernet interface, then directly program the FPGA over a null ethernet cable? Fei linux (192.168.1.1) <--> fpga_ethernet (192.168.1.2) <--> fpga spi flashArticle: 130976
Jon Elson <elson@wustl.edu> wrote: ... > Anyway, I have made enormous progress on migrating to Spartan 2E, so I Take a plunge and go directly to 3E... -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 130977
Jon Elson wrote: <snip> > I've never been very successful at opening up Xilinx pacakges. The > epoxy is > harder than steel (well, at least really abrasive) and I don't have > something that will dissolve it. These are TQFP's, so there's no metal > lid. They come in waffle trays, so there are a lot of "ends" to start > from. What you say MAY make some sense, however, as the first batch of > boards I did used about half the tray without any bad ones! Then, the > second batch I got 50+% bad. Very curious! Solder the device onto a spare scrap of PCB, and then use a flat metalworking file to remove the plastic. As the covering gets very thin, it will lift off the die, so with a little care, you can get quite clean exposure of most of the die. Enough to confirm it is 'Xilinx inside' :) -jgArticle: 130978
On Apr 7, 1:53 am, Antti <Antti.Luk...@googlemail.com> wrote: > Hi > > I am trying to squeeze some read speed out from CF using systemACE and > xilinx standard libraries, but the performance is really really bad > > read using xilfats 400KB/s > read using systemace low level (direct sector reads) 1MB/s > > I have found NO information in any Xilinx documentation what speeds > can be excpected to be achived with systemACE > > the 400KB/s looks like really miserable :( > > i am using the CF card supplied by Xilinx, that is have not yet done > testbenching with other better CF cards, but i would like to know if > such testing has been done, and if there is hope of BIG speed > improvment when using some high-speed CF cards. > > if i look at the spec of the CF card supplied by Xilinx it has 2ms > controller overhead (command to data ready delay) this would limit > access to maximum 500 sector reads commands sent to the CF, but we > need to add time for data transfer too, but this could explain the 1MB/ > s measured speed > > Antti We've noticed the same thing working with the sysace fs. The problem is the overhead from it is QUITE slow since its missing some essential features like a real seek(). My guess is that we're also seeing slowdown on the SystemACE controller in the FPGA. We're using the OPB- based one from EDK 9.1. IIRC, the sysace_*() use extra locking, etc for each operation that adds overhead to the bus. It probably also depends on what you're doing with the sysace files. We're reading ELF's from CF, and b/c there was no seek() there were tons of extra read()'s just to get to the intended part of the ELF, for loading. Currently, we're looking at using the dosfs, which I think you pointed a link to a few years back. -- MikeArticle: 130979
Karl wrote: > why all this fuss ... > > thanks I definitely think more abstraction is important, but I don't see the need for a new language. Like Kolja points out, the languages we have now are fine. There is plenty of abstractability in Verilog that is not supported by synthesizers. Some synthesizers support very little abstraction, meaning a lot of code has to be structural. This level of nonabstraction lengthens development time and makes the code nonportable and nonmaintainable. The abstraction is mostly dependent upon the synthesizer, not the language. If you look at any of the new-fangled languages, you'll find that they are not any more abstract than Verilog. Once you take one of these supposedly abstract languages and manually insert the parallelism and pipelining and unrolling to make it synthesize the way you want, there is no abstraction. The C, Matlab code, Perl, or whatever all ends up looking like low-level Verilog. Maybe there is some marketing value in saying you can convert C to gates, but if it still takes a hardware engineer to write the C in the correct way, you haven't gained anything. Things will only change when you can have a high-level algorithm coder write sequential code that can automatically be synthesized efficiently to a parallel pipelined circuit. Or, in the case of a multicore processor, compiled to well-parallelized code. But despite claims, this isn't happening and doesn't seem to be within grasp. There are tools that do this, but they do it poorly. Marketing folk like to claim, "Your C coders can write in C. Our tool converts C to gates. Therefore your C coders can build circuits." But that's akin to saying, "Your employees can all write in English. Therefore they can all create great war novels." The state-of-the-art English compilers might be able to correct most spelling and a bit of grammar, but they aren't going to take your crappy prose and turn it into Hemingway or synthesize a sonnet. -KevinArticle: 130980
On 7 Apr., 22:50, morphiend <morphi...@gmail.com> wrote: > On Apr 7, 1:53 am, Antti <Antti.Luk...@googlemail.com> wrote: > > > > > Hi > > > I am trying to squeeze some read speed out from CF using systemACE and > > xilinx standard libraries, but the performance is really really bad > > > read using xilfats 400KB/s > > read using systemace low level (direct sector reads) 1MB/s > > > I have found NO information in any Xilinx documentation what speeds > > can be excpected to be achived with systemACE > > > the 400KB/s looks like really miserable :( > > > i am using the CF card supplied by Xilinx, that is have not yet done > > testbenching with other better CF cards, but i would like to know if > > such testing has been done, and if there is hope of BIG speed > > improvment when using some high-speed CF cards. > > > if i look at the spec of the CF card supplied by Xilinx it has 2ms > > controller overhead (command to data ready delay) this would limit > > access to maximum 500 sector reads commands sent to the CF, but we > > need to add time for data transfer too, but this could explain the 1MB/ > > s measured speed > > > Antti > > We've noticed the same thing working with the sysace fs. The problem > is the overhead from it is QUITE slow since its missing some essential > features like a real seek(). My guess is that we're also seeing > slowdown on the SystemACE controller in the FPGA. We're using the OPB- > based one from EDK 9.1. IIRC, the sysace_*() use extra locking, etc > for each operation that adds overhead to the bus. It probably also > depends on what you're doing with the sysace files. We're reading > ELF's from CF, and b/c there was no seek() there were tons of extra > read()'s just to get to the intended part of the ELF, for loading. > > Currently, we're looking at using the dosfs, which I think you pointed > a link to a few years back. > > -- Mike hm dont think there is any help, i just did buy "EXTREME III" CF card with advertised min speed of 20MB/s, to my surprise it did not make any speed improvement at all ! :( the RAW sector read (no filesystem) is about 1MB/s, and i need 3MB/s as bare minimum. so using dosfs or any other library will not help as plain raw reads are way too slow. AnttiArticle: 130981
Hello, We have a design that has an embedded PIC processor that uses ESB's for instruction and data RAM. The target is an Altera APEX 20K100 with an EPC2 configuration PROM. What we would like to do is download the current POF from the configuration PROM and update the instruction ROM with an updated version. While this would be trivial to do going through the build system again, we aren't sure the Quartus project we have builds exactly what is in the EPC2 (hardware-wise). We got the code and project from the contractor who designed the firmware, but the firmware was done before revision control was in place, and no one knows what, exactly, got put into the revision control system. So, can you take a POF file from an EPC2 configuration memory and alter the ROM contents of the ESB's? Thanks!Article: 130982
On Apr 6, 6:08 pm, Karl <karl.polyt...@googlemail.com> wrote: > why all this fuss about the need for new system level languages and > higher abstraction.. ... because, at least for FPGAs, the synthesis and simulation tools have become free (witness Synplicity selling out to Synopsys) and as such the big tool vendors need something to sell to you (or, at least, to management). -aArticle: 130983
Petter Gustad <newsmailcomp6@gustad.com> wrote: >cpandya@yahoo.com writes: > >> If there is already a ready made solution for this then that will help >> us. > >I've made a programmer that works over ethernet. I've been modifying >it over the last few years to get the cost down. I will make it into a >product if there is a demand for such a programmer. I can program >fpga's (altera and xilinx), as well as spi devices, i2c, and microchip >microcontrollers. It can also program several flash devices attached >to other processors etc which have a jtag interface. > >I use it under linux, and the benefit is that you don't need a driver >other than the network driver that is available with most (if not all) >operating systems. > >Would there be any interest in such a programmer, or will most users >want to stick with the programmers provided by the vendors? Something that would be really nice is a parallel port programmer. With a huge twist... Years ago I've build an eprom emulator which simply simulates a printer. Configuring it is a matter of printing text commands. Downloading the hex file is simply a matter of printing it. No device drivers whatsoever are required. It will work with USB to parallel converters (including the crappy ones). There is full flow control as well and it is bleeding fast. It amazes me no-one ever came up with something like that. -- Programmeren in Almere? E-mail naar nico@nctdevpuntnl (punt=.)Article: 130984
In comp.arch.fpga Andy Peters <google@latke.net> wrote: > On Apr 6, 6:08 pm, Karl <karl.polyt...@googlemail.com> wrote: > > why all this fuss about the need for new system level languages and > > higher abstraction.. > ... because, at least for FPGAs, the synthesis and simulation tools > have become free (witness Synplicity selling out to Synopsys) and as > such the big tool vendors need something to sell to you (or, at least, > to management). You mean like everybody in the shop needs to upgrade his office because the boss had got a need Laptop with Office 2xxx on it? -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 130985
On Apr 6, 1:05 am, Peter Alfke <al...@sbcglobal.net> wrote: > On Apr 5, 11:12 am, Simon <wlpstx...@gmail.com> wrote: > > > > > On Mar 23, 4:01 pm, pmull...@yahoo.com wrote: > > > > On Mar 3, 10:22 am, "BobW" <nimby_NEEDS...@roadrunner.com> wrote: > > > > > "Antti" <Antti.Luk...@googlemail.com> wrote in message > > > > >news:ee42d07c-3062-489e-93b1-d9afa01fbbac@y77g2000hsy.googlegroups.com... > > > > > > On 3 Mrz., 17:15, Kolja Sulimma <ksuli...@googlemail.com> wrote: > > > > >> On 3 Mrz., 11:20, Antti <Antti.Luk...@googlemail.com> wrote: > > > > > >> > but as the V5FX has been delaying so long, I have almost lost interest > > > > >> > to follow up how much longer it is delaying in reality... > > > > > >> > The Spartan-4 is much more interesting, > > > > > >> Well, we are desperately waiting for the V5 MGTs. > > > > >> Actually we need a solution for 10gbps soon as XAUI is going to be > > > > >> replaced > > > > >> by SFP+ really soon. We can't place external 10G serdes on 12 ports. > > > > > >> Kolja Sulimma > > > > > > well EVERY new xilinx family since V2ProX is DOWNGRADING the speed of > > > > > MGTs > > > > > V4 less than V2 > > > > > V5 less than V4 > > > > > > so you may need wait V6 :( > > > > > > Antti > > > > > V6? Don't hold your breath. > > > > > A reliable source tells me that the 10Gbps serdes will be fully functional > > > > in V12 Pro (they're skipping V13 for obvious reasons). > > > > > Bob > > > > I would check with Altera on Serdes as they have done it right and > > > have been up to 6 Gbps for years. > > > As shown on the homepage of Xilinx, the new Virtex5 FXT is out now. > > Does anybody know whether there is development board featured with > > Virtex5 FXT available? Is that ML507, if so where is the info or data > > sheet for this board? > > > Simon > > To the best of my knowledge, the ML507 board is identical in layout > and appearance with the ML505 board, since the 'LXT and 'FXT chips are > pin-compatible. > Let's see on Monday at work... > Peter Alfke Is that possible to have a customised ML523 board armed with Virtex5 FXT instead of LXT? SimonArticle: 130986
Andy Peters wrote: > On Apr 6, 6:08 pm, Karl <karl.polyt...@googlemail.com> wrote: >> why all this fuss about the need for new system level languages and >> higher abstraction.. > > ... because, at least for FPGAs, the synthesis and simulation tools > have become free (witness Synplicity selling out to Synopsys) and as > such the big tool vendors need something to sell to you (or, at least, > to management). > > -a The (erroneously) presumed fungability of all synthesis tools does eventually reduce their quality to the lowest common denominator.Article: 130987
Frank Buss <fb@frank-buss.de> writes: > The difference between Xilinx and Intel chips is that the decimal point for > the price of the Xilinx parts is at the wrong position :-) I dunno about that. It seems to me that Xilinx makes a lot of Spartan 3 parts that are at quite attractive price points. I certainly wouldn't want to see Xilinx raise those prices to match Intel.Article: 130988
Antti wrote: > Hi > > I have been think and part time working towards a goal to make useable > and useful serialized processor. The idea is that it should be > > 1) VERY small when implemented in any modern FPGA (less 25% of > smallest device, 1 BRAM) > 2) be supported by high level compiler (C ?) > 3) execute code in-place from either serial flash (Winbond quad speed > SPI memory delivers 320 mbit/s!) or from file on sd-card > > serial implementation would be smaller and run at higher speeds, so > 128 clock per machine cycle would already mean 2 MIPS, what would be > acceptable for many applications. > > Parallax basic stamps I executes 2KIPS only, so ultra lite serial > processor in FPGA with 2 MIPS would be eh, for me its some to dream > off :) > > I have poked around this idea for some years, but never got the "final > kick" to really go and do-complete the design and development of this > processor. > > So I decided to offer some bounty for others to maybe motivate to work > for this goal and dream, current list of items available for the > developers from my own funding is listed here (I hope to add items and > maybe some $ by the time) > > http://code.google.com/p/serial-processor/w/list > > there is also very preliminary spec-goal document as well > > Antti Lukats Antti, I actually have something along those lines way back in my archives. Unfortunately, it was for an XC3100 series part and was done as a schematic using Viewlogic. I'd have to do some digging to a) find it, and b) extract it at this point. Unfortunately, I don't have the spare bandwidth to tackle that at the moment.Article: 130989
Simon wrote: > On Apr 6, 1:05 am, Peter Alfke <al...@sbcglobal.net> wrote: >> On Apr 5, 11:12 am, Simon <wlpstx...@gmail.com> wrote: >>> As shown on the homepage of Xilinx, the new Virtex5 FXT is out now. >>> Does anybody know whether there is development board featured with >>> Virtex5 FXT available? Is that ML507, if so where is the info or data >>> sheet for this board? >>> Simon >> To the best of my knowledge, the ML507 board is identical in layout >> and appearance with the ML505 board, since the 'LXT and 'FXT chips are >> pin-compatible. >> Let's see on Monday at work... >> Peter Alfke > > > Is that possible to have a customised ML523 board armed with Virtex5 > FXT instead of LXT? > > Simon The first units of the ML507 will be available in June and they will be identical to the ML505 & ML506 boards except that they will use the new XC5VFX70T-1CES devices, so get your PO and/or credit cards ready. We will also be releasing ML52x boards with Virtex-5 FXT devices on them, but this will not happen until late this year. Your local System I/O Specialist FAE has the new ML523-FXT boards in hand and should be able to give you a demo earlier than the production release date. Ed McGettigan -- Xilinx Inc.Article: 130990
grant0920 wrote: > Hi! everyone > > I have a very basic problem. I know that the 6-position DIP switch on > the ML403 board can control the configuration address and FPGA > configuration mode. On the ML310 board, I am not sure where can set > the FPGA configuration mode. I want to set the configuration mode of > my ML310 borad as the SelectMAP mode. Please tell me how to set its > FPGA configuration mode. Thanks very much! This can't be done. There is no support for SelectMAP configuration on the ML310. Ed McGettigan -- Xilinx Inc.Article: 130991
I'm pretty new to fpgas, but theres an i2c core on opencores.org that I'd like to use in my Altera project. I understand Wishbone is a subset of Avalon, but what is involved in bridging these two together? I'm assuming its not too trivial since I could buy an IP bridge that does it from Men Micro, but what exactly is involved if I were to try tackling this myself? Thanks!Article: 130992
"benn" <benn686@hotmail.com> wrote in message news:9778f926-8359-4310-a9bd-1ec3c9d0fabf@u36g2000prf.googlegroups.com... > I'm pretty new to fpgas, but theres an i2c core on opencores.org that > I'd like to use in my Altera project. I understand Wishbone is a > subset of Avalon, but what is involved in bridging these two together? > Not much, they have different names for the signals and that's most of the differences. Functionally they are almost the same. > I'm assuming its not too trivial since I could buy an IP bridge that > does it from Men Micro, but what exactly is involved if I were to try > tackling this myself? > Businesses are in business to sell, whether it's easy or hard doesn't matter, there is still $$ to be made. To roll your own... 1. Take a look at the I2C core to see which types of transactions it handles (most likely it's a slave with only simple read and writes with a ready signal to hold things off). 2. Read through the Wishbone spec to get an understanding of the types of transactions that can be performed, but paying more attention to the subset of ones that the I2C core actually uses. 3. Repeat step 2 but reading the Avalon spec, making note of the differences. As I mentioned at the start, you'll probably find that signal names are darn near the only differences. 4. Take a day or so and write the couple lines of code that it takes to create an entity/architecture that has Wishbone names on one side, Avalon on the other. Write a testbench and see that it seems to work, hook up the I2C core to the Wishbone side and see if that works then start integrating the bridge and I2C core into your main design. The water is not too deep in making such a bridge, 'specially when narrowing it down to a particular Wishbone component. Once you've done it for one component, you'll probably find that it's also not too difficult to generalize the bridge to handle more generic Wishbone components and still you'll find that it's not terribly difficult. Kevin JenningsArticle: 130993
On 2008-04-05, Antti <Antti.Lukats@googlemail.com> wrote: > the OP wants COTS board to be used > 1) with no mods to the board > 2) with no additions to the board > > so adding anything isnt an option One way to do this (which is somewhat based on security through obscurity) would be to modify the BIOS on the computer so that it writes some secret initialization sequence to the FPGA to enable it. There are tools available which allows you to easily insert or remove an option ROM image into an AWARD base BIOS. Of course, this will not buy you _real_ security. But it is enough to make sure that someone will have to spend some time to analyze what is really going on in your device. If you want to tighten things up further you could make sure that the secret initialization sequence will depend on a serial number present in the computer (harddrive or DDR dimm for example). This will make things much more complicated for you and might also annoy a customer if they have more than one of your device and for some reason want to exchange parts in it. Otherwise, perhaps you could use a TPM module in some way, but I don't know if that could work or not in your case. /AndreasArticle: 130994
benn wrote: > I'm pretty new to fpgas, but theres an i2c core on opencores.org that > I'd like to use in my Altera project. I understand Wishbone is a > subset of Avalon, but what is involved in bridging these two together? Completely and utterly trivial. Indeed, if it weren't for the fact that the I2c core has an unsigned port you wouldn't need to do anything at all, but since it does you need a (very thin) wrapper that presents only std_logic(_vector) ports. Then you create a component, and simply map each port in the component builder to the equivalent Avalon signal. The only one that isn't perhaps _immediately_ obvious is that ACK <=> waitrequest_n and BTW you map *both* cyc and stb to chipselect (and ignore the warning). I also chose to hard-code the generic in my wrapper as well, thus not presenting it in the wrapper port map. Regards, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, <http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266Article: 130995
On 7 Apr., 23:29, radarman <jsham...@gmail.com> wrote: > Hello, > We have a design that has an embedded PIC processor that uses ESB's > for instruction and data RAM. The target is an Altera APEX 20K100 with > an EPC2 configuration PROM. > > What we would like to do is download the current POF from the > configuration PROM and update the instruction ROM with an updated > version. While this would be trivial to do going through the build > system again, we aren't sure the Quartus project we have builds > exactly what is in the EPC2 (hardware-wise). We got the code and > project from the contractor who designed the firmware, but the > firmware was done before revision control was in place, and no one > knows what, exactly, got put into the revision control system. > > So, can you take a POF file from an EPC2 configuration memory and > alter the ROM contents of the ESB's? > > Thanks! NO Altera is SO UTTERLY stupid in this regard. a DATA2MEM (elf to bit file merge) is VERY important for softcore processors in FPGA's, and Altera kinda claims they have NIOS and stuff, but the MOST IMPORTANT too for FPGA-soc is missing from their toolchain!! :( AnttiArticle: 130996
On 7 Apr., 22:50, morphiend <morphi...@gmail.com> wrote: > On Apr 7, 1:53 am, Antti <Antti.Luk...@googlemail.com> wrote: > > > > > Hi > > > I am trying to squeeze some read speed out from CF using systemACE and > > xilinx standard libraries, but the performance is really really bad > > > read using xilfats 400KB/s > > read using systemace low level (direct sector reads) 1MB/s > > > I have found NO information in any Xilinx documentation what speeds > > can be excpected to be achived with systemACE > > > the 400KB/s looks like really miserable :( > > > i am using the CF card supplied by Xilinx, that is have not yet done > > testbenching with other better CF cards, but i would like to know if > > such testing has been done, and if there is hope of BIG speed > > improvment when using some high-speed CF cards. > > > if i look at the spec of the CF card supplied by Xilinx it has 2ms > > controller overhead (command to data ready delay) this would limit > > access to maximum 500 sector reads commands sent to the CF, but we > > need to add time for data transfer too, but this could explain the 1MB/ > > s measured speed > > > Antti > > We've noticed the same thing working with the sysace fs. The problem > is the overhead from it is QUITE slow since its missing some essential > features like a real seek(). My guess is that we're also seeing > slowdown on the SystemACE controller in the FPGA. We're using the OPB- > based one from EDK 9.1. IIRC, the sysace_*() use extra locking, etc > for each operation that adds overhead to the bus. It probably also > depends on what you're doing with the sysace files. We're reading > ELF's from CF, and b/c there was no seek() there were tons of extra > read()'s just to get to the intended part of the ELF, for loading. > > Currently, we're looking at using the dosfs, which I think you pointed > a link to a few years back. > > -- Mike Hi Mike I tried my luck on Xilinx forums and there an Xilinx employee suggested enableing burst mode in xps_sysace! In EDK 9.2 and 10.1 the burst mode is hardcoded to 0 (disabled) and explained as being 0 in the datasheet on page 9. So while the Xilinx employee answer looked promising... HAA I invented a new word ! XILOTEN everyone is free to guess the meaning Antti PS Xilinx sorry, I have been saying that Xilinx systemACE is NOT RECOMMENDED for new designs for years, now I just got another reason why this is so.Article: 130997
Hello all,
I am creating at MIG a external DDR2 Memory controller.
Then i am trying to add this core to an XPS design. This controller i
want to be attached at the PLB bus. When i am going to import
peripheral from XPS my created core signals does not interface in
total number with the PLB's ones.
I would like to ask if there is a PDF or something similar explains
the step by step the process for core insertion from coregen to an
XPS project.
regards
xenix
Article: 130998Forgot to say that i am using EDK 9.2Article: 130999
Antti <Antti.Lukats@googlemail.com> writes: > a DATA2MEM (elf to bit file merge) is VERY important for softcore > processors in FPGA's, and Altera kinda claims they have NIOS and > stuff, but the MOST IMPORTANT too for FPGA-soc is missing from their > toolchain!! You can get the same functionality using quartus_cdb --update_mif Petter -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
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