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
Mike Treseler wrote: > ALuPin@web.de wrote: > > > I have tried to synthesize the synchronous fifo example "FIFO.vhd" > > from Ben Cohen's book "Real Chip Design and Verification Using Verilog > > and VHDL" on a Lattice EC15 (Synplicity compiler) > > For the FIFO registers declaration I add the following > > attribute : > > > > attribute syn_ramstyle : string; > > attribute syn_ramstyle OF FIFO_r : SIGNAL IS "block_ram"; > > > > And yet the synthesis results show that no Embedded RAM > > blocks are used. > > If the target fpga has block ram, and if you > use the recommended code template, no > attribute hints are required. > > > Is the used attribute not appropriate or is Synplify not able > > to implement the registers as EBR in that hardware description? > > Attributes and commented directives > are vendor specified, and only work > for tools that recognize them. > > > -- Mike Treseler Also make sure the FIFO code can be made from block RAM. In Lattice, like Xilinx, the block RAM's have registered outputs, so code that implements a combinatorial read function cannot be synthesized using EBR.Article: 108126
Thanks Antti! Unfortunately, the phase is not guarenteed over multiple frames. The interface needs to be able to sync each frame transmission. It's is definitely going to be tricky. The SERDES I was referring to was in the ILOGIC stuff. I haven't even looked into using the MGT's, though that may be a possibility. Oh well......Article: 108127
Austin Lesea <austin@xilinx.com> wrote: >Tejo, > >http://direct.xilinx.com/bvdocs/userguides/ug073.pdf > >Yes, the 18X18 multiplier/accumulator is a hardened block, so that >performing this function results in from 8 to 20 times less power than >performing this function would if it was done in the logic of the FPGA >(luts, dff, interconnect, etc.) > >The above guide details use of the V4 for "extreme" DSP uses. > >FPGAs are useful for tasks that DSP processors are too slow for, >otherwise, DSP processors are generally far easier and better suited for >DSP. For example, a video conference processor, where multiple streams >must be encoded, decoded, combined, along with all audio processing is >one such task where a FPGA would excel for both cost, power, and >performance. I doubt about cost and preformance. Developing such a device would probably take so much time that an ASIC is just as cost effective and uses even less power. An older PC is already capable of doing these functions with a development time that can be expressed in days, not years. Even when dealing with loads of videostreams at high resolutions it is more cost effective, reliable and flexible to use PCs on a fast network to do the processing rather than building a custom FPGA/ASIC solution. -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 108128
300 MB/s may be a little slow, but you might find good info in http://www.xilinx.com/bvdocs/appnotes/xapp671.pdf The method I'm using (derived before finding this XAPP) in the Spartan3E family has a phase locked clock and a long training period to recover 3 channels of 600 Mb/s data each. I don't believe (I'm not sure) the method in XAPP671 needs much of a training period. While the 300 MB/s is easily half the speed covered by that app note, you might find good ideas there. _____ "motty" <mottoblatto@yahoo.com> wrote in message news:1157480088.467287.234360@d34g2000cwd.googlegroups.com... >I need to recover data from a serial LVDS I/O stream running at over > 300 MHz. A reference 26 MHz clock is provided by the data source. So > that clock needs to be bumped up to the data rate. The fast data is > NOT phase aligned with the reference (or derived) clock. There is a > 16-bit sync pattern at the start of every 'frame' of data. There is > guarenteed to be at least one bit of '0' before the sync pattern starts > - between frames or from reset. It starts with a '1'. So a zero to > one tansition will start the sync pattern if the 'logic' is 'searching' > for the sync. > > I have implemented some hardware that will work by using 4 phases of > the fast clock. And I basically built a serial-to-parallel logic block > that takes the data and deserializes it. The sync is searched for and > detected. Once detected, the data is passed from the best phased clock > domain. This all works fine and well at 100 MHz. I knew I would never > get it up to the speed I need (Virtex4 LX25 -10) using the fabric. So > I've looked in to using the SERDES IO technology. I've read the user > guide and looked at some applications notes, but haven't found anything > that really matches what I need. The logic that the app notes > implement either rely on bit-syncronization techniques or a steady > training pattern over a 'long' time. Those take too long to complete. > I need to decide what phase of the clock to use (to ensure good data > capture over a given frame) and pass that data on in less than the > 16-bit sync pattern. I know there are many possible solutions, but I > was just posting this while I mess around with this problem. Anyone > have any ideas? > > Thanks! >Article: 108129
Nico, We (Peter and I) have decided to avoid any marketing discussions. On technical subjects, at least I can (usually) post something useful. You decide when, where, and how to use Xilinx FPGAs. I am happy if you use them at all, for whatever you find profitable. The website speaks for itself: there are lots of customer testimonials for those who wish to read them. You decide. Perhaps others can post why they use our FPGAs for extreme DSP? Austin Nico Coesel wrote: > Austin Lesea <austin@xilinx.com> wrote: > >> Tejo, >> >> http://direct.xilinx.com/bvdocs/userguides/ug073.pdf >> >> Yes, the 18X18 multiplier/accumulator is a hardened block, so that >> performing this function results in from 8 to 20 times less power than >> performing this function would if it was done in the logic of the FPGA >> (luts, dff, interconnect, etc.) >> >> The above guide details use of the V4 for "extreme" DSP uses. >> >> FPGAs are useful for tasks that DSP processors are too slow for, >> otherwise, DSP processors are generally far easier and better suited for >> DSP. For example, a video conference processor, where multiple streams >> must be encoded, decoded, combined, along with all audio processing is >> one such task where a FPGA would excel for both cost, power, and >> performance. > > I doubt about cost and preformance. Developing such a device would > probably take so much time that an ASIC is just as cost effective and > uses even less power. An older PC is already capable of doing these > functions with a development time that can be expressed in days, not > years. > > Even when dealing with loads of videostreams at high resolutions it is > more cost effective, reliable and flexible to use PCs on a fast > network to do the processing rather than building a custom FPGA/ASIC > solution. >Article: 108130
Nico Coesel wrote: > Even when dealing with loads of videostreams at high resolutions it is > more cost effective, reliable and flexible to use PCs on a fast > network to do the processing rather than building a custom FPGA/ASIC > solution. > Probably there are other constraints. Do you need 1,000 of these? Is it a mass market product? Does it need to fit in a rack? In a unit the size of a pack of cigarettes? Getting something working in a lab in just any old manner, perhaps for getting funding, is one thing. Getting to a fieldable solution... There is no way one can make a blanket statement about the best solution without knowing all the requirements. In my case I worked on a project that had to encode live NTSC video to mpeg-2 I frames with a minimum of latency. The solution ended up being DSP based, blackfin DSP's, 4 video/audio inputs on a PCI card. It was a big project. In the end we were limited by the performance of the DSP's. The frame size ended up being 352x240 at 60 hz. There was just no way we could ever do 720x240 -- had to downsample in X. Now if we'd opted for an FPGA, if it was big enough we'd have had lots of options to improve performance. We could have licensed some existing IP, modified it to suit. It would have been a bigger unknown since none of us had direct FPGA experience, but we did have low level programming experience. Going an FPGA route might have been a better investment in the long run... Use the right technology/solution for the task at hand. No one size fits all. -Dave -- David Ashley http://www.xdr.com/dash Embedded linux, device drivers, system architectureArticle: 108131
David Ashley wrote: > Now if we'd opted for an FPGA, if it was big enough we'd have had > lots of options to improve performance. We could have licensed > some existing IP, modified it to suit. It would have been a bigger > unknown since none of us had direct FPGA experience, but we did > have low level programming experience. Going an FPGA route might > have been a better investment in the long run... One more thing occured to me. With the Analog Devices blackfin DSP approach we found out the hard way memory bandwidth was a severely limiting factor. The DSP had some small amount of on chip memory that ran at the CORE clock frequency. The SYSTEM clock was a fraction of that, say 1/5th or 1/6th. Accessing external SDRAM took something like 6 SCLOCKS, which translates to 36 CORE clocks. Thats a *long* time in DSP space. The SDRAM controller never did burst accesses, as I recall. What that means is you can't effectively do anything unless you use the on chip fast memory, which operates at the CORE clock frequency (600 mhz to 750 mhz for example). But that was a limited resource. And there was no way to improve the SDRAM controller, that was part of the chip. So the resolution *couldn't* improve, we didn't have memory for it, and no amount of optimization would work. With an FPGA, on the other hand, one could have modified the external memory controller to burst out a whole 64 byte chunk of memory, or burst one into a BRAM. Then operate in the BRAM, then write it back out. Doing burst accesses would really speed things up, and the memory IO could go in in parallel with other processing. In short there would be almost unlimited ability to optimize, as needed. With the fixed-cpu DSP approach, we found out the limits the hard way. Then we had to reduce our expectations. In the end it was OK, but it might have been a disaster. -Dave -- David Ashley http://www.xdr.com/dash Embedded linux, device drivers, system architectureArticle: 108132
A Virtex4 FPGA is mounted on a board which has a sleep mode to conserve battery power during periods of inactivity. Is it only necessary to keep the VCCaux power on to maintain the configuration memory, and all the other power inputs can be turned off?Article: 108133
Pomerado, The Vcc_config must stay powered, the Vcc_aux must stay powered, and the Vccint must stay powered. If any of these drops below their power on reset thresholds, the device erases all memory before trying to configure. Vcco_config POR trip is ~ 0.5 to 0.75V Vcc_aux POR trip is ~1.3 to 1.8V Vccint POR trip is ~0.5 to 0.75V I recommend that you may lower each supply only to what is specified in the recommended operating conditions table of the data sheet, and no less. This, of course, after you place the design in a state where all clocks are disabled, IOs tristate, and just waiting for a signal on an IOB pin to wake up, and start processing from where it left off. Table 4 is where you will find the min currents: http://direct.xilinx.com/bvdocs/publications/ds302.pdf Austin pomerado@hotmail.com wrote: > A Virtex4 FPGA is mounted on a board which has a sleep mode to conserve > battery power during periods of inactivity. Is it only necessary to > keep the VCCaux power on to maintain the configuration memory, and all > the other power inputs can be turned off? >Article: 108134
motty wrote: > Thanks Antti! > > Unfortunately, the phase is not guarenteed over multiple frames. The > interface needs to be able to sync each frame transmission. It's is > definitely going to be tricky. > > The SERDES I was referring to was in the ILOGIC stuff. I haven't even > looked into using the MGT's, though that may be a possibility. > > Oh well...... > MGTs on V4-LX parts? You may want to revisit the datasheet before getting your hopes up: only the FX V4 variant has MGTs. Unless you can still ECO the part and live with the price delta between the two parts, this avenue is busted. -- Daniel Sauvageau moc.xortam@egavuasd Matrox Graphics Inc. 1155 St-Regis, Dorval, Qc, Canada 514-822-6000Article: 108135
CBFalconer wrote: > I used to install a roughly 68 ohm 1/2 watt carbon resistor across > the AC mains (110 volt) after the power switch. This was usually > done at lunch time, while someone else was preparing for his > initial smoke test on a new instrument (back in the days of > tubes). The result was a satisfactory grrr-bang and smoke. Modern > resistors don't work as well, they just fizzle. > Try 1/4 watt 1000 Ohm metal film resistors, they glow red, then make a decent, "pop". ~100 uF ~10V radial aluminum electrolytics make great confetti generators, when plugged into standard 120V power outlets. Kids, don't try this at home. Ah, memories! TomArticle: 108136
zcsizmadia@gmail.com wrote: > I've reversed engineer the CableServer communication with Impact and > written from scratch a brand new CableServer. Currently only Parallel > III cable is implemented, but new cables can be added very easily. I > will post the project on sourceforge.net next week. Nice! Good work. > Antti wasn't really helpful to come up with a name for the project, so > it will be called "cblsrv" :) If it doesn't crash like the Xilinx one you could call it "AbleServe" :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8CArticle: 108137
tlbs101 wrote: > CBFalconer wrote: > > >>I used to install a roughly 68 ohm 1/2 watt carbon resistor across >>the AC mains (110 volt) after the power switch. This was usually >>done at lunch time, while someone else was preparing for his >>initial smoke test on a new instrument (back in the days of >>tubes). The result was a satisfactory grrr-bang and smoke. Modern >>resistors don't work as well, they just fizzle. >> > > > Try 1/4 watt 1000 Ohm metal film resistors, they glow red, then make a > decent, "pop". > > ~100 uF ~10V radial aluminum electrolytics make great confetti > generators, when plugged into standard 120V power outlets. An SCR, placed across the terminals of a decent sized gelcell will give a very rewarding blue flash followed by an orange fireball after it's been turned on.Article: 108138
jacko wrote: > hi > > just wondering if grey code (1 bit change) addressed stack memory might > be useful for cutting down carry chain logic for pre-post dec/inc > addressing?? Gray codes are useful for reading data, but they need extra hardware for counting and addressing. (If course, Gray-code addressing is no different from any other scrambling of the address lines too a memory chip. Page accesses aside, the memory doesn't care. It can make a ROM difficult to reverse engineer, particularly id the data lines are scrambled too.) Jerry -- Engineering is the art of making what you want from things you can get. ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻArticle: 108139
Daniel S. wrote: > motty wrote: > > Thanks Antti! > > > > Unfortunately, the phase is not guarenteed over multiple frames. The > > interface needs to be able to sync each frame transmission. It's is > > definitely going to be tricky. > > > > The SERDES I was referring to was in the ILOGIC stuff. I haven't even > > looked into using the MGT's, though that may be a possibility. > > > > Oh well...... > > > > MGTs on V4-LX parts? You may want to revisit the datasheet before > getting your hopes up: only the FX V4 variant has MGTs. Unless you can > still ECO the part and live with the price delta between the two parts, > this avenue is busted. > > -- > Daniel Sauvageau > moc.xortam@egavuasd > Matrox Graphics Inc. > 1155 St-Regis, Dorval, Qc, Canada > 514-822-6000 Yeah, I am not well versed in the V4 parts, but I quickly found out the LX doesn't have MGT's. : ) We will eventually be using a V5 part, so I need to look into those details. I don't know if the MGT would work anyway. It lists a minimum frequency of ~600 Mbps. I don't know if that is a hard line or not. But right now I am just looking in to what methods are available and trying different approaches.Article: 108140
I might add that the two authors of XAPP671, Catalin Baetoniu and Tze Yi Yeoh, are experienced and very much respected within Xilinx. Peter Alfke =================== John_H wrote: > 300 MB/s may be a little slow, but you might find good info in > > http://www.xilinx.com/bvdocs/appnotes/xapp671.pdf > > The method I'm using (derived before finding this XAPP) in the Spartan3E > family has a phase locked clock and a long training period to recover 3 > channels of 600 Mb/s data each. I don't believe (I'm not sure) the method > in XAPP671 needs much of a training period. While the 300 MB/s is easily > half the speed covered by that app note, you might find good ideas there. > _____ > > "motty" <mottoblatto@yahoo.com> wrote in message > news:1157480088.467287.234360@d34g2000cwd.googlegroups.com... > >I need to recover data from a serial LVDS I/O stream running at over > > 300 MHz. A reference 26 MHz clock is provided by the data source. So > > that clock needs to be bumped up to the data rate. The fast data is > > NOT phase aligned with the reference (or derived) clock. There is a > > 16-bit sync pattern at the start of every 'frame' of data. There is > > guarenteed to be at least one bit of '0' before the sync pattern starts > > - between frames or from reset. It starts with a '1'. So a zero to > > one tansition will start the sync pattern if the 'logic' is 'searching' > > for the sync. > > > > I have implemented some hardware that will work by using 4 phases of > > the fast clock. And I basically built a serial-to-parallel logic block > > that takes the data and deserializes it. The sync is searched for and > > detected. Once detected, the data is passed from the best phased clock > > domain. This all works fine and well at 100 MHz. I knew I would never > > get it up to the speed I need (Virtex4 LX25 -10) using the fabric. So > > I've looked in to using the SERDES IO technology. I've read the user > > guide and looked at some applications notes, but haven't found anything > > that really matches what I need. The logic that the app notes > > implement either rely on bit-syncronization techniques or a steady > > training pattern over a 'long' time. Those take too long to complete. > > I need to decide what phase of the clock to use (to ensure good data > > capture over a given frame) and pass that data on in less than the > > 16-bit sync pattern. I know there are many possible solutions, but I > > was just posting this while I mess around with this problem. Anyone > > have any ideas? > > > > Thanks! > >Article: 108141
John_H wrote: > Moving pointers would require an addressable load and an addressable read - > what's available with dual-ports. A fixed entry with single addressable > output mux gives everything needed for an addressable serial-in shift > register without the need for extra bits. Maintaining the in pointer and > calculating the out pointer from the "I want the 5th bit" control to the > output mux is a sincere amount of logic above and beyond the normal LUT > structure. The SRL's output MUX is the same as used for providing the LUT > output in normal operation requiring no additional logic beyond the shift > through the 16 memory cells. > > There are many applications where a FIFO structure is best handled with > separate in/out pointers, particularly when changing between time domains. > The SRLs ar restricted to the same time domain for the input and output but > don't need the extra pointers. As a FIFO, the SRLs have a slightly more > complicated single pointer (adds and subtracts for write and read, > respectively) but ends up more compact in the end. I gave this a bit more thought and realized that there is already a lot of circuitry in the LUT. It has the output mux (read decode) and the write address decode and the LUT RAM bits are already in a shift register for loading configuration data. So the SRL is essentialy free. To use a moving pointer two 4 bit counters would have to be added, so I am sure they would not want to do it this way. Can you use the SRL as a FIFO? I was not aware that you could change the length. I thought that was a configuration setting. If they are doing that the only extra for the moving pointers would be the 4 bit write address counter.Article: 108142
small corrections inserted: rickman wrote: > I gave this a bit more thought and realized that there is already a lot > of circuitry in the LUT. It has the output mux (read decode) and the > write address decode and the LUT RAM bits are already in a shift > register for loading configuration data. Not really, there is a common loading mechanism, but that has to serve the whole chip. The "prior to V5" SRL16 uses the age-old trick of differentiating the clock and putting a low-pass filter between the latches. Like we used to do in the 'fifties and 'sixties, when transistors were expensive. Since this does not scale well at 65 nm and below, V5 went back to the "proper 2-latches per bit, master/slave" method. >So the SRL is essentialy > free. To use a moving pointer two 4 bit counters would have to be > added, so I am sure they would not want to do it this way. > > Can you use the SRL as a FIFO? I was not aware that you could change > the length. I thought that was a configuration setting. If they are > doing that the only extra for the moving pointers would be the 4 bit > write address counter. You use a fixed insertion point for writing into the SRL16, but move the read location by changing the mux address forwards, backwards or not at all. Takes a moment to understand... Peter AlfkeArticle: 108143
Hi there I'm trying to export a waveform from the quartus 2 web edition. In the quartus 2 help, there's a nice explanation how to do that: >Export Dialog Box (SignalTap II Logic Analyzer) > >-------------------------------------------------------------------------------- >You open this dialog box by clicking Export on the File menu. > >Exports the current SignalTap II waveform data to a Comma-Separated Value File (.csv), >Vector Table Output File (.tbl), Value Change Dump File (.vcd), Vector Waveform File (.vwf), >JPEG File Interchange Format (.jpg), or Bitmap File (.bmp). Unfortunately, when i execute the described action, I can only export VHDL testbench files (*.vht) and Verilog testbench files (*.vt). Can anybody tell me if this is because of the licence, or if i'm doing something else wrong? My version is 6.0 build 202 SJ Web Edition, with service pack 1 installed. Thanks a lot and have a nice day totoArticle: 108144
rickman wrote: > I gave this a bit more thought and realized that there is already a lot > of circuitry in the LUT. It has the output mux (read decode) and the > write address decode and the LUT RAM bits are already in a shift > register for loading configuration data. So the SRL is essentialy > free. To use a moving pointer two 4 bit counters would have to be > added, so I am sure they would not want to do it this way. > > Can you use the SRL as a FIFO? I was not aware that you could change > the length. I thought that was a configuration setting. If they are > doing that the only extra for the moving pointers would be the 4 bit > write address counter. The SRLs are absolutely useable as FIFOs with the only caveat that they're in the same time domain. The output value is a combinatorial result from the 16 values in the memory and the LUT address: the standard F1-F4 or G1-G4 lines. If the data gets shifted in right when you're trying to read, no amount of coordination with the output mux select will give you a static value. So... used in a synchronous fashion, these are *great* for variable length FIFOs rather than just static delay lines. The pointer comes down to something like: always @(posedge clk) SRLsel[3:0] <= SRLsel[3:0] + ld - rd; The up/down count takes more than one level of logic but it sure is quick & easy to code. It infers pretty well as long as you don't try to add a reset to the mix. The register coupled to the LUT in the slice also has an enable that can be different than the write enable (shift enable) allowing a little more flexibility. Although the early SRLs were a bit slower than one might want in-system, the current generation of Spartan devices - as I've been assured by the Xilinx support folks - can reach the full speed of the device if you use the slice register from the LUT/SRL output.Article: 108145
Tim Wescott wrote: > Antti wrote: > >> neha.karanjkar@gmail.com schrieb: >> >> >>>Hi all. >>>I'm an undergrad student doing a year long project on designing an 8051 >>>variant for FPGA. >>> We're required to decide upon the specifications, by targeting any >>>particular application. >>>I'd be really thankful for any suggestions for the applications.... >>> Could someone guide me to sites that offer a comparison, & >>>applications of available 8051 cores? >>> >>>thanx in advance >> >> >> there are many many many free and commercial 8051 derivates. spending a >> year to make another clone really doesnt make sense unless there is >> something around the 8051 that makes the whole SoC different from the >> current offerings. >> >> Antti >> > It's a _class project_ for crying out loud! The real point is to start > from something that's pretty fully specified, then make it work in the > real world. Applicability has little to do with it. > At least some of that depends on whether the student wants a "A" or less. "A" level work exhibits general knowledge of where 8051's have been / are used and either does one of those things better or does something new and challenging. -- JosephKK Gegen dummheit kampfen die Gotter Selbst, vergebens.  --SchillerArticle: 108146
"Jim Stewart" <jstewart@jkmicro.com> wrote in message news:bvSdncft9qz4kWPZnZ2dnUVZ_uydnZ2d@omsoft.com... > An SCR, placed across the terminals of a decent > sized gelcell will give a very rewarding blue > flash followed by an orange fireball after it's > been turned on. We used to put those 0.5mm pencil fillings across the 220V terminals (the screw type that also accepts banana plugs) at the test benches at school.... Especially the softer types (4-6B) produced a nice soft orange flash followed by enormous amounts of smoke :-) MeindertArticle: 108147
Hi All, Here is a open-source CableServer replacement for Xilinx Impact. Currently Parallel III and Altera ByteBlaster are supported, but any 3rd party programmer cable can be implemented easily and can be used from Impact. This open-source implementation can be used as a Programmer Cable SDK for Impact. I've tested only Impact 8.2, if anybody has any problem with 7.1, please let me know! Impact and Xilinx CableServer communication are very pooly written. There is no error recovery at all. If server stops, Impact GUI will crash. To avoid this you must disconnect server from GUI using Output/Cavble disconnect menu. http://sourceforge.net/projects/xilprg http://sourceforge.net/project/showfiles.php?group_id=175344&package_id=203209 Regards, ZoltanArticle: 108148
rickman wrote: > jacko wrote: > > just wondering if grey code (1 bit change) addressed stack memory might > > be useful for cutting down carry chain logic for pre-post dec/inc > > addressing?? > > Why bother? On FPGAs carry chain logic is free, fast and the easy > path. I guess you are thinking custom chip, eh? I wasn't sure I understood the question. Is it to reduce the worst-case speed for the increment? A traditional carry-type grey code implement has a worst case just as bad as binary, but it sounds like he's thinking about dedicating the space for a faster method. But likely I misunderstood. Why would he need the increment to be fast when something else would surely be slower anyway? And I'd expect a binary increment to take less space.Article: 108149
Hi all. I would like to link my own library file with the standard ones created in EDK by Xilinx. So I had thought to use the advanced compiler options--> I mean set a directory in the -L for the linker and moreover the file in the -l. But it doesn't work: i see the compiler get these options but an error says that not found the library... I'm sure and " have checked more times the path and the library name. Why? Could be a bug? I'm using EDK 8.1.02i. Thanks in advance. Cheers, Al.
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