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
On Feb 4, 10:01=A0am, "RCIngham" <robert.ing...@gmail.com> wrote: > >Hello All, > > >I am using the UNIFORM procedure in VHDL to generate random numbers. > >UNIFORM generates random numbers in the range 0.1 to 0.99999. I wish > >to generate random signed and unsigned numbers of variable > >widths(integer range). I would like to get some ideas on how I should > >scale this data? Right now, when i convert the real output from real > >to integer to signed, it just gives me an output of wither 0 or 1 . > >Your comments would be appreciated > > >Thank you > > Actually it returns reals in the range 0.0 to 1.0 (exclusive), that is it > can return 0.0, but not 1.0. > > As a previous reply states, you need to multiply the returned value by a > (real type) scaling factor before conversion to unsigned, and remember to > offset if converting to signed. Thank you very much everyone.Article: 128726
On 5 Feb., 14:17, hilo_p...@hotmail.com wrote: > Hi all, > > I am currently building a Digital Down Converter on Xilinx System > Generator 9.1 platform which unfortunately overshot resources provided > by mt target Virtex 4 chip by 400%. Is there any optimization way to > shrink it down.? Yes, suitable optimization functions can only be found in some minds of engineers thesedays. I would be suprised if anybody finds a set of switches that "optimize this DDC design by 400% in area".Article: 128727
LilacSkin wrote: > Hello, > > I have a problem with apparently no issue. > > I use a V5 and I have a problem with the data path delay of a net. > This net is used everywhere in my design and particulary in fixed > blocs. > The fanout is reduced to the maximum and I put a maxdelay constraint > on it. > The syntesis options are configured for speed. > > Anybody have an idea to reduce this delay ? > > Tk. > There are two normal ways to fix this problem. Firstly to add pipe-lining stages (series flip-flops) in, accepting that this puts a clock delay on the signal. The delay may or may not matter depending on your design. Alternatively, replicating the logic would help to reduce the fan-out. The latter is something that your synthesis tool may try. This depends on the tool settings, but you should be able to see if it has by looking at the synthesis reports. If you do it manually in the RTL you may be able to do it in a more transparent and controllable and therefore maintainable manner. Regards, Dunstan Power ByteSnap Design Ltd, Web: www.bytesnap.co.ukArticle: 128728
On Feb 5, 9:56 am, Michael Meeuwisse <mickeymeeuw@nospamplease_thesearchcompanywithcolorfulletters'emailservice.com> wrote: > Hi, > > > > Sky46...@trline5.org wrote: > > Michael Meeuwisse <mickeymeeuw@nospamplease_thesearchcompanywithcolorfulletters'emailservice.com> wrote: > > >>I'm trying to configure a Xilinx Spartan 3 s400 through JTAG in a new > >>prototype but I'm getting some weird results back while programming it. > >>I hope somebody with more experience can help me out. > > >>The fpga is the 2nd device in a chain of 3 devices, of which the third a > >>XC95144XL is which can be programmed succesfully. I assume therefore > >>that there are acceptable noise levels on the bus and bus speed > >>(currently at about ~1.2MHz - depends a bit on how fast the programmer > >>can handle incoming data but not faster than that) is Ok. > > > * Check power for any dips or transients. > > My VccAux seems to be 2.34V, this is supplied by a lm1086-2.5 so I don't > really know what's causing this (it's just below the minimum required, > isn't it?) or how I can fix it. Vcco is 3.34V and VccInt is 1.20V. > > > * Connect directly with a parallell port jtag adapter. > > Like this:http://www.xilinx.com/support/programr/jtag_cable.pdf > > > (And only try the USB approch once it confirmed to work) > > The thing is, the programmer is embedded on the board itself so > connecting a different programmer would require me to start cutting pcb > traces. > > > * Lower the clocking frequency, try 50 kHz. > > Didn't seem to help. Afaik there's no minimum clock so I even tried it > at ~100Hz (which takes forever btw, in case you never tried it) but it > still failed. > > > * Double check all pins related to configuration (DONE, M0,M1,M2, INIT_B, > > CCLK, etc) > > M[2:0] are all tied to ground, and changing this would again require > some force so I'd rather not. This shouldn't matter afaik, since you can > always program using JTAG anyway, right? Likewise, when configuring > using JTAG it doesn't matter what CCLK is, does it? I mentioned the > state of INIT_B, PROG_B and DONE earlier. > > > * You could connect pins to the fpga DIN etc.. back to your PC to verify your > > fpga actually get the data you expect. > > Would data pushed in through JTAG appear on DIN? I could write something > that checks TDO but I'm told the spartan spits out zeroes or other > nonsense when I'm shifting data in. > > Thorsten Trenz wrote: > > > Hi, > > > > Try to switch the modepins to JTAG only. Do you use a PC3 clone? There > > seems to be some problems in certain impact versions with PC3 and S3 if > > the chip is not in JTAG only mode. > > The programmer is an FTDI FT2232 using an homebrew XSVF parser. I > believe I've got all the bugs worked out of the software since > programming the CPLD goes without a problem. > > Cheers, > > Mikehttp://projectvga.org You didn't say what the first device in the chain was. There are known issues when placing a PlatformFlash (XCF02S for instance) in front of a Spartan device wired up for master serial configuration mode. Do you have a pullup on the DONE pin? If not have you checked the "Drive Done pin high" option in bitgen? Are you providing enough clocks at the end of the bitstream load to start up the device (again look at where DONE is supposed to go high in the bitgen options)? That's all I can think of. By the way if you are using an XFCxxS device in front of your FPGA, try erasing it to see if that helps the JTAG load. Regards, GaborArticle: 128729
hilo_pupu@hotmail.com wrote: > Hi all, > > I am currently building a Digital Down Converter on Xilinx System > Generator 9.1 platform which unfortunately overshot resources provided > by mt target Virtex 4 chip by 400%. Is there any optimization way to > shrink it down.? That is a bad overshoot ! The first thing that I would look at is memory usage ie are you using block RAMs ? Make sure you don't have some memories being turning into flops ! I have had some versions of Synplicity do this on pretty benign code, where previous versions synthesized the memory as Block RAM. Look at your synthesis report. Other things you can do is logic sharing ie use one block to serve multiple parts of the design by clocking it at a higher frequency than the rest of the design and multiplex the input and outputs. You need to get a handle on which the biggest blocks are and tackle those first if they are not 3rd party IP. Ultimately You may have to face that your target FPGA is far too small of course. You wouldn't be the first one ... Regards -- Dunstan Power ByteSnap Design Ltd, Web: www.bytesnap.co.ukArticle: 128730
Hi, Sky465nm@trline5.org wrote: > Michael Meeuwisse <mickeymeeuw@nospamplease_thesearchcompanywithcolorfulletters'emailservice.com> wrote: > >>I'm trying to configure a Xilinx Spartan 3 s400 through JTAG in a new >>prototype but I'm getting some weird results back while programming it. >>I hope somebody with more experience can help me out. > > >>The fpga is the 2nd device in a chain of 3 devices, of which the third a >>XC95144XL is which can be programmed succesfully. I assume therefore >>that there are acceptable noise levels on the bus and bus speed >>(currently at about ~1.2MHz - depends a bit on how fast the programmer >>can handle incoming data but not faster than that) is Ok. > > > * Check power for any dips or transients. My VccAux seems to be 2.34V, this is supplied by a lm1086-2.5 so I don't really know what's causing this (it's just below the minimum required, isn't it?) or how I can fix it. Vcco is 3.34V and VccInt is 1.20V. > * Connect directly with a parallell port jtag adapter. > Like this: http://www.xilinx.com/support/programr/jtag_cable.pdf > > (And only try the USB approch once it confirmed to work) The thing is, the programmer is embedded on the board itself so connecting a different programmer would require me to start cutting pcb traces. > * Lower the clocking frequency, try 50 kHz. Didn't seem to help. Afaik there's no minimum clock so I even tried it at ~100Hz (which takes forever btw, in case you never tried it) but it still failed. > * Double check all pins related to configuration (DONE, M0,M1,M2, INIT_B, > CCLK, etc) M[2:0] are all tied to ground, and changing this would again require some force so I'd rather not. This shouldn't matter afaik, since you can always program using JTAG anyway, right? Likewise, when configuring using JTAG it doesn't matter what CCLK is, does it? I mentioned the state of INIT_B, PROG_B and DONE earlier. > * You could connect pins to the fpga DIN etc.. back to your PC to verify your > fpga actually get the data you expect. > Would data pushed in through JTAG appear on DIN? I could write something that checks TDO but I'm told the spartan spits out zeroes or other nonsense when I'm shifting data in. Thorsten Trenz wrote: > Hi, > > Try to switch the modepins to JTAG only. Do you use a PC3 clone? There > seems to be some problems in certain impact versions with PC3 and S3 if > the chip is not in JTAG only mode. The programmer is an FTDI FT2232 using an homebrew XSVF parser. I believe I've got all the bugs worked out of the software since programming the CPLD goes without a problem. Cheers, Mike http://projectvga.orgArticle: 128731
On 5 f=E9v, 15:19, Dunstan Power <dunst...@bytesnap.co.uk> wrote: > LilacSkin wrote: > > Hello, > > > I have a problem with apparently no issue. > > > I use a V5 and I have a problem with the data path delay of a net. > > This net is used everywhere in my design and particulary in fixed > > blocs. > > The fanout is reduced to the maximum and I put a maxdelay constraint > > on it. > > The syntesis options are configured for speed. > > > Anybody have an idea to reduce this delay ? > > > Tk. > > There are two normal ways to fix this problem. Firstly to add > pipe-lining stages (series flip-flops) in, accepting that this puts a > clock delay on the signal. The delay may or may not matter depending on > your design. > > Alternatively, replicating the logic would help to reduce the fan-out. > The latter is something that your synthesis tool may try. This depends > on the tool settings, but you should be able to see if it has by looking > at the synthesis reports. If you do it manually in the RTL you may be > able to do it in a more transparent and controllable and therefore > maintainable manner. > > Regards, > > Dunstan Power > > ByteSnap Design Ltd, > Web: www.bytesnap.co.uk I cannot change the logic because this net is used in an IP. In a virtexII there were low skew lines, there is sometning like that in a v5 ?? Tk.Article: 128732
Not knowing anything about the system generator, but knowing a thing or two about DDC, my suspicion is that you have run into one of two issues (assuming this is the usual DDS-CIC-FIR type downconverter): - Your sin/cos LUT is not in RAM or has more entries than needed. If you want, I can send you a matlab script that will show you the tradeoff between various LUT table lengths, wordlengths vs. noise that may help you design this better. - Your FIR filter is attempting to do many parallel multiplies, this is very resource intensive. One of the reasons for downsampling is that you can reduce the data rate in the FIR and not have 20 parallel multipliers in a 20 tap FIR, but rather do them sequentially in between new samples coming into the FIR stage. ChrisArticle: 128733
Hello, From searching, I see that others have had this same problem, but the solutions were vague and old (2002). I'm using XPS 8.1 with Spartan IIE 600 and I'm trying to bring a couple of signals from a peripheral to a pin, but XPS automatically assumes that they are clocks, so it uses a GCLK which results in the error: "Number of GCLKs: 5 out of 4 125% (OVERMAPPED)". How can I find out which signals it has routed as GCLKs? How can I reduce the number of GCLKs used? How can I manually assign GCLKs to the signals I want, without XPS doing it automatically? I've tried passing the signals through an OBUF in the wrapper of my peripheral, but that results in an "illegal buffer" error. Thanks for your help.Article: 128734
Gabor wrote: > On Feb 5, 9:56 am, Michael Meeuwisse > <mickeymeeuw@nospamplease_thesearchcompanywithcolorfulletters'emailservice.com> > wrote: > >>Hi, >> >> >> >>Sky46...@trline5.org wrote: >> >>>Michael Meeuwisse <mickeymeeuw@nospamplease_thesearchcompanywithcolorfulletters'emailservice.com> wrote: >> >>>>I'm trying to configure a Xilinx Spartan 3 s400 through JTAG in a new >>>>prototype but I'm getting some weird results back while programming it. >>>>I hope somebody with more experience can help me out. >> >>>>The fpga is the 2nd device in a chain of 3 devices, of which the third a >>>>XC95144XL is which can be programmed succesfully. I assume therefore >>>>that there are acceptable noise levels on the bus and bus speed >>>>(currently at about ~1.2MHz - depends a bit on how fast the programmer >>>>can handle incoming data but not faster than that) is Ok. >> >>> * Check power for any dips or transients. >> >>My VccAux seems to be 2.34V, this is supplied by a lm1086-2.5 so I don't >>really know what's causing this (it's just below the minimum required, >>isn't it?) or how I can fix it. Vcco is 3.34V and VccInt is 1.20V. >> >> >>> * Connect directly with a parallell port jtag adapter. >>> Like this:http://www.xilinx.com/support/programr/jtag_cable.pdf >> >>> (And only try the USB approch once it confirmed to work) >> >>The thing is, the programmer is embedded on the board itself so >>connecting a different programmer would require me to start cutting pcb >>traces. >> >> >>> * Lower the clocking frequency, try 50 kHz. >> >>Didn't seem to help. Afaik there's no minimum clock so I even tried it >>at ~100Hz (which takes forever btw, in case you never tried it) but it >>still failed. >> >> >>> * Double check all pins related to configuration (DONE, M0,M1,M2, INIT_B, >>> CCLK, etc) >> >>M[2:0] are all tied to ground, and changing this would again require >>some force so I'd rather not. This shouldn't matter afaik, since you can >>always program using JTAG anyway, right? Likewise, when configuring >>using JTAG it doesn't matter what CCLK is, does it? I mentioned the >>state of INIT_B, PROG_B and DONE earlier. >> >> >>> * You could connect pins to the fpga DIN etc.. back to your PC to verify your >>> fpga actually get the data you expect. >> >>Would data pushed in through JTAG appear on DIN? I could write something >>that checks TDO but I'm told the spartan spits out zeroes or other >>nonsense when I'm shifting data in. >> >>Thorsten Trenz wrote: >> >> > Hi, >> > >> > Try to switch the modepins to JTAG only. Do you use a PC3 clone? There >> > seems to be some problems in certain impact versions with PC3 and S3 if >> > the chip is not in JTAG only mode. >> >>The programmer is an FTDI FT2232 using an homebrew XSVF parser. I >>believe I've got all the bugs worked out of the software since >>programming the CPLD goes without a problem. >> >>Cheers, >> >>Mikehttp://projectvga.org > > > You didn't say what the first device in the chain was. There are > known > issues when placing a PlatformFlash (XCF02S for instance) in front of > a Spartan device wired up for master serial configuration mode. > Yeah sorry, it's a XCF04S. I've got some other issues with that one however, it seems that is has some dead banks which is why I'm trying to program the fpga directly in the first place. As far as I can tell these two problems are unrelated. > Do you have a pullup on the DONE pin? If not have you checked the > "Drive Done pin high" option in bitgen? > No, no external pull up. I've set "Configuration pin done" to Float and checked "Drive done pin high" as suggested by table 2.6 of ug332. > Are you providing enough clocks at the end of the bitstream load to > start up the device (again look at where DONE is supposed to go high > in the bitgen options)? > I think so, I've tried programming the CPLD after I attempted to program the FPGA which should provide plenty of clock cycles, but it didn't change anything. > That's all I can think of. > > By the way if you are using an XFCxxS device in front of your FPGA, > try erasing it to see if that helps the JTAG load. > > Regards, > Gabor As it turns out, the LM1086-2.5 needs a minimum of 4V and I'm only giving it 3.3V so that might be cause of some of the trouble - it certainly explains why my VccAux is only ~2.3V. I'm going to fix that now and hopefully it'll help. Cheers, Mike http://projectvga.orgArticle: 128735
"Dunstan Power" <dunstanp@bytesnap.co.uk> wrote in message news:13qgr82q2bdc6de@corp.supernews.com... > > You are right that DCMs have minimum clock freq restrictions (eg 24MHz in > V5), Hi Dunstan, Indeed, he is right, but I think you may not be. To be technically correct, (the best kind of correct!) if you use only the DFS output, FCLKINLFFXMSMIN is 1 MHz. Read DS202, tables 50, 51. I couldn't find 24MHz anywhere, are you thinking of a different family? V5 MS mode apparently has a minimum of 32MHz, MR mode 19MHz. Cheers, Syms.Article: 128736
On Feb 5, 12:23=A0am, Daniel Koethe <dkoe...@nospam-web.de> wrote: > I want also > know if there is everywhere a Documentation or a Howto about the FPGA > Editor. Well, I've been looking for some docs about the Editor every now and then myself, but couldn't find anything instructive. So I suppose it's pretty undocumented, except for the Help from within the application itself. EliArticle: 128737
Hey everyone, Just wonderting if anyone else has upgraded Leonardo Spectrum in a while. I went from a (very) old version 2003b_65 to 2007a_37 and now I'm getting erros when it tries to load libraries adn such. Apparently the licenses known as ls3..... are now leospec3.... and the former was for use with a MOdeltech daemon but the latter newer versions are for use with a Mgcld daemon. I got that last bit from the Mentor website: https://origin-www.mentor.com/supportnet/news/hdl_license_features.html#leo but it doesnt say how or what I have to update to change this. I have the leospec3.... licenses but just cant seem to get Leonardo Spectrum to look for them! :-S Ayone else have this issue? Oh errors im getting are like thos included below: Security Error -1: Checkout of "ls3_xi5" failed - Licensing checkout error with feature ls3_xi_pkg. (Error code -97.) Thanx for any help and happy pancake tuesday!!!!! Rob.Article: 128738
>> * Check power for any dips or transients. >My VccAux seems to be 2.34V, this is supplied by a lm1086-2.5 so I don't >really know what's causing this (it's just below the minimum required, >isn't it?) or how I can fix it. Vcco is 3.34V and VccInt is 1.20V. XC3S400-PQ208 http://direct.xilinx.com/bvdocs/publications/ds099.pdf (t31 p58/208) Min Nom Max Vccint 1.140 1.200 1.260 Vccaux 2.375 2.500 2.625 Vcco 1.140 - 3.450 LM1086-2.5 http://users.ece.utexas.edu/~valvano/Datasheets/LM1086.pdf Min Typ Max Vout 2.450 2.50 2.525 (Vin=4-18V Ifull) Current limit: Min=1.5A Typ=2.7A at Vin=8V Your Vcco regulator uses "3V3" for Vin with a 10uF capacitor on each input and output. "3V3" comes from S53, S39, S33, S27, S21, C25, C31, C36, C41, C43, C54 on the PCI connector (CON1). (Schematic: http://wacco.mveas.com/img/schema1d.png) So the Vin of the 2.5V regulator is not enough. Also there's the issue of voltage ramp time upon startup. Vcco 2000 us Vccaux - us (no requirement) Vccint 500 us (p57 Table 29 Power voltage ramp time requirements) So you might need to check Vccint vs Vccaux. The Vccaux should be powered before Vccint, but it's not that sensitive (or?). (see p53) Check that your oscillator does have proper power. And outputs a correct waveform at the XC3S400 input (Bank5 GCLK2, P76). (LVTTL 0.8 - 2.0 swing + flanks) >> * Connect directly with a parallell port jtag adapter. >> Like this: http://www.xilinx.com/support/programr/jtag_cable.pdf >> (And only try the USB approch once it confirmed to work) >The thing is, the programmer is embedded on the board itself so >connecting a different programmer would require me to start cutting pcb >traces. Measure the output of your onboard usb programmer that it does what you expect it to do. Ie feedback it's TDO to your parallell port. If this fails, try the cut traces approach and solder some wires so you can change programmer at will. Also use program directly via JTAG mode to start with, only when that works try eeprom. The first bitstream ("program") should be something simple like pulsing a LED. (604-00033G-ND IC FTDI2232L USB/SERIAL 48-LQFP) Scan chain (reverse order?): FTDI2232L - XC95144XL - XC3S400 - XCF01S - FTDI2232L >> * Lower the clocking frequency, try 50 kHz. >Didn't seem to help. Afaik there's no minimum clock so I even tried it >at ~100Hz (which takes forever btw, in case you never tried it) but it >still failed. Verify bitstream at TDI+TCK? {M0,M1,M2} = 3'b000 (ds099 p45 for mode table) So configuration mode is master serial. Thus CCLK+DIN is the ones that dictates programming. Setting M0=1, M1=0, M2=1 gives you jtag programming mode. Which might make life easier in the beginning. It's also the mode that is smoother to use when developing. >> * Double check all pins related to configuration (DONE, M0,M1,M2, INIT_B, >> CCLK, etc) >M[2:0] are all tied to ground, and changing this would again require >some force so I'd rather not. This shouldn't matter afaik, since you can >always program using JTAG anyway, right? Likewise, when configuring >using JTAG it doesn't matter what CCLK is, does it? I mentioned the >state of INIT_B, PROG_B and DONE earlier. M[2:0] = 000 => Master serial mode according to datasheet ds099 page 45. So CCLK will matter. Btw, check if CCLK (2.5V) does output a proper waveform at the eeprom input (Pin3 CLK). And that eeprom output is correct at the fpga. Btw, notice that CCLK is 2.5V, and eeprom output is 3.3V Signals: INIT_B Shall go high after memory is cleared. And shall not be tied low. PROG_B Goes high? DONE Goes high after configuration is complete. HSWAP_EN Is tied low in your schematic => Pullup resistors enabled on all pins not activly involved in the configuration process. Check that no pullup'ed pin interfere with the configuration process. (ds099 p101) You might use these to find out what's going on. >> * You could connect pins to the fpga DIN etc.. back to your PC to verify your >> fpga actually get the data you expect. >Would data pushed in through JTAG appear on DIN? I could write something >that checks TDO but I'm told the spartan spits out zeroes or other >nonsense when I'm shifting data in. My idea was to attach a wire directly to TDI/TDO + TCK back into an INPUT pin of the parallell port to verify data. >Thorsten Trenz wrote: > > Hi, > > > > Try to switch the modepins to JTAG only. Do you use a PC3 clone? There > > seems to be some problems in certain impact versions with PC3 and S3 if > > the chip is not in JTAG only mode. >The programmer is an FTDI FT2232 using an homebrew XSVF parser. I >believe I've got all the bugs worked out of the software since >programming the CPLD goes without a problem. Verify board connections -> Power -> Clocks -> Other. I think also that if you try to program: Onboard USB -> XCF01S eeprom eeprom -> FPGA You add more steps that may fail. Also you could try to manually read if the contents of the XCF01S is what you expect. >it's a XCF04S. I've got some other issues with that one >however, it seems that is has some dead banks which is why I'm trying to >program the fpga directly in the first place. As far as I can tell these >two problems are unrelated. So you need to alter M[0:2] pins to 1-0-1 (ds099 p45). And according to table 26 (ds099 p45) you need at least an XCF02S. So schematic is contradictive.. :) Your schematic would be easier to follow if you added consistent chip identifications ie Ux XC3S400 etc.. Also soldering pads for debug fixes could be something to have in mind for later revisions. Assume failure ;)Article: 128739
maverick <sheikh.m.farhan@gmail.com> wrote: >Hi, >i need to know is it possible to readback and verify the loaded >configuration in the FPGA after the GSR is deasserted and the FPGA is >up and running with the loaded configuration? I am suspecting that due >to power requirement of my application, the FPGA loses its >configuration when the current demand increases ( HDD is connected to >the FPGA board, when the FPGA talks to the HDD through SATA >controller, the current goes up from .8 Amp to 1.7 Amps)and the FPGA >stops working in the expected manner. Try separate power supplies for the FPGA and HDD ..?Article: 128740
On Feb 5, 6:03 pm, Sky46...@trline5.org wrote: > >The synthesis tools currently run as a single threaded process, and > >therefore dual and quad core CPUs have a limited effect on > >performance. I run the tools on my dual core desktop and the main > >benefit of dual core for me is that I can perform other tasks while > >the tools are crunching away on one of the CPUs, on my previous single > >core machine it was pretty much unusable. > >Apart from having at least one fast CPU you will also benefit greatly > >from having a large amount of high bandwidth memory (<=2GB). Make sure > >it is dual channel and some high frequency DDR variant. > >I'm not sure what impact fast hard drives make, since (as far as i > >know) as long as you don't run out of memory that's where the number > >crunching is performed. > > The factors seems to look like this: > * Don't bother with more than one core. > * L2 cache is really good (L1 doesn't hurt). > * Fast memory bus (FSB speed). > * Fast dram chips (DDR2 >600 MHz etc). > * 64 bit over 32bit. > * CPU frequency. > > So you should get fast memory primarly, and secondarly look at cpu frequency. Hi, Rob, sky46 Thanks a lot for your inputs. -- GoliArticle: 128741
Dave, Thanks so much. Actually removing -target mdm worked! I feel dumb to have spent weeks trying to fix this issue! But at least it is working now! Thanks a lot again, Amir On Feb 4, 11:26 pm, David <simianfe...@gmail.com> wrote: > > I actually tried this command: > > $ xmd -tcl genace.tcl -jprog -hw implementation/download.bit -board > > ml310 -target mdm -elf timer_test/executable.elf -ace system.ace > > > My software code is supposed to write something to hyperterminal > > through RS232 port and I have in fact populated the local BRAMs with > > the data and instructions of my software code and download.bit should > > contain that information (I tried commands with and without -elf > > timer_test/executable.elf). > > Did you try removing the "-target mdm" as well? If your program is in > bram it shouldn't be necessary. > > > Firstly I don't know why it is so, secondly I know no more convenient > > way to make sure that my design is actually loaded and working (the > > only way I found convenient is to write something to the output)! > > You could try a very simple design in ISE that just flashes a led or > something and make an ace file from that. That should at least tell > you whether it is a problem with the systemAce or the microblaze. > > Also, re-reading your original post - you probably don't need the OPB > SysAce controller unless you intend to write to the compact flash - it > could be causing some conflict with the sysace chip if it's not set up > properly. > > Cheers, > DaveArticle: 128742
Hi I have done some VHDL implementations that were successfully running on an FPGA. However, I still feel unsecure about what constructs so that the design is working in the end. I am using XST, they have some modelling advices for specific constructs. Are there any other sources that could help me to improve my code? Many thanks!Article: 128743
The resources of Xilinx FPGAs - BlkRAMSs - multipliers - LUTS - FFs - DCMs all can be the first to max out. You need to look at your .mrp report to get an idea of which resoures max'd out first. Cutting back an implementation by 75%, and still have identical functionallity sounds pretty tough. However, Basic Debug 101 should tell you to go back to the core generator, and selectively enable/disable certain features of your DDS so you can get an idea of the resource size of each block element. Then you can explore whether parts of design might be reduced in performance to give area reductions. ie, the DSP Slice in V4 contains multipliers that are 18x18. You might want to choose tap coefficients 18 bits or less. Otherwise multiple slices may be used for single multiply. I think the FIR is usually the resource hog in the downconverter. You might want to temporarily skip the DDS, and compile the FIR with different attribute sizes to get an idea of what the resource usage might be. Good luck. -- Regards, John Retta Owner and Designer Retta Technical Consulting Inc. Colorado Based Xilinx Consultant phone : 303.926.0068 email : jretta@rtc-inc.com web : www.rtc-inc.comArticle: 128744
I am getting the following warning in Modelsim # ** Warning: Design size of 10053 statements or 1 leaf instances exceeds ModelSim PE Student Edition recommended capacity. # Expect performance to be quite adversely affected. When I run simulations, I do not see any waveforms and it just freezes there forever. My design size if around 1000 lines. I do have other vhdl files for other projects. I have Modelsim Student edition. How do I fix this problem? ThanksArticle: 128745
>Hi > >I have done some VHDL implementations that were successfully running on >an FPGA. However, I still feel unsecure about what constructs so that >the design is working in the end. I am using XST, they have some >modelling advices for specific constructs. Are there any other sources >that could help me to improve my code? > >Many thanks! > The definitive answer is to follow the synthesis interoperability subset definded in IEEE 1076.6, but this is very restrictive, and you probably cannot get hold of it without paying. Altera, Xilinx, and Actel support very similar synthesisable subsets, so if you follow the XST guidelines you will not go far wrong. Inferring RAMs, ROMs, and some other technology-related constructs is where things may diverge. Being technology independent is a worthy aim, but getting your design working on the technology you are using now is the primary goal.Article: 128746
giorgos.puiklis@gmail.com wrote: > 1. How can I see the exact functionality of the the cells Leonardo > produces in its RTL Schematic, after reading my input HDL files? These are just place holders for blocks of logic. After place and route, they won't be recognizable. Functionality is determined by your source code, not synthesis. > 2. When I use the VHDL "block" statement, the synthesizer appears to > completely neglect (in its RTL schematic) the blocks I asked for. It > creates the same schematic it did before I entered the block- > statements. Is there a way to make the synthesizer take into account > block-statements? The vhdl block statement is just a language scope limiter. If I wanted a structural block I would make a separate entity. -- Mike TreselerArticle: 128747
robquigley@gmail.com wrote: > Anyone else have this issue? Yes. We updated the server to mgcld several years ago, but I don't remember the details. Call Mentor. -- Mike TreselerArticle: 128748
FPGA wrote: > # ** Warning: Design size of 10053 statements or 1 leaf instances > exceeds ModelSim PE Student Edition recommended capacity. > # Expect performance to be quite adversely affected. > How do I fix this problem? Remove 53 lines or buy a license. -- Mike TreselerArticle: 128749
This information is from ISE9.2i, Spartan 3e target. > How can I find out which signals it has routed as GCLKs? In the GUI, bring up the design summary. Under "Design Overview" in the Design summury window. Click on "CLOCK REPORT" If a clock is listed as beign in Resource BUFGMUX_*, It is being assigned to GCLK. > How can I reduce the number of GCLKs used? I don't know. > How can I manually assign GCLKs to the signals I want, without XPS > doing it automatically? Xilinx Constraint User Guide(P191 of 396) (UCF) INST "buf1" LOC=GCLKBUF1; <markmcmahon@hotmail.com> wrote in message news:dba09492-1743-4a7f-a11f-53228ff01620@e10g2000prf.googlegroups.com... > Hello, > > From searching, I see that others have had this same problem, but the > solutions were vague and old (2002). I'm using XPS 8.1 with Spartan > IIE 600 and I'm trying to bring a couple of signals from a peripheral > to a pin, but XPS automatically assumes that they are clocks, so it > uses a GCLK which results in the error: > > "Number of GCLKs: 5 out of 4 125% (OVERMAPPED)". >
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