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
The device is a Spartan 3. The project was previously synthesized without using modular design and there is nothing mentioned in that log about problems with TBUF's. Is this something specific to using modular design flow that is making this occur? Perhaps having to use the -iobuf no option when synthesizing a module. On Jun 4, 7:24 am, Gabor <g...@alacron.com> wrote: > On Jun 4, 12:09 am, javaguy11...@gmail.com wrote: > > > I have a project where I am trying to use modular design flow. When I > > do synthesis of one of my modules I see the message in the log. > > > Number of TBUFs: 61 out of 0 (*) > > > I think this is causing me problems when I try to do the assemble, > > because those modules get dropped from the design. > > > Any suggestions on what I am doing wrong or how to work around it. > > Which device are you using? Spartan, XL, II, IIe have TBUF in > hardware. > Spartan 3, 3e, 3a, 3an, ... do not. Normally synthesis can replace > internal tri-state buses with LUTs, but if you try to instantiate > TBUF's in a part that doesn't have any you will "overmap" the device > as shown in your report. > > HTH, > GaborArticle: 120251
On 4 Jun., 01:09, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> wrote: > On Sun, 03 Jun 2007 06:35:36 -0700, jid...@hotmail.com wrote: > >"Microcontrollers have a better predictable time behaviour, because > >their circuit is integrated in silicon and is unchangeable; unlike > >FPGAs which have variable timing performances." > > >Is this statement correct? > > I don't know, because it's nearly meaningless. > > What I *do* know is this: Once you've successfully implemented > a given function or circuit on an FPGA, its timing is entirely > predictable in the sense that every copy of that FPGA will meet > the same timing spec - maximum clock frequency, input setup time, > output delay, etc. In a rather similar way, every microprocessor > chip of the same type that you buy will meet its data sheet > timing spec. So in that sense, the statement is nonsense because > FPGA implementations and microprocessors are equally predictable > at meeting their timing specs. > > I also know that a typical microcontroller represents a large > investment in design and verification work by the manufacturer, > work that I would have to do myself if I wished to implement > exactly that microcontroller in an FPGA. So I'm not going > to bother to do that. I'll buy the uC chip, thanks - unless > the uC function can be trivially integrated into my FPGA > using the nice system-builder tools currently on offer. > > I also know that I can design things in an FPGA that will > outrun a microcontroller by many orders of magnitude in > speed. And here we perhaps get to the nub of your statement, > because until I embark on the FPGA design I can't know > exactly how fast it will run - what its Fmax will be. In > that sense, and only in that sense, the FPGA is "unpredictable". > However, modern timing analysis tools, combined with my own > engineering intuition about which parts of the design are > most likely to be timing-critical, will quickly lead me > to a good estimate of the speed that I will ultimately > achieve, and therefore will guide my design strategy so > that I can meet my application's requirements. > -- > Jonathan Bromley, Consultant > > DOULOS - Developing Design Know-how > VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services > > Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK > jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com > > The contents of this message may contain personal views which > are not the views of Doulos Ltd., unless specifically stated. Thanks for the informative answers. Lets say I implement a core processor on a certain FPGA, e.g. Spartan-3 XC3400, and figure out the timing speicifications. Later, I want to implement this same core in the same FPGA series only bigger, e.g. Spartan-3 XC 3S1000; how accurate will the timing specifications I did in the previous FPGA be here?Article: 120252
On 1 juin, 09:03, Tim Morlion <tmorl...@gmail.com> wrote: > I would like to use partitions with the edif flow. I'm using an older version of > SynplifyPro which does not support partitions. From what I understand, the only > thing Synplify does, is adding a timestamp to the partitions in the edif file. > e.g. (instance or1200_dc_top (viewRef verilog (cellRef or1200_dc_top)) (property > PARTITION (string "1169730682")) ) > > However after adding this, ngdbuild still reports that no partitions are available. > > Does anybody know what exactly has to be added to the edif for the ise tools to > recognize partitions? > > Thanks I'm not sure how the edif-based partition flow works. My understanding is that you still need to run the whole design (including the synthesis stage) in ISE. By using edif, you minimize the work done by xst but I think that xst needs to run in ISE for partitions to work later down the flow. You might also want to give the -smartguide flag a try at the map and par stages instead. PatrickArticle: 120253
Patrick Dubois wrote: > On 1 juin, 09:03, Tim Morlion <tmorl...@gmail.com> wrote: >> I would like to use partitions with the edif flow. I'm using an older version of >> SynplifyPro which does not support partitions. From what I understand, the only >> thing Synplify does, is adding a timestamp to the partitions in the edif file. >> e.g. (instance or1200_dc_top (viewRef verilog (cellRef or1200_dc_top)) (property >> PARTITION (string "1169730682")) ) >> >> However after adding this, ngdbuild still reports that no partitions are available. >> >> Does anybody know what exactly has to be added to the edif for the ise tools to >> recognize partitions? >> >> Thanks > > I'm not sure how the edif-based partition flow works. My understanding > is that you still need to run the whole design (including the > synthesis stage) in ISE. By using edif, you minimize the work done by > xst but I think that xst needs to run in ISE for partitions to work > later down the flow. > > You might also want to give the -smartguide flag a try at the map and > par stages instead. > > Patrick > In edif flow, xst is not used as synthesis tool. A third party synthesis tool, like Synplify Pro, generates an edif, which is passed to the xilinx ngdbuild, map and par tools. For the xilinx tools to know which partitions are defined and which partions have been changed, the third party synthesis tool has to write writes this information into the edif file. So both the third party synthesis tool and xilinx tools agree on where this information is found in the edif. That is what my question is about, where can I find documentation on what exactly is written in the edif file, for what concerns partitions. In addition, I have read somewhere that Synplify Pro also generates a tcl file with some info regarding partitions, but again with no details.Article: 120254
I Just checked their website, but this device is not yet available on their store. XP however has online pricing, and availability for some of the parts. I suppose it is just a matter of Mouser (powering the web store) buying the parts. Luc On Mon, 4 Jun 2007 11:20:27 +0000 (UTC), Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de> wrote: >Antti <Antti.Lukats@googlemail.com> wrote: > >> options, nothing nothing nothing. Xilinx has really mis-understood the >> meaning of >> "online shop"... > >Another example: > >Look in the online shop of the XC3S500E in hand solderable PS2008. Nill, >Zilch, Nada... > >Then go to digikey.: On stock ... > >> lets hope XP2 devices are readily available, the RAM to flash transfer >> seems nice > >IS XP2 in some online shop, with online pricing?Article: 120255
Hi I am designing a board with a Virtex 4 FX20. I want to use 4 out of the 8 MGT devices. I am planning to use a 312.5MHz oscillator for the clock. My question is can I supply the clock to each of the MGT tiles (2) or should I use a fan out chip so that each tile has its own clock which will be derived from my input oscillator. Cheers JonArticle: 120256
I wrote: > For V2: > Download the HSPICE models, unzip, then look in the v2_pkg_flight > subdirectory, which has excel files for each package. > The trace lengths, when available, can also be dumped using partgen to create an ASCII .pkg file I believe PACE and Jim Wu's ADEPT will also display this information. BrianArticle: 120257
John Adair <g1@enterpoint.co.uk> wrote: > Uwe > If you like something hand solderable for XC3S500E have a look at out I already have a selfmade board with XC3S500-PQ208 running. The 500E was bought at digikey. Programming is done via USB by a FT2232 and a modified xc3sprog -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 120258
On 4 juin, 10:22, Tim <tmorl...@gmail.com> wrote: > In edif flow, xst is not used as synthesis tool. A third party synthesis tool, > like Synplify Pro, generates an edif, which is passed to the xilinx ngdbuild, > map and par tools. > For the xilinx tools to know which partitions are defined and which partions > have been changed, the third party synthesis tool has to write writes this > information into the edif file. So both the third party synthesis tool and > xilinx tools agree on where this information is found in the edif. > That is what my question is about, where can I find documentation on what > exactly is written in the edif file, for what concerns partitions. > > In addition, I have read somewhere that Synplify Pro also generates a tcl file > with some info regarding partitions, but again with no details. Yes, I understand that Synplify generates the edif. My point is that in order for the ngdbuild, map and par tools to know about partitions, the design must be implemented using the ISE environnement (no need to use xst after all, my mistake). The only place where you can specify what part of the design is a partition, is within the ISE flow. Basically you can't just feed your edif to ngdbuild, it won't recognize the partitions. >From AR 24870: "When ISE parses the EDIF file, it will create the relative Partition for each tagged hierarchical node." Only ISE can create partitions which will be understood by ngdbuild. I just found this article, it seems to explain everything we need to know about partitions+Synplify. http://syndicated.synplicity.com/Q107/xilinx.html If you want to stay all command-line, you need to use the new tcl interface to run the Xilinx tools (you can't run them directly to use partitions). See chapter 3 of the Development System Reference Guide. Good luck.Article: 120259
"maxascent" <maxascent@yahoo.co.uk> wrote in message news:UaGdnZAJ1LhDvPnb4p2dnAA@giganews.com... > > I am designing a board with a Virtex 4 FX20. I want to use 4 out of the 8 > MGT devices. I am planning to use a 312.5MHz oscillator for the clock. My > question is can I supply the clock to each of the MGT tiles (2) or should > I use a fan out chip so that each tile has its own clock which will be > derived from my input oscillator. If the tiles are you want to use are on the same side then one MGT clock is enough, otherwise you'll need two. /MikhailArticle: 120260
But can the BRAM FIFO be made to work with back-to-back reads? Since the BRAM registers the address, it won't work if you just increment the read address pointer when read enable is true - the output data is a clock behind the read address pointer, so you need an idle clock cycle between each read. Barry Brown "Peter Alfke" <alfke@sbcglobal.net> wrote in message news:1180812666.685871.195270@i38g2000prf.googlegroups.com... > If you use a BlockRAM as a FIFO, you have to accept that any read > operation is synchronous, i.e. the result of a read-clock edge. > First-word-fall-through puts the first word written into a previously > empty FIFO onto the output, synchronously with the read clock, but > irrespective of the read clock enable. > I call it a push operation, as opposed to the pull in normal mode. > Once more than one word is in the FIFO, there is no difference between > the two modes, you can always get a new word on the nect Read clock > tick, if that is what you want. > Peter Alfke, Xilinx > > > On Jun 2, 11:18 am, Duane Clark <junkm...@junkmail.com> wrote: >> Pasacco wrote: >> > Hi >> >> > I have problem to implement a FIFO with "Synchronous WRITE, >> > Asynchronous READ" in Xilinx device. >> >> > Since the FIFO size is large (more than 48-deep words), I would like >> > to use BRAM or Built-in FIFO. >> >> > I tried "Synchronous WRITE, Synchronous READ" using dual-ported BRAM >> > and it seems okay. >> >> > Problem is that >> >> > Every time we 'read', one cycle delay occurs. >> > I want to 'immediately read' a data in the location that the "read >> > address" points to. >> >> > I am not finding a way to implement "Asynchronous READ" in BRAM. >> >> > If anyone has this experience, please let us know. >> > Thank you in advance >> >> The BRAMs are synchronous devices; you cannot read them asynchronously. >> So the only solution is some sort of prefetching, as mentioned. The CLB >> RAMs do allow asynchronous reads, and "more than 48-deep words" is not >> terribly large. That means probably 4 CLBs per word bit (depending on >> the device used), so a 16 bit word is 64 CLBs. Not really that many. So >> you might want to consider just using them if you don't want to bother >> with prefetching. > >Article: 120261
Hi does anyone already made a tcl command to write down any signals from the wave into a CSV file (excel compatible) thanks for your help jackyArticle: 120262
Here we are. The problem was that the ICAP wasn't configured well. For some reason, XPS didn't add the BASE and HIGH ADRESSES in the xparameters.h I did it by hand, editing that file and when running the app again, I could finally read and write a frame throught ICAP. "BaseAdress : 0" has now the right adress. Hope this can help somebody... Fabien On Jun 4, 11:07 am, "fabien....@gmail.com" <fabien....@gmail.com> wrote: > Thanks you Neil. > I read that, but I am using the Slave Serial configuration mode, which > shouldn't disable the ICAP. We are still investigating the board/FPGA > configuration to see if it could be related to something else. > > Fabien > > On Jun 2, 1:07 am, Neil Steiner <neil.stei...@vt.edu> wrote: > > > > I read somewhere, there may be a conflict when using ICAP and JTAG. > > > Do anybody have any information about this? > > > That is correct. Read the "Important Note" paragraph on page 3 ofhttp://www.xilinx.com/bvdocs/ipcenter/data_sheet/opb_hwicap.pdf(actual > > page number is 70): > > > "Important Note: The HWICAP core uses the ICAP found inside Virtex IITM > > and Virtex-II ProTM devices. The ICAP port interface is similar to the > > SelectMAP interface, but is accessible from general interconnects rather > > than the device pins. The JTAG or "Boundary Scan" configuration mode pin > > setting (M2:M0 = 101) will disable the ICAP interface. Therefore, when > > using the HWICAP core, another mode pin setting must be used. If JTAG > > will be used as the primary configuration method, select another mode > > pin setting to avoid disabling the ICAP interface. JTAG configuration > > will still be available because it overrides other means of > > configuration, and the HWICAP core will function as intended." > > > "Besides being disabled with the Boundary Scan mode pin setting, the > > ICAP will be disabled if the persist bit in the device configuration > > logic's control register is set. When using bitgen one must make sure > > that the Persist option is set to No, which is the default. This option > > is generally specified in the bitgen.ut file in the etc subdirectory of > > the EDK project."Article: 120263
jidan1@hotmail.com wrote: > Thanks for the informative answers. > Lets say I implement a core processor on a certain FPGA, e.g. > Spartan-3 XC3400, and figure out the timing speicifications. Later, I > want to implement this same core in the same FPGA series only bigger, > e.g. Spartan-3 XC 3S1000; how accurate will the timing specifications > I did in the previous FPGA be here? As long as the speed grade and the FPGA family doesn't change, the achievable maximum frequency should be more or less the same. But it depends on how big the core implemented is. If it fills up a large portion of the FPGA, the tools might not be able to place and route everything in the most optimal way, because they have a hard time squeezing the design into the FPGA in the first place. In such a case, the design will perform better in a bigger device. HTH, Sean -- My email address is only valid until the end of the month. Try figuring out what the address is going to be after that...Article: 120264
> >+From "dmesg": >parport0: PC-style at 0x378 [PCSPP] > So after a bit more hunting I see that from dmesg that parport0 is only set up for PCSPP mode, but I need ECP mode to utilize the faster PC4 mode or COMPAT for slower download. Any thoughts?Article: 120265
Simon, That is the intent of this number. Of course, some say this number is inflated (to discourage ASIC conversion), and others say it is "realistic." I have no opinion on the matter. Making ASICs is hard enough without any other factors, though. Perhaps someone from our software team will reply. I am in San Diego at DAC all week. AustinArticle: 120266
On Jun 3, 3:55 am, Jan Pech <n...@spam.please> wrote: > On Sat, 2007-06-02 at 17:40 +0000, morphiend wrote: > > On Jun 2, 10:27 am, Jan Pech <n...@spam.please> wrote: > > > On Sat, 2007-06-02 at 13:08 +0000, morphiend wrote: > > > > I have a system on a Virtex4-FX with a MicroBlaze and the xilinx > > > > opb_emc (v 2.00). I thought I set up the parameters properly to match > > > > the async FLASH memory chip that I have on my development board, but > > > > the controller does not look to be respecting the settings I set. > > > > > I have the system running at 100MHz, and the external FLASH chip is a > > > > 70ns Spansion part. On a read, the address needs to stay valid for > > > > 70ns, but it's only staying valid for ~2 cycles (where the cycles are > > > > based upon the 100MHz clock, and observed using ChipScope). The same > > > > happens for a write, for say putting the chip into CFI mode, the write > > > > line is only staying asserted for ~2 cycles when it needs to be 70ns > > > > as well. > > > > > I tried increasing the timespec values for the ipcore, but the > > > > external operation stayed exactly the same even if I doubled the > > > > requirements. > > > > > Has anyone seen or experienced similar problems? > > > > > TIA, > > > > > Mike Koss > > > > Mike, > > > Did you set the memory type to asynchronous? What you describe looks > > > like synchronous mode. > > > Jan > > > Yes I have it currently set to asynchronous, because the part I was > > interfacing to is asynchronous (no clock input). Is this not the > > correct assumption? > > Your assumption is correct. But from the behavior you described I got > the feeling the mode had been set to synchronous. When you choose > asynchronous mode of the EMC, the controller takes into account the > timing parameters. If you set the synchronous mode, the only timing > related parameter EMC looks at is the pipeline latency (1 or 2 clock > cycles). At least OPB_EMC v. 2.00.a behaves this way. > Jan I double-checked my project and it was set to async mode for the memory bank. I tried changing it to sync (to see what happens) and it changed from two-cycle to one-cycle. That was what I expected: it still didn't work. I'm using the latest ISE/EDK 8.2 and the opb_emc v.2.00.a. Looks like I'm going to have to file a webcase for the problem and see what Xilinx has to say.Article: 120267
lgs23 <lgs23@cornell.edu> wrote: > > > >+From "dmesg": > >parport0: PC-style at 0x378 [PCSPP] > > > So after a bit more hunting I see that from dmesg that parport0 is only > set up for PCSPP mode, but I need ECP mode to utilize the faster PC4 mode > or COMPAT for slower download. Any thoughts? Ever tried to enter BIOS on bootup and set the appropriate mode? -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 120268
"Barry Brown" <b0_nws2@agilent.com> wrote in message news:1180971829.270177@newsreg.cos.agilent.com... > But can the BRAM FIFO be made to work with back-to-back reads? Since the > BRAM registers the address, it won't work if you just increment the read > address pointer when read enable is true - the output data is a clock > behind the read address pointer, so you need an idle clock cycle between > each read. > Barry Brown If the read address changes combinatorially with the read enable, the clock edge will provide the data for the next address in the back-to-back reads for the BlockRAM. No problem.Article: 120269
On May 27, 10:12 pm, "Xilinx user" <xilinx_u...@nowhere.net> wrote: > DoesQuartus-II 7.1 support theSystemverilogpreprocessor's `` > concatenator? > > `define pori_reg(r) \ > r <= def_``r > > localparam int def_hp_length = 800; > localparam int def_hp_retrace_end = 720; > localparam int def_hp_disp_start = 80; > > always @( posedge clk ) > if ( !rstn ) > begin > `pori_reg( hp_length ); > `pori_reg( hp_retrace_end ); > `pori_reg( hp_disp_start ); > > ///////////////////////////////////////////////// > // equivalent to > ///////////////////////////////////////////////// > > always @( posedge clk ) > if ( !rstn ) > begin > hp_length <= def_hp_length; > hp_retrace_end <= def_hp_retrace_end; > hp_disp_start <= def_hp_disp_start; > > This simulates fine in Modelsim XE-III 6.2c Starter Edition, butQuartus > complains: > Error (10108): Verilog HDL Compiler Directive error at vga_reg.sv(42): > missing Compiler Directive > Error (10170): Verilog HDL syntax error at vga_reg.sv(42) near text > "hp_length"; expecting ";" > ... No, Quartus II does not support any of the `define extensions defined by the SystemVerilog language. These include `", `\`", and ``. These features will be added to Quartus II 8.0. - Subroto Datta Altera Corp.Article: 120270
On May 30, 10:28 am, mozilla <godzilla...@gmail.com> wrote: > Hi, > > I recently got a nexys -1000 board for a project i'm working on and > would like to put a xilinx EDK design on the board, however Digilent > don't provide a .xbd (board description file) for this board. Rather > than re-invent the wheel i was wondering if anyone out there had found > one or had already compiled one? > > Any help would be greatly appreciated. I guess, 13 answers later you still didn't get the .xbd file, right ?Article: 120271
mahalingamv@gmail.com wrote: > ERROR:NgdBuild:455 - logical net 'myclknot' has multiple driver(s): > pin O on block myclknot1_INV_0 with type INV, > pin PAD on block myclknot with type PAD Have you checked the source of "myclknot"? Seems like it is being driven by a pad AND by logic. cu, Seam -- My email address is only valid until the end of the month. Try figuring out what the address is going to be after that...Article: 120272
javaguy11111@gmail.com wrote: > The device is a Spartan 3. > The project was previously synthesized without using modular design > and there is nothing mentioned in that log about problems with TBUF's. I think during a normal synthesis run, TBUFs are automatically replaced by logic. I know that at least in Virtex4, there are no internal tristates, so if you describe tristate busses, the tools don't complain but just replace them with logic. But if you do the modular design flow, the TBUFs become sort of "external ports" that can't be changed automatically, so the synthesis tool tries to keep the TBUFs, and ngdbuild/map stop later because there aren't any in that architecture. I don't think the "-iobuf"-option will help in that case, since it turns on/off automatic insertion of IO buffers by the tools, but it will not change/remove buffers that you have instantiated manually. I guess the only thing you can do is have two seperate signals for the two directions and one direction signal as module ports, instead of the tristate-line. Not sure how you would properly constrain the localtion of the module crossings in that case, though. BTW, I thought the whole modular is deprectaed since ISE8/9, and now there is only "partitions"? Haven't tried that out yet, but maybe you should have a look. -- My email address is only valid until the end of the month. Try figuring out what the address is going to be after that...Article: 120273
Hello,
I have a weird issue with a Virtex-4 design. The problem is that xst
somehow manages to find the coregen fifos vhd files in my design and
synthesizes them (I'm using a command line flow). This effectively
deletes the fifo because the vhd wrapper is full of translate_off
statement. XST shouldn't find any fifo vhd files at all (just the ngc
at the ngdbuild stage).
The weirdest thing is that xst finds the path to my fifos although
they are NOT listed in the prj source file and I am not specifying a
path to find cores with the -sd flag.
Here's the relevant part of the log:
Synthesizing Unit <s_fifo_w8_d16>.
Related source file is "D:/Telops/common_hdl/coregen_v4/
s_fifo_w8_d16.vhd".
WARNING:Xst:647 - Input <clk> is never used.
WARNING:Xst:647 - Input <rd_en> is never used.
WARNING:Xst:647 - Input <din> is never used.
WARNING:Xst:1305 - Output <almost_full> is never assigned. Tied to
value 0.
WARNING:Xst:647 - Input <rst> is never used.
WARNING:Xst:1305 - Output <empty> is never assigned. Tied to value 0.
WARNING:Xst:647 - Input <wr_en> is never used.
WARNING:Xst:1305 - Output <almost_empty> is never assigned. Tied to
value 0.
WARNING:Xst:1305 - Output <overflow> is never assigned. Tied to value
0.
WARNING:Xst:1305 - Output <valid> is never assigned. Tied to value 0.
WARNING:Xst:1305 - Output <full> is never assigned. Tied to value 0.
WARNING:Xst:1305 - Output <dout> is never assigned. Tied to value
00000000.
Unit <s_fifo_w8_d16> synthesized.
How can xst find the path to the "Related source file"??? There's some
magic going on that I don't understand.
I might as well include the prj and xst files, sorry for the bloat:
top_level_v4.xst:
set -tmpdir .
set -xsthdpdir d:/Telops/CAMEL/uc2/synthesis/xst
run
-ifn top_level_V4.prj
-ifmt mixed
-ofn top_level_V4
-ofmt NGC
-p xc4vfx12sf363-10
-top top_level_V4
-opt_mode speed
-opt_level 1
-iuc yes
-glob_opt allclocknets
-write_timing_constraints no
-verilog2001 yes
-keep_hierarchy yes
-hierarchy_separator /
-bus_delimiter <>
-case maintain
-cross_clock_analysis no
-slice_utilization_ratio 100
-dsp_utilization_ratio 100
-read_cores no
-fsm_extract yes -fsm_encoding Auto
-vlgcase full-parallel
-resource_sharing yes
-fsm_style lut
-ram_extract yes
-ram_style auto
-rom_extract yes
-rom_style auto
-mux_extract yes
-mux_style auto
-decoder_extract yes
-priority_extract yes
-shreg_extract yes
-shift_extract yes
-xor_collapse yes
-use_dsp48 auto
-iobuf yes
-max_fanout 500
-bufg 32
-bufr 16
-register_duplication yes
-equivalent_register_removal yes
-register_balancing no
-iob auto
-slice_packing yes
-optimize_primitives no
-safe_implementation no
-use_clock_enable yes
-use_sync_set yes
-use_sync_reset yes
-slice_utilization_ratio_maxmargin 5
top_level_v4.prj:
vhdl Common_HDL D:/Telops/Common_HDL/telops.vhd
vhdl work D:/Telops/Common_HDL/Utilities/ram_dist.vhd
vhdl work D:/Telops/Common_HDL/RS232/uarts.vhd
vhdl work D:/Telops/Common_HDL/Utilities/sync_reset.vhd
vhdl work D:/Telops/Common_HDL/Utilities/double_sync.vhd
vhdl work D:/Telops/Common_HDL/Wishbone/uc2_wb_master.vhd
vhdl work D:/Telops/Common_HDL/Wishbone/wb_8i8o.VHD
vhdl work D:/Telops/Common_HDL/Wishbone/ARB0001a.VHD
vhdl work D:/Telops/Common_HDL/Wishbone/MEM0001a.VHD
verilog work D:/Telops/Common_HDL/Wishbone/rs232_syscon/
auto_baud_with_tracking.v
verilog work D:/Telops/Common_HDL/Wishbone/rs232_syscon/serial.v
verilog work D:/Telops/Common_HDL/Wishbone/rs232_syscon/rs232_syscon.v
vhdl work D:/Telops/Common_HDL/Wishbone/wb_intercon_8s.vhd
vhdl work ..\src\defines.vhd
vhdl work ..\compile\top_level_v4.vhd
vhdl work ..\..\common_hdl\ultracontroller-ii/jtagppc_wrapper.vhd
vhdl work ..\compile\simple_dcm_v4.vhd
vhdl work ..\src\rs232/config_decoder.vhd
vhdl work ..\src\rs232/rs232_dispatcher.vhd
vhdl work ..\compile\dpb_rs232_manager_v4.vhd
vhdl work ..\compile\uc2_block_8s.vhd
vhdl work ..\..\common_hdl\ultracontroller-ii/virtex-4/uc2.vhd
vhdl work ..\compile\uc2_block_8s_prom.vhd
vhdl work ..\..\common_hdl\ultracontroller-ii/prom2jtag.vhd
vhdl work ..\..\common_hdl\ultracontroller-ii/prom2uar.vhd
verilog work ..\..\common_hdl\ultracontroller-ii/uar_load.v
vhdl work ..\compile\uc2_block_8s.vhd
Does anyone understand what is going on here? I tried with ISE v8.2.03
and v9.1.03, same problem.
Thanks.
Patrick
Article: 120274Hello, I need some advise... I'm trying to find my way for having an FFT running on a FPGA (along with some other easy stuff) Before switching to the option of writing the FFT VHDL myself,I was exploring what existing codes I could use. The Altera FFT-Megacore is a possibility although may have trouble to pay for it since this is for an hobby application not for a commercial product. On the OpenCore.org I could find a design "Generated by Confluence 0.6.3/Launchbird Design Systems, Inc." that fails on the Quartus II fitter, even so the expected resources to be used are extremely high (6 times the altera megacore for same size/performance), so I do believe the way the code was written/generated is not so good for synthesis and it would become not an interesting option either. Could find also a couple of educational developments but not really what one could use without rewriting parts if interesting to do that at all. (for that I would be tempted to switch to the do it all myself option). I'm a bit stuck... Please, comments are very welcome. Luis C. -- (edit my email addr if you want to email me directly)
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