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
Hi all, using sysgen from Xilinx and inserting an Chipscope block the code generation will stop with a "fatal error" giving me the advice to look for help on the Xilinx support page. But there was no such help. Maybe I can find it here. The project for ISE is generated with some files missing, belonging to the Chipscope core. I have installed all the software properly in version 6.1i (ISE, Chipscope, Sysgen) so I don't know the reason sysgen behaves like that. Any solutions are welcome. But don't tell me to reinstall all, I wont do that - again ... JanArticle: 69251
Hi, I'm implementing routines in C which extensively use 16-bit multiplication. My Nios core is configured to support the MUL instruction which exploits the Stratix DSP-blocks . All my multiplications are resolved by the compiler to call __mulhi3 to use the MUL instruction. But this involves some calling overhead. I want to get rid of this overhead and directly use the MUL in my code without issuing a subroutine call (inlining). Does anybody know how to configure the system to get inlined multiplications? Thank you. JoeArticle: 69252
tushitjain@yahoo.com (tushit) wrote in message news:<ec6aab0.0404262123.545dc255@posting.google.com>... > Hi, > I am using QuartusII 3.0. I setup a tsu requirement on some input pins > and quartus did a P&R and said it could not meet the tsu by 0.5ns on > only one of the paths. So I relaxed my tsu by about 1ns on all pins > and did an incremental fitting. Now Quartus came back and said it > could not meet timing on about 15 paths by 1.5ns. Why is this? Is > there anyway of adding more predictibility in the P&R of Quartus? > Thanks & regards > tushit What was the violation over the 0.5 ns path ? If the violation was less than 0.5 ns and you realy need 1 ns setup then you can ignore the report . Another idea: instead of relaxing the constraints -> press them even further. Ofcourse the report will say that more paths failed the 0.3 ns setup constraint, but you might just find that all path met 0.5 ns setup. Bye, NAHUMArticle: 69253
Florian Student <studenfn@trick.informatik.uni-stuttgart.de> wrote in message news:<c73qvi$aju$1@inf2.informatik.uni-stuttgart.de>... > Hi comp.arch.fpga, > > I know it's a bit off-topic but because I think that some of you might > be able to help me I'll ask anyway. > > I'm planning to connect some ram to a cpld for fast data acquisition. > Probably using sram instead of dram should be easier because no refresh > signal is needed and it might also be faster(?) > > Does anybody of you have a recommendation what device I should use; it > should have >= 1 MBit capacity and not be to expensive. Also, it should > be possible to order very low quantities of it. > > Thank you in advance, > Florian I might suggest pseudo static ie DRAM< packaged as a SRAM with simple IO ans hidden auo refresh. I believe they are used in cell phones that means they should be very cheap & low power, but it might mean you need to order large vol. Anyway some some samples might be available. Can't remember the vendors, try Micron,Infineon,Samsung to start. hope that helps, use google pseudo static dram or something regards johnjakson_usa_comArticle: 69254
Thanks ! ~vinod On 29 Apr 2004 17:00:54 -0700, ramntn@yahoo.com (ram) wrote: >HI >Modelsim XE will not support there is a limitatino on the number of >lines of VHDL code. >you need Modelsim SE /PE >Ram > >vananth@gmail.com (Vinod) wrote in message news:<6cd79f5.0404290531.ffccd75@posting.google.com>... >> Hi, >> I am using EDK 3.2 with ISE 5.1.3 on a WinXp machine, and targeting >> the Virtex 2 pro board. Does Modelsim XE allow me to simulate code >> running on the PowerPC along with other external blocks written in >> VHDL as one whole unit? >> I do not have a board yet, and was also wondering whether such >> simulations would be prohibitively long. >> >> Links to informative websites would be appreciated >> >> Thanks >> VinodArticle: 69255
Hi, I'm using a gigabit ethernet mac generated by coregen. Coregen generates a toplevel example and an .ucf file with some timing constraints, for instance: ############################################################ # PCS/PMA Clock period Constraints: please do not relax # ############################################################ NET brefclk_ibufg TNM_NET = brefclk; TIMESPEC TS_brefclk = PERIOD brefclk 16 ns HIGH 50 %; This brefclk_ibufg signal is coming from a dcm that is in the generated toplevel. Now I have some wrappers around the "coregen toplevel" and assign the .ucf file to my own toplevel. But at that moment the signal brefclk_ibufg is not found anymore: Annotating constraints to design from file "../../Gb_eth/vhdl_source/gb_eth_rtx.ucf" ... ERROR:NgdBuild:756 - Line 19 in '../../Gb_eth/vhdl_source/gb_eth_rtx.ucf': Could not find net(s) 'brefclk_ibufg' in the design. To suppress this error specify the correct net name or remove the constraint. I tried something with paths, without success. Does anyone know how to fix this? Do I have to route the signal to my toplevel file or move the dcm part to my toplevel? TIA, FrankArticle: 69256
Hello: I'm generating a new design using an Altera Cyclone FPGA. But I think this issue may be applicable to all FPGAs. I have 8 identical modules that each have an 11 bit status register. The CPU (in this case a NIOS embedded on the same device) needs to read these status registers. The question is what is the best (size first, speed second) configuration for these inputs? Can I use a tristate type construction and save interconnects to the CPU. Does this really save any routine resources and at what expense. In this design I can live with long delays on reading the status registers. Any input would be appreciated. Thanks GeorgeArticle: 69257
nate <nathan_wilson@tepidmail.com> wrote in message news:<Xns94DB630BB20F7nathanwilson@209.242.86.10>... > I have a bunch of free mach231 chips but I can't find any information about > how to program them. I have gathered from the web that they are not JTAG. > The datasheet does not explain how to program the chip. I am planning on > constructing a programmer but there is not a lot of information about how > to do this. The closest thing I have found is some information and > schematics showing how to build the expro-60. Any ideas or information > would be appreciated. > > Nathan > > change tepid to hot to reach me by e-mail This is a problem with most programmable chips these days. The manufacturers normally supply the programming data to the major programmer manufacturers (Data I/O, BP, etc.) and don't bother to put it in the databook unless the part is in-system programmable. If you can get the information at all, you'll do best to contact Lattice Semiconductor directly. Good Luck GaborArticle: 69258
I was finding the old Micron Synchronous SRAM parts to be priced best around the 4Mbit size - the smaller die aren't so popular anymore. Micron sold their line to Cypress so check them out. There are different flavors of Synchronous SRAM, the least expensive requiring a turnaround of 2 cycles on the data bus from a read to a write. The good news is that these sub-$5 parts are good for up to 200MHz operation in 100-pin TQFPs. The flavors include a single-clock result (flow-through) or a two-clock result for the best performance (pipeline). "Florian Student" <studenfn@trick.informatik.uni-stuttgart.de> wrote in message news:c73qvi$aju$1@inf2.informatik.uni-stuttgart.de... > Hi comp.arch.fpga, > > I know it's a bit off-topic but because I think that some of you might > be able to help me I'll ask anyway. > > I'm planning to connect some ram to a cpld for fast data acquisition. > Probably using sram instead of dram should be easier because no refresh > signal is needed and it might also be faster(?) > > Does anybody of you have a recommendation what device I should use; it > should have >= 1 MBit capacity and not be to expensive. Also, it should > be possible to order very low quantities of it. > > Thank you in advance, > Florian > > > > > >Article: 69259
Most DLL use a chain of buffers to stretch over a whole period. That limits the lower frequency end to something like 20 MHz (which might need a thousand stages of 50 ps each). In a CPLD, this is out of the question. Your best bet is an external PLL, or "knit your own" using an external VCO and do the 7-bit counting and the phase detector inside the CPLD. Here is a weird idea: If your 6 MHz need not be a continuously running signal, but only the right number of pulses averaged over time, you could build an RC oscillator of, say, 10 MHz and turn it off after 128 pulses, on again at the beginning of the next 48 kHz signal. That could be done with 8 macrocells, 3 pins, and 2 resistors and one capacitor.... Just thinking out-of-the-box... Peter Alfke > From: "Jim" <Jim@eab.nl> > Organization: Posted via Supernews, http://www.supernews.com > Newsgroups: comp.arch.fpga > Date: Sun, 2 May 2004 15:24:09 +0200 > Subject: frequency multiplication > > Hi, for a re-desing i'd like to omit a 'standard' pll with counters etc. > used for > frequency multiplication, by a cpld. > Among other things, the cpld has to perform a 128x frequency multipliction > 48KHz to 6144Khz). > Some (many) cpld's have on-board pll's but these are not usefull because > they are inteded > for clock distribution and the lowest operating frequency is much lower than > 48KHz. > > Therefor i'd like to implement a 'dpll' in a cpld, that can multiply 48KHz > to 6144KHz, or > is there perhaps another way? > > Are there any free vhdl sources for this pll? > > Best, > Jim > > > >Article: 69260
Hi Frank, You need to find the name of the net after your synthesis process. So, run Translate, and open the Floorplanner that's listed alongside in the process window of navigator. Look for your DCM, and find the net name you want. Then edit you UCF file to match. I'm guessing that:- NET "*brefclk_ibufg" TNM_NET = brefclk; would work! Cheers, Syms.Article: 69261
Check your PATH environment. XILINX_EDK must before XILINX Matthew Ouellette wrote: > Vinod, > > EDK 3.2 is compatible with 5.2 SP1 and greater only. Check the Getting > Started Guide for more information. > > Matt > > Vinod wrote: > >> Hi, >> I am having problems starting up the Xilinx Platform Studio. I have >> installed EDK 3.2 with service pack 2. When I run it, I get a message >> saying >> >> "The procedure entry point >> ?GetProjectToolBarID@Dco_PlToolBarManager@@SAIXZ could not be located >> in the dynamic link library libDco_Plugin.dll" >> >> Im running Windows XP professional with SP1. Also have Xilinx ISE >> 5.1.3i installed. My env variables seem to be pointing to the correct >> location. I've tried reinstalling, but of no avail. >> >> Any help will be appreciated. >> >> Vinod -- / 7\'7 Paulo Dutra (paulo.dutra@xilinx.com) \ \ ` Xilinx hotline@xilinx.com / / 2100 Logic Drive http://www.xilinx.com \_\/.\ San Jose, California 95124-3450 USAArticle: 69262
George, AFAIK the LE's on the Cyclone (and other FPGA's I've used) don't have a tristateable output - this is only available in the IOB's. So when creating memory mapped registers I used a single write bus with address decodes generating clock enables for the latches, and multiple read buses (one per input register) going to a big MUX controlled by the address lines. The ability to create apparent tri-states inside the design is an artifice, the sythesis will have to turn this into something similar to the above. I think in answer to your question, you can use a tristate configuration to describe your design intent concisely, but the synthesis will convert this into a purley combinational function. Hope a) I'm right and b) this helps. Gary "George" <george.martin@att.net> wrote in message news:e9d879fa.0405030651.523d875c@posting.google.com... > Hello: > > I'm generating a new design using an Altera Cyclone FPGA. But I think > this issue may be applicable to all FPGAs. I have 8 identical modules > that each have an 11 bit status register. The CPU (in this case a > NIOS embedded on the same device) needs to read these status > registers. > > The question is what is the best (size first, speed second) > configuration for these inputs? Can I use a tristate type > construction and save interconnects to the CPU. Does this really save > any routine resources and at what expense. In this design I can live > with long delays on reading the status registers. > > Any input would be appreciated. > > Thanks > GeorgeArticle: 69263
george.martin@att.net (George) wrote in message news:<e9d879fa.0405030651.523d875c@posting.google.com>... > Hello: > > I'm generating a new design using an Altera Cyclone FPGA. But I think > this issue may be applicable to all FPGAs. I have 8 identical modules > that each have an 11 bit status register. The CPU (in this case a > NIOS embedded on the same device) needs to read these status > registers. > > The question is what is the best (size first, speed second) > configuration for these inputs? Can I use a tristate type > construction and save interconnects to the CPU. Does this really save > any routine resources and at what expense. In this design I can live > with long delays on reading the status registers. Um, a mux? -aArticle: 69264
Hi Vaughn, Subroto Thanks for all your help. I am abandoning trying to meet the setup time since the project is a prototyping of an ASIC design on FPGA and will not go to a customer. As long as the PCI works on some PC with reasonable reliability we will be happy and the design does seem to work okay even with the 7ns slack on the setup time. I think this may be because the PCI slot of my PC supports 66Mhz PCI in the same slot and so the motherboard and PCI chip on it may have lower tco and propagation delay than the PCI spec. requires, giving me extra margin for the tsu. Thank you once again. Regards Tushit > Hi Tushit, > > I don't think you'll have much luck with manual placement and routing, > or emptying the device of other logic. The problem is simply too many > logic levels on the Tsu critical path. > > Maximum fanout constraints aren't going to be much help here either, > since in the PCI cores I've seen the high-fanout signals are trdy and > irdy, and since those are sourced by IOs you can't duplicate them. > > You'll have to redesign the Tsu-critical logic, or guide the > technology mapper to a better solution for Tsu by adding lcell buffers > to your HDL. > > Regards, > > Vaughn > AlteraArticle: 69265
Jan, I have not used sysgen but on occasion I have had problems with chipscope in regular ISE 6.1. These problems usually stem from selecting an ineligible signal to be sampled or as the trigger or as the clock. You could eliminate this theory by minimzing your chipscope selections and only selecting signals you are sure are valid. Good luck Matt On Mon, 3 May 2004, Jan Losansky wrote: > Hi all, > > using sysgen from Xilinx and inserting an Chipscope block the code > generation will stop with a "fatal error" giving me the advice to look for > help on the Xilinx support page. But there was no such help. Maybe I can > find it here. The project for ISE is generated with some files missing, > belonging to the Chipscope core. I have installed all the software properly > in version 6.1i (ISE, Chipscope, Sysgen) so I don't know the reason sysgen > behaves like that. Any solutions are welcome. But don't tell me to reinstall > all, I wont do that - again ... > > Jan > > >Article: 69266
George wrote: > I have 8 identical modules > that each have an 11 bit status register. The CPU (in this case a > NIOS embedded on the same device) needs to read these status > registers. > > The question is what is the best (size first, speed second) > configuration for these inputs? I don't know anything about nios, but I expect it doesn't have 88 IO's, so consider doing nios read cycles for your registers at its standard width. Maybe drive 11 of the 16? bits for each address. > Can I use a tristate type > construction and save interconnects to the CPU. Whatever the nios data bus is, you will have to match. Consider avoiding on-chip tristates descriptions if you can. A big mux is much less trouble and probably what the hardware really does, in any case. -- Mike TreselerArticle: 69267
"Peter Alfke" <peter@xilinx.com> wrote in message news:BCBBB6BB.611D%peter@xilinx.com... > Here is a weird idea: > If your 6 MHz need not be a continuously running signal, but only the right > number of pulses averaged over time, you could build an RC oscillator of, > say, 10 MHz and turn it off after 128 pulses, on again at the beginning of > the next 48 kHz signal. That could be done with 8 macrocells, 3 pins, and 2 > resistors and one capacitor.... > Just thinking out-of-the-box... I am guessing from the numbers given by the original poster that this is for digital audio, probably an external clock being multiplied to drive an oversampling ADC clock input or something of this sort. If this is the case not only it has to be continuous, but it has to be low jitter too. /Mikhail -- To reply directly: matusov at square peg ca (join the domain name in one word and add a dot before "ca")Article: 69268
Even if it is for audio, the 6 MHz might be just for data storage, and so be independent of the audio rate. Peter Alfke > From: "MM" <mbmsv@yahoo.com> > Newsgroups: comp.arch.fpga > Date: Mon, 3 May 2004 15:24:12 -0400 > Subject: Re: frequency multiplication > > "Peter Alfke" <peter@xilinx.com> wrote in message > news:BCBBB6BB.611D%peter@xilinx.com... >> Here is a weird idea: >> If your 6 MHz need not be a continuously running signal, but only the > right >> number of pulses averaged over time, you could build an RC oscillator of, >> say, 10 MHz and turn it off after 128 pulses, on again at the beginning of >> the next 48 kHz signal. That could be done with 8 macrocells, 3 pins, and > 2 >> resistors and one capacitor.... >> Just thinking out-of-the-box... > > I am guessing from the numbers given by the original poster that this is for > digital audio, probably an external clock being multiplied to drive an > oversampling ADC clock input or something of this sort. If this is the case > not only it has to be continuous, but it has to be low jitter too. > > > /Mikhail > > -- > To reply directly: > matusov at square peg ca > (join the domain name in one word and add a dot before "ca") > > > >Article: 69269
"David Brown" <david@no.westcontrol.spam.com> wrote in message news:<c74svr$fv3$1@news.netpower.no>... > > > > Been there, redone that. It was power-ramp dependant, temperature > dependant, > > look-at-dependant and debug-unfriendly. > > > > Ah well, it looks like the answer to my question is "no" - at least if I > want the card to work reliably! > > Thanks to those that replied. > > David David, We have had some customers try the crystal-to-the-FPGA approach over time, and it's generally not successful for the reasons the other posters have listed. To answer your other question: >>is it possible to use a low frequency crystal as a reference for the Cyclone PLLs, or do they require a high minimum frequency? The minimum input frequency for the Cyclone PLL is 15.625 MHz. Sincerely, Greg Steinke gregs@altera.com Altera CorporationArticle: 69270
george.martin@att.net (George) wrote in message news:<e9d879fa.0405030651.523d875c@posting.google.com>... > Hello: > > I'm generating a new design using an Altera Cyclone FPGA. But I think > this issue may be applicable to all FPGAs. I have 8 identical modules > that each have an 11 bit status register. The CPU (in this case a > NIOS embedded on the same device) needs to read these status > registers. > > The question is what is the best (size first, speed second) > configuration for these inputs? Can I use a tristate type > construction and save interconnects to the CPU. Does this really save > any routine resources and at what expense. In this design I can live > with long delays on reading the status registers. > If you can live with very long delays, consider one long shift register or eight 11-bit shift registers with an 8:1 mux. Status can be loaded into the shift registers in parallel and then shifted into the CPU. This is a little like JTAG boundary scan logic. It reduces global interconnect, but probably uses as much resources (though different kind, flip-flops vs. LUT's or TriState buffers) as the brute force parallel method. > Any input would be appreciated. > > Thanks > GeorgeArticle: 69271
Driving a crystal from an PLD device. Since this question pops up again and again, maybe it deserves a better explanation. A crystal is usually connected as a Colpitts oscillator, where the IC provides the first 180 degree phase shift, and the xtal plus external RC combine for the remaining 180 degrees. The total circuit loop must have 360 degree phase shift and a gain of exactly 1.0. That is the condition for stable oscillation. XC3000 had such a single-stage amplifier, and could implement an oscillator with just a crystal, two capacitors and two resistors. But there were lots of problems when users connected obscure crystals, ranging from 32 kHz to 100 MHz. Most digital designers lack even the most rudimentary understanding of oscillators, why they require a single amplifier stage, and why they cannot reliably be implemented with the multi-stage amplifier typically between an input and an output of a modern CMOS IC. So, please, don't even try. You will not be able to design a reliable xtal oscillator this way, one that starts and runs reliably, and does not break out in wild harmonic or non-harmonic oscillations. Finally: Packaged oscillators are cheap, just pennies more than the simple xtal. It does not make sense to jeopardize your design for the $ 0.25 saved by using a naked crystal. Let the oscillator manufacturers sweat out all those analog details, they are good at it. Us digital folks are not. Peter Alfke > From: gregs@altera.com (Greg Steinke) > Organization: http://groups.google.com > Newsgroups: comp.arch.fpga > Date: 3 May 2004 13:59:03 -0700 > Subject: Re: Connecting a crystal to a Cyclone or Max PLD > > "David Brown" <david@no.westcontrol.spam.com> wrote in message > news:<c74svr$fv3$1@news.netpower.no>... >>> >>> Been there, redone that. It was power-ramp dependant, temperature >> dependant, >>> look-at-dependant and debug-unfriendly. >>> >> >> Ah well, it looks like the answer to my question is "no" - at least if I >> want the card to work reliably! >> >> Thanks to those that replied. >> >> David > > David, > We have had some customers try the crystal-to-the-FPGA approach over > time, and it's generally not successful for the reasons the other > posters have listed. > > To answer your other question: >>> is it possible to use a low frequency crystal as a reference for the > Cyclone PLLs, or do they require a high minimum frequency? > > The minimum input frequency for the Cyclone PLL is 15.625 MHz. > > Sincerely, > Greg Steinke > gregs@altera.com > Altera CorporationArticle: 69272
i used core generator to generate the RAMs, and they have 64-depth 64-bit RAMs, so I have no much control over how XST implements it in the synthesis. Actually in Floor Planner I can see some BRAM and MULT18X18 side by side... I have replaced 16 multipliers with LUTs implementions from Core generator... And it is working now but I am concerned with the slice usage... Kelvin "Ken Morrow" <junk@not_morro.co.uk> wrote in message news:vzrkc.36293$h44.5385972@stones.force9.net... > Kelvin, > > You will probably find that some of the multiplier sites are blocked from > being used due to > some block RAMs having widths of > 18 bits. If so, try to change some of the > RAMs to > have smaller widths. > > I have a design which now uses all 144 of the V2-6000 multipliers, and most > of the RAMs > without prob. I had to reduce the width of all of the RAMs to 18 bits or > less for the multipliers > to be available for use. > > (I was impressed that Mentor Precision automatically used multipliers built > with LUTs, once it had > used up all the available multipiers). > > Good Luck, > > Ken, > Morrow Electronics Limited, UK > Currently specialising in FPGA design for 3G. > www.morro.co.uk > > > "Kelvin @ SG" <kelvin8157@hotmail.com> wrote in message > news:4091f4e6@news.starhub.net.sg... > > Hi, there: > > > > I am implementing a partial chip for virtex-2-6000. My module has 116 > > multipliers, the module is allocated an area group with 120 multipliers. > > Later I got 9 multipliers not placed, while the PAR > > informs there are 13 available sites for placing them...However, the > > placement failed... > > > > How may I handle such a situation? > > Replace some smaller * with rtl implementation? How many slices can I > > implement an 8X8 muldipler? > > Repartitioning to put some * signs in somebody else's modules? > Possible > > but troublesome... > > > > Best Regards, > > Kelvin > > > > > > > > > > > > > > Phase 6.9 > > WARNING:Place:119 - Unable to find location. MULT component > > > > > i_ofdm_rx/i_wrx_top/i_channel_top/i_channel_wk_calc/Mmult_wkq_calc_mul_inst_ > > m > > ult_11 not placed. > > MULT18X18 > > > "i_ofdm_rx/i_wrx_top/i_channel_top/i_channel_wk_calc/Mmult_wkq_calc_mul_inst > > _mul > > t_11". > > COMPGRP "RX.MULT18X18" LOCATE = SITE > "MULT18X18_X1Y23:MULT18X18_X5Y0" > > LEVEL 4 ; > > Only the one associated with MULT18X18 > > > i_ofdm_rx/i_wrx_top/i_channel_top/i_channel_wk_calc/Mmult_wkq_calc_mul_inst_ > > mult > > _11 will be looked at. > > The AREA group contains 120 possible sites for this component. 13 of > these > > sites were available to place this component into. > > =============================================================== > > List of 13 available sites in area are: > > Site MULT18X18_X1Y3 > > Site MULT18X18_X1Y5 > > Site MULT18X18_X1Y12 > > Site MULT18X18_X1Y15 > > Site MULT18X18_X1Y19 > > Site MULT18X18_X2Y4 > > Site MULT18X18_X2Y6 > > Site MULT18X18_X2Y8 > > Site MULT18X18_X2Y12 > > Site MULT18X18_X2Y16 > > Site MULT18X18_X2Y19 > > Site MULT18X18_X2Y20 > > Site MULT18X18_X2Y22 > > =============================================================== > > List of comps in area without same LOC are: > > =============================================================== > > WARNING:Place:119 - Unable to find location. MULT component > > > > > i_ofdm_rx/i_wrx_top/i_channel_top/i_channel_calc/Mmult_data_q0_b_mul_inst_mu > > l > > t_2 not placed. > > MULT18X18 > > > "i_ofdm_rx/i_wrx_top/i_channel_top/i_channel_calc/Mmult_data_q0_b_mul_inst_m > > ult_ > > 2". > > COMPGRP "RX.MULT18X18" LOCATE = SITE > "MULT18X18_X1Y23:MULT18X18_X5Y0" > > LEVEL 4 ; > > Only the one associated with MULT18X18 > > > i_ofdm_rx/i_wrx_top/i_channel_top/i_channel_calc/Mmult_data_q0_b_mul_inst_mu > > lt_2 > > will be looked at. > > The AREA group contains 120 possible sites for this component. 13 of > these > > sites were available to place this component into. > > =============================================================== > > List of 13 available sites in area are: > > Site MULT18X18_X1Y3 > > Site MULT18X18_X1Y5 > > Site MULT18X18_X1Y12 > > Site MULT18X18_X1Y15 > > Site MULT18X18_X1Y19 > > Site MULT18X18_X2Y4 > > Site MULT18X18_X2Y6 > > Site MULT18X18_X2Y8 > > Site MULT18X18_X2Y12 > > Site MULT18X18_X2Y16 > > Site MULT18X18_X2Y19 > > Site MULT18X18_X2Y20 > > Site MULT18X18_X2Y22 > > =============================================================== > > List of comps in area without same LOC are: > > =============================================================== > > WARNING:Place:119 - Unable to find location. MULT component > > > > > i_ofdm_rx/i_wrx_top/i_multipath_top/i_multipath_wk_calc/Mmult__n0009_inst_mu > > l > > t_3 not placed. > > MULT18X18 > > > "i_ofdm_rx/i_wrx_top/i_multipath_top/i_multipath_wk_calc/Mmult__n0009_inst_m > > ult_ > > 3". > > COMPGRP "RX.MULT18X18" LOCATE = SITE > "MULT18X18_X1Y23:MULT18X18_X5Y0" > > LEVEL 4 ; > > Only the one associated with MULT18X18 > > > i_ofdm_rx/i_wrx_top/i_multipath_top/i_multipath_wk_calc/Mmult__n0009_inst_mu > > lt_3 > > will be looked at. > > The AREA group contains 120 possible sites for this component. 13 of > these > > sites were available to place this component into. > > =============================================================== > > List of 13 available sites in area are: > > Site MULT18X18_X1Y3 > > Site MULT18X18_X1Y5 > > Site MULT18X18_X1Y12 > > Site MULT18X18_X1Y15 > > Site MULT18X18_X1Y19 > > Site MULT18X18_X2Y4 > > Site MULT18X18_X2Y6 > > Site MULT18X18_X2Y8 > > Site MULT18X18_X2Y12 > > Site MULT18X18_X2Y16 > > Site MULT18X18_X2Y19 > > Site MULT18X18_X2Y20 > > Site MULT18X18_X2Y22 > > =============================================================== > > List of comps in area without same LOC are: > > =============================================================== > > WARNING:Place:119 - Unable to find location. MULT component > > > > > i_ofdm_rx/i_wrx_top/i_channel_top/i_channel_wk_calc/Mmult_dataii_mul_inst_mu > > l > > t_1 not placed. > > MULT18X18 > > > "i_ofdm_rx/i_wrx_top/i_channel_top/i_channel_wk_calc/Mmult_dataii_mul_inst_m > > ult_ > > 1". > > COMPGRP "RX.MULT18X18" LOCATE = SITE > "MULT18X18_X1Y23:MULT18X18_X5Y0" > > LEVEL 4 ; > > Only the one associated with MULT18X18 > > > i_ofdm_rx/i_wrx_top/i_channel_top/i_channel_wk_calc/Mmult_dataii_mul_inst_mu > > lt_1 > > will be looked at. > > The AREA group contains 120 possible sites for this component. 13 of > these > > sites were available to place this component into. > > =============================================================== > > List of 13 available sites in area are: > > Site MULT18X18_X1Y3 > > Site MULT18X18_X1Y5 > > Site MULT18X18_X1Y12 > > Site MULT18X18_X1Y15 > > Site MULT18X18_X1Y19 > > Site MULT18X18_X2Y4 > > Site MULT18X18_X2Y6 > > Site MULT18X18_X2Y8 > > Site MULT18X18_X2Y12 > > Site MULT18X18_X2Y16 > > Site MULT18X18_X2Y19 > > Site MULT18X18_X2Y20 > > Site MULT18X18_X2Y22 > > =============================================================== > > List of comps in area without same LOC are: > > =============================================================== > > WARNING:Place:119 - Unable to find location. MULT component > > > > > i_ofdm_rx/i_wrx_top/i_channel_top/i_channel_calc/Mmult_data_i0_a_mul_inst_mu > > l > > t_2 not placed. > > MULT18X18 > > > "i_ofdm_rx/i_wrx_top/i_channel_top/i_channel_calc/Mmult_data_i0_a_mul_inst_m > > ult_ > > 2". > > COMPGRP "RX.MULT18X18" LOCATE = SITE > "MULT18X18_X1Y23:MULT18X18_X5Y0" > > LEVEL 4 ; > > Only the one associated with MULT18X18 > > > i_ofdm_rx/i_wrx_top/i_channel_top/i_channel_calc/Mmult_data_i0_a_mul_inst_mu > > lt_2 > > will be looked at. > > The AREA group contains 120 possible sites for this component. 13 of > these > > sites were available to place this component into. > > =============================================================== > > List of 13 available sites in area are: > > Site MULT18X18_X1Y3 > > Site MULT18X18_X1Y5 > > Site MULT18X18_X1Y12 > > Site MULT18X18_X1Y15 > > Site MULT18X18_X1Y19 > > Site MULT18X18_X2Y4 > > Site MULT18X18_X2Y6 > > Site MULT18X18_X2Y8 > > Site MULT18X18_X2Y12 > > Site MULT18X18_X2Y16 > > Site MULT18X18_X2Y19 > > Site MULT18X18_X2Y20 > > Site MULT18X18_X2Y22 > > =============================================================== > > List of comps in area without same LOC are: > > =============================================================== > > WARNING:Place:119 - Unable to find location. MULT component > > > > > i_ofdm_rx/i_wrx_top/i_multipath_top/i_multipath_wk_calc/Mmult__n0010_inst_mu > > l > > t_3 not placed. > > MULT18X18 > > > "i_ofdm_rx/i_wrx_top/i_multipath_top/i_multipath_wk_calc/Mmult__n0010_inst_m > > ult_ > > 3". > > COMPGRP "RX.MULT18X18" LOCATE = SITE > "MULT18X18_X1Y23:MULT18X18_X5Y0" > > LEVEL 4 ; > > Only the one associated with MULT18X18 > > > i_ofdm_rx/i_wrx_top/i_multipath_top/i_multipath_wk_calc/Mmult__n0010_inst_mu > > lt_3 > > will be looked at. > > The AREA group contains 120 possible sites for this component. 13 of > these > > sites were available to place this component into. > > =============================================================== > > List of 13 available sites in area are: > > Site MULT18X18_X1Y3 > > Site MULT18X18_X1Y5 > > Site MULT18X18_X1Y12 > > Site MULT18X18_X1Y15 > > Site MULT18X18_X1Y19 > > Site MULT18X18_X2Y4 > > Site MULT18X18_X2Y6 > > Site MULT18X18_X2Y8 > > Site MULT18X18_X2Y12 > > Site MULT18X18_X2Y16 > > Site MULT18X18_X2Y19 > > Site MULT18X18_X2Y20 > > Site MULT18X18_X2Y22 > > =============================================================== > > List of comps in area without same LOC are: > > =============================================================== > > WARNING:Place:119 - Unable to find location. MULT component > > > > > i_ofdm_rx/i_wrx_top/i_channel_top/i_channel_wk_calc/Mmult_dataqq_mul_inst_mu > > l > > t_1 not placed. > > MULT18X18 > > > "i_ofdm_rx/i_wrx_top/i_channel_top/i_channel_wk_calc/Mmult_dataqq_mul_inst_m > > ult_ > > 1". > > COMPGRP "RX.MULT18X18" LOCATE = SITE > "MULT18X18_X1Y23:MULT18X18_X5Y0" > > LEVEL 4 ; > > Only the one associated with MULT18X18 > > > i_ofdm_rx/i_wrx_top/i_channel_top/i_channel_wk_calc/Mmult_dataqq_mul_inst_mu > > lt_1 > > will be looked at. > > The AREA group contains 120 possible sites for this component. 13 of > these > > sites were available to place this component into. > > =============================================================== > > List of 13 available sites in area are: > > Site MULT18X18_X1Y3 > > Site MULT18X18_X1Y5 > > Site MULT18X18_X1Y12 > > Site MULT18X18_X1Y15 > > Site MULT18X18_X1Y19 > > Site MULT18X18_X2Y4 > > Site MULT18X18_X2Y6 > > Site MULT18X18_X2Y8 > > Site MULT18X18_X2Y12 > > Site MULT18X18_X2Y16 > > Site MULT18X18_X2Y19 > > Site MULT18X18_X2Y20 > > Site MULT18X18_X2Y22 > > =============================================================== > > List of comps in area without same LOC are: > > =============================================================== > > WARNING:Place:119 - Unable to find location. MULT component > > > > > i_ofdm_rx/i_wrx_top/i_channel_top/i_channel_wk_calc/Mmult_wki_calc_mul_inst_ > > m > > ult_11 not placed. > > MULT18X18 > > > "i_ofdm_rx/i_wrx_top/i_channel_top/i_channel_wk_calc/Mmult_wki_calc_mul_inst > > _mul > > t_11". > > COMPGRP "RX.MULT18X18" LOCATE = SITE > "MULT18X18_X1Y23:MULT18X18_X5Y0" > > LEVEL 4 ; > > Only the one associated with MULT18X18 > > > i_ofdm_rx/i_wrx_top/i_channel_top/i_channel_wk_calc/Mmult_wki_calc_mul_inst_ > > mult > > _11 will be looked at. > > The AREA group contains 120 possible sites for this component. 13 of > these > > sites were available to place this component into. > > =============================================================== > > List of 13 available sites in area are: > > Site MULT18X18_X1Y3 > > Site MULT18X18_X1Y5 > > Site MULT18X18_X1Y12 > > Site MULT18X18_X1Y15 > > Site MULT18X18_X1Y19 > > Site MULT18X18_X2Y4 > > Site MULT18X18_X2Y6 > > Site MULT18X18_X2Y8 > > Site MULT18X18_X2Y12 > > Site MULT18X18_X2Y16 > > Site MULT18X18_X2Y19 > > Site MULT18X18_X2Y20 > > Site MULT18X18_X2Y22 > > =============================================================== > > List of comps in area without same LOC are: > > =============================================================== > > WARNING:Place:119 - Unable to find location. MULT component > > > > > i_ofdm_rx/i_wrx_top/i_channel_top/i_channel_calc/Mmult_data_i0_b_mul_inst_mu > > l > > t_2 not placed. > > MULT18X18 > > > "i_ofdm_rx/i_wrx_top/i_channel_top/i_channel_calc/Mmult_data_i0_b_mul_inst_m > > ult_ > > 2". > > COMPGRP "RX.MULT18X18" LOCATE = SITE > "MULT18X18_X1Y23:MULT18X18_X5Y0" > > LEVEL 4 ; > > Only the one associated with MULT18X18 > > > i_ofdm_rx/i_wrx_top/i_channel_top/i_channel_calc/Mmult_data_i0_b_mul_inst_mu > > lt_2 > > will be looked at. > > The AREA group contains 120 possible sites for this component. 13 of > these > > sites were available to place this component into. > > =============================================================== > > List of 13 available sites in area are: > > Site MULT18X18_X1Y3 > > Site MULT18X18_X1Y5 > > Site MULT18X18_X1Y12 > > Site MULT18X18_X1Y15 > > Site MULT18X18_X1Y19 > > Site MULT18X18_X2Y4 > > Site MULT18X18_X2Y6 > > Site MULT18X18_X2Y8 > > Site MULT18X18_X2Y12 > > Site MULT18X18_X2Y16 > > Site MULT18X18_X2Y19 > > Site MULT18X18_X2Y20 > > Site MULT18X18_X2Y22 > > =============================================================== > > List of comps in area without same LOC are: > > =============================================================== > > ERROR:Place:120 - There were not enough sites to place all selected > > components > > Phase 6.9 (Checksum:39386fa) REAL time: 27 mins 46 secs > > > > Total REAL time to Placer completion: 27 mins 47 secs > > > > > > > >Article: 69273
Symon, thanks for the tip. I can not run the floorplanner, because the translate process is generating the error, but your suggestion about the name did work. Frank "Symon" <symon_brewer@hotmail.com> wrote in message news:c75rjp$1fhv$1@ID-212844.news.uni-berlin.de... > Hi Frank, > You need to find the name of the net after your synthesis process. So, run > Translate, and open the Floorplanner that's listed alongside in the process > window of navigator. Look for your DCM, and find the net name you want. Then > edit you UCF file to match. I'm guessing that:- > NET "*brefclk_ibufg" TNM_NET = brefclk; > would work! > Cheers, Syms. > > > >Article: 69274
Matt, thank you for your answer. But I even tried it on a simple design with two inputs an XOR an one output trigerring on one input and measuring it. Still the same behavior. I have checked an example provided by Xilinx too with no change. I probably have to call someone at Xilinx. Jan "Matthew E Rosenthal" <mer2@andrew.cmu.edu> schrieb im Newsbeitrag news:Pine.LNX.4.58-035.0405031434030.19831@unix49.andrew.cmu.edu... > Jan, > I have not used sysgen but on occasion I have had problems with chipscope > in regular ISE 6.1. These problems usually stem from selecting an > ineligible signal to be sampled or as the trigger or as the clock. You > could eliminate this theory by minimzing your chipscope selections and > only selecting signals you are sure are valid. > > Good luck > > Matt
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