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
"Allan Herriman" <allanherriman@hotmail.com> wrote in message news:Xns9BBD4BFB4EB0allanherrimanhotmail@216.151.153.43... > "Krzysztof Kepa" <nospam_blondikk@poczta.fm> wrote in > news:go0pr0$6jj$1@aioe.org: > >> >> "Allan Herriman" <allanherriman@hotmail.com> wrote in message >> news:Xns9BBCD0C44FABBallanherrimanhotmail@216.151.153.43... >>> Hi, >>> >>> I guess my questions are: >>> >>> 2. Will future generations FPGAs be able to be programmed via PCIe? >>> If so, when? >>> >> Now? ;) Just need to use some external components to tie it >> together...or use partial reconfiguration (PR) flow. > > I meant "gluelessly". With PR, one must get the original configuration > into the FPGA somehow, and (as I understand it) that cannot be done with > PCIe. > We're using PCIe link for both, loading partial bitstreams (which contain new accelerator design) and accessing accelerator functionality. However, in our case the original configuration (with PR accelerator blank) is loaded in the "normal way" from the external flash or CF during FPGA power up. Maybe you could also do some crude bit-banging on the PCIe bridge IO in order to configure the FPGA...or look for a PCIe counterpart of the Cypress FX2 chip used in USB designs (and FPGA programming cables :) Regards, KrzysztofArticle: 138476
A lot of empty columns in the timing specifications, but already errata listed for two devices of the family. Worth a look: http://www.latticesemi.com/corporate/newscenter/newsletters/newsfebruary2009/ecp3.cfm Regards, GaborArticle: 138477
On Feb 24, 1:10=A0am, "Finn S. Nielsen" <removethis_finnsta...@vip.cybercity.dk> wrote: > Weng Tianxiang skrev: > > > Hi, > > It is intersting to find that $24.50 is for an Altera ByteBlast > > programmer mentioned in a topics in FPGA group. > > > I need to buy a programmer suitable for Xilinx Virtex II XC2V1500 chip > > only. > > > Please give any tips where I can buy a cheap programmer. > > > Thank you. > > > Weng > > This one perhaps:http://www.morphologic.dk/shop/product_info.php?products= _id=3D28 > > Finn Hi Finn, I think the product fits my need. 1. It has a connector to be connected to a board with the chip; 2. It has a UPS connector to be connected to a computer; 3. It has some wires to connect to trigger points. Am I right for above functions? I don't know what DKK656,00 means. Is it a price tag? How much in US dollar? Thank you. WengArticle: 138478
On Feb 24, 8:27=A0am, Allan Herriman <allanherri...@hotmail.com> wrote: > "Krzysztof Kepa" <nospam_blond...@poczta.fm> wrote innews:go0pr0$6jj$1@ai= oe.org: > > > > > "Allan Herriman" <allanherri...@hotmail.com> wrote in message > >news:Xns9BBCD0C44FABBallanherrimanhotmail@216.151.153.43... > >> Hi, > > >> I guess my questions are: > > >> 2. =A0Will future generations FPGAs be able to be programmed via PCIe? > >> If so, when? > > > Now? ;) Just need to use some external =A0components to tie it > > together...or use partial reconfiguration (PR) flow. > > I meant "gluelessly". =A0With PR, one must get the original configuration > into the FPGA somehow, and (as I understand it) that cannot be done with > PCIe. > > Thanks for your comments. > > Allan I haven't looked at processors like the Atom in a while, but I seem to recall that you get some number of general purpose I/O pins on most any processor. You only need four pins to completely control an FPGA configuration; PRGM, CCLK, DONE, INIT. They can be bit banged in software. The FPGA interface is not used very much when considered in the grand scheme of things. So I expect you will never see direct support for it on processors. I also doubt that you will see dedicated support for PCIe in FPGAs. This is a bit lofty for a configuration interface. PCIe is point to point (right?) and taking one of the two PCIe interfaces on an Atom for booting the FPGA would be a bit of overkill. There are few applications where a processor like the Atom is used and you can't wait the few milliseconds for the FPGA to boot serially. RickArticle: 138479
Allan Herriman wrote: (snip, someone wrote) >>>2. Will future generations FPGAs be able to be programmed via PCIe? >>>If so, when? > I meant "gluelessly". With PR, one must get the original configuration > into the FPGA somehow, and (as I understand it) that cannot be done with > PCIe. If you have an FPGA that can do partial reconfiguration: Load from serial EEPROM enough configuration to get it onto the PCIe bus. Then the external data source supplies data through the PCIe bus as reconfiguration data for another part of the FPGA. Or, again start with the FPGA configured through serial EEPROM. Load the actual configuration data through the FPGA into static RAM. Then switch the configuration source and configure from the RAM. -- glenArticle: 138480
Hello everyone, I'm trying to synthesise a pretty big project on my PC using Xilinx ISE 10.1 SP3, but XST inevitably hangs just after starting the HDL Analysis step. The process keeps running and using more and more memory. I have to stop it manually every time. There's no errors or warnings, and check syntax works successfully. Also, I've simulated it in Modelsim SE 6.3 without any problems. I've got many sub-modules, and I've successfully synthesised all of them individually. I've thought about commenting sections of code to find the culprit section. This would be very long since ISE often freezes for a few seconds or even ends up not responding at all. Has anyone encountered a problem like this? If not, does anyone have a suggestion on how to debug this? Using another synthesis tool is a possibility, but I use Xilinx memories (RAMB), so a code re-write would be necessary. Thanks for any help, Isabelle LaRoche Research Professional Laval University Quebec, CanadaArticle: 138481
isabellelaroche@gmail.com wrote: > I'm trying to synthesise a pretty big project on my PC using Xilinx > ISE 10.1 SP3, but XST inevitably hangs just after starting the HDL > Analysis step. The process keeps running and using more and more > memory. I have to stop it manually every time. There's no errors or > warnings, and check syntax works successfully. Also, I've simulated it > in Modelsim SE 6.3 without any problems. I've got many sub-modules, > and I've successfully synthesised all of them individually. Without more details, it sounds fine to me. A large design takes a long time to run, especially as it gets close to the size of the FPGA and/or you have timing constraints. You might try running in a larger device just to see if it can do it at all. Also, be sure that you have enough real memory. If it starts swapping (thrashing) it will run really slow. Use the task manager (windows) or top (linux) to see how much real and virtual memory it is using, and how much CPU time it is getting. -- glenArticle: 138482
Yes, that should work. At least it worked to me to at least 190MHz. Just be careful not tu use the LE just one column from the side. Move to the 2nd column and then you can get the timing right. Good luck On Mon, 23 Feb 2009 17:38:49 +0100, Frank Buss <fb@frank-buss.de> wrote: >Bert wrote: > >> Quartus2 complaints that the input clock for the second PLL "must be >> driven by a non-inverted input clock pin". So I guess PLL macros >> cannot be cascaded. >> >> How could I resolve this issue? Has anyone a better design? > >Maybe using one PLL with two outputs at 0° and 90° and then inverting the >outputs for 180° and 270° work. At least a test project compiles without >errors and with 0 warnings (after supressing the LogicLock feature warning; >I like 0 warnings :-) > >http://www.frank-buss.de/tmp/ClockTest.zipArticle: 138483
Hello, I need to design a system that uses IEEE1588 PTP to synchronize clock within a couple of 100's of nanosecs. Anyone has some experience with it and can share some thoughts? Oh, by the way, the FPGA should be an Altera with Nios on board. Regards, LucArticle: 138484
On Feb 23, 1:38 pm, Weng Tianxiang <wtx...@gmail.com> wrote: > Hi, > It is intersting to find that $24.50 is for an Altera ByteBlast > programmer mentioned in a topics in FPGA group. > > I need to buy a programmer suitable for Xilinx Virtex II XC2V1500 chip > only. > > Please give any tips where I can buy a cheap programmer. > > Thank you. > > Weng You have a board with a $300 FPGA on it, and you are wanting something cheaper than the 20~30 dollar programmers available all day long on eBay? OK then.Article: 138485
On 2009-02-24, Glen Herrmannsfeldt <gah@ugcs.caltech.edu> wrote: > High speed is not required. (10MHz might be fine, maybe less.) DDR might not run that slowly. -- Ben Jackson AD7GD <ben@ben.com> http://www.ben.com/Article: 138486
On Tue, 24 Feb 2009 12:19:36 -0800, isabellelaroche wrote: > Hello everyone, > > I'm trying to synthesise a pretty big project on my PC using Xilinx ISE > 10.1 SP3, but XST inevitably hangs just after starting the HDL Analysis > step. The process keeps running and using more and more memory. I have > to stop it manually every time. There's no errors or warnings, and check > syntax works successfully. Also, I've simulated it in Modelsim SE 6.3 > without any problems. I've got many sub-modules, and I've successfully > synthesised all of them individually. > > I've thought about commenting sections of code to find the culprit > section. This would be very long since ISE often freezes for a few > seconds or even ends up not responding at all. > > Has anyone encountered a problem like this? If not, does anyone have a > suggestion on how to debug this? Using another synthesis tool is a > possibility, but I use Xilinx memories (RAMB), so a code re-write would > be necessary. > > Thanks for any help, > > Isabelle LaRoche > Research Professional > Laval University > Quebec, Canada You're problem could be a lack of memory, use top to see if you are paging. I just did an LX330 design that required 10G. There are also lots of completely legal constructs that XST can't handle, for example nested for loops, I've see XST go nuts and grab memory until it hit the virtual memory limit and Linux killed it. The best way to figure out where your problem is to compile the modules one at a time until you find the one that XST can't handle.Article: 138487
Ben Jackson wrote: > On 2009-02-24, Glen Herrmannsfeldt <gah@ugcs.caltech.edu> wrote: >>High speed is not required. (10MHz might be fine, maybe less.) > DDR might not run that slowly. Yes, I didn't mean it that way. The clock will probably be 100MHz, but I only need to access it at 10MHz or less. That might mean that I don't need complications such as FIFOs, that would be needed at higher speeds. I understand that much of the complication of DDR is when high speed is really needed, but in this case it isn't. I am hoping that simplifies the design somewhat. -- glenArticle: 138488
On Tue, 24 Feb 2009 12:19:36 -0800 (PST) isabellelaroche@gmail.com wrote: > Hello everyone, > > I'm trying to synthesise a pretty big project on my PC using Xilinx > ISE 10.1 SP3, but XST inevitably hangs just after starting the HDL > Analysis step. The process keeps running and using more and more > memory. I have to stop it manually every time. There's no errors or > warnings, and check syntax works successfully. Also, I've simulated it > in Modelsim SE 6.3 without any problems. I've got many sub-modules, > and I've successfully synthesised all of them individually. > > I've thought about commenting sections of code to find the culprit > section. This would be very long since ISE often freezes for a few > seconds or even ends up not responding at all. > > Has anyone encountered a problem like this? If not, does anyone have a > suggestion on how to debug this? Using another synthesis tool is a > possibility, but I use Xilinx memories (RAMB), so a code re-write > would be necessary. > > Thanks for any help, > > Isabelle LaRoche > Research Professional > Laval University > Quebec, Canada I've had problems in the past where XST would otherwise be working fine, but the GUI keels over and dies, locking up the whole process. It's the main reason that I control my FPGA builds from GNU Make rather than from the Project Navigator; the back-end tools seem to have much more attention paid to quality control than do the front-end. You might want to try running XST from the command line or TCL shell instead. This can be non-trivial to do, but shouldn't take any more than about 15 minutes to work out the details of. If it works properly from there, then you've been ISEd and ought to work out some cleaner means of driving the back-end tools directly, either a Makefile, TCL script, batch file, or something else that's a little more reliable than the GUI. -- Rob Gaddi, Highland Technology Email address is currently out of orderArticle: 138489
On Feb 24, 5:41=A0pm, Rob Gaddi <rga...@technologyhighland.com> wrote: > I've had problems in the past where XST would otherwise be working > fine, but the GUI keels over and dies, locking up the whole process. > It's the main reason that I control my FPGA builds from GNU Make rather > than from the Project Navigator; the back-end tools seem to have much > more attention paid to quality control than do the front-end. What he said! In the past I've seen the Project Navigator take up almost 1GB of memory, seriously eating into what's available for XST, map and par. When I started using make to run my synthesis builds I saw an immediate improvement in run times and overall results. I've put some skeleton build info together here: http://members.cox.net/ebrombaugh1/synth/armfpga/build_scripts.zip maybe you can use them. EricArticle: 138490
> I'm trying to synthesise a pretty big project on my PC using Xilinx > ISE 10.1 SP3, but XST inevitably hangs just after starting the HDL > Analysis step. The process keeps running and using more and more > memory. I have to stop it manually every time. There's no errors or > warnings, and check syntax works successfully. Also, I've simulated it > in Modelsim SE 6.3 without any problems. I've got many sub-modules, > and I've successfully synthesised all of them individually. I have had a somewhat similar problem in the past related to a small verilog design which was highly parameterized. I'm sorry I can't remember exactly what design it was, and thus the exact details, but XST would run for a while then run out of memory and crash. I seem to remember the problem was to do with a function I was using to configure a parameter on a lower level module ... I cant remember if using an intermediate "localparam" fixed the problem or caused it. I think it fixed it .... > I've thought about commenting sections of code to find the culprit > section. This would be very long since ISE often freezes for a few > seconds or even ends up not responding at all. > This, unfortunately, is probably the only way to track it down. That said, if your design is large, taking some time to set up a means to build the main parts of your design separately is a very useful thing to do. I like the Xilinx TCL design flow, though it's also very usable with makefiles. Doing this has benefits including allowing you to track size/speed of submodules, quicker rebuilds (though this isn't always helpful - building a design in bits, rather than as a whole, can have problems related to meeting eventual timing goals) and most importantly finding problematic parts of the design. > Has anyone encountered a problem like this? If not, does anyone have a > suggestion on how to debug this? Using another synthesis tool is a > possibility, but I use Xilinx memories (RAMB), so a code re-write > would be necessary. > XST is somewhat better at VHDL than Verilog, but not really that good at either. Thats my opinion anyway. I say that from a language coverage point of view, as well as it's eventual ability to generate working hardware. I like having the tool on my desktop for simple parts of a design, but I just do not trust it to produce a working FPGA bitstream. If you are able to use something commercial (though frankly rather expensive), Synplify has been a great help to me for the last decade. Pulling back a little from the XST bashing a bit - once you know how to get code through its front end (I am still learning it foibles to be honest), it's back end (ie optimisers) are just as good as the commercial synthesizers. I really hope one day Xilinx will sort this out - FWIW I have found that Altera's synthesizer is vastly more robust than XST. Cheers, AndyArticle: 138491
On 2009-02-24, isabellelaroche@gmail.com <isabellelaroche@gmail.com> wrote: > Has anyone encountered a problem like this? If not, does anyone have a > suggestion on how to debug this? Using another synthesis tool is a > possibility, but I use Xilinx memories (RAMB), so a code re-write > would be necessary. First of all, even if you use another synthesis tool you probably will not need to rewrite the code. I didn't have to do this when using the Precision synthesis tool and I would be surprised if Synplify forced you to do this. Another possibility is that some stale information is used by the synthesis tool. Try to clean out all temporary files in your synthesis directory. If you use ISE this may be hard as it spews temporary files all over the place, but the "xst" directory should contain most of the files that the XST tool will output. /AndreasArticle: 138492
On 2009-02-25, luudee <rudolf.usselmann@gmail.com> wrote: > I know that MB is big-endian, vs my linux box being little-endian. > But shouldn't the C compiler produce the same results, regardless > of the system endianness ? No, as far as I know, casting a pointer to int to a pointer to char and accessing the data as chars is undefined. (I'm not sure, but I don't think that the standard even guarantees that two's complement numbers are used although this is probably a safe bet to make.) If you want to do something like this in a more portable fashion, use something like: int i = 0xaabbccdd; char a,b,c,d; a = i & 0xff; b = (i >> 8) & 0xff; c = (i >> 16) & 0xff; d = (i >> 24) & 0xff; /AndreasArticle: 138493
Hi, try to reboot your PC and then try again. I have sometimes strage problems with ISE. It hangs up or tells some failures. After rebooting all working fine. Another problem I had with ISE 9.1 is that I can't run after using Modelsim. I had to clean the Project files (Project --> Cleanup Project Files). After doing this the problems are gone. MatthiasArticle: 138494
Here is a small test program:
int main() {
unsigned int dword;
unsigned char *c;
dword = 0x87654321;
c = (char *)&dword;
printf("%0x\n", dword);
printf("c[0]=%02x\n", c[0]);
printf("c[1]=%02x\n", c[1]);
printf("c[2]=%02x\n", c[2]);
printf("c[3]=%02x\n", c[3]);
return(0);
}
On Linux (i386), I get:
87654321
c[0]=21
c[1]=43
c[2]=65
c[3]=87
But on the Microblaze system, I get:
87654321
c[0]=87
c[1]=65
c[2]=43
c[3]=21
I know that MB is big-endian, vs my linux box being little-endian.
But shouldn't the C compiler produce the same results, regardless
of the system endianness ?
Cheers,
rudi
Article: 138495In article <1c3663ae-9616-416b-9a6f-d4d2d8143f76@r4g2000yqa.googlegroups.com>, luudee <rudolf.usselmann@gmail.com> wrote: >I know that MB is big-endian, vs my linux box being little-endian. >But shouldn't the C compiler produce the same results, regardless >of the system endianness ? Only if you stick to doing permitted things, and writing to an object of one size and reading it via an pointer to an object of another size is precisely one of the things that is forbidden. If you want to read the parts of a dword in an endianness-independent fashion, try A = x&0xff; B = (x>>8)&0xff; C = (x>>16)&0xff; D = (x>>24)&0xff; TomArticle: 138496
>I know that MB is big-endian, vs my linux box being little-endian. >But shouldn't the C compiler produce the same results, regardless >of the system endianness ? Which one is right? If the compiler could do the "right" thing, we wouldn't have endian wars. -- These are my opinions, not necessarily my employer's. I hate spam.Article: 138497
rickman <gnuarm@gmail.com> wrote in news:3774b465-11f4-4daa-aee7-d44f72fce9a6@n20g2000vba.googlegroups.com: > On Feb 24, 8:27 am, Allan Herriman <allanherri...@hotmail.com> wrote: >> "Krzysztof Kepa" <nospam_blond...@poczta.fm> wrote >> innews:go0pr0$6jj$1@ai > oe.org: >> >> >> >> > "Allan Herriman" <allanherri...@hotmail.com> wrote in message >> >news:Xns9BBCD0C44FABBallanherrimanhotmail@216.151.153.43... >> >> Hi, >> >> >> I guess my questions are: >> >> >> 2. Will future generations FPGAs be able to be programmed via >> >> PCIe? If so, when? >> >> > Now? ;) Just need to use some external components to tie it >> > together...or use partial reconfiguration (PR) flow. >> >> I meant "gluelessly". With PR, one must get the original >> configuration into the FPGA somehow, and (as I understand it) that >> cannot be done with PCIe. >> >> Thanks for your comments. >> >> Allan > > I haven't looked at processors like the Atom in a while, but I seem to > recall that you get some number of general purpose I/O pins on most > any processor. You only need four pins to completely control an FPGA > configuration; PRGM, CCLK, DONE, INIT. They can be bit banged in > software. The FPGA interface is not used very much when considered in > the grand scheme of things. So I expect you will never see direct > support for it on processors. > > I also doubt that you will see dedicated support for PCIe in FPGAs. > This is a bit lofty for a configuration interface. PCIe is point to > point (right?) and taking one of the two PCIe interfaces on an Atom > for booting the FPGA would be a bit of overkill. There are few > applications where a processor like the Atom is used and you can't > wait the few milliseconds for the FPGA to boot serially. That PCIe isn't wasted; it is needed for FPGA <-> cpu comms after configuration. I was actually thinking of applications without the chance of using GPIO lines, e.g. on a PCIe plugin card. It still seems that the PCIe to local bus bridge is the best solution for my hypothetical problem. The other suggestions involved Flash memories (with an implied extra step during manufacturing to program the dang things, not to mention the extra complexity involved with in-the-field upgrades of that image) or a non-trivial amount of glue logic. I thought Glen's suggestion of loading the image into SRAM first was neat, but probably not suitable for me. Thanks, AllanArticle: 138498
Glen Herrmannsfeldt <gah@ugcs.caltech.edu> wrote: > Ben Jackson wrote: > > On 2009-02-24, Glen Herrmannsfeldt <gah@ugcs.caltech.edu> wrote: > >>High speed is not required. (10MHz might be fine, maybe less.) > > DDR might not run that slowly. > Yes, I didn't mean it that way. The clock will probably be 100MHz, > but I only need to access it at 10MHz or less. That might mean > that I don't need complications such as FIFOs, that would be needed > at higher speeds. > I understand that much of the complication of DDR is when > high speed is really needed, but in this case it isn't. > I am hoping that simplifies the design somewhat. If you have unrelated accessed, DRAM isn't much faster then 10 MHz... -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 138499
On Feb 25, 3:55=A0pm, Thomas Womack <twom...@chiark.greenend.org.uk>
wrote:
>
> Only if you stick to doing permitted things, and writing to an object
> of one size and reading it via an pointer to an object of another size
> is precisely one of the things that is forbidden.
>
..
>
> Tom
So what is considered "permitted" ?
How about:
union my_union {
unsigned int dword[1];
unsigned char byte[4];
};
I guess the bigger question here is how to correctly
interface a little endian peripheral to a big-endian
SoC ?
Byte swapping everything would mean that the user manual
for the pripoheral would have to be rewritten as well ...
Can I just place a mirror next to my monitor (at 45
degrees) and just work of that for this project ?
Cheers,
rudi
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