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
"Sylvain Munaut" <tnt_at_246tNt_dot_com@reducespam.com> a écrit dans le message de news: 42125d33$0$311$ba620e4c@news.skynet.be... > Jonathan Dumaresq wrote: >> yes i con buit it too.. >> >> >> When I look at the system.pbd, I expected to to see a new bus for the wb. >> But i did'nt see it. I don't know if we need to see it or not. > > No you won't see a new bus. This wrapper just export all wishbone bus > signals as port. Then you need to connect them manually. hi, I have beeen able to generate the netlist with the gpio of opencore. But as you said, the wrapper doesn't connect them together directly. I don't know if there is a easy way to plug it together intead of playing with the generated file from xst ? I have some problem with the include verilog file. for now i have put the content of the included file in the top file to get the netlist to work .. Is there a simpliest way to make included verilog file pass to the netlist generator ? regards Jonathan > > >> But i see that the wrapper is connected to the opb bus as a slave. > > Yes, the opb2wb wrapper translate OPB access to WishBone access. So it's > an OPB Slave and a WishBone master. > >> The other question that i have is how to built a edk-core compatible with >> verilog file ? >> >> As i can see ther is only the vhdl file that can be use to make an edk >> core compitible. >> >> so if anyone have any idea of what we have to do to plug a simple >> wishbone GPIO connected to opbbus via the wrapper.... > > Just use the wizard and you can use a verilog design. But AFAIK, you can't > easily use a mixed verilog/vhdl ... > > > SylvainArticle: 79226
Falk, Good point, but I will grant that if they post a scope picture, I will very likely believe it. Austin Falk Brunner wrote: > "Austin Lesea" <austin@xilinx.com> schrieb im Newsbeitrag > news:cutibd$baf1@cliff.xsj.xilinx.com... > >>Paul, >> >>OK. I'll reserve my judgement until I see the scope pictures. > > > You believe in scope pictures in the age of Photoshop?? ;-)) > > Regards > Falk > > > > >Article: 79227
The LUT RAM (which came before the SRL) uses SR instead of CE for its write enable to allow packing a RAM and an FDE together in the same slice without forcing the RAM's WE to be tied to the FF's CE. When the SRL16 feature was added, its implemenation used the same basic "write" circuitry, so its CE became the same pin as the RAM's WE, namely SR. Thus, if you'd like to have an SRL driving a FDRE, you'll have to place them in different slices, as one poster already suggested. As for ALTDIG driving SRLs... The LUT you see in FED is an abstraction. In silicon, there actually exists no path from the ALTDIG to the SRL's data input, nor is there a path from ALTSIN to the LUT RAM's data input. One other point... the REV pin on the FFs should not be used without also using the SR pin. Using the REV pin to reset your FF while using the SR to do something unrelated (i.e. SRL CE) doesn't work. Regards, Trevor Bauer XilinxArticle: 79228
John, Thanks for your posting. A very few comments below. Austin John_H wrote: > Austin, > > You railed against Altera and your comments on the tool and their parts were > obscured by the sheer volume of sarcasm. Maybe if I knew you, I'd take > extreme sarcasm as appropriate critique; I just wasn't brought up that way. OK, fair enough. I have been told that my 'style' is a mystery to some. I am working on it. > > There are those who believe triple oxide is the way to go. We see some benefits: low leakage for memory and interconnect, higher speed for interconnect, better SEU FIT rate (lower) for memory.... There are those > who believe low-K dielectric is golden. We'd love to have lo-K! But our fabs (yes, plural) could not meet our reliability goals for qual. So we ended up pushing the Vt's to get back the speed we lost, and paid for it with slightly increased leakage in V2 Pro. In V4, we don't need lo-K to get the speed we needed. There are others in the industry > stepping away from low-K because they see a path to 65 nm and beyond without > the need for the exotic materials. As it turns out, we can now have lo-K, and have it committed for 65nm. They finally got it working to our requirements. As with politics and religions, there > are data to back up the claims by both camps, not just "I'm right, you're > stupid." Well, I would NOT say they are stupid, as they have explained why they made their choice: triple oxide was considered too much of a risk at their fab at the time they did their design. For us, lo-K was considered too risky. You do not get to choose, the fab chooses for you. > I find it difficult to ignore "attacks" from any vendor. I've been > primarily using Xilinx devices over the last decade having first cut my > teeth on the Altera devices. Thank you. I prefer brand X because of problems I had > getting appropriate I/O performance on brand A as little as 5 years ago. > For me, brand X was a superior technical solution for my needs. I hope we can continue to show that our offering meets your needs. I am sure that Altera can also make a decent showing to meeting your needs, as well. In no way are their parts "bad" or "slow" -- they are a serious competitor with a competitive offering (to our Spartan, Virtex 4 LX and SX families, although I would state that we have no competition to the FX family .... yet). I don't > like to see anyone "disrespecting my parts" out of spite nor do I like to > see someone in "my camp" producing a virtually useless discourse on how much > the competition lies and cheats. Paul does not lie. He does not cheat. I did not say that. If you read our postings carefully, you will note that he, and I, are very very careful about what we post. When they ran their benchmarks, they saw a speed improvement. When we run our benchmarks, we see a speed improvement. When I run our power predictor spreadsheet, I see an improvement. When Paul runs his, he sees an improvement. The devil is in the details: is a static power reduction at 25C an improvement? Yes, and No. Is comparing our middle speed grade with their fastest honest? Well, if that is the only thing they can get their hands on, perhaps it is. Would it be better to compare their slowest with our slowest? Who would be excited about that? > > If someone believes in their product - or religion, or politics - I don't > mind listening to their discourse when it's not offensive. When their > message degrades to mud slinging and name calling - as it appeared to be > when an Altera marketing VP posted here several months ago - it brings the > whole forum down a notch or two. > > It appears Altera's power estimators have some bugs. > It appears Xilinx hasn't published worst-case numbers on all power figures. True. We have not finished all characterization. Our FAEs have the present worst case numbers for customer design, but we prefer to let them cool a little longer. Use Web power to 85 C junction temp and multiply by 2.5 to get worst case (for now, until we release the finals). Even then, we are still up to 70% less leakage. > It appears Triple Oxide is a win for Xilinx. Yes. 70% better worst case leakage is big. SEU improvement is good. Speed is good. > It appears Low-K is a win for Altera. 5% less C, means 5% less core power, and ~5% more speed over regular K. All good. > It appears that most marketing messages are more politics and religion than > fact. Sadly, true. > It appears Engineers on both sides of the camp believe their marketing. Yup. But I get to tell marketing what numbers to use, before they use them. I don't know if Paul is also the manager of their characterization group. > That's fine. > > It appears I get annoyed when people turn argumentative for the sake of > argument. > > I've been a hardware engineer at Xerox Corp since '99 - john dot handwork at > office dot xerox dot com - and use my home email to limit spam. There's > typically no reason for my work email on this forum. I made Telecomm test > equipment at TTC (Telecommunications Techniques Corp, now Acterna) in > Germantown, Maryland for a dozen years before switching to color laser > printers here in Wilsonville, Oregon. FPGAs are my daily work. Cool. I bought and used TTC test equipment in my 23 years as a telecommunications transmissions system designer before I was reincarnated as an IC Design Engineer. Great equipment! > > Thanks for your continued contribution of useful information. I appreciate > all the folks on this board that help expand my horizons with respect to > FPGA design. You are welcome. I don't want (you) to be sorry about respecting my field. > > - John Handwork > > > "austin" <austin@xilinx.com> wrote in message > news:curnam$baj2@cliff.xsj.xilinx.com... > >>Well, >> >>John, the issue is "what is the leakage current of the new 90nm >>technology node?". >> >>Xilinx has claimed (and we think we have proved it) that the use of >>triple oxide (basically keeping memory cells and pass gates at 130 nm in >>90nm) gives us both speed, and a 3X leakage advantage. Not to mention >>an SEU advantage (we haven't even started on that weakness in the >>competition, yet). >> >>They claim that their simpler process is more cost effective (? where >>are the $ quotes ?) and more producable (we are both shipping), and have >>similar or better leakage, and better speed. >> >>These claims are false. Physics is physics. No smoke and mirrors 6 lut >>is going to work. >> >>They may have solved the surge issue, but we have yet to see any parts >>where that is true. It is also true they do not make it easy for Xilinx >>to buy their parts. We are oblidged to pay for them like any customer, >>so there is a fair and level playing field. So we admit we may not >>have seen their fixed parts. Have you? >> >>The engineering community is a group of very well educated professionals >>who deserve to know what is going on. Most of them have a sense of >>humor, and appreciate the banter, some do not. If you are one who does >>not appreciate my postings, please ignore them. >> >>If you objected to the tone of my posting, I am very sorry: I can't >>help it when I see such total nonsense being presented (IMHO). >> >>If the gentlemanly thing to do is to respond in a "proper" fashion (in >>your humble opinion), then I will leave that to others, as I am not >>going to live long enough to tolerate such nonsense. Life is far too >>precious to me to waste. Perhaps if you knew me better you would >>understand. Since you do not, please feel free to ignore me. >> >>Again, my intent is to say it like it is, and not to gloss over the fine >>points, as it is the fine points that leave customers' systems broken >>and worthless. >> >>Let me know what you are objecting to specifically: the truth of the >>matter, or the tone I take. I can and do apologize, and I am able to >>learn, grow, and change. >> >>austin@xilinx.com >> >>Austin >> >>PS: from the raw message, I can not see exactly where (or who) you are. >> I respect that, as I too am inundated with spam, and I understand you >>wishing to avoid that. > > > <snip> > >Article: 79229
Is there anyway to know synplify_pro version through tcl command or variable? Since its 8.0 has some major difference than old version in false path constraints. I just want to load those automatically generated constraints if synplify_pro version is greater than 8.0. thanks, PeiArticle: 79230
The power-on glitch is not something you can wish away, or spirit away with processing tricks. It only goes away when the designer really understands the issue, and does something clever and thorough to eliminate the current spike. We did that about 6 years ago, eliminated the spike in Virtex-II and all later FPGA designs (including Spartan-3). So, if Altera says they got rid of it, let's assume that they finally found the right way to design (or redesign) their chips. Welcome to the club of spike eliminators ! What an ugly problem it was... Peter AlfkeArticle: 79231
Austin Lesea wrote: (big snip) > The devil is in the details: is a static power reduction at 25C an > improvement? Yes, and No. Is comparing our middle speed grade with > their fastest honest? Well, if that is the only thing they can get > their hands on, perhaps it is. Would it be better to compare their > slowest with our slowest? Who would be excited about that? I wonder what fraction of FPGA designs are not very speed sensitive. I used to wonder about that in TTL days, building digital clocks (60Hz for the fastest signals) out of 30MHz TTL chips. Many designs could easily only require on half or one tenth of what current FPGAs are capable of, and still be worth putting in an FPGA. For those, the slowest devices, especially with lower static power, might be very useful. For the most part, I don't find this discussion very useful. We all know about marketing departments, and having engineers argue this doesn't cause me to look favorable on their company or products. -- glenArticle: 79232
Antti, if I read your message correctly you have two seperate problems: 1. You cannot configure the FPGA using an ACE file. 2. You cannot access the DOS partition on your CF card to load image.bin The first problem might be caused by the TDO tristate errata on some LX25 -ES samples. Whether you do or do not see the problem depends on many factors one of them the order of the devices in the JTAG chain. What devices and in what order are your devices in the JTAG chain? Is the ACE file generated with the correct parameters, i.e. how do you generate your ACE file? If you look at (intermediary) SVF files you will see that they consist of a data shifted out on TDI and bits shifted in on TDO. The bits shifted in on TDO are then compared against a mask. If the mask and the TDO bits do not match System ACE CF will stop and generate an error. As a quick test you can remove the TDO part from the SVF file and use impact to generate an ACE file. With that you disable the error checking, i.e. you blindly shift the data into the FPGA. I'm not sure what causes your second problem. - Peter Antti Lukats wrote: > Hi > > has any one some hints or tips how to get an Virtex4 LX25-ES configured from > SystemACE? > we can configure from iMpact and if we load the uclinux kernel from XMD it > works too. > but now when I try to load the uclinux image from CompactFlash then there > are problems > if the FPGA is configured by impact then there will always be random sector > read errors > when attempting to load the image.bin from CompactFlash. On ML300 I had to > load from > CF in order to access the CF, but with V4LX the FPGA config from > CompactFlash doesnt > seem to work, the status led blinks once and then the error led goes on. I > assume it is the TDO > tristate problem with -ES samples, but... > > ML401 has systemACE as well and that works! So whats the trick ?? > > Antti > >Article: 79233
I'm using Verilog under Quartus 4.1sp2 to build a model of a custom part that has 25 identical (more-or-less) sub-modules, each with a small rom. Working bottom-up I built and tested the submodule: no problems. I used the wizard to build the rom code, specifing a .hex file for initialization. I then created the top module with the 25 instances of the rom, but could not find any way to specify 25 UNIQUE .hex files for the roms. An Altera service request was not helpful except to get to the essence of the problem. Then I built a 4 sub-module test model, and, by hand, created 4 differently named copies of the rom module, renaming the .hex file specified in it. That worked, but there has to be a simpler way! Question 1: what is it? Some of the sub-module's outputs, connected only to other sub-modules, are the inverted contents of a register. I got the correct values for the sub-module test, but the inverters were 'hidden' by synthesis, even when I specified 'firm' hierarchy boundaries. The execution of the custom part assumes the inversion, and I've got to include it. Question 2: How? Thanks, JohnArticle: 79234
Austin Lesea wrote: > Falk, > > Good point, but I will grant that if they post a scope picture, I will > very likely believe it. There is a 'sort of scope picture' showing startup currents here http://www.altera.com/products/devices/stratix2/features/st2-competitive.html does that count ? Better (closer to the real world) would be scope ramp up _AND_ ramp down on an operating FPGA - from both suppliers, of course :) - that way they get to choose the design that makes their dynamic operation look the best. [ maybe there is a dV/dT that looks best on inrush too ? ] Of interest is if the inrush is purely cap modeled (non clamping) or if it is the stalling clamp type, where a current limited supply can freeze at some point up the inrush mountain ( and a fold back supply may be completely the wrong solution ! ) -jgArticle: 79235
i like this 'great' flexibility in FPGA. In this context, i dare to make more 'what if' questions (to me, to others).... What if we have 2 microblazes (uBLAZE0, uBLAZE1) with BRAM0 and BRAM1, respectively. Suppose BRAM0 ranges 0x00000000 - 0x00003ffff and BRAM1 ranges 0x00004000 - 0x00007ffff. The uBLAZE0 wanna access BRAM1 using shared variable so that programmar see 2 BRAMs as one big global memory. Then problem will be bus ( memory access ) arbitration. So we may need a special hardware. Writing an application code will be uneasy as well, because we will need only one main routine. How can we utilize xilinx-provided design resources to do those? This seems to be very hard but interesting ......Article: 79236
There was a thread recently about how to protect IP, and one respondent said that it is too much trouble to worry about protecting IP and a better model is to just sue anybody that steals it. This seemed perhaps naive since there are places where IP rights are not respected and attempts to sue will probably be fruitless. Here is an excerpt from an article in the NY Times that illustrates this: "The Chinese are adept at copying and quite loose in their interpretation of intellectual property rights. One of Mr. Fishman's more striking examples is the auto industry, which looms large in China's economic plans. American and Japanese companies spend $1 billion to $2 billion to develop a new car. The Chinese, by forcing foreign car companies to form joint ventures with their companies and to share their technology in order to enter China, hope to leapfrog over those kinds of development costs. Foreign companies, salivating at the thought of 100 million Chinese customers, cannot stop themselves from signing on the dotted line. Sometimes, rude surprises await. At the 2003 Shanghai auto show, G.M. executives unveiled a new $9,000 small family van, only to discover an identical vehicle, priced at $6,000, at a Chinese booth in the same row. The clone was made by Chery, a Chinese company owned in part by Shanghai Auto, G.M.'s joint-venture partner. "Article: 79237
Jim, That is not a scope picture. I will get a scope picture within a few more days. I was just hoping they'd go ahead and post one for me. I have a lot to do other than go get scope pictures of Iccint! Austin Jim Granville wrote: > Austin Lesea wrote: > >> Falk, >> >> Good point, but I will grant that if they post a scope picture, I will >> very likely believe it. > > > There is a 'sort of scope picture' showing startup currents here > http://www.altera.com/products/devices/stratix2/features/st2-competitive.html > > > does that count ? > > Better (closer to the real world) would be scope ramp up _AND_ ramp > down on an operating FPGA - from both suppliers, of course :) > - that way they get to choose the design that makes their dynamic > operation look the best. [ maybe there is a dV/dT that looks best on > inrush too ? ] > > Of interest is if the inrush is purely cap modeled (non clamping) or > if it is the stalling clamp type, where a current limited supply can > freeze at some point up the inrush mountain ( and a fold back supply may > be completely the wrong solution ! ) > > > -jg >Article: 79238
Hi, I face the problem of using the file input output function such as fdopen, fopen, fclose.... During compilation using SDK shell, it always prompted up a lot of error message. I believe i confuse with the syntax. Can anybody give me a guide how to use these function by giving me a very simple example? For example, how to call these function out from our C program. Besides, can anybody tell me what is the difference between fopen and fdopen?? Thank you very much and wish you all have a nice day.Article: 79239
> Better (closer to the real world) would be scope ramp up _AND_ ramp > down on an operating FPGA - from both suppliers, of course :) > - that way they get to choose the design that makes their dynamic > operation look the best. [ maybe there is a dV/dT that looks best on > inrush too ? ] > Of interest is if the inrush is purely cap modeled (non clamping) or > if it is the stalling clamp type, where a current limited supply can > freeze at some point up the inrush mountain ( and a fold back supply may > be completely the wrong solution ! ) Power supply design is not my forte. But yes, startup currents are complicated and I'm not sure how much I'd trust any one scope shot. What order do you power up the various power supplies on the chip (it changes things)? What temperature/voltage are you testing at? What point on the process curve is the chip under test? Rate of ramp up in the power supply is a good example -- if you have a supply that can supply infinite current immediately, you *will* see a "spike". But it's likely the result of charging of board caps and chip caps, and if you use a supply with less capacity, it will just take longer to ramp up to full Vcc. Capacitive "spikes" are not really an issue so long as the board/chip powers up to Vcc within the spec'ed ramp time. Contention-based power-up cannot be overcome with time. If you do not supply the necessary current, Vcc never reaches the proper value and the chip does not power up. This is the type of "in-rush current" I think we're debating here. It's easy to design around an "in-rush current" by just using the right size power supply. Getting rid of contention-based start-up currents in the FPGA require that we stage all the various initialization logic the right way, etc. Not rocket science, but there are a number of details to get right. Regards, Paul Leventis Altera Corp.Article: 79240
glen herrmannsfeldt wrote: > Austin Lesea wrote: > (big snip) > > > The devil is in the details: is a static power reduction at 25C an > > improvement? Yes, and No. Is comparing our middle speed grade with > > their fastest honest? Well, if that is the only thing they can get > > their hands on, perhaps it is. Would it be better to compare their > > slowest with our slowest? Who would be excited about that? > > I wonder what fraction of FPGA designs are not very speed > sensitive. I used to wonder about that in TTL days, building > digital clocks (60Hz for the fastest signals) out of 30MHz TTL > chips. > > Many designs could easily only require on half or one tenth of > what current FPGAs are capable of, and still be worth putting in > an FPGA. For those, the slowest devices, especially with lower > static power, might be very useful. > > For the most part, I don't find this discussion very useful. > We all know about marketing departments, and having engineers > argue this doesn't cause me to look favorable on their company > or products. > > -- glenArticle: 79241
> Well, I would NOT say they are stupid, as they have explained why they > made their choice: triple oxide was considered too much of a risk at > their fab at the time they did their design. For us, lo-K was > considered too risky. You do not get to choose, the fab chooses for you. No, the main reason we chose not to use triple oxide was we found that it hurts speed too much for the resulting reduction in static power. There are other levers to use (varying gate length, threshold voltage) that also reduce static power and can do so with less speed hit. Obviously, your engineers came to a different conclusion. My guess is the real reason for the difference in approach comes down to different product goals and performance/power targets. In the end, we chose a different point on the speed vs. static power curve for Stratix II than you did for V4. You can talk about "system performance" until you are blue in the face, but in the end our logic + routing fabric is significantly faster than V4s. That's where the bulk of the transistors are still, and we chose faster, leakier transistors where you chose slow, less leaky ones. Regards, Paul Leventis Altera Corp.Article: 79242
> True. We have not finished all characterization. Our FAEs have the > present worst case numbers for customer design, but we prefer to let > them cool a little longer. Use Web power to 85 C junction temp and > multiply by 2.5 to get worst case (for now, until we release the > finals). Even then, we are still up to 70% less leakage. Could you post some details on how you are getting this "up to" 70% leakage number? If I take 85C Typical data from WPT4.0 for V4 and multply by 2.5 (VccInt + VccAux), and compare to 85C Maximum data from the PowerPlay Early Power Estimator 2.1 for Stratix II (VccInt + VccPD), here is what I find. LX15 580 mW 2S15 825 mW -29% LX25 840 mW LX40 1212 mW 2S30 1191 mW +2% LX60 1782 mW 2S60 2232 mW -20% LX80 2210 mW LX100 2817 mW 2S90 3233 mW -13% LX160 3727 mW 2S130 4411 mW -15% LX200 4542 mW 2S180 5445 mW -17% I have a graph that plots vs. normalized LE count since device sizes don't line up perfectly, but you get the picture. Now I know the 2.5x factor is a rough estimate on your part, but I still find it hard to see a massive V4 advantage on static power here. And if we add in our dynamic power advantage (see Vaughn's posting)... Regards, Paul Leventis Altera Corp.Article: 79243
I have an .rbt file, and as you know is full of 0' and 1's, and I want to know, and I want to count the number of frames that this file contains, so my question is: How can I know how many frames there are on the file? or How do I know that a frame starts so that way I can count them. Thank you for your time.Article: 79244
This is a mostly laguage forum so you might not be able to get a good response for this query. I suggest you post it to snug group in deepchip.com.Article: 79245
Paul, OK. There it is folks: they are leakier. Seems their fab did not show any improvements they felt were worth having. And, if you decide to use only LUTs and interconnect, and not take advantage of any advanced features (SRL, LUT RAM, FIFO/BRAM, BRAM w/ECC, PPC, EMAC, DSP48, and so on and so forth), nor attempt to push our tools, you can also get faster performance, too. (Although I am still very suspicious of this claim). But, if you are serious about static power, and concerned about getting the best performance, and willing to actually use some of the hardened (faster) functions, then I ask you to consider the Virtex 4 FPGA. And if you need built in source synchronous IO with individual pin settable or adjustable delays, 450 MHz PPC, EMACs, or MGTs, well, there is no other choice, is there? Austin Paul Leventis wrote: >>Well, I would NOT say they are stupid, as they have explained why > > they > >>made their choice: triple oxide was considered too much of a risk at > > >>their fab at the time they did their design. For us, lo-K was >>considered too risky. You do not get to choose, the fab chooses for > > you. > > No, the main reason we chose not to use triple oxide was we found that > it hurts speed too much for the resulting reduction in static power. > There are other levers to use (varying gate length, threshold voltage) > that also reduce static power and can do so with less speed hit. > Obviously, your engineers came to a different conclusion. > > My guess is the real reason for the difference in approach comes down > to different product goals and performance/power targets. In the end, > we chose a different point on the speed vs. static power curve for > Stratix II than you did for V4. You can talk about "system > performance" until you are blue in the face, but in the end our logic + > routing fabric is significantly faster than V4s. That's where the bulk > of the transistors are still, and we chose faster, leakier transistors > where you chose slow, less leaky ones. > > Regards, > > Paul Leventis > Altera Corp. >Article: 79246
Paul, Sign up, and watch Peter. Austin Paul Leventis wrote: >>True. We have not finished all characterization. Our FAEs have the >>present worst case numbers for customer design, but we prefer to let >>them cool a little longer. Use Web power to 85 C junction temp and >>multiply by 2.5 to get worst case (for now, until we release the >>finals). Even then, we are still up to 70% less leakage. > > > Could you post some details on how you are getting this "up to" 70% > leakage number? > > If I take 85C Typical data from WPT4.0 for V4 and multply by 2.5 > (VccInt + VccAux), and compare to 85C Maximum data from the PowerPlay > Early Power Estimator 2.1 for Stratix II (VccInt + VccPD), here is what > I find. > > LX15 580 mW 2S15 825 mW -29% > LX25 840 mW > LX40 1212 mW 2S30 1191 mW +2% > LX60 1782 mW 2S60 2232 mW -20% > LX80 2210 mW > LX100 2817 mW 2S90 3233 mW -13% > LX160 3727 mW 2S130 4411 mW -15% > LX200 4542 mW 2S180 5445 mW -17% > > I have a graph that plots vs. normalized LE count since device sizes > don't line up perfectly, but you get the picture. > > Now I know the 2.5x factor is a rough estimate on your part, but I > still find it hard to see a massive V4 advantage on static power here. > And if we add in our dynamic power advantage (see Vaughn's posting)... > > Regards, > > Paul Leventis > Altera Corp. >Article: 79247
cant say for sure but check if you have completely defined the type and range for UFix and it is visible to the function.Article: 79248
Hi Andres, To ensure an unnecessary register is not optimized away, use the "preserve" attribute. To do the same for a combinational node, use the "keep" attribute. Virtual pins will also work, but as other posters have noted, they require that you connect the register to an I/O of your (sub) design. Virtual pins are really intended to support bottom-up design flows (create a module, compile in isolation, then bring module/placement/maybe routing) into the higher level design. So while they can be used to preserve registers, they're not as convenient as just using "preserve". Here are some details from help on the altera website: For details regarding the syntax for these attributes, refer to the Quartus II Integrated Synthesis chapter in volume 1 of the Quartus II Handbook. The Keep Combinational Node attribute, keep or syn_keep, directs the compiler to keep a wire or net configuration intact during logic synthesis minimizations and netlist optimizations. When this attribute is applied, the Compiler will insert LCELL buffers in the design to maintain the node name. The option cannot preserve nodes that have no fan-out. The Preserve Registers attribute, preserve or syn_preserve, directs the compiler not to minimize or remove a specified register during synthesis optimization or advanced netlist optimizations. Optimizations can eliminate redundant registers and registers with constant drivers. This option can preserve a register so you can observe it during simulation or with the SignalTap® II logic analyzer. Additionally, it can preserve registers if you are creating a preliminary version of the design in which secondary signals are not specified. The option cannot preserve registers that have no fan-out. "Andrés" <nospam_nussspucke@gmx.de> wrote in message news:3718pjF58afv7U1@individual.net... > ALuPin wrote: >> Hi, >> >> in one the last posts Christos recommended me to use Virtual Pins >> if I want the Fitter not to optimize registered unused signals away. >> >> I have a module "sie.vhd" instantiated in my top level schematic design >> file >> "top_d.vhd". >> >> The module "sie.vhd" has a port "Eop_not_recog" of type std_logic. >> It is a registered signal which is not used at all.Article: 79249
I did. My question remains unanswered. - Paul
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