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 Paul, > > Cyclone EP1C6Q240C6: > > fmax: 98 MHz, 2066 LC/Es (34% out of 5980) > > Spartan-3 XC3S200-5 > > fmax: 82 MHz, 2015 LC/Es (52% out of 3840) > > By turning on Minimize Area w/Chains under Fitter Settings/More > Settings.../Auto Packed Registers - Cyclone you can cut the LE count to 1868 > LEs (from 2066). Quartus doesn't try too hard to put registers & LUTs > together unless it runs out of room (or you tell it to with this setting). > In my compile, this didn't hurt Fmax (Fmax was 99 Mhz). On average, > aggressively packing can slightly hurt performance and cause an increase in > wiring. Thank's for the hint. It's nice to get it smaller AND faster. > too. To automatically try-out the area optimization tricks in Quartus, run > the Design Space Explorer tool, and select "Area Optimization" mode under > the Advanced settings. It'll take a while, but this will find you the best > settings (for area) for your design. I could not find the 'Design Space Explorer' in Quartus. If you mean the Resource/Timeing Opt. Adviser under 'Tools' than I'm in bad luck. This function is not available with the web edition of Quartus. > In this particular case, your critical path appears to stretch from a RAM to > a RAM (configured as a ROM) with little logic in-between. Logic + > routing-rich paths tend to accentuate the speed differences between the two > devices, while RAM-heavy paths show a smaller advantage. > In this case I think it's a logic/routing-rich path. From the memory data out (unregistered) there is a 8-bit 'lookup table' and an adder, resulting in 6 LCs till the next register (in this case the address register of another RAM). Perhaps the ALM structure from the Stratix II would help for this function, but the Stratix devices are too big and too expensive ;-) Or a clock-free ROM as it was available in the ACEX parts. In fact, Quartus implements this structure in a block RAM when targeting the ACEX device (I still have several ACEX boards laying around and collectiong dust ;-). Martin ---------------------------------------------- JOP - a Java Processor core for FPGAs: http://www.jopdesign.com/Article: 74026
"Antti Lukats" <antti@case2000.com> wrote in message news:<cjlt48$uvo$01$1@news.t-online.com>... > > Antti Lukats wrote: > > I could be wrong, but I thought open source cores that run uCLinux were > > already available for FPGAs. The only difference is that this one is > > code compatible with uBlaze. Am I wrong about this? > > Yes, if there would be similar reference platform for OR1100, but it is not > available. LEON is real nice system, but the ref system hardly fits into > XCV2000 !! LEON is an implementation that is focused on a radiaton hard operation of an architecture (SPARC) that was designed for ASICs. Whereas MB is an architecture that was optimized from the beginning for a small FPGA implementation. There will never be a SPARC implementation that will get the same performance per LUT as MB does. AFAIK the OR1k architecture also is not optimzed for FPGA implementation and is therefore rather large. So I think it is great to see an open source implementation of MB. Can you comment on how many LUTs your implementation requires? Also: You mention on your web site that some instructions are not impleneted. Which instruection are these? Kolja SulimmaArticle: 74027
> LEON is an implementation that is focused on a radiaton hard operation > of an architecture (SPARC) that was designed for ASICs. It is designed for radiation hard per se? Isn't it just an open source SPARC. Do you knwo how to design for radiation hard applications, especially in an FPGA? Redundant structures and hoping that the synthesizer does not detect them and optimize it away... MartinArticle: 74028
"whatisasics" <whatisasics@none.net> wrote in message news:A5p7d.5328$nj.3186@newssvr13.news.prodigy.com... > Antti Lukats wrote: > > http://uclinux.openchip.org/forum/viewtopic.php?t=4 > > > > here is proof :) > > > > the opensource version as available from opencores is not yet good enough to > > run uCLinux - well lets see if that will change, > > I think there is a wish to have an open-souce multi-vendor FPGA softcare > > capable to run uCLinux inside many people :) > > And this is what irks me...if you "need" a "free" FPGA cpu core, there > are already several to choose from (www.opencores.org.) One of them I dont know what the "irks" means, but - if it really irks you then please please: 1) goto to opencores, 2) download any of the several cores you mentioned 3) port the uCLinux reference desing for that core to the FPGA board you use 4) boot uCLinux to the shell prompt on your FPGA board I would really like to hear your comments after you have managed 1..4 from above! And please post with your real name not using anon email address! Antti PS porting MicroBlaze-uCLinux reference design (mbvanilla) to new FPGA board takes usually less than 5 hoursArticle: 74029
"rickman" <spamgoeshere4@yahoo.com> wrote in message news:415E3A81.329A38AB@yahoo.com... > Antti Lukats wrote: > > > > http://uclinux.openchip.org/forum/viewtopic.php?t=4 > > > > here is proof :) > > > > the opensource version as available from opencores is not yet good enough to > > run uCLinux - well lets see if that will change, > > I think there is a wish to have an open-souce multi-vendor FPGA softcare > > capable to run uCLinux inside many people :) > > I could be wrong, but I thought open source cores that run uCLinux were > already available for FPGAs. The only difference is that this one is > code compatible with uBlaze. Am I wrong about this? Hi Rick, Yes, OR1K is uCLinux capable, I guess also M68K and LEON and maybe Aquarius/SH-3 could be. The thing is that MicroBlaze-uCLinux reference design (mbvanilla) requires 1) any FPGA starting from XC2S200 2) 4MB SRAM/SDRAM/DDR 3) interrupt/timer/uart 4) porting of the mbvanilla to new board can be done withing few hours ASFAIK there is nothing to compete with that - OR1K reference design doesnt pass even synthesis out of box, just tried out of curiosity. MicroBlaze is small and minimal MicroBlaze-uCLinux is small as well, actually there is almost no overhead to make MicroBlaze system uCLinux reference design compatible. Yes, if there would be similar reference platform for OR1100, but it is not available. LEON is real nice system, but the ref system hardly fits into XCV2000 !! M68K is not complete i think and SH3, not sure if there is uCLinux available for it all. So you are not wrong per se, but I dont envy you if you try to use some existing open ip core for the uCLinux bringup. anttiArticle: 74030
> Same problem with many other CAST's processor cores > mentioned: 80C51, TMS32025 and "Z80 Compatible Microprocessor" > CZ80CPU, the data sheets mention only Spartan-3 XC3S400-4 and > Spartan-IIE XC2S300E-7 and some larger Virtex-II's as Example > Devices on which to implement them. > > Does this mean that XC3S200 has not enough logic > to implement ANY of these or just that CAST Inc. > didn't have XC3S200-device at hand, and thus > haven't tested their designs on it? You can find a 6809 with VGA, UART and keyboard controller running on the Starter Kit at: http://members.optushome.com.au/jekent/Spartan3/index.html MartinArticle: 74031
Antti Lukats wrote: > so as for the moment the open-MB is the smallest free-open IP-core with > "proven" gnu toolchain support I would say, or does some better alternative > exist ?? What happened to all this implementations of the DLX ? There was the whole GNU chain available at one time, and a lot of people used them for their diploma work etc...Article: 74032
> Ha, I see Martin has also already responded, for I just offered to donate my > acex jopcore PCB to the MB designer, so it goes for good cause at last! > Hi Antti, that's really nice (and funny) how much used this single board gets ;-) And a MB on an Altera FPGA, that's the end of the world. BTW: I have some more ACEX boards. I could donate them (or a small fee..) for projects that can convince me... MartinArticle: 74033
Followup to: <cjl7vb$tks$1@agate.berkeley.edu> By author: nweaver@soda.csua.berkeley.edu (Nicholas Weaver) In newsgroup: comp.arch.fpga > > In article <HZCdnbCLRZsnmsPcRVn-uw@megapath.net>, > Hal Murray <hmurray@suespammers.org> wrote: > >>As far as timing models go, any implication that redundancy affects quality > >>of timing models is pure FUD. So long as the max and min delays reflected > >>within the software are an upper-bound and lower-bound on the delay that can > >>be seen in any repaired part, then everything's cool. > > > >How much trouble do you get from customers who are right at the edge > >and have a design that works most of the time but is flaky on chips > >which happen to use the redundancy path on a critical signal? > > That will only be a problem if the (emm, I guess the only word thats > polite is) customers rely on empirical measurements rather than the > static timing analysis. > Right, but at that point you're screwing yourself anyway because of PVT variations. PVT variations are considerable in modern high-density processes, and unless you do as extensive a set of characterizations as the vendors themselves then you don't have much of a hope to get a handle on that. Thus, redundancy timings is just one of many variables that vary from chip to chip. -hpaArticle: 74034
Followup to: <415E306A.38AD3EA0@yahoo.com> By author: john@bluepal.net In newsgroup: comp.arch.fpga > > > FPGAs have 0% extra area for BIST (they are 100% BIST with a different > > bitstream!). > > No, by definition an FPGA has extra area for BIST, that is what makes it > an FPGA, all the *extra* stuff in it!!! What is the area overhead for > an FPGA vs. an ASIC; 10X, 20X? Even if you build an ASIC that is two > generations back such as 150 nm vs. 90 nm, the ASIC will be smaller, > faster and therefore cheaper. > .... after you cross some volume threshold, which these days can be quite large. > > > You must understand that the 405PPC, MGT, DCM, and other "hardened IP" > > are just like ASICs, so we already know everything there is to know > > about ASICs, their design, and testing. In fact Xilinx the 3rd largest > > 'ASIC' manufacturer in the world (behind IBM and NEC -- > > Gartner/Dataquest 'ASIC/FPGA Vendor Ranking 2003'). > > > > FPGA vendors may be the last stronghold of full custom ASIC design left > > in the world. ASIC houses are mostly standard cell, or structured > > (basically same thing), with little or no full custom. > > > > Our customers tell us that if they want to play with the latest and > > greatest technologies and designs (like 10 Gbs MGTs), they need to use > > our FPGAs, because the ASIC cells are a generation behind. > > How is using the "latest and greatest technologies" an advantage when it > comes with a 10X area premium??? > Because it otherwise would be 20-40x premium? -hpaArticle: 74035
> Set a time constraint for clk (in this case I used 12ns). However, this
> should already be done in the UCF you downloaded with the project. Then
> look at the 'text-based post-plcae & route static timing report'. At the
> end you will find:
>
> Design statistics:
> Minimum period: 12.848ns (Maximum frequency: 77.833MHz)
Design statistics:
Minimum period: 17.812ns (Maximum frequency: 56.142MHz)
... Even with effort level high, it's even worse !?
Design statistics:
Minimum period: 18.508ns (Maximum frequency: 54.031MHz)
Could you send me the exact files you compile to '246tnt' at the domaim gmail dot com ?
Maybe ise just don't like vmware ?
> Don't let yourself be fooled by the maximum frequency from the synthesis
> report. These are dummy numbers (in this case 96 MHz...).
Yup, I know that the warning is pretty clear
--- QUOTE ---
NOTE: THESE TIMING NUMBERS ARE ONLY A SYNTHESIS ESTIMATE.
FOR ACCURATE TIMING INFORMATION PLEASE REFER TO THE TRACE REPORT
GENERATED AFTER PLACE-and-ROUTE.
------------
> Btw, does somebody know why the lead free devices are more expensive. I
> did'n know up to now that semiconductors contain lead. I only know that
> it's part of the solder and when it's forbidden will probably increase
> production cost of PCBs.
The alloid used are more complex and uses more precious metals. (for
the solder balls and solder plating of terminal)
Sn/Pb before
and now, like Nickel/Palladium
>>Yup, I think there are 200LC used for a booth multiplier, should be
> easy to lower that with a dedicated multiplier (and also go faster i
> would guess).
>
> Yes that would drop the LC count and I could go with the next smaller
> Spartan-3. Uups, where is the XC3S100?
;) I'm more interested on the space I win to put more devices connected to
JOP like an ethernet mac, a i2s master, lcd controller ...
> The multiplication would be faster, but the multiplication (imul bytecode
> in the JVM) has a dynamic instruction frequency of 0.24% in typicall Java
> programs. That would not compensate for the clock frequency factor of 1.2
> between the Cyclone and the Spartan-3.
Sure, I never meant it would fill the gap !
>>Btw, is there any networking available ?
>>I have a Avnet Spartan 3 kit with an ethernet PHY on bard, that would
> be nice to get TCP/IP ;)
>
> Do you mean available with JOP? Yes, I have a small TCP/IP stack in Java
> with drivers for the CS8900 (Ethernet), PPP and SLIP. Even a small
> webserver is running on JOP: http://84.112.19.23 ;-)
Silly me ... I must had a windows over my browser hiding the link ;)
Since you use an external ethernet controller, I guess I would need a MAC
inside the FPGA and the appropriate drivers for it too.
Sylvain
Article: 74036> > Set a time constraint for clk (in this case I used 12ns). However, this > > should already be done in the UCF you downloaded with the project. Then > > look at the 'text-based post-plcae & route static timing report'. At the > > end you will find: > > > > Design statistics: > > Minimum period: 12.848ns (Maximum frequency: 77.833MHz) > > Design statistics: > Minimum period: 17.812ns (Maximum frequency: 56.142MHz) That's strange, perhaps you have a different version (my ISE is 6.2 as shipped with the board). > Could you send me the exact files you compile to '246tnt' at the domaim gmail dot com ? > Maybe ise just don't like vmware ? done > Yup, I know that the warning is pretty clear > > --- QUOTE --- > NOTE: THESE TIMING NUMBERS ARE ONLY A SYNTHESIS ESTIMATE. > FOR ACCURATE TIMING INFORMATION PLEASE REFER TO THE TRACE REPORT > GENERATED AFTER PLACE-and-ROUTE. > ------------ Ooh, I'm sorry that I did not read it and complained about missing it in another thread. One excuse: I usually don't read the synthesis results, only the P&R reports. I only had to post about it since I get many of these high fmax reports from Xilinx users (and this was an issue in the MB thread too). > The alloid used are more complex and uses more precious metals. (for > the solder balls and solder plating of terminal) > Sn/Pb before > and now, like Nickel/Palladium Solder balls ok, but that difference in QFP packages? > > Do you mean available with JOP? Yes, I have a small TCP/IP stack in Java > > with drivers for the CS8900 (Ethernet), PPP and SLIP. Even a small > > webserver is running on JOP: http://84.112.19.23 ;-) > > Silly me ... I must had a windows over my browser hiding the link ;) > Since you use an external ethernet controller, I guess I would need a MAC > inside the FPGA and the appropriate drivers for it too. But a MAC is a big and difficult beast and you still need an external chip for the voltage levels. An external Ethernet chip is cheap, works an d you usually get a lot of memory for buffering Ethernet frames. Martin ---------------------------------------------- JOP - a Java Processor core for FPGAs: http://www.jopdesign.com/Article: 74037
Followup to: <cjkl5p$ieu$1@news.onet.pl> By author: "greg" <xgrzes@poczta.onet.pl> In newsgroup: comp.arch.fpga > > Hello > i need to implement gigabit ethernet in FPGA.. > now all is almost done (MAC in FPGA , PHY), and need to implement a simple > protocol that will ensure proper delivery of all data from digital camera (1 > picture = 128MB). I thought about IP/UDP and own protocols with handshake > and retransmition of lost packets, but maybe there exists something > simpler - already used and implemented protocols - i just need to make > programmer's life easier at the other end of cable:) > At that point you might as well use TCP... implementing TCP is not that hard if you don't care about super-high performance across very long distances. See for example uIP or lwIP for small TCP/IP stacks that can be run on a small microcontroller which can easily be synthesized in an FPGA. If you want to use UDP or raw Ethernet packets you probably want to do something like TFTP. -hpaArticle: 74038
Does anyone have any suggestions on how to do Logs and Powers? Part of the design I'm working on has "log(1 + B^d)", and we're pretty much stuck there. So far, the ideas being kicked around are to either use the Taylor series (I'm not the biggest fan of this), or to try to use CORDIC. I haven't found any free/open IP that looked like it would work, the closest being a couple of (fixed-point) CORDIC cores from Open Cores. Accuracy and speed are the two main concerns, but memory is tight, so I don't know if a lookup table is doable. Are there any other approximations that might work, and might be easier to implement using floating point? And how do the hardware implementations in some FPU's work? Thanks, MikeArticle: 74039
> Incorporating extra functionality in an FPGA is usually done because it > provides some additional advantage beyond absorbing external components. > Let's look for a second at incorporating volatile RAM. Altera clearly > thinks it is worth including medium-sized SRAM blocks (hence the 512 Kb rams > in Stratix and Stratix II). Designs often require one or two large RAMs > (off-chip) for long-term data storage, and a few medium RAMs for buffering I would like to add my 'wish-list' for an FPGA: As I'm working with processors in FPGA I always need external SRAM: costing money, PCB space, routing troubles, more pins... I would like to see more SRAM on-chip. I don't need it as super-fast dual-ported block RAMs. I would be happy with a single port 10-20ns access RAM, but larger. Let's say 128KBbytes (not bit) to 1MB in EP1C3-EP1C12 devices. When the system memory is integrated I will vote for smaller packages: tqfp100 or even tqfp44. The idea is the same as for microcontrollers in very small packages. And an open documentation (not only as feature in NIOS) how to write to the serial config Flash from within the FPGA. my 2c Martin ---------------------------------------------- JOP - a Java Processor core for FPGAs: http://www.jopdesign.com/Article: 74040
In article <eb4ab45b.0410021355.1acfcb@posting.google.com>, Mike Delaney <mmdst23@pitt.edu> wrote: >Does anyone have any suggestions on how to do Logs and Powers? >Part of the design I'm working on has "log(1 + B^d)", and we're pretty If this is the only log and power you need to do and if either "B" or "d" is a constant, I'd be suggest trying to do the whole function in one go. I'd be very tempted to come up with a function that is sort of close and then use a Taylor series to fix it. If "d" is the only variable, breaking it into 2 ranges, one for each sign of "d" would be a natural thing to do. -- -- kensmith@rahul.net forging knowledgeArticle: 74041
Hi Martin > That's strange, perhaps you have a different version (my ISE is 6.2 as > shipped with the board). Thanks for the files. I finally got to the same result. The problem was : - A ISE 6.2 not updated - A 'bad' constraint file >>The alloid used are more complex and uses more precious metals. (for >>the solder balls and solder plating of terminal) >>Sn/Pb before >>and now, like Nickel/Palladium > > Solder balls ok, but that difference in QFP packages? I think the pins are plated with something similar to the solder to get good solering. That plating probably must be "updated". Reflow temp is also higher IIRC > But a MAC is a big and difficult beast and you still need an external > chip for the voltage levels. An external Ethernet chip is cheap, works an > d you usually get a lot of memory for buffering Ethernet frames. Yeah but the devboard I have already has the PHY. (Standard Avnet spartan 3 kit). But indeed the MAC seems pretty big ;( about 2000 slice. SylvainArticle: 74042
Martin Schoeberl wrote: > Btw, does somebody know why the lead free devices are more expensive. I > did'n know up to now that semiconductors contain lead. I only know that > it's part of the solder and when it's forbidden will probably increase > production cost of PCBs. >>The alloid used are more complex and uses more precious metals. (for >>the solder balls and solder plating of terminal) >>Sn/Pb before >>and now, like Nickel/Palladium > > > Solder balls ok, but that difference in QFP packages? That's an easy one : because they can. It's a good place to do a little cost recovery/price racking, as users will have designed in the devices, and are thus captive by both the legistation and the layout, plus many do not compare Pb/PbFree prices, so that's the ideal time to nudge the prices! -jgArticle: 74043
As part of a signal processing design I'm working on (I was given C/Matlab code, and told "go make it hardware"), I need to calcuate log(1+B^d). So far, I've found some information on CORDIC and 2 software approximations. I need to do this in 32 bit floating point, and the requirements call for "as much accuracy as you can get" as no one has been able to figure out how much we really need yet. There's also a large possible difference betwen the biggest and smallest numbers that are used in this calcuation, so using some fixed-point system is most likly more work then it's worth. I'm thinking that I could calcuate B^d as e^(d * LN(B)), since I'm hoping that whatever way I end up using to find log(x) can be reversed to find e^x as well. The approximations I've found so far have all been software based, and didn't seem that accurate (about 5 or so decimal digits when tested in Matlab). It also seems like taking the iterative/software-based approach is the wrong way to go, and could easily lead to the log/exp unit needing over a hundred cycles to execute. The two approximations I've looked at are the one from glibc and the one used in the VHDL Real Math package. CORDIC seemed more promising at first, but it looks like it's not widly used for floating point. However, I haven't been able to find any deatails on what other methods might be better. Can anyone suggest a better way? Are there any approximations that are more hardware then software based? Or would I be better off either using one of them, or CORDIC? Thanks, Mike (Sorry if tihs is a re-post, I tried to post this an hour ago, but it didn't show up, I might have clicked the wrong button.)Article: 74044
i am trying to implement an image convolution filter that has negative values in it on a spartan IIe fpga. So i need to perform (for instance) A*B + C*D where A,B,C,D are all signed numbers in the ieee std logic int range. what is the best way to implement this? It seems that the way i am doing it now (using std_logic_vector) fails for negative values of the filter coeffs. can anyone give a suggestion how to fix this (the best way to code it in vhdl). What is the best way to do a numerical comparison (ie. A < B in vhdl (that is also synthesizeable), where A,B are signed integers) thanks -- Geoffrey Wall Masters Student in Electrical/Computer Engineering Florida State University, FAMU/FSU College of Engineering wallge@eng.fsu.edu Cell Phone: 850.339.4157 ECE Machine Intelligence Lab http://www.eng.fsu.edu/mil MIL Office Phone: 850.410.6145 Center for Applied Vision and Imaging Science http://cavis.fsu.edu/ CAVIS Office Phone: 850.645.2257Article: 74045
Martin- It makes sense that integrating ram replacing external memory would reduce pin count etc, the confusing part of your message is realted to this thread being NV memory oriented. Do you want your 128KB on chip memory truly for ram or for code storage? Does that relate to the NV aspect of the discussion for those low density devices you mention? -cheers "Martin Schoeberl" <martin.schoeberl@chello.at> wrote in message news:pIF7d.330373$vG5.20442@news.chello.at... > > Incorporating extra functionality in an FPGA is usually done because it > > provides some additional advantage beyond absorbing external > components. > > Let's look for a second at incorporating volatile RAM. Altera clearly > > thinks it is worth including medium-sized SRAM blocks (hence the 512 Kb > rams > > in Stratix and Stratix II). Designs often require one or two large > RAMs > > (off-chip) for long-term data storage, and a few medium RAMs for > buffering > > I would like to add my 'wish-list' for an FPGA: > As I'm working with processors in FPGA I always need external SRAM: > costing money, PCB space, routing troubles, more pins... > I would like to see more SRAM on-chip. I don't need it as super-fast > dual-ported block RAMs. I would be happy with a single port 10-20ns > access RAM, but larger. Let's say 128KBbytes (not bit) to 1MB in > EP1C3-EP1C12 devices. When the system memory is integrated I will vote > for smaller packages: tqfp100 or even tqfp44. The idea is the same as for > microcontrollers in very small packages. > And an open documentation (not only as feature in NIOS) how to write to > the serial config Flash from within the FPGA. > > my 2c > Martin > ---------------------------------------------- > JOP - a Java Processor core for FPGAs: > http://www.jopdesign.com/ > > >Article: 74046
Hi Austin, Thanks for your reply. Makes a lot of sense. I can understand the part on 49% of signals not toggling relating to the situation you are talking about. How about the setting of signals (61%). 1) Does this mean that the information is not transferred by the vcd file or 2) No activity is detected so it is not reflected (In which case there is no difference from not toggling) If it is 1), I guess it is the fault of settings in ModelSim, how then can I address the problem? The format of my modelsim script is as follows: add wave sim:/<entity>/* vcd file <somefile>.vcd vcd on vcd add /* force <statements> run <sim length> Thanks Ed austin <austin@xilinx.com> wrote in message news:<cjmodr$ihm4@cliff.xsj.xilinx.com>... > Ted, > > It is trying to tell you that your simulation test bench doesn't cause > much to happen. > > The estimate is only as good as the test bench. > > If all those nodes don't ever switch, then you can probably simplify > your design! > > The number of cycles is no measure of coverage. If I hold a register in > reset, and clock it a million times, I will not see much power. > > So, without a test bench that exercises all of the registers, with the > worst case transitions, the estimate isn't very good. > > But only you can tell what the register values should be, the tool can't > just guess. > > Some people use a LFSR to generate pseudo random data as a stimulus. > Might, or might not be appropriate in your case. > > Austin > > Ted wrote: > > > Hi All, > > > > I am using XPower and I encounter the following warnings: > > WARNING:Power:762 - Only 61% of the design signals have been set. > > WARNING:Power:763 - Only 49% of the design signals toggle. > > INFO:Power:556 - Estimate is inaccurate based on analysis of the > > design, user > > input and characterization data. > > > > I am using the post-place-and-route simulation model and the > > activities of all nodes are set by ModelSim using a vcd file > > simulating up to 10000 cycles. > > > > 1) Specifically, how does it determine that the estimate is > > inaccurate? > > > > 2) Are register-rich designs tend to be like that i.e. because > > activities at varoius nodes has not been set properly? > > > > 3) WHAT CAN I DO? > > > > The detailed report is below: > > > > ---------------------------------------------------------------- > > Release 6.3.01i - XPower SoftwareVersion:G.36 > > Copyright (c) 1995-2004 Xilinx, Inc. All rights reserved. > > Design: stream > > Preferences: stream.pcf > > VCD File: stream.vcd > > Part: 2v1000ff896-6 > > Data version: ADVANCED,v1.01,07-31-02 > > > > Power summary: I(mA) P(mW) > > ---------------------------------------------------------------- > > Total estimated power consumption: 567 > > --- > > Vccint 1.50V: 103 154 > > Vccaux 3.30V: 100 330 > > Vcco33 3.30V: 25 83 > > --- > > Clocks: 1 1 > > IOs: 0 18 > > Inputs: 0 0 > > Logic: 1 1 > > Outputs: > > Vcco33 19 62 > > Signals: 1 1 > > --- > > Quiescent Vccint 1.50V: 100 150 > > Quiescent Vccaux 3.30V: 100 330 > > Quiescent Vcco33 3.30V: 1 3 > > Startup Vccint 1.5V: 250 > > Startup Vccaux 3.3V: 100 > > Startup Vcco33 3.3V: 50 > > --- > > Package power limits, ambient 25C: 5085 > > 250 LFM: 7317 > > 500 LFM: 8955 > > 750 LFM: 10169 > > > > Thermal summary: > > ---------------------------------------------------------------- > > Estimated junction temperature: 32C > > 250 LFM 30C > > 500 LFM 29C > > 750 LFM 28C > > Ambient temp: 25C > > Case temp: 31C > > Theta J-A: 12C/W > > --- > > Max ambient at junction max of 85C: 78C > > 250 LFM 80C > > 500 LFM 81C > > 750 LFM 82C > > > > Decoupling Network Summary: Cap Range (uF) # > > ---------------------------------------------------------------- > > Capacitor Recommendations: > > Total for Vccint : 44 > > 470.0 - 1000.0 : 1 > > 4.70 - 10.00 : 2 > > 0.470 - 2.200 : 5 > > 0.0470 - 0.2200 : 8 > > 0.0100 - 0.0470 : 14 > > 0.0010 - 0.0047 : 14 > > --- > > Total for Vccaux : 8 > > 470.0 - 1000.0 : 1 > > 0.0470 - 0.2200 : 1 > > 0.0100 - 0.0470 : 2 > > 0.0010 - 0.0047 : 4 > > --- > > Total for Vcco33 : 11 > > 470.0 - 1000.0 : 1 > > 0.470 - 2.200 : 1 > > 0.0470 - 0.2200 : 2 > > 0.0100 - 0.0470 : 3 > > 0.0010 - 0.0047 : 4 > > ----------------------------- > > I/O Bank Details: > > > > Bank 0 (3.3V) : > > 470.0 - 1000.0 : 1 > > 0.470 - 2.200 : 1 > > 0.0470 - 0.2200 : 2 > > 0.0100 - 0.0470 : 3 > > 0.0010 - 0.0047 : 4 > > Total : 11 > > --- > > ---------------------------------------------------------------- > > For further information on Bypass/Decoupling Capacitors see > > application note 623 > > > > WARNING:Power:762 - Only 61% of the design signals have been set. > > WARNING:Power:763 - Only 49% of the design signals toggle. > > INFO:Power:556 - Estimate is inaccurate based on analysis of the > > design, user > > input and characterization data. > > > > Power details: > > ------------------------------------------------------------------------------- > > Outputs:1 Loads Loading(fF) C(pF) F(MHz) > > I(mA) P(mW) > > ------------------------------------------------------------------------------- > > Vcco33 > > mpc_d<10>-E0 35000 13 5.1 > > 0.8 2.7 > > mpc_d<12>-E0 35000 13 5.1 > > 0.8 2.7 > > mpc_d<14>-E0 35000 13 5.1 > > 0.8 2.7 > > mpc_d<15>-E0 35000 13 5.1 > > 0.8 2.7 > > mpc_d<16>-E0 35000 13 5.1 > > 0.8 2.7 > > mpc_d<20>-E0 35000 13 5.1 > > 0.8 2.7 > > mpc_d<22>-E0 35000 13 5.1 > > 0.8 2.7 > > mpc_d<27>-E0 35000 13 5.1 > > 0.8 2.7 > > mpc_d<07>-E0 35000 13 5.0 > > 0.8 2.6 > > mpc_d<08>-E0 35000 13 4.9 > > 0.8 2.6 > > ------------------------------------------------------------------------------- > > Logic: Loads Loading(fF) C(pF) F(MHz) > > I(mA) P(mW) > > ------------------------------------------------------------------------------- > > CompRegD345<3>-E1 1 10.0 > > 0.0 0.0 > > CompRegB378-U1/SP.WSGEN 0 10.0 > > 0.0 0.0 > > CompRegB378.WSGEN 0 10.0 > > 0.0 0.0 > > CompRegB381-U1/SP.WSGEN 0 10.0 > > 0.0 0.0 > > CompRegB381.WSGEN 0 10.0 > > 0.0 0.0 > > CompRegB384-U1/SP.WSGEN 0 10.0 > > 0.0 0.0 > > CompRegB384.WSGEN 0 10.0 > > 0.0 0.0 > > CompRegB387-U1/SP.WSGEN 0 10.0 > > 0.0 0.0 > > CompRegB387.WSGEN 0 10.0 > > 0.0 0.0 > > CompRegB583-U1/SP.WSGEN 0 10.0 > > 0.0 0.0 > > ------------------------------------------------------------------------------- > > Signals: Loads Loading(fF) C(pF) F(MHz) > > I(mA) P(mW) > > ------------------------------------------------------------------------------- > > __ibuf_mpc_a<04> 33 19 2.8 > > 0.1 0.1 > > __ibuf_mpc_a<03> 33 19 2.8 > > 0.1 0.1 > > __ibuf_mpc_a<02> 33 19 2.5 > > 0.1 0.1 > > __ibuf_mpc_a<05> 33 17 2.2 > > 0.1 ~0.0 > > __ibuf_mpc_oe 36 9 3.2 > > 0.0 ~0.0 > > CompRegC216 78 23 0.9 > > 0.0 ~0.0 > > internal_mpc_d<15> 1 3 5.1 > > 0.0 ~0.0 > > internal_mpc_d<22> 1 2 5.1 > > 0.0 ~0.0 > > internal_mpc_d<01> 1 2 4.9 > > 0.0 ~0.0 > > internal_mpc_d<00> 1 2 4.8 > > 0.0 ~0.0 > > ------------------------------------------------------------------------------- > > Clocks:1 Loads Loading(fF) C(pF) F(MHz) > > I(mA) P(mW) > > ------------------------------------------------------------------------------- > > stream/clk/IBUFG > > Logic: > > stream/clk/BUFG 6 10.0 > > 0.1 0.1 > > Nets: > > stream/clk 94 38 10.0 > > 0.6 0.9 > > stream/clk/IBUFG 1 0 10.0 > > 0.0 ~0.0 > > ------------------------------------------------------------------------------- > > Inputs: Loads Loading(fF) C(pF) F(MHz) > > I(mA) P(mW) > > ------------------------------------------------------------------------------- > > stream/clk/IBUFG 3 10.0 > > 0.1 0.1 > > __ibuf_mpc_oe 3 3.2 > > 0.0 0.0 > > __ibuf_mpc_a<00> 3 3.0 > > 0.0 0.0 > > __ibuf_mpc_a<03> 3 2.8 > > 0.0 0.0 > > __ibuf_mpc_a<04> 3 2.8 > > 0.0 0.0 > > __ibuf_mpc_a<07> 3 2.8 > > 0.0 0.0 > > __ibuf_mpc_we<3> 3 2.8 > > 0.0 0.0 > > __ibuf_mpc_a<13> 3 2.7 > > 0.0 0.0 > > __ibuf_mpc_a<10> 3 2.6 > > 0.0 0.0 > > __ibuf_mpc_a<11> 3 2.5 > > 0.0 0.0 > > ------------------------------------------------------------------------------- > > IOs:1 Loads Loading(fF) C(pF) F(MHz) > > I(mA) P(mW) > > ------------------------------------------------------------------------------- > > Vcco33 > > __ibuf_mpc_d<05> 3 5.3 > > 0.0 0.0 > > mpc_d<05>-E0 35000 13 5.2 > > 0.8 2.7 > > __ibuf_mpc_d<06> 3 4.9 > > 0.0 0.0 > > mpc_d<06>-E0 35000 13 5.2 > > 0.8 2.7 > > mpc_d<01>-E0 35000 13 4.9 > > 0.8 2.6 > > __ibuf_mpc_d<01> 3 5.5 > > 0.0 0.0 > > __ibuf_mpc_d<00> 3 5.8 > > 0.0 0.0 > > mpc_d<00>-E0 35000 13 4.8 > > 0.8 2.5 > > __ibuf_mpc_d<02> 3 5.2 > > 0.0 0.0 > > mpc_d<02>-E0 35000 13 4.8 > > 0.8 2.5 > > ------------------------------------------------------------------------------- > > > > Power improvement guide: > > ------------------------------------------------------------------------------- > > 3 of 101 registers use an enable signal > > ------------------------------------------------------------------------------- > > Signal Power when Power when Power > > savings > > asserted(mW) disabled(mW) at > > 50%(mW) > > ------------------------------------------------------------------------------- > > AddrInCount355/Start-E0 567.1 567.1 0.0 > > > > > > For further suggestions on power improvements see application note no. > > 421 > > > > Analysis completed: Sat Oct 02 16:28:00 2004 > > ----------------------------------------------------------------Article: 74047
Ok I understand...but isn't it better to have a reset for all our flip flop? If something goes wrong - or when I press the reset button...- the controller can always reset everything to zero before we start again... Thanks, David "Ray Andraka" <ray@andraka.com> wrote in message news:415DAEA4.AAFC9B99@andraka.com... > The SRL16 does not have a reset pin on it...ie, you can't clear its > contents in one clock cycle. Your code has a reset in it that clears the > whole shift register, which means it cannot be implemented using an SRL16 > primitive (which costs only one LUT+FF instead of 9). If you can > eliminate the reset on this shift register, then you get a more compact > implementation. Your code would look like this: > > always @ (posedge mclk or negedge resetb) > begin > if (sclkRise == 1) begin > datain[63:1] <= datain[62:0]; > datain[0] <= sdata; > end > if (lrclkRise == 1) begin > leftdata <= datain[63:40]; > rightdata <= datain[31:8]; > end > > end > > David wrote: > > > Hi, > > I'm getting an HDL ADVISOR message when I synthesize this code. > > Basically, it is a big shift register that shift-in data on each > > rising edge of mclk if srclkRise is high, and outputs its data on the > > rising edge of mclk if lrclkRise is high. I don't quite understand the > > advice here. Can anybody help? > > Thanks, > > David > > > > --ADVICE > > INFO:Xst:741 - HDL ADVISOR - A 9-bit shift register was found for > > signal <datain<8>> and currently occupies 9 logic cells (5 slices). > > Removing the set/reset logic would take advantage of SRL16 (and > > derived) primitives and reduce this to 1 logic cells (1 slices). > > Evaluate if the set/reset can be removed for this simple shift > > register. The majority of simple pipeline structures do not need to be > > set/reset operationally. > > > > --CODE > > always @ (posedge mclk or negedge resetb) > > begin > > if (~resetb) begin > > datain <= 0; > > leftdata <= 0; > > rightdata <= 0; > > end > > else begin > > if (sclkRise == 1) begin > > datain[63:1] <= datain[62:0]; > > datain[0] <= sdata; > > end > > if (lrclkRise == 1) begin > > leftdata <= datain[63:40]; > > rightdata <= datain[31:8]; > > end > > end > > end > > -- > --Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email ray@andraka.com > http://www.andraka.com > > "They that give up essential liberty to obtain a little > temporary safety deserve neither liberty nor safety." > -Benjamin Franklin, 1759 > >Article: 74048
On Fri, 01 Oct 2004 07:54:13 -0700, Austin Lesea <austin@xilinx.com> wrote: >30%+ of a Pentium IV is BIST logic I find that very hard to believe. Do you have any references to back up that claim ?Article: 74049
>Ok I understand...but isn't it better to have a reset for all our flip flop? >If something goes wrong - or when I press the reset button...- the >controller can always reset everything to zero before we start again... "Better" is an interesting word. Sure, it's cleaner. How much are you willing to pay for that? If it's just data in a pipeline things will get cleaned out after a few cycles. (May not be true if IIR filters are involved.) Note for example that (most) RAMs don't have a reset pin to clear out the whole array. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.
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