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
"Thomas Entner" <aon.912710880@aon.at> wrote in message news:46014d7e$0$25619$91cee783@newsreader02.highway.telekom.at... > Does this mean, that > XST and/or ISE should not be used for serious work? Unfortunately, there is no way of not using ISE back-end tools when working with Xilinx devices. You can replace XST synthesis with 3rd party, but not map or par. /MikhailArticle: 117001
"Derek Simmons" <dereks314@gmail.com> wrote in message news:1174506809.038963.261740@d57g2000hsg.googlegroups.com... > > They're too busy trying to get QuartusII V7.0 out the door. My > complaint is they just released V6.0 six months ago. What new and > major changes could justify a new version already? What 'changed' is the calendar. For the past several years, Altera's version numbering on Quartus has been the last digit of the year followed by .0 (for the first release in the calendar year), .1 for the next, etc. No, I'm not kidding. Kevin JenningsArticle: 117002
"John_H" <newsgroup@johnhandwork.com> writes: > If a tool is broken, it's good to know from any source. But how > many webcases from "freeloaders" - students or otherwise - are > truely tool errors and not a user issue? (I don't consider students > as freeloaders but acknowledge that the professor should be better > informed as a first resort for problem resolution). It takes time > and effort - real cost to Xilinx - to go through every webcase that > isn't a case at all but instead an issue of understanding the tool > or language capabilities. Not every part of a business is a money making enterprise, so it's a bit of a false argument to claim that they shouldn't accept reports from 'freeloaders' (my word) because it might cost too much money. Yes, that happens. There are all sorts of problems like that; at the company where I work, there are countless hours spent tracking down problems which turn out to be bad RAM in the customers computer. There are countless other hours lost tracking down a problem with the software, to have it turn out they supplied the wrong core file. Generally, it's pretty easy to determine who's reporting a legitimate error, who's trying to get hints on their homework, and who is a newbie, and that doesn't really take much time. This can also be mitigated by having a good front end for categorizing issues the the product: Select product. Select type of problem. If your problem isn't shown in the selection list, then you're in the wrong place. But, what I'm talking about is absolutely legitimate errors: internal crashes with assertion failure information, language constructs which are handled incorrectly -- with simple test programs which demonstrate the error. When the 'freeloader' is willing to do all the work for you, except actually fix the issue, it's pretty cheap to listen. > Why should I expect even an hour's worth of a Customer Application > Engineer's time if the only person benefitting from the time is me? > Not some company I work for now or in the future, not Xilinx, but > only myself. When a legitmate defect is fixed, the whole world benefits. thuttArticle: 117003
Herbert Kleebauer wrote:
> Jim Granville wrote:
>
>
>>What are the prime teaching targets: learning FPGA flows, or
>>learning shematic entry ?
>
>
> Nothing of both. The goal is, to use a handful of FlipFlops and
> gates to implement a design for which you only get the specification.
> It's just a replacement for a prototyping board with many TTL gates.
OK, I understand why you want to keep as much 'visible' as possible.
>
>>Isn't '5 years old', actually new on your time scales ?
>>Get the Atmel tools and try them
>
>
> Atmel only offers a place and route tool. Therefore I asked if
> somebody can suggest a simple to use design software (with
> a schematic entry) for the Atmel FPGA's.
>
>
>>> - has anybody experience with ATMEL's AT40K20 and can suggest
>>> development software (it must be a schematic entry, no VHDL
>>> because the students have to "see" the processor at gate level.
>>
>>What about simpler HDLs, like CUPL or ABEL ?
>>With those, you can 'see' the AND and OR terms ?
>>What about 'seeing' the result in the report files - is that
>>gate-level enough ?
>
>
> That's like a city map which doesn't use graphics but only
> textual description of the street position and connections.
> You will never get a feeling for the layout of the city
> whereas a fast glance on the graphical city map shows you
> all. Sure, if you use one of the modern navigation systems
> you don't need any overview of the city, you are told
> when to turn left or right. This may be is the best way
> if you only want to go from position A to position B,
> but if have to understand how the city is organized, then
> this is completely inappropriate.
Yes, I can follow this SCH thrust, only to a point, so let's look more
closely :
In your Doc, there is a nice block diagram, on page 3.
That's what I used, [and I note it is not actually from Viewlogic]
So, you certainly keep that.
but if I drill down, to your ALU example, I can see 16 blocks, but
they are still macros, and I need to drill further to ADDNOR.
Now, ask the student : "Quick, how many macrocells will the ALU need
in device AAX ? "
Next, look at YGATE or YREG, and in both HDL, and SCH I'd call that
pretty much a tie.
YReg.d = Din;
YReg.ck = CLK;
YReg.ce = s2;
should be clear to anyone, as a CE DFF ?
Next, look at the state engine - and this is where SCH fails badly.
I would not try and duplicate your design from the GATES on p10, but
I would either use the table you give on page 4, and probably paste that
into a CUPL table statement, or I'd use the Boolean equations you have
provided on page 4, and code using those, or I could use a Sequence
state construct.
With state engines, I prefer to make it readable.maintainable, and let
the tools do the packing - they are tricky things, and clarity is
important.
Another advantage of HDL/Boolean eqn entry, is the student WILL have
to read the FIT reports, and the equations in those are ? - yes, boolean
Eqns. So, it is faster/easier to jump between Source in editor, and
report, in the same editor, than Source in SCH XYZ, and report in
separate editor.
Source Code:
YReg.d = Din;
YReg.ck = CLK;
YReg.ce = s2;
YGate = s6 & YReg
# !s6 & 'h'0001;
FIT report
YReg0.C = CLK;
YReg0.CE = s2;
YReg0.D = Din0;
!YGate0 = (!YReg0.Q & s6); /* student exercise: what/why has the fitter
done this ? */
I spend a significant portion of design time looking at the FIT reports,
and I also frequently use multiple constructs, and pick the best one.
$IFDEF VesionCom
Code = here # there;
$ELSE
Code.d = here # there;
$ENDIF
Try that in Viewlogic ? :)
Then we come to tool control: I can feed commands to the fitter, from
CUPL source, - how do you do that from Viewlogic ?
Simulation ?: Also in the same editor. How do you enter/view simulation
data, with Viewlogic ?
>
>
>>>2. Was somebody able to run Viewlogic (DOS version) in a virtual
>>> PC emulation. The problem is, the virtual PC must provide
>>> the proper graphics mode, mouse type and support a physical
>>> dongle on the virtual parallel port.
>>
>>Keys on virtual parallel ports ?! Nope...
>
> Then it should be legal to remove the copy protection from
> the software.
I thought it almost was, in this type of case, in the EU ?
-jg
Article: 117004Update: I figured out that XIo_In/Out weren't compiling in as macros which caused my write to be very slow. However, I've come across another problem. I have a custom peripheral with dma (based on ipif_common_v1_00_d). I need the dma to just write from one address to another address, i.e. no sinc or dinc. This works fine until I transfer more bytes that the burst setting in the peripheral. Then it's clear that the destination address is being incremented and garbage is being written all over the place. I tried to disable bursts as per the note: -- specify the size (must be power of 2) of burst that dma uses to -- tranfer data on the bus, a value of one causes dma to use single -- transactions (burst disabled). -- cep test - disable burst transactions constant DMA_BURST_SIZE : integer := 1; But when I compile it I get the error: WARNING:Xst:821 - "C:/EDK/hw/XilinxProcessorIPLib/pcores/ipif_common_v1_00_d/hdl/vhdl/dma_sg_p kg.vhd" line 127: Loop body will iterate zero times WARNING:Xst:2096 - "C:/EDK/hw/XilinxProcessorIPLib/pcores/ipif_common_v1_00_d/hdl/vhdl/dma_sg_s im.vhd" line 772: Use of null array slice on signal <LENGTH_cco> is not supported. FATAL_ERROR:Xst:Portability/export/Port_Main.h:127:1.16 - This application has discovered an exceptional condition from which it cannot recover. Process will terminate. To resolve this error, please consult the Answers Database and other online resources at http://support.xilinx.com. If you need further assistance, please open a Webcase by clicking on the "WebCase" link at http://support.xilinx.com This is a v4fx12 part under edk 8.2.02. Thanks, Clark "cpope" <cepope@nc.rr.com> wrote in message news:45fe9bf4$0$27083$4c368faf@roadrunner.com... > I have a usb phy chip sitting on my opb_emc. I always have to use XIo_Out > and XIo_In to access. Direct read/write to these addresses doesn't work. My > problem is the access time is 100x slower than it should be. Howdo I get > down to the access time the chip demands (50 ns)? > > Thanks, > Clark > >Article: 117005
RemisN@gmail.com wrote: > On Mar 20, 11:24 pm, Jim Granville <no.s...@designtools.maps.co.nz> > wrote: > >>InmateRemo wrote: >> >>>I've played around with Xilinx PicoBlaze processor, but it's time to step up >>>into 32-bit softcore CPU world for more serious designs, potentially getting >>>in line with embedded OS. >> >>>I am facing a choice, whether to use always up to date Xilinx EDK tools >>>integrated with ISE and MicroBlaze, which comes with good documentation, >>>there is a third party uClinux port. >> >>>The other alternative is using Altium Designer FPGA goodies bag. They offer >>>a wide range of Wishbone compatible cores (no source code though), platform >>>independent primitive libraries, a choice of few softcore processors >>>including 32-bit RISC core TSK3000, and even support for the same >>>MicroBlaze, but I've noticed that supported version is a bit behind. >> >>>Currently I am considering Altium route as it brings more value to the >>>table, providing vendor independence, but at the same time I would entirely >>>depend on Altium continuous support towards FPGAs. >> >>>I would appreciate if anybody could share a similar experience or thoughts. >> >>Aren't these two mutually exclusive ?! >>"(no source code though)" >>and >>"providing vendor independence" >> >>ie, with no source code, you have just locked yourself into vendor >>Altium - surely a crazy thing to do ? >> >>If you like vendor independance, then look at Lattice Mico8/Mico32, >>which are open source. >> >>-jg > > > Yes Lattice Mico8/Mico32 are open source, but can you really use them > anywhere else except only with Lattice ISP Lever and Lattice FPGA > devices??? Look at their web site. Open source means that. > > Yes, seems like Atlium has invested heavily into FPGAs, leading EDA > industry with seamless integration, and having schematics, layout, > FPGA code as well as C/C++ code for softcore CPU all integrated into > single environment does bring benefits to the design team. And I am > sure Altium will support this vision as long as it brings cash on the > table. Is that an Altium user talking, or the PR spin on a sales brochure ? -jgArticle: 117006
On Mar 21, 1:15 pm, Rem...@gmail.com wrote:
Hi all,
> Yes Lattice Mico8/Mico32 are open source, but can you really use them
> anywhere else except only with Lattice ISP Lever and Lattice FPGA
> devices???
Yes, you can.
I'ts running on my Spartan-3E starter kit and I'm currently porting it
over to the
Altera Cyclone-II Starter kit.
I don't have it integrated into the Eclipse IDE Lattice is shipping --
but at least I've
got the CPU running in my own wishbone based SOC.
Having the source for all components available feels quite good for
me. And it's cross-platform.
I won't go back to MicroBlaze in the foressable future.
j.
Article: 117007On 21 Mar, 15:58, "Daniel S." <digitalmastrmind_no_s...@hotmail.com> wrote: > ZHI wrote: > > I have to generate a block ram in xilinx. The data width is not fixed > > and it will be changed according to the requirement of project. I have > > noticed that the data width in the block ram has been designed to be > > the 2's exponential size. Sometimes the data width I needed was not > > exactly the 2's exponential size. Is there a way to make the data > > size not the 2's exponential size exactly? Like 18bit width. > > Available widths are 1,2,4,8,9,16,18,32 and 36bits - 9, 18 and 36bits > widths are achieved by using parity bits. > > To achieve high speeds and and area efficiency, BRAMs are built as SRAMs > and come with similar row-column organization that places some restrictions > on how freely bits can be accessed. If you use 8, 16 or 32 bits, you waste > the parity bits. If you use 9, 18 or 36bits, you can use every bit within > the BRAM. For any other width not listed in the first paragraph, you will > be wasting bits up to the next widest width. -------------------------------------------------- Thanks. But Xilinx2P doesn't support this function, does it? I found it in Xilinx-4/5Article: 117008
Austin Lesea wrote: > Thomas, > > It is up to you. After you read the FAQ sheet, and the quote: > > "Xilinx uses XST as a proving ground for many of the innovative > optimization ideas that Xilinx engineers have for improving HDL design > flows for Xilinx devices. These improvements are then shared with Xilinx > third party synthesis partners to ensure that anyone targeting Xilinx > FPGAs as their solution can benefit from the best optimization the > industry has to offer." > <snip> > as right there in the FAQ it states that it > is not a 100% complete tool (recognizing all possible elements and > constructs). No, you've lost me - _where_ does it state it is not a 100% complete tool ? and where does it state that you are dreaming if you expect "XYZ to synthesize correctly in XST" ? What you are saying may well be Xilinx corporate policy, and the WEB merely the PR spin of the nastier reality, but it is hard to believe a company would be that short sighted. No one from the XST SW team has commented yet - well, at least not on this forum/thread ;) -jgArticle: 117009
mtsuka...@gmail.com wrote: > Working with a coolrunner2 CPLD. Is there a way to erase whatever has > been programmed into the CPLD, without using JTAG? Unless you're storing crytographic keys in the CPLD, what's the point of erasing it without using JTAG? Dave Pollum wrote: > As far as I know, the only way to erase/program Xilinx CPLDs is via > JTAG. For erasure, thermite works too. A hammer may work but is not as certain.Article: 117010
On Mar 21, 2:59 pm, "MM" <m...@yahoo.com> wrote: > "Thomas Entner" <aon.912710...@aon.at> wrote in message > > news:46014d7e$0$25619$91cee783@newsreader02.highway.telekom.at... > > > Does this mean, that > > XST and/or ISE should not be used for serious work? > > Unfortunately, there is no way of not using ISE back-end tools when working > with Xilinx devices. You can replace XST synthesis with 3rd party, but not > map or par. I have a sneaking suspicion that whoever manages Xilinx's programmers is aware of that fact, and allocates resources accordingly...Article: 117011
"Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message news:46019d62$1@clear.net.nz... > > No, you've lost me - _where_ does it state it is not a 100% complete tool > ? and where does it state that you are dreaming if you expect > "XYZ to synthesize correctly in XST" ? > > What you are saying may well be Xilinx corporate policy, and the WEB > merely the PR spin of the nastier reality, but it > is hard to believe a company would be that short sighted. > > No one from the XST SW team has commented yet - well, at least not > on this forum/thread ;) > > -jg Reality is that Xilinx tries to be 100% accurate and complete. Even mainstream synthesizers can't guarantee 100% for everything even if they have tried to achieve that goal. XST will probably not produce intustry-best Quality of Results since it's not their focus. They will not support all new language features *as quickly* as mainstream synthesizers because that's not their focus. If you want optimizations based on pipelining in inferred multiplers, chances are they DO have good support because their focus DOES appear to be the support of new technology elements. I have heart that XST's VHDL is lagging behind Verilog in robustness, probably a main driver behind the extreme opinion of the free tool that started this thread. I like that XST is available. I use SynplifyPro to have a stable, well supported design flow geared towards solid QoR. If I come across issues using XST - at home, for instance, where I don't have Synplicity tools - I expect to work around those issues as I work around all other bugs. If I came across a synthesis problem in SynplifyPro, I'd feed back to the CAEs what the issues are. For XST I'd tend to work around the issues myself and not bother the company that supplies us with 10s of thousands of FPGAs each year. Yes, the synthesis tool could use improvements. It's just not their focus. - John_HArticle: 117012
Jim, I quote: "Q: How extensive is XST language coverage? A: With each release, XST is closing in on the de facto coverage set by other synthesis tools. Xilinx estimates the current language support covers at least 95% of the constructs supported by other synthesis tools. Many of the unsupported constructs are infrequently used or have simple work-arounds. Also, many of these constructs are not handled consistently by each synthesis tool. For example, one tool accepts a construct in one way, another tool accepts the construct in a different way, and a third tool flags a parsing error. In some cases, XST is more precise than other tools, and requires exact, complete descriptions while other tools accept incomplete or vague code. These are common considerations when moving code from one synthesis tool to another." This was written in 2001, and I am told that we are much better now, but still not 100% of what is covered by the commercial tools. As for the software group, they have contacted me. And we have talked this over. They are very proud of their tool, and find this thread troubling. They would not characterize their tool as "experimental," but as a world-class synthesis tool, examining limitations that other tool vendors have. Their tool provides value to many (most), and is probably more widely used to synthesize logic from HDL than any other tool. AustinArticle: 117013
Thanks for the link! I think I'm mainly looking to be at a point where I would feel comfortable doing some initial timing analysis on an FPGA I/O interface such as SPI-4 or DDR2, or perhaps something system synchronous. Do you know of any detailed examples of where this might be done so I can get a feel for it? I'll leave most of the internal analysis to the software tools I think. =)Article: 117014
Taylor, In a previous position at Xilinx , I provided customer support for four years. I agree that with enough experience, you get a feel for who is a student, who is coming to you without doing due diligence on their given issue and those who have. Never, do we put less emphasis on an individual using WebPACK as those who have paid. Granted we do not support students, but they do have resources through an MIT forum to obtain assistance. I will even go as far as saying that we take the 'small' guys problems as seriously as the 'big' guys (at least I did). You are correct that everybody benefits from submitting a case and supplying a simple testcase that exhibits the crash, error, bogus warning, etc. This is the only means that we have to reproduce the problem for SW developers. Sometimes it turns out to be bad RTL and sometimes it is a bug on our end. I used to meet weekly with the FPGA Editor developers and can say that they took bugs very seriously. We were generally able to provide a workaround or tactical patch for a customer. That said, XST is a much different and a more complex tool. While I have not worked with any of the developers directly, I have been on the sidelines and can say that they take bugs in their tools seriously too. So while you may get frustrated (and perhaps with good reason), I would encourage you to send those Web cases in and keep the test cases coming. -David "Taylor Hutt" <thutt151@comcast.net> wrote in message news:m3r6ripdal.fsf@localhost.localdomain... > "John_H" <newsgroup@johnhandwork.com> writes: > >> If a tool is broken, it's good to know from any source. But how >> many webcases from "freeloaders" - students or otherwise - are >> truely tool errors and not a user issue? (I don't consider students >> as freeloaders but acknowledge that the professor should be better >> informed as a first resort for problem resolution). It takes time >> and effort - real cost to Xilinx - to go through every webcase that >> isn't a case at all but instead an issue of understanding the tool >> or language capabilities. > > Not every part of a business is a money making enterprise, so it's a > bit of a false argument to claim that they shouldn't accept reports > from 'freeloaders' (my word) because it might cost too much money. > > Yes, that happens. There are all sorts of problems like that; at the > company where I work, there are countless hours spent tracking down > problems which turn out to be bad RAM in the customers computer. > There are countless other hours lost tracking down a problem with the > software, to have it turn out they supplied the wrong core file. > > Generally, it's pretty easy to determine who's reporting a legitimate > error, who's trying to get hints on their homework, and who is a > newbie, and that doesn't really take much time. > > This can also be mitigated by having a good front end for categorizing > issues the the product: Select product. Select type of problem. If > your problem isn't shown in the selection list, then you're in the > wrong place. > > But, what I'm talking about is absolutely legitimate errors: internal > crashes with assertion failure information, language constructs which > are handled incorrectly -- with simple test programs which demonstrate > the error. When the 'freeloader' is willing to do all the work for > you, except actually fix the issue, it's pretty cheap to listen. > >> Why should I expect even an hour's worth of a Customer Application >> Engineer's time if the only person benefitting from the time is me? >> Not some company I work for now or in the future, not Xilinx, but >> only myself. > > When a legitmate defect is fixed, the whole world benefits. > > thuttArticle: 117015
No, this is not the official Xilinx position. XST is critical to our business and we have a strong, dedicated team working on it. In addition, there are tens of thousands of happy customers using XST in real designs. We work very closely with our Synthesis partners (Synplicity and Mentor) and usually recommend that customers have access to more than one synthesis tool because no one tool works the best for all designs. Yes, we realize that there are some language support issues and we are working on addressing them. Most have pretty easy workarounds and the ones that don't get prioritized higher for being fixed. The web page Austin refered to is at least 5 years old and I am personally going to make sure it is changed to reflect our current position. Regarding why students cannot enter webcases, I believe this the main reason: We are using the professors to filter out bad coding techniques and questions like how do I create a state machine or how do I design a chess game in an FPGA. Steve "Thomas Entner" <aon.912710880@aon.at> wrote in message news:46014d7e$0$25619$91cee783@newsreader02.highway.telekom.at... >> In other words, XST is a test vehicle where we are intentionally >> experimenting, in order to improve. > > Hi Austin, > > is this your personal meaning, or official Xilinx? Do the > Xilinx-software-team see their work in this context? Does this mean, that > XST and/or ISE should not be used for serious work? > > Thomas > >Article: 117016
Michael,
9.1i Service Pack 2 has around a 20% memory reduction so you might try that.
For larger FPGAs, we recommend 64bit Linux systems.
Steve
"Michael Schöberl" <MSchoeberl@mailtonne.de> wrote in message
news:46011575$1@news.fhg.de...
>> I'm going to work on a Virtex 4 FX100 soon so I'll
>> need all the horsepower I can get for the P&R runs...
>
> I've been working on a Virtex4 LX100 design early this
> year and the main problem was memory usage. I upgraded
> my Windows XP Box to 4 GBytes (and patched to allow
> 3 GBytes/process) and even that was not enough!
>
> Above something like 55% Lut/FF usage par 8.2 failed
> ("out of memory") after 2 hours or more.
>
> I wonder how it should be possible to work with
> even larger FPGAs!?
>
>
> bye,
> Michael
Article: 117017I don't know of a comprehensive resource exists (if someone else does, please share!) There are some Xilinx application notes that discuss it; most are very specific to a particular interface. This is the most general I could find: http://www.xilinx.com/bvdocs/appnotes/xapp259.pdf I also stumbled across this, which I found interesting reading: download.intel.com/education/highered/signal/ELCT762/Class03_Signal_Parameters_II.ppt Eric <FPGAEngineer@gmail.com> wrote in message news:1174515000.274989.98920@n76g2000hsh.googlegroups.com... > Thanks for the link! I think I'm mainly looking to be at a point > where I would feel comfortable doing some initial timing analysis on > an FPGA I/O interface such as SPI-4 or DDR2, or perhaps something > system synchronous. Do you know of any detailed examples of where > this might be done so I can get a feel for it? I'll leave most of the > internal analysis to the software tools I think. =) >Article: 117018
Have you seen or used the inferred RAM/ROM in the Xilinx Toolbox? "ZHI" <threeinchnail@gmail.com> wrote in message news:1174471565.885982.284820@y66g2000hsf.googlegroups.com... >I have to generate a block ram in xilinx. The data width is not fixed > and it will be changed according to the requirement of project. I have > noticed that the data width in the block ram has been designed to be > the 2's exponential size. Sometimes the data width I needed was not > exactly the 2's exponential size. Is there a way to make the data > size not the 2's exponential size exactly? Like 18bit width. > > Thank you. >Article: 117019
Sorry for the delayed response -- I just got off the phone with the fruit basket place ;-) We've released new versions of the Quartus II software at least twice per year for quite a while now. As Kevin correctly observed, our version numbers happen to line up with <last_digit_of_year>.<major_release #>. Each major release of the software incorporates new features in a variety of areas. Here's a partial list of major features in the past couple of releases: QII 7.0: Cyclone III device support, including TimeQuest Timing Analysis and PowerPlay Power Analysis and Optimization. QII 6.1: Stratix III device support. Multi-processor support (parallel compile). Chip Planner tool. Advanced I/O Timing (I/O + board trace timing & signal integrity). Mjor GUI changes, including dockable windows. QII 6.0: TimeQuest Timing Analyzer. Project Manager Interface. In addition, we're constantly changing the synthesis, placement and routing algorithms "under the hood" that optimize the quality of results for your design. This affects the critical path delay, dynamic and static power, and density (# of LEs required) of your design, as well as compile time and memory footprint of the software. And of course, we're fixing bugs, updating timing models, adding support for device features, adding assembler support, adding new OSes, etc. We release "Service Packs" of the software between major releases to more frequently roll out these sorts of changes. So if you don't care about Stratix III or Cyclone III devices, don't want faster & better compilation results, don't need to interface with a PCB, and aren't hitting any bugs that affect your design, there's no reason for you to move to QII v7.0. However, the migration experience is fairly painless, and you may find yourself liking some of the new features you can by migrating. Regards, Paul Leventis Altera Corp.Article: 117020
It is important not to muddle things here by mixing dynamic power,
static power, and I/O power. All of these are important, but it's
much cleaner to compare things separately. I will also focus on
Spartan-3E, since Virtex-5 is in a different weight class and
(justifiably) burns a ton of power in comparison.
*** STATIC POWER ***
The below table compares the two families at 85C junction temperature,
for typical static power. As you point out, we do not have publicly
available worst-case power specs. These are available upon request
(by customers ;-)) and will be released generally when the family
enters production status in a few months. In the meantime, I assure
you our typical -> worst-case multiplier is in the same ballpark as
that of Spartan-3E and should be a non-factor in this comparison.
Typical # of Block RAM 18x18
Static @ 4-LUTs (Kbs) Mults
85C or FFs
XC3S100E 0.037W 1920 72 4
XC3S500E 0.098W 9312 360 20
XC3S1600E 0.249W 29504 648 36
EP3C10 0.048W 10320 414 23
EP3C25 0.086W 24624 594 66
EP3C80 0.135W 81264 2745 244
EP3C120 0.172W 119088 3888 288
At similar density (1600E vs. 3C25), that's 1/3 the static power. Or
looking at the 1600E vs. 3C120, that's 30% lower static power for 4x
the LUTs & FFs, 6x the RAM, and 8x the multipliers. Not bad.
*** DYNAMIC POWER ***
Dynamic power is much harder to compare. The Altera Early Power
Estimator and the Xilinx XPower Estimator both cannot model "worst-
case" dynamic power. They model the typical case. Dynamic power does
not vary much with process (die-to-die variation), however it varies
considerably with the exact implementation of the design and the
vectors applied. All we can hope is a user does their best to guess
the vectors (which turns into toggle rate), and we must do our best to
represent the typical design.
For example, we must pick *one* number that represents the power of a
LUT as a function of the % toggle of its output. However, the power
will vary by the LUT mask (function implemented), as well as the
amount of routing (= capacitance) hooked up to the LUT output.
I know how the Altera EPE is made. We take 100+ designs, compile them
in Quartus (which is correlated to silicon/simulations), and figure
out the average amount of routing that dangles on the output of LUT.
That's what we put in the EPE. Some designs will be worse than this,
some will be better, but it is after all an estimate. For example,
the routing power ascribed to a FF in the EPE represents roughly a C4
+ R4 wire.
Not to pick on the XPE, but it has some dubious results. If I enter
10000 FFs @ 300 Mhz, I get 0.189W. But this doesn't change with the
fanout -- I would think there should be more routing power? If I
change toggle rate from 12.5% to 25%, the power stays at 0.189W.
Strange. And if I reduce the number of FFs to 1, power drops to 0 --
is there no clock in the chip?
That said, let's look at the estimates for a variety of logic types
according to the EPE vs. XPE:
S-3E C-III
10000 LUTs, 10% Toggle, 200 Mhz 0.229W 0.080W
10000 FFs, 10% Toggle, 200 Mhz 0.126W 0.111W <--
Suspicious XPE FF power
50/100 Simple Dual-Port 16-Bit RAMs,
200 Mhz, 50% enable & R/W rates 0.264W 0.129W <-- 50 BRAMs,
100 M9Ks
100 18x18 200 Mhz 50%/"medium" toggle,
registered multipliers 1.848W 0.346W
Looking good for CIII. Of course, that shouldn't be too surprising --
65 nm = smaller transistors & wires = lower capacitance. And Cyclone
II already had considerably lower power than Spartan-3E.
*** I/O POWER ***
I/O power is largely a function of the drive strength of the buffer
and the load / termination network connected to it. Pin capacitance
differences aside, I/O power should be similar between the families,
so I won't bother crunching the numbers.
> For example, the "maximum" value for Spartan 3E goes from .85W to about
> 1 watt. At least that is a guaranteed value for the worst case power
> one could get.
Careful -- you're only guaranteeing the static power portion of the
power estimate. It increases for the XC3S1600E from ~0.249W to 0.386W
@ 85C Tj. The dynamic power portion of the estimate is not a worst-
case bound, as discussed above. I wouldn't want people getting the
wrong idea!
Regards,
Paul Leventis
Altera Corp.
Article: 117021Forgot one thing... > but then the RAM adds a very tiny value to power. Actually, in my experience RAM is one of the largest contributors to dynamic power. Why is that? As HDL designers, none of us really think of shutting off things we don't care about. We just don't do anything with those signals. RAMs are usually a good example of this. Most people don't turn off their clock and/or read enable signal when they don't need the value of a RAM in a given cycle. The result is that the RAM toggles "100%" of the time -- even if you are reading the same address on consecutive cycles. Internally, the RAM must precharge and discharge all the (differential) bit lines on each access, resulting in a large dynamic power draw. The PowerPlay Power Optimization feature of Quartus II helps mitigate this by automatically disabling RAMs when it can. There's a good paper from Transactions on CAD on some of the techniques we use (http://www.ecs.umass.edu/ece/tessier/tcad-rampower.pdf). I've seen some pretty neat results on customer designs. Regards, Paul Leventis Altera Corp.Article: 117022
On Feb 16, 4:30 am, "Peter Alfke" <p...@xilinx.com> wrote: > On Feb 14, 9:59 am, "jetq88" <jetq5...@gmail.com> wrote: > > > goto Xilinx > > and check MIG tool, nowhere to download MIG tool for ISE9.1. guess I > > have to use old tool, then import to ISE9.1 and tweak it by myself. > > In late February Xilinx will release the newest MIG1.7 that works with > ISE9.1i . > Peter Alfke It's now late March but still no sign of MIG1.7. This is starting to get silly.Article: 117023
On Wed, 21 Mar 2007, John_H wrote: >> NET "clkp" TNM_NET = FFS(*) "clkp"; >> TIMESPEC "TS_clkp" = PERIOD "clkp" 3.8 ns HIGH 50 %; > > Get rid of the FFS(*) and see what happens. > > The BlockRAM specifically needs RAMS(*) if you're trying to keep other > elements such as multipliers and latches off the timing specification. I > usually end up with something like > > NET sysClk TNM_NET = sysClk; > > to specify my main clock. In this syntax it applies to all sequential > elements. John, Thanks a million! Of course that was it, now everything runs fine up to 325 MHz. And my earlier (working) version did not have FFS(*). That is what happens when you try to get rid of unimportant warnings :( -- Dmitry TeytelmanArticle: 117024
On Mar 21, 8:19 am, patrick.me...@dmradiocom.fr wrote: > hi, > > I have a design with two clock that I want to mux toward a single > clock like this > > with mode select CLK <= > CLK_1 when mode_1, > CLK_2 when mode_2, > CLK_1 when others; > > Is there another manner to do this because Quartus says that CLK is a > gated clock ! > > thanks Assuming you are not switching clocks at any random time creating some undesired pulse in the output of the MUX, or that if you do, you are resetting the whole circuit after switching clocks, you can simply ignore the warning. We give you a warning because the Timing Analyzer does not know if this was intended or not, but we know this can create a static hazard. But you are the designer and know better if this is safe or not based on your intended behavior. Note that the Classic Timing Analyzer will assume four domains when computing slack: CLK_1->CLK_1 CLK_1->CLK_2 CLK_2->CLK_1 CLK_2->CLK_2 Simply add the following two QSF assignments to cut the cross-clock domains (again, assuming all registers are clocked by the output of the MUX): set_instance_assignment -from CLK_1 -to CLK_2 -name CUT ON set_instance_assignment -from CLK_2 -to CLK_1 -name CUT ON Hope that helps, - David karchmer Altera Corp.
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