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
"John Williams" <jwilliams@itee.uq.edu.au> wrote in message news:newscache$tgdt9i$ao4$1@lbox.itee.uq.edu.au... > Hi > > R!SC wrote: > > > i have buy a development board spartan-3 fga based. > > http://www.silica.com/en/products/evaluationkits/SP3%20Development%20kit.html > > > > i heve read from a little time the LEON2 CORE. I have a question: > > > > Which thing you me councils for this board? uclinux on microblaze or LEON2 > > on uclinux? > > You will achieve a much higher max clock freq with microblaze than > LEON2, because Microblaze is specifically tuned for the Xilinx parts > (and other reasons). > > Regards, > > John I'm finding out that fmax not a useful indicator of performance. The bottom line is how fast can the core execute your algorithm. Sure you might get a 100MHz vs. 50MHz fmax, but if reads take 12 clocks for the 200Mz core vs. 3 for the 50 MHz core then which would you rather have? fmax is for shiny brochures IMO. KenArticle: 77376
Hello all I have a perfectly reasonnable design with bidir pins, written in the purest VHDL style: lberr_b <= lberr_b_out when lberr_b_oen = '1' else 'Z'; (as an example, I have a handfull of such outputs) (note that lberr_b_out and lberr_b_oen are both registered and are not used anywhere else in the design) I turned the "Fast Output Register" option on for these outputs and Quartus tells me :"Warning: Can't pack non-peripheral register local_if:local_if_inst_1|lberr_out to bidir I/O pin lberr_b -- output register and TRI or OPNDRN primitives cannot both fan-out" What's wrong there? Is it a feature the Flex10K is missing? -- ____ _ __ ___ | _ \_)/ _|/ _ \ Adresse de retour invalide: retirez le - | | | | | (_| |_| | Invalid return address: remove the - |_| |_|_|\__|\___/Article: 77377
Dear All, I hope that you can help. I am looking at trying to fit a number of IP cores into a single Xilinx FPGA, I have heard that it is not possible to completly utilise all the FPGA resources (RAM, Logic Cells, DCMs etc ... ) because of routing problems. Do anyone know of a rough percentage of the the FPGA resources that can be expected to be utilised before issues arise in trying to route the design? I have head that it is as low as 60% but am hoping that this is not the case. I understand that it really does depend on what you put into the FPGA but to only be able to utilise 60% on average seams a little poor to me. Kind Regards SimonArticle: 77378
Hi Austin, Just goes to show those lead frame packages are history! One small point, in the excerpt below you say that LVDS pairs have trouble if they're "not perfectly differential (they have coupling to ground)". Assuming the Xilinx LVDS outputs are truly differential, my opinion is that as long as each one of the pair is identically coupled to ground, or indeed to any other plane, there shouldn't be a problem. In other words, the coupling to ground shouldn't, per se, cause a di/dt power supply event when the output switches. Of course, if the pair isn't perfectly symmetrical (perhaps due to the lead frame?) there will be a net power supply current change when the output switches. In fact, where you say "NOT two separate 50 ohm signal leads", I disagree. Each pin of the pair should be able to drive separate independent 50 Ohm lines with no di/dt problems, provided these 50 Ohm lines are identical in characteristics. (You could AC couple the lines to overcome any DC termination non-linearity issues.) How could the LVDS output 'know' it wasn't driving a 100 Ohms differential pair rather than two separate 50 Ohm ones? Best, Syms. "Austin Lesea" <austin@xilinx.com> wrote in message news:41DC10B6.1010301@xilinx.com... > Brian, > > A few hopefully useful comments below, > > Austin > > Brian Davis wrote: >> LVDS SSO weirdness: >> >> The strangely low SSO limitations on those spiffy current-mode >> LVDS output drivers are still there for all Spartan-3 packages, >> including the BGA parts. >> >> Answer Record 19972 used to say: >> >> "Because the Spartan-3 LVDS driver is very balanced, its switching >> causes a negligible amount of transient current. As a result, SSOs >> are not a problem." > > This is only true if the driver is driving a true differential load (NOT > two separate 50 ohm signal leads!!!). As most differential trace runs are > not perfectly balanced, and not perfectly differential (they have coupling > to ground), we also have to start assuming standard pcb trace routes are > used....Article: 77379
Hei,
using the Quartus SignalTap Node finder i encountered the following
problem. When i use a graphical designfile (*.bdf) and i name the
instance of a register, i.e. reg_A, then i can search for this name in
the SignalTab nodefinder. When i do the same with a VHDL file and i name
the register, i.e. REG_A : process(clk), then the nodefinder doesn't
find the name. Instead i see something like i~0 since the name was not
preserved during synthesis. So i tried to preserve the name by using the
"keep" attribute for the registered signal as it is described in an
older thread. But this generates an additional logic cell and changes my
design.
Is there any way to keep the name of an instance/register in a vhdl file
without generating additional logic cells?
Cheers,
Torsten
Article: 77380I use in my project a pci target ( it a free core from Lattice). I must to control some devices (a few motors and other things...) and I choise to do this through pci. One of the signals that control the motor are start/stop, run/brake, dir,..... I must to send command for this motor through pci. After pci target module I interfaced a ram block where in location0 I mapped this signals. In location1 I mapped others signals for another device... For controlling the motor I write in this ram some words at location0. I choise to use a ram because I have more devices. I made ram block dual port whith synchron write on port1 and asynchron read on port2( on port1 I write command and on port2 I read signal controls). It is this best solution???? Have you another solution for me? Please help me.. Thanks,Article: 77381
It's possible to make NIOS board with EPCS16? (EPCS1&EPCS4 yes). I can't make custom target board design for programming EPCS16 by Flash Programmer. I want to put in EPCS16 programm code and configuration image, I've made it, but when I was programing EPCS16, I got an error ID is incorrect. Maybe someone known what I should do. Thx.Article: 77382
Aurelian Lazarut wrote: > Ewan, > > it seems that you are forcing (in batch mode) to run to LPT0 and the > cable is attached to LPT1 > > // *** BATCH CMD : setCable -port LPT0 > > Aurash I wondered about that... When I select LPT1 as the device to use, the output says LPT0. I tried selecting LPT2 and LPT3 and the output showed LPT1, LPT2 respectively. None of them worked, I assumed it was just an off-by-1 error in the software or something. I'm not sure how to change this in any event, the batch stuff was just something the iMPACT software did by itself. The output did say "Connecting to cable (Parallel Port - LPT1).", the reference to the wrong LPT number was after the error messages. Thanks very much for replying. I appreciate it. Ewan D. Milne Egenera, Inc. milne@egenera.comArticle: 77383
Symon, Well, this needs some explaining. Maybe we are in agreement? See below, Austin Symon wrote: > Hi Austin, > Just goes to show those lead frame packages are history! > One small point, in the excerpt below you say that LVDS pairs have trouble > if they're "not perfectly differential (they have coupling to ground)". > Assuming the Xilinx LVDS outputs are truly differential, my opinion is that > as long as each one of the pair is identically coupled to ground, or indeed > to any other plane, there shouldn't be a problem. The LVDS driver consists of a source 4 mA, and a sink 4 mA source that are switched by a 'tree' of fets. If these were perfect current sources, then their impedance would be infinite. Since they are not perfect at DC< and certainly much less than perfect for AC (capacitance coupling), they are only as good as the best the technology can deliver - which is not all that wonderful. In other words, the > coupling to ground shouldn't, per se, cause a di/dt power supply event when > the output switches. Of course, if the pair isn't perfectly symmetrical > (perhaps due to the lead frame?) So, just due to the imperfect current sources, and the capacitive couipling, you get imbalanced DC currents. Additionally, there are pre-drivers which must drive the larger switches, and these are also generating single ended return currents. there will be a net power supply current > change when the output switches. In fact, where you say "NOT two separate 50 > ohm signal leads", I disagree. Each pin of the pair should be able to drive > separate independent 50 Ohm lines with no di/dt problems, provided these 50 > Ohm lines are identical in characteristics. No such thing. Hence the more conservative warning. I have never seen anything perfect yet. There is always some mismatch. (You could AC couple the lines > to overcome any DC termination non-linearity issues.) How could the LVDS > output 'know' it wasn't driving a 100 Ohms differential pair rather than two > separate 50 Ohm ones? By measuring the common return currents. If I drove a 100 ohm twinlead straight up off the pcb which was termianted in a 100 ohm resistor, I guarantee I would see different behavior than if I drive two separate 50 ohm lines, only because there is no such thing as perfectly matched 50 ohm lines. Unfortunately, 100 ohm twinlead is not a very common application. Forcing an AC balance by coupling the + to - together only works in the ratio of the imbalanced C to the forced C -- as well as ruining the edges on the channel. > Best, Syms. > > "Austin Lesea" <austin@xilinx.com> wrote in message > news:41DC10B6.1010301@xilinx.com... > >>Brian, >> >>A few hopefully useful comments below, >> >>Austin >> >>Brian Davis wrote: >> >>>LVDS SSO weirdness: >>> >>>The strangely low SSO limitations on those spiffy current-mode >>>LVDS output drivers are still there for all Spartan-3 packages, >>>including the BGA parts. >>> >>>Answer Record 19972 used to say: >>> >>>"Because the Spartan-3 LVDS driver is very balanced, its switching >>>causes a negligible amount of transient current. As a result, SSOs >>>are not a problem." >> >>This is only true if the driver is driving a true differential load (NOT >>two separate 50 ohm signal leads!!!). As most differential trace runs are >>not perfectly balanced, and not perfectly differential (they have coupling >>to ground), we also have to start assuming standard pcb trace routes are >>used.... > > >Article: 77384
"Michel Bieleveld" <thechatter@hotmail.com> schrieb im Newsbeitrag news:0tqnt0dvs2d1mbgvfv9r0iqkgpboal6gdv@4ax.com... > Thanks for the suggestions ! > > I am using a spartan 2E so i guess that DCM is not an option for me. The spartan-IIE has the DLL, which can do phase shifts of 90, 180, 270 degree (provided that the clock frequency is >25 MHz) You can use a 90 degree phase shifted clock to fix the delay in a reliable way. > Currently, which also works, I am using an area constraint to put the > logic closer to one pin than the other. In this way everything is > "schedules" as i want to. I was hoping for a similiar and cleaner > result by using some kind of timing constraint. > > I imagine that this constraint would accept a minimum of delay > compared to another signal. If this delay after synthesis is not met i > would expect that aditional logic is place between pad and signal to > delay the logic. Forget about such crap. This was a nasty (but often working) trick in the good ole, TTL days. No real option anymore. Regards FalkArticle: 77385
Daniel wrote: > @Bret Thanks for the suggestion. Didnt know that its possible to fix the routing also within RPM macros. > > Are RPM macros usefull for design modules as large as my one (376 CLB Slices (752 FlipFlops, 260FG's), 8BRAMs and 1GlobalBuffer) or does this lead to problems with performance or even unstable workflows? Yes, large RPM macros can be used effectively. Multiple small RPMs can be assembled with offsets defined by hierarchical RLOCs to assemble a large RPM. Automatic placement of large RPMs can be a challenge so it may be necessary to locate the macro. I believe that Ray Andraka has posted on the subject of large RPMs in the past. You may want to Google for that. > > How fix is the routing "fixed" with directed routing in the later PAR of the whole design? Is it possible that the router changes anything? Directed Routing is a relative constraint, and so the constraints will be valid wherever the macro ends up, providing that the relative location of the component pins is consistent with the routing constraints. It may be necessary to use BEL constraints as well as RLOC constraints to ensure the pin locations are correct. Once the routing constraint is successfully applied, the routing is fixed. Since you mentioned that a large macro is involved, I should point out that Directed Routing is not recommended for use with large numbers of signals on the order of hundreds. Guide should be used instead. That recommendation depends on the nature of the routing involved and the level of congestion around the locked routing. > > Best regards Daniel Some more information on Directed Routing here: http://toolbox.xilinx.com/docsan/xilinx6/books/data/docs/cgd/cgd0044_7.html#wp239816 Regards, BretArticle: 77386
There are a number of possibilities. The first could be that you
actually have something else using the parallel port. Are you using,
perchance, anything by Macraigor? If so this solution record (section
8) will help:
http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=15742
The other items in the solution record may be useful but it seems unlikely.
Another possibility is that you have multiple versions of iMPACT running
(or ChipScope or EDK). Only one can run at a time. It is possible
that you have opened the cable in Slave Serial mode and then tried to
use it in Boundary-Scan mode without first closing it in Slave Serial mode.
These are some possibilities and some issues have been resolved with the
latest versions (6.3i)
I hope this helps.
Ewan D. Milne wrote:
> Hello everyone.
>
> I have been having some trouble with iMPACT 5.1i and I was hoping
> that someone would recognize the problem and be kind enough to help me.
>
> I am using a 3rd party Parallel Cable III from Digilent, and I cannot
> get the iMPACT software to use the Parallel port. When I invoke "Cable
> Setup..." I get the messages:
>
> Connecting to cable (Parallel Port - LPT1).
> Checking cable driver.
> Driver Version = 212.
> LPT port is already in use.
> Cable connection failed.
> // *** BATCH CMD : setCable -port LPT0
> // *** BATCH CMD : setMode -bs
> =>
>
> The parallel port is set up for Bidirectional mode in the BIOS.
> The system is a laptop running Windows 2000. The Xilinx software
> fileset.txt and install.log appear to be OK, and I do have windrvr.sys
> and xpc4drvr.sys present in the WINNT/system32/drivers
> folder.
>
> I know this has to be something fairly basic, but after a lot of
> experimenting I just can't seem to figure out what is wrong. I have
> searched the web and the Xilinx web site but there doesn't seem to be
> anything that resembles the problem I am seeing.
>
> Has anyone seen this before? I tried disabling the LPT port in the
> device manager, but that didn't seem to make any difference.
>
> Thanks in advance for any replies. I read this group regularly and
> find it to be one of the most interesting and informative groups on
> Usenet.
>
> Ewan D. Milne
> Egenera, Inc.
> milne@egenera.com
>
--
*CAUTION:* Shameless self-promotion follows...
Article: 77387Austin Lesea wrote: > > We also have to assume some kind of series inductance for the customer > pcb for ground and power pins. If it is less, the performance is > better. If it is more, the performance is worse. I believe we assume > 500 pH for each power and ground (1uH total in the power and ground > circuit series L from the PCB). That would be 1 NANO-Henry, not 1 MICRO-Henry, from 2 x 500 pH. External lead inductance of only 500 pH is real good, when you need to use a via to get to an internal ground plane. I think you need to use microvias in the pad to keep it this low. JonArticle: 77388
Hi, all, I got a "The IO standards specified for IOs in Bank0 are not VCCO compatible" error when I ran DRC in the PACE, which I wasn't expecting under my pin assignments. My IOs in bank0 were all specified as LVCMOS33. I am using WebPack 6.3i with SP3. The FPGA is XC3S1000-5-FG456. I tried LVCMOS25, then the DRC passed. But I didn't specify the VCCO as 2.5V in PACE. Actually I don't know whether we can specity the VCCO voltage in PACE at all. Could anybody help to figure out or just shed some light on. :) TIA, JaneArticle: 77389
Jon, OOPS. Yes, 1 nanohenry (1nH) total power loop inductance for the pcb loop. Now, there are more than one power and ground pin for an IO bank, so this also has to be taken into account (the numebr of pins in parallel, and how effective they are). Austin Jon Elson wrote: > > > Austin Lesea wrote: > >> >> We also have to assume some kind of series inductance for the customer >> pcb for ground and power pins. If it is less, the performance is >> better. If it is more, the performance is worse. I believe we assume >> 500 pH for each power and ground (1uH total in the power and ground >> circuit series L from the PCB). > > > That would be 1 NANO-Henry, not 1 MICRO-Henry, from 2 x 500 pH. > > External lead inductance of only 500 pH is real good, when you need to > use a via to > get to an internal ground plane. I think you need to use microvias in > the pad to keep it > this low. > > Jon >Article: 77390
In my state machine I would like to add a counter which is used to increment and address each time through a certain state. Whats the best way to implement this? I've tried defining a signal but not sure where to initialize it. Do I add and init state to the state machine? or is there another way? Thanks, JoelArticle: 77391
Marius Vollmer <marius.vollmer@uni-dortmund.de> writes: > I will try to get my hand on the license, I haven't found it yet on > their web pages. I now have a copy of the license agreement (and STMicroelectronics was very helpful). As expected, GOSPL is not even close to being Open Source or Free Software. It is basically a free of charge, semi-closed industry consortium controlled by STMicroelectronics. But I believe them when they say that this is only intermittent and the real goal is indeed to go Open Source in the future. -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405Article: 77392
stockton wrote: > Do anyone know of a rough percentage of the the FPGA resources that > can be expected to be utilised before issues arise in trying to route > the design? > > I have head that it is as low as 60% but am hoping that this is not > the case. Big things like BRAMs and DLLs easily do 100% utilization. The critical thing will be LUT utilization which, in my experience (xilinx) goes up to 60% until you use the "disable register ordering" switch then you can get over 90% at a slight speed hit. -JeffArticle: 77393
hugo wrote: > Hi everyone, > > I am trying to design an interface between an XScale PXA255 CPU and an > Altera FPGA - we have a working SRAM-like asynchronous interface, but > would like to make it synchronous for improved performance and lower > latency. I have been considering making the FPGA look like an SDRAM > device and using the CPU's internal SDRAM controller to interface, but > due to some issues with bust mode and so on, that approach could result > in even higher latencies and lower throughput that the SRAM-like > interface. Has anyone solved this problem before or know of a suitable > way to do it? > Kind regards, > Hugo Vincent, > Bluewater Systems (www.bluewatersys.com) I've interfaced the PXA255 and FPGAs, but not synchronously. You never mentioned your bandwidth and latency requirements. Can you use the DMA channels on the xscale? Maybe you could describe your application in more detail. -JeffArticle: 77394
Hi I am looking for a HDMI source driver/transmission driver which would support 1920 X 1080 HDTV standard. I would appreciate be nice if somebody could send me the related links or manufacturer names. This for the HDMI digital video interface on a board. Thanks NithinArticle: 77395
In the light of recent comments on this site relating to Structured-ASICs in general and Altera and HardCopy in particular, I would like to correct a few factual inaccuracies which may have crept in. Our competition is apparently basing its decision not to follow our lead into this market on its experience with a failed product from years gone by. I would say two things about this. Firstly, technology has moved on. In the 1990s, it was not possible to base the heart of a complex system on an FPGA - they were too small. This has obviously changed, such that a single FPGA can now cover over 80% of all ASIC starts. Secondly, the increasing costs of ASIC NREs now represent a considerable barrier to the use of ASICs - this was not the case in the '90s, as NREs were typically less than $200K at that point. Deciding not to do a Structured-ASIC product today on the basis of experience from 10 years ago is a bit like a camera company deciding not to produce a digital camera today because they tried it when resolution was 300K pixels and nobody bought them! The financial community is certainly not of the opinion that this is a "non-starter". We have now completed over 50 HardCopy tapeouts and are running at a rate of over 1 per week. We believe that this means that HardCopy is currently leading the Structured-ASIC market in terms of tapeouts. The rate of designs being booked is increasing, and our backlog indicates that 2005 will see revenue tripling based on the designs that were booked in 2004. The current version of HardCopy has been shipping for exactly one year now, and its combination of seamless, risk-free migration together with the ability to reduce power and increase performance over the FPGA is unique in the industry. Clearly the Structured-ASIC industry is new and relatively small at present. However, like many of the significant players in the ASIC market, Altera believes that it will grow strongly over the next few years, and our design bookings confirm this. We are very happy to be alone in this market. Paul Hollingworth Altera MarketingArticle: 77396
Let's start with the dedicated resources, the BlockRAMs, multipliers, DCMs. Global clocks, PPCs, MGTs and the general-purpose I/O. You know before you start your desigh what percentage of these resources you need, and I bet it seldom will be 100% of each of them. So here you get everything you need (or you already know you need a different, bigger chip.) That leaves us with the balancing between logic resources (LUTs, flip-flops, SRL16s), routing capabilities, and your specific needs. Routing used to be the limiting factor in the distant past, but modern FPGAs have such an abundance of routing resources that this is seldom the limitation. Performance may suffer when the chip gets really crowded, but that depends very much on your requirements. 60% sounds to me like an insanely conservative number. Butt with over 100,000 new designs started every year, there is an enormous spread, and one should never say "never". Let's settle on "extremely unlikely". With the increasing complexity available in modern FPGAs, designers also have developed a more mature attitude, realizing that some spare room is a good thing to have. 15 years ago, some cried when a few LUTs went unused: "Such a waste !". Now they say: "Nice to have some room for future changes." Peter Alfke, Xilinx ApplicationsArticle: 77397
Austin wrote: > >> - high speed output standards are severely restricted for >> PQ/TQ/VQ parts > >The added package inductance for these packages leads to this obvious >result. As Lpkg got larger, V = -Ltotal * di/dt got larger, too. > The point of my "Bad News" commentary was to highlight to other designers that the new SSO guidelines mean these parts can often only use a small percentage of the available I/O pins as outputs. For me, it's equally "obvious" that the big leaded parts really need to have more pwr/gnd pins per bank - do "virtual" pwr/gnd pins created with a high strength driver count the same as normal pwr/gnd pin pairs for SSO calculations? I'd love to have participated in the design review where it was decided that 2-4 output pins per bank for most standards was an acceptable design target for the leaded S3 parts :) My own wish list for hypothetical "Spartan-3E" (sic) leaded parts: - ground paddle packages with GND S+ S- GND(VCC) pinout - implement _DT differential terminators - remove DCI ( hopefully improving Cin ) - better slew rate control options for output drivers (instead of DCI) <re LVDS SSO> > >> But oddly, the Virtex2 LVDS SSO Answer Record #13572 still says >> LVDS SSO's are "not a problem" ... so, has the LVDS output driver >> design changed drastically from V2 to S3 ? > >No, the S3 differential IOs are quite the same as V2 and V2P. > Thanks, that's good to know. So it's just the differential net loading balance assumptions used in the SSO calculations that have changed, not the drivers themselves. ( One trick I've used to damp out the input Cin reflection when there's plenty of drive signal is to stick a differential attenuator ahead of the receiver; the same idea should also work at the driver to let it 'see' a more perfect load. Panasonic makes some nifty 100 ohm differential attenuators in a tiny [0404] package, stocked by DigiKey. ) > >> Now it says: >> >> "Because the Spartan-3 LVDS driver is very balanced, its switching >> causes a negligible amount of transient current. As a result, SSOs >> are typically not a problem in the smaller device/package combinations. >> However, SSO does become a concern with the larger device/package >> combinations so please be aware of the SSO guidelines for Spartan-3." > >Sort of like saying: "we are ususally OK, but some folks have had a less >wonderful experience, and maybe if you have a lot of them, you should >simulate the SI." Not much different that my usual stance: simulate, >simulate, simulate. > How do you propose that the end user simulate on-chip SSO problems created by unbalanced loading on an LVDS driver? AFAIK, the the current generation of Xilinx IBIS models, when used with presently available IBIS simulation tools, can not model on-chip SSO related supply problems for differential I/O standards. Perhaps if all 200,000+ user seats of Xilinx S/W also bought a copy of HSPICE to use the encrypted SPICE models, they too could attempt to model on-chip SSO for a particular differential pair routing topology... Off to buy some Synopsys stock, BrianArticle: 77398
I have received a job offer from a company in San Jose, California. The position title is: Test Development Engineering. The salary offered is 67k/year with Relocation Assistance and a Benefits package. I already have a 60k/year job in Toronto, Canada as Applications Engineer. The San Jose job is closer to circuit-design which is an area I would like to get into. I was told that the housing prices of Bay Area will make this salary into a 50k equivalent of Toronto. So practically my "buying power" is reduced. I have a dillema whether: -Professional advantages of this position, closer to ciruit design. -Working in Silicon Valley, the Mecca of HighTech. outweigh the offered salary ? Thanks in advance.Article: 77399
simon.stockton@baesystems.com (stockton) wrote: >I am looking at trying to fit a number of IP cores into a single >Xilinx FPGA, I have heard that it is not possible to completly utilise >all the FPGA resources (RAM, Logic Cells, DCMs etc ... ) because of >routing problems. > >Do anyone know of a rough percentage of the the FPGA resources that >can be expected to be utilised before issues arise in trying to route >the design? Depends. For example, on a Xilinx Spartan-3, if you use the full width of the large memories known as block rams (x36) you can't use the multipliers in the same tile. Block rams can be configured from 16k x1, 8k x2, 4k x4, 2K x9, 1k x18, and 512 x36. If the IP you buy has nothing but full width block rams (configured as 512 x36) and uses multipliers, you might not even get past 50% on the large resources. Yet anther question to ask the IP vendors. On the other hand, I've used 100% of the block rams on several different designs. >I have head that it is as low as 60% but am hoping that this is not >the case. > >I understand that it really does depend on what you put into the FPGA >but to only be able to utilise 60% on average seams a little poor to >me. The key question is: What is the limiting resource? Pins? Memory? Multipliers? Lookup tables? Time? Money? If you need X pins and that requires a given size part, you may have no use for the extra logic and memory that comes with that part. If you need Y bytes of internal RAM and have no use for multipliers, you may well use 0% of the multipliers. If you need a design done in a short design time (and your volumes are not huge), using a smaller percentage of the part can save time making things fit. If you hope to make and sell millions of items, spending a lot of time to cram the design into a smaller part can make sense. It usually wouldn't make sense if the world wide lifetime demand is exactly eight units. -- Phil Hays Phil-hays at posting domain (- .net + .com) should work for email
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