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
On May 8, 4:34 am, Antti <Antti.Luk...@xilant.com> wrote: > 1) Impact TCP protocol has been reverse engineered > and there is open-source cable-server > 2) I have tried to make software support for Cable IV high > speed mode, even made special FPGA-PCI design that emulates > LPT port + Cable IV. There is no final result on that yet. > 3) I have written Coolrunner disassembler in order to reverse > engineer the Cable IV code > 4) There is 3rd party replacement firmware for USB platform cable > 5) possible more projects that we dont know about. The biggest problem with much of this, is a mine field caused by the Xilinx NDA in their software license, combined with US copyright laws (slightly mitigated by EU restrictions), especially where any form of encryption is used for protection. Some open source projects have openly ignored the legal reverse engineering standards, requiring independent teams to write functional specifications and do the implementation from those clean room specifications without knowledge of the original implementation details and coding. Failure to do so. leaves the reverse engineered (rewritten) product contaminated or tainted, and a derivative work. These legal standards for reverse engineering were set by years of litigation by major corporations, and set a very clear line in the sand about what is, and is not, legal ... right down to hiring workers which have detailed inside knowledge of a product and what that worker can do at a new employers shop. In the US, such reverse engineering failures can result in significant legal judgements, and/or possible jail where encryption algorithms are concerned, or risk of flight exists to avoid court proceedings. Even if you live abroad, entry into the US after such violations, can leave you in jail, if US laws are applied to you when you enter. Selling products which violate Xilinx IP rights, or giving them away as open source, will give Xilinx the power to pick and choose who they wish to enforce their rights against. The Xilinx software NDA terms are very broad, so if the information you use for the reverse engineering is included in their software products, watch out ... carefully follow both the US and EU laws. It's this simple problem of Xilinx NDA and license terms that makes the company very very high risk to support with open source development. They include/use major Open Source products freely, but then hide behind these very strict NDA and License terms to protect everything from documentation, algorithms, to data formats from being used openly for open source development to support their product line. We've had this discussion several times in this forum. JohnArticle: 119176
On May 14, 3:39 am, "MJ Pearson" <mjp...@york.ac.uk> wrote: > Hello, I have a xupv2p board and I am wanting to use this board to perform image processing from 2 camera-link based cameras. I am building a connection board that will connect the cameras to the board and perform the de-serialization of the signals. Save yourself a lot of aggravation, and use one of the National Semiconductor Camera Link chips to do the de-serialization. For example, see: http://www.national.com/pf/DS/DS90CR288A.html. -aArticle: 119177
On Mon, 14 May 2007 15:45:51 +0100, "Symon" <symon_brewer@hotmail.com> wrote: >p.s. The Google toolbar has this great feature where you can add a Xilinx >(or anything else) search to your toolbar. If you have the thing installed, >go to the Xilinx website, right click on the search box in the top right, >click 'Generate Custom Search' in the menu box. V. useful. > Excellent! I never would have found that myself. A tip o' the hat to you, sir, and to our Google overlords. Bob Perlman Cambrian Design Works http://www.cambriandesign.comArticle: 119178
The legal requirements for reverese engineering date back to 1970's and 1980's. Big name successes were clean-room reverse engineering of the BIOS for the IBM PC by Compaq and Pheonix in the early 1980's, and AMD's clean room versions of Intel Microcode. See http://en.wikipedia.org/wiki/Clean_room_design http://en.wikipedia.org/wiki/Compaq_Computer_Corporation http://software.newsforge.com/article.pl?sid=06/02/01/1630225&tid=132&tid=25 http://en.wikipedia.org/wiki/Advanced_Micro_Devices As a result, we frequently see license terms which completely bar reverse-engineering, so even where it might be completely legal otherwise, such as areas outside the US, the legal contract created by the license and NDA extends the protections in ways that can result in civil and criminal litigation. In places where the legal protections are lacking, it's quite common to see licenses which specifically prevent it's sale into those regions, holding the seller/buyer at risk under US law.Article: 119179
Hello, I am trying to specify a timing constraint for a latch that I have in my design. I need to make sure that from the rising edge of the clock to when a control signal goes high that causes the latch to switch, I have less than one clock cycle delay. This is my UCF file: ####################### ## System level constraints Net CLK TNM_NET = CLK; TIMEGRP "RISING_CLK" = RISING "CLK"; NET "add1_rdy" TPTHRU = "ADD1_RDY"; NET "accumulate<31>" TNM_NET = ACC; NET "accumulate<30>" TNM_NET = ACC; NET "accumulate<29>" TNM_NET = ACC; NET "accumulate<28>" TNM_NET = ACC; NET "accumulate<27>" TNM_NET = ACC; NET "accumulate<26>" TNM_NET = ACC; NET "accumulate<25>" TNM_NET = ACC; NET "accumulate<24>" TNM_NET = ACC; NET "accumulate<23>" TNM_NET = ACC; NET "accumulate<22>" TNM_NET = ACC; NET "accumulate<21>" TNM_NET = ACC; NET "accumulate<20>" TNM_NET = ACC; NET "accumulate<19>" TNM_NET = ACC; NET "accumulate<18>" TNM_NET = ACC; NET "accumulate<17>" TNM_NET = ACC; NET "accumulate<16>" TNM_NET = ACC; NET "accumulate<15>" TNM_NET = ACC; NET "accumulate<14>" TNM_NET = ACC; NET "accumulate<13>" TNM_NET = ACC; NET "accumulate<12>" TNM_NET = ACC; NET "accumulate<11>" TNM_NET = ACC; NET "accumulate<10>" TNM_NET = ACC; NET "accumulate<9>" TNM_NET = ACC; NET "accumulate<8>" TNM_NET = ACC; NET "accumulate<7>" TNM_NET = ACC; NET "accumulate<6>" TNM_NET = ACC; NET "accumulate<5>" TNM_NET = ACC; NET "accumulate<4>" TNM_NET = ACC; NET "accumulate<3>" TNM_NET = ACC; NET "accumulate<2>" TNM_NET = ACC; NET "accumulate<1>" TNM_NET = ACC; NET "accumulate<0>" TNM_NET = ACC; # Constrain CLK to 200 MHz TIMESPEC TS_CLK = PERIOD CLK 5 ns; # Constrain the accumulate latch (one CLK cycle) TIMESPEC TS_ACC_LATCH = FROM "RISING_CLK" THRU "ADD1_RDY" TO "ACC" TS_CLK * 0.99; ####################### During PAR, I always get the message that the following constraint is ignored: WARNING:Timing:3223 - Timing constraint TS_ACC_LATCH = MAXDELAY FROM TIMEGRP "RISING_CLK" THRU TIMEGRP "ADD1_RDY" TO TIMEGRP "ACC" TS_CLK * 0.99; ignored during timing analysis. Why is that? What is the right way to specify what I'm trying to constraint? ThanksArticle: 119180
Are you cutting and pasting directly? I haven't seen the Xilinx tools add the MAXDELAY in the timing constraint before. If there is no MAXDELAY keyword in your definition, is the add1_rdy net in your compiled design? If it got renamed, the "THRU" could be a problem. Suggestion: if you only have the 32 bit bus by that name, try NET "accumulate<*>" TNM_NET = ACC; to specify all 32 wires feed the latches that you want fixed. If the accumulate bus is the latch output, that would be your problem: the TNM_NET tags all *downstream* synchronous elements. Me, I'd just include the latches directly in the TO part as LATCHES( MyLatches<*> ) rather than using the TNM_NET to tag them all. - John_H "Dima" <Dmitriy.Bekker@gmail.com> wrote in message news:1179174473.784383.79900@n59g2000hsh.googlegroups.com... > Hello, > > I am trying to specify a timing constraint for a latch that I have in > my design. I need to make sure that from the rising edge of the clock > to when a control signal goes high that causes the latch to switch, I > have less than one clock cycle delay. > > This is my UCF file: > > ####################### > ## System level constraints > Net CLK TNM_NET = CLK; > TIMEGRP "RISING_CLK" = RISING "CLK"; > NET "add1_rdy" TPTHRU = "ADD1_RDY"; > NET "accumulate<31>" TNM_NET = ACC; > NET "accumulate<30>" TNM_NET = ACC; > NET "accumulate<29>" TNM_NET = ACC; > NET "accumulate<28>" TNM_NET = ACC; > NET "accumulate<27>" TNM_NET = ACC; > NET "accumulate<26>" TNM_NET = ACC; > NET "accumulate<25>" TNM_NET = ACC; > NET "accumulate<24>" TNM_NET = ACC; > NET "accumulate<23>" TNM_NET = ACC; > NET "accumulate<22>" TNM_NET = ACC; > NET "accumulate<21>" TNM_NET = ACC; > NET "accumulate<20>" TNM_NET = ACC; > NET "accumulate<19>" TNM_NET = ACC; > NET "accumulate<18>" TNM_NET = ACC; > NET "accumulate<17>" TNM_NET = ACC; > NET "accumulate<16>" TNM_NET = ACC; > NET "accumulate<15>" TNM_NET = ACC; > NET "accumulate<14>" TNM_NET = ACC; > NET "accumulate<13>" TNM_NET = ACC; > NET "accumulate<12>" TNM_NET = ACC; > NET "accumulate<11>" TNM_NET = ACC; > NET "accumulate<10>" TNM_NET = ACC; > NET "accumulate<9>" TNM_NET = ACC; > NET "accumulate<8>" TNM_NET = ACC; > NET "accumulate<7>" TNM_NET = ACC; > NET "accumulate<6>" TNM_NET = ACC; > NET "accumulate<5>" TNM_NET = ACC; > NET "accumulate<4>" TNM_NET = ACC; > NET "accumulate<3>" TNM_NET = ACC; > NET "accumulate<2>" TNM_NET = ACC; > NET "accumulate<1>" TNM_NET = ACC; > NET "accumulate<0>" TNM_NET = ACC; > > # Constrain CLK to 200 MHz > TIMESPEC TS_CLK = PERIOD CLK 5 ns; > > # Constrain the accumulate latch (one CLK cycle) > TIMESPEC TS_ACC_LATCH = FROM "RISING_CLK" THRU "ADD1_RDY" TO "ACC" > TS_CLK * 0.99; > ####################### > > During PAR, I always get the message that the following constraint is > ignored: > WARNING:Timing:3223 - Timing constraint TS_ACC_LATCH = MAXDELAY FROM > TIMEGRP "RISING_CLK" THRU TIMEGRP "ADD1_RDY" TO TIMEGRP "ACC" TS_CLK * > 0.99; ignored during timing analysis. > > Why is that? What is the right way to specify what I'm trying to > constraint? > > Thanks >Article: 119181
Thanks John, I changed my UCF file to: ## System level constraints Net CLK TNM_NET = CLK; TIMEGRP "RISING_CLK" = RISING "CLK"; # Constrain CLK to 200 MHz TIMESPEC TS_CLK = PERIOD CLK 5 ns; # Constrain the accumulate latch (one CLK cycle) TIMESPEC TS_ACC_LATCH = FROM "RISING_CLK" TO LATCHES( accumulate<*> ) TS_CLK * 0.99 DATAPATHONLY; Now that latch constraint is picked up by ISE. I don't think I need the THRU as the ready signal is synchronous with the clock. And to answer your question, yes, the MAXDELAY was inserted automatically by ISE when it gave the warning in my previous post. ThanksArticle: 119182
On May 9, 6:07 pm, Jim Granville <no.s...@designtools.maps.co.nz> wrote: > How did the GPUs stack up in this comparison ? Sorry, miss place my copy of the proceedings ... here are a few points from the paper presented at FCCM 4/24/07 by Los Alamos Labs: "Matched Filter Computation on FPGA, Cell, GPU", by Zachary Baker, Maya Gokhale, and Justin Tripp. Implementation Speedup Cost Power Speedup/$K Speedup/kWatt Cray XD1/2VP50 3.91 $10K 350W 0.39 11.2 Nvidia GeForce 7900 3.10 $2.6K 350W 1.24 8..7 IBM Cell Processor 8.0 $8K 315W 1.0 25.4 This table is normalized to a reference CPU. The authors presentation provided a great wealth of comparitive development cost issues not presented in the paper, where the FPGA and GPU didn't fare well ... lack of tools and internals documention for optimization. With the Cell processor going commodity, it is very likely to take over numerical applications where FPGA's previously had leadership ... such as DSP. I still believe the FPGA's have a good market ... if large FPGA's can leverage commodity pricing combined with excellent low cost license free tools. Since this is a completely different market, with very different expectations, it's unlikely the existing vendors tools team can/will provide the tools. They are still focused on what hardware designers need, not large scale programmer lead teams that are certainly NOT going to code in VHDL. With the cost of electricity soaring with energy cost increases, we are already seeing $0.36/KWH in some places. So Super Computer faciities that are tens of megawatts are seeing cost of ownership hinge on power and cooling costs.Article: 119183
So the problem probably was the TNM_NET corresponding to downstream elements rather than the latch itself. If I wanted to group a bunch of synchronous elements by name, another way would be to use the INST rather than the NET to associate with a group, using TNM rather than TNM_NET. I believe that's what gets you the good associations that aren't simply convenient wildcard groups. Are you adding this TIMESPEC because Xilinx tools associate the WRONG edge with the timing analysis result? I never have been happy with default timing analysis with latches. "Dima" <Dmitriy.Bekker@gmail.com> wrote in message news:1179177606.917789.47830@e51g2000hsg.googlegroups.com... > Thanks John, > > I changed my UCF file to: > > ## System level constraints > Net CLK TNM_NET = CLK; > TIMEGRP "RISING_CLK" = RISING "CLK"; > > # Constrain CLK to 200 MHz > TIMESPEC TS_CLK = PERIOD CLK 5 ns; > > # Constrain the accumulate latch (one CLK cycle) > TIMESPEC TS_ACC_LATCH = FROM "RISING_CLK" TO LATCHES( accumulate<*> ) > TS_CLK * 0.99 DATAPATHONLY; > > Now that latch constraint is picked up by ISE. I don't think I need > the THRU as the ready signal is synchronous with the clock. > > And to answer your question, yes, the MAXDELAY was inserted > automatically by ISE when it gave the warning in my previous post. > > ThanksArticle: 119184
The only reason I am specifying this TIMESPEC is so ISE throws me a failing constraint if the latching delay exceeds one clock cycle. There is a control signal (synchronous with clock) that sets / resets the accumulator (32-bit signal), but the latch itself is asynchronous. I can't make this synchronous because the control line changes state after a small delay from the edge of the clock and I need the latch to switch right away and stabilize before the next rising edge. So this TIMESPEC serves as a check to make sure if I specify a high frequency clock, the latching delay does not exceed the one clock cycle. And it is also indicates what the delay actually is (its a little over 2ns in this case) so I can take note of it.Article: 119185
fpga_toys@yahoo.com wrote: > On May 9, 6:07 pm, Jim Granville <no.s...@designtools.maps.co.nz> > wrote: > >>How did the GPUs stack up in this comparison ? > > > > Sorry, miss place my copy of the proceedings ... here are a few points > from the paper presented at FCCM 4/24/07 by Los Alamos Labs: "Matched > Filter Computation on FPGA, Cell, GPU", by Zachary Baker, Maya > Gokhale, and Justin Tripp. > > Implementation Speedup Cost Power > Speedup/$K Speedup/kWatt > Cray XD1/2VP50 3.91 $10K 350W > 0.39 11.2 > Nvidia GeForce 7900 3.10 $2.6K 350W > 1.24 8..7 > IBM Cell Processor 8.0 $8K 315W > 1.0 25.4 > > This table is normalized to a reference CPU. The authors presentation > provided a great wealth of comparitive development cost issues not > presented in the paper, where the FPGA and GPU didn't fare well ... > lack of tools and internals documention for optimization. With the > Cell processor going commodity, it is very likely to take over > numerical applications where FPGA's previously had leadership ... such > as DSP. > > I still believe the FPGA's have a good market ... if large FPGA's can > leverage commodity pricing combined with excellent low cost license > free tools. Since this is a completely different market, with very > different expectations, it's unlikely the existing vendors tools team > can/will provide the tools. They are still focused on what hardware > designers need, not large scale programmer lead teams that are > certainly NOT going to code in VHDL. > > With the cost of electricity soaring with energy cost increases, we > are already seeing $0.36/KWH in some places. So Super Computer > faciities that are tens of megawatts are seeing cost of ownership > hinge on power and cooling costs. Thanks - interesting numbers. -jgArticle: 119186
Antti wrote: > I think it is. > cable IV is nice piece of hardware when it works in high speed mode > - but this is very seldom, on most PC's xilinx-software-drivers fall > back into Cable III mode without explanation. > > every other LPT connected software can use the LPT ports to the > maximum, its just the crappy Xilinx drivers that can not handle it > properly. Imagine if they open sourced this, someone might be able to actually fix it, and then everyone would benefit.... Xilinx ? Sounds like a good place to start ? -jgArticle: 119187
Antti wrote: > On 13 Mai, 12:00, pbF...@ludd.invalid wrote: > >>Antti <Antti.Luk...@xilant.com> wrote: >> >>>Stephen Williams schrieb: >>> >>>>-----BEGIN PGP SIGNED MESSAGE----- >> >>>>Where I work, we've pretty much given up on being able to use >>>>impact for anything other then writing ACE files, and it does >>>>a clunky job at that. I suspect that open-sourcing impact would >>>>make a *lot* of folks very very happy. >>> >>>Hi Steve >>>I just recalled, I have reverse engineered the ACE file format >>>even written ACE compressor and player, so the work has begun >>>already :) >>>ah, yes I can open-source the ACE player.. please remind in a few days >>>should i forget.. >> >>Isn't ACE just a compression algorithm/format..? > > > I mean the "Xilinx ACE", file format for SystemACE > its sort of JTAG bytecode, and the information is not public > > its very simple code, and player is very simple too, > way simpler than jam or xsvf... Hi Antti, A simpler bytecode/compression scheme sounds like something that would benefit everyone ? So, this is the requested reminder, after a few days, to open source this :) I'd also cc Xilinx, and say this has wide industry support. They could take a lead from Lattice - they are getting good PR mileage from their Open Sourced SoftCPUs. If I were in Xilinx, I'd sponser a web site for this stuff. It's cheaper than $$$ advertising, and it really does help burnish a tarnished image. Xilinx ? -jgArticle: 119188
fpga_toys@yahoo.com wrote: > On May 9, 6:07 pm, Jim Granville <no.s...@designtools.maps.co.nz> > wrote: > >>How did the GPUs stack up in this comparison ? > > > > Sorry, miss place my copy of the proceedings ... here are a few points > from the paper presented at FCCM 4/24/07 by Los Alamos Labs: "Matched > Filter Computation on FPGA, Cell, GPU", by Zachary Baker, Maya > Gokhale, and Justin Tripp. > > Implementation Speedup Cost Power > Speedup/$K Speedup/kWatt > Cray XD1/2VP50 3.91 $10K 350W > 0.39 11.2 > Nvidia GeForce 7900 3.10 $2.6K 350W > 1.24 8..7 > IBM Cell Processor 8.0 $8K 315W > 1.0 25.4 I also see this in todays news: AMD leapfrogs Nvidia with graphics chip http://www.eetimes.com/news/latest/showArticle.jhtml;jsessionid=CGUERC2TICR3EQSNDLOSKHSCJUNN2JVN;?articleID=199501447 Of course, one's latest release _should_ come out in front of the opposition's current production. 320 ALU and 512 bit memory... "Both the AMD and Nvidia chips show graphics accelerators are undergoing a major shift from being specialized engines aimed at processing polygons and pixels to being highly-parallel general purpose processors. Intel Corp. has signaled it too will participate in this trend with a design in the works called Larabee about which it has so far not revealed many details." Now, we just need the tools to catch up to the silicon :) -jgArticle: 119189
Hi everybody. I'm sitting over a partial reconfiguration project for university. I'm absolutelly new to this topic, but as an introduction to this topic, of course I 've already read the concerning xilinx appsheets and several further sheets from 3rd persons or university papers that are going more into detail. But they all have something in common. They don't say much about those bus macros, how they work, where to get them or how to create them. They mainly talk about the design flow. In the last sheet I recently have read that fpga specific bus macros are available over the website of xilinx, but I had no success in finding them there. Other sheets say, that you have to built them on your own via the fpga editor. But how, when it's absolutelly unclear to me how they work. I'm also wondering if I have to create one bus macro in the fpga editor per 4 interconnecting signals between dynamic and static parts or if i can reuse one bus macro and instantiate from it several times in my vhdl code. Maybe someone experienced to this can give me some advises and clarify some things. The used device is a virtex2pro (xc2vp30-ff896) mounted on the ml310. used software is the ISE and EDK version 7. Another problem with ISE I encountered is, that after I have build a new system via the base system builder and created a new ISE project from the vhdl-filed created by the EDK, the ISE cannot find those referenced vhdl modules from the xilinx library inside the EDK folder on the hard disk. Instead it marks all the components instantiated with a question mark. Does there exist a possibility to tell the ISE, where to look up for the library modules (a library path or something like that)? thanks a lot for your help greetings, Lars SchreiberArticle: 119190
At Altera, power estimation is important. If customers rely on accurate power estimates for making decisions on power management, thermal management, and device selection, then accuracy also matters. We vigorously test our power modeling across a large suite of customer designs to ensure accuracy and continuous improvement. 2 differences comparing estimators for Stratix III and Virtex 5 . . - clock power should not be omitted from the estimator (even the Virtex-4 XPE includes a worksheet for clock power) - register power should vary with toggle rate (it does for the Stratix III EPE) We've done the technical analysis and benchmarking on the accuracy of the spreadsheet based tools. Details on power estimation and other elements of Stratix III Programmable Power Technology (if you are interested) are discussed in a recent net seminar at: http://www.altera.com/education/net_seminars/all/ns-stratix3-design-power-voltage.html Relying on 20% margin for estimation of Altera devices is reasonable. Using consistent assumptions in early power estimators for device selection benchmarking may not be reasonable. Dave Greenfield Altera MarketingArticle: 119191
And, How predictable was that? The fact that we beat them, hands down, for power on V4, led to Altera posing the estimator as the 'issue'. Watch the shells, and keep your eye on that (power estimator) pea: you know where it is, don't you? You will win the prize. Unfortunately, it is the oldest scam in the book. Distract your attention, and cause you to focus where they want. This all the while they rob you blind. They can not have it both ways: is triple oxide bad or good? If you read the Stratix 2 stuff, it is "bad" and "risky" and "unproven." If you read Stratix 3 literature, it is "power saving" and a "breakthrough." Imitation is the sincerest form of flattery. Austin AustinArticle: 119192
On May 14, 12:49 am, Bob Perlman <bobsrefuse...@hotmail.com> wrote: > In light of a recent flameboree in these parts, I thought it might be > helpful to provide a link to an article entitled, "How to Ask a > Question the Smart Way." Although aimed at programmers and programmer > wannabes, the advice is equally applicable to hardware designers old > and new. Also be nice to have a good article on how to ANSWER it in a nice way too :) or not so nice ..... hehehe http://www.flayme.com/Article: 119193
On May 12, 4:54 am, Eric Smith <e...@brouhaha.com> wrote: > kha_vhdl <abai...@gmail.com> writes: > > i want know what are the basics that i should know to choose the > > perfect fpga( for example Sparta,3 or Virtex 4 into Xlinx) and thank > > you for your answer > > Add the family number, pin count, the number of CLBs, three times the > number of multipliers, half the number of block RAMs, and the last > four digits of the telephone number of the local vendor sales office, > then divide by 42 for a figure of merit. Pick the FPGA with the > highest figure of merit, unless there is a full moon, in which case > you should use the third-highest (or wait a few days). > > Eric bingo..... :) patent it... patent it.... patent it... Regards, JKArticle: 119194
Hello Leon, The quality of a power estimate depends on many factors. Let's talk only about dynamic power, since our worst-case static power is a specification and thus pessimistic by nature. *Models* The power models in Quartus II for our recent FPGAs are extremely detailed and are correlated against silicon with many thousands of different targeted designs. Whatever Austin may think, the models for Stratix II & Cyclone II predict dynamic power within a range of +20..-10%. We try to err on the side of slightly over- predicting power since underpredicting has worse consequences for our customers. However, this assumes that we have *perfect vectors* for the operation of your design. And designs that have very glitchy paths (for example, long XOR chains) could be over-predicted by the tools even more. *Design Information* You've used the PowerPlay Power Analyzer on your full design, so it knows everything - synthesis, placement, routing, and bit settings. However, for people who use the Early Power Estimator spreadsheet, then it doesn't know everything -- it must make guesses for LUT functions and length/fanout of routes, and you must make guesses for block modes, etc. *Vectors/Toggle Rates* Assuming the tools & models are of high quality, this is where the biggest source of error comes from. Did you provide vectors from a gate-level simulation of your full design? Did your vectors truly reflect the worst-case mode of operation you will encounter in the real system? If you only had partial vectors, Quartus will fill in the blanks (for example, for combinational logic between registers in RTL simulations) -- and it's fairly good at this, but this is another source of error. Even with good models and perfect vectors, the power tools are designed primarily for estimating power dissipation for thermal design and/or battery life. When it comes to adequately sizing your supply, you begin to run into a new problem -- current transients. Vectors turn into average power over the period of simulation -- but you will have periods of time where the switching exceeds this average. But then again, you have on-chip and off-chip decoupling capacitors that filter/smooth out these spikes. There is no quick-and-easy answer here... So at the end of the day, I can't help you with what a reasonable guard-band is to apply to determine your power supply. 2X is a number I know some customers use -- but that could be too low or horribly over-engineered. Some customers over-engineer their prototype, but downsize their supplies after characterizing the first batch without needing to respin the board design. Sorry I can't give you a more concrete answer, Paul Leventis Altera Corp.Article: 119195
Hi Austin, I'm sure the readers of this newsgroup are shocked to hear that companies try to draw attention to their own strengths and point out competitor's weaknesses :-). Yes, we focus a lot on power, power analysis, and power estimation for the reason you suggest -- we believe we have clear advantages in this area, and we think power is an important criteria of our customers when selecting devices. > draw attention away from the areas where they do not > excel, and into an area where no one can prove anything! Open up you Virtex-5 estimator. Type in 20000 FFs. Set the toggle rate to 10% and clock to 200 Mhz. Then change the toggle rate to 20%. No change in power despite a change in switching activity? For that matter, where is the clock tree power? I guess bugs are expected in software, but these are fairly egregious omissions. Perhaps the tool is accurate for designs without FFs and clocks, but somehow I don't think that's a lot of your target market ;-) > So, is Altera's power estimator that accurate? Yes. All your deflections aside, I have yet to see anything from you to refute the accuracy of our estimators. > I would give the estimate a 20% bump for what it might actually be in > practice. Any one unit will be under the estimate. Only a fast corner > processed part which is shipped to fill the order will come in at the > high end of the estimate. Since you can not only order "typical" parts, > the additional margin is absolutely necessary. This is a fairly confusing statement. I'm not sure whether you are talking about dynamic or static power or both. If the power tool a customer is using does not provide "Maximum" silicon characteristics, then yes, they need to bump up the *static power* portion of the estimate. How much depends on many factors, but I believe Austin's own advice in the past has been 2X from typical to maximum, and in the absence of any other information, 2X is actual not a bad guess. However, if the tool they are using has maximum or worst- case specs available, then there is no need to guardband -- the estimates already reflect the fastest they will receive. Of course, the junction temperature must be representative of the hottest conditions the chip will be operating in, since temperature also has a large impact on static power consumtion. When it comes to dynamic power, process variation does not have a strong impact. When you select Maximum characteristics in the EPE/ Quartus, we do adjust dynamic power slightly to account for worst-case dynamic power we see on corner units. But this variation is small (a few percent). Metal cap can vary, but it varies independently between metal layers (resulting in an averaging effect). Faster transistors have very little impact on dynamic power, since the capacitance that needs to be charged is still the same, and the short-circuit current becomes shorter (transistor switches faster) but more intense (transistor pull current faster), resulting in little change in dynamic power for most circuits. > We also > demonstrated how the same design in both chips led to a 15 to 20 degree > C power savings in V4. I am not familiar with the details of this particular design. Is it the same one you were showing customers that had some of our I/Os shorted to power? That was a nifty trick. Very dramatic demo. Regardless, there will always be designs that work well on one chip vs. the other. We also have demonstrated a number of designs to customers and in various NetSeminars. Short of making our HDL & designs open to one another for critique, I doubt we will ever get agreement (or complete buy-in from our audiences) on our dynamic power demonstrations. But what is more important in these demos is how good is estimator accuracy? At end of the day, its not only important which device consumes lower power (I think ours do, you think yours do), but can the customer figure out what that power will be early in the design cycle? Can they measure it or profile it accurately during design? Can they optimize it with the push of a button in the CAD tools as they can with Quartus? PaulArticle: 119196
Paul ha scritto: > Gain = multiplication or even simpler, right bitshift if you only > need scaling factors of powers of 2 > Offset = addition > > both operations are done very easily in an FPGA > > If you're really asking how to perform multiplication and addition in > an fpga, then you should go purchase a decent VHDL or Verilog textbook > - there are many out there. For VHDL I like Andrew Rushton's VHDL for > Logic Synthesis, but that's a personal preferance. For Verilog I have > no idea, but I'm sure many people here would be happy to recommend you > one. > > > > On May 14, 2:31 am, "Marco T." <marcotos...@gmail.com> wrote: > > Hallo, > > which is the way to perform digital vgain and offset correction using > > a fpga? > > > > Thanks, > > Marco T. I wasn't asking about how to perform addition and multiplication. I was asking if there are other implementations or auto tuning- techniques, in example if someone has made a loopback to perform it. But if + and * are the only ones... so it's not useful to go on with this conversation. Marco T.Article: 119197
fpga_toys@yahoo.com writes: > The biggest problem with much of this, is a mine field caused by the > Xilinx NDA in their software license, combined with US copyright laws > (slightly mitigated by EU restrictions), especially where any form of > encryption is used for protection. If your mention of US copyright laws is meant to reference the DMCA provisions against reverse engineering for circumvention, it should be noted that the DMCA specifically exempts reverse-engineering for the purposes of achieving iteroperability.Article: 119198
Hello Lars, you can find this link in the Xilinx Application Note 290: http://www.xilinx.com/bvdocs/appnotes/xapp290.zip In this zip-file you 'll find a bus_macro-folder with bus_macros for your Virtex2Pro. Best regards, David L. Schreiber schrieb: > Hi everybody. > > I'm sitting over a partial reconfiguration project for university. > > I'm absolutelly new to this topic, but as an introduction to this topic, > of course I 've already read the concerning xilinx appsheets and several > further sheets from 3rd persons or university papers that are going more > into detail. > > But they all have something in common. They don't say much about those > bus macros, how they work, where to get them or how to create them. They > mainly talk about the design flow. > > In the last sheet I recently have read that fpga specific bus macros are > available over the website of xilinx, but I had no success in finding > them there. > > Other sheets say, that you have to built them on your own via the fpga > editor. But how, when it's absolutelly unclear to me how they work. > > I'm also wondering if I have to create one bus macro in the fpga editor > per 4 interconnecting signals between dynamic and static parts or if i > can reuse one bus macro and instantiate from it several times in my vhdl > code. > > Maybe someone experienced to this can give me some advises and clarify > some things. > > The used device is a virtex2pro (xc2vp30-ff896) mounted on the ml310. > used software is the ISE and EDK version 7. > > Another problem with ISE I encountered is, that after I have build a new > system via the base system builder and created a new ISE project from > the vhdl-filed created by the EDK, the ISE cannot find those referenced > vhdl modules from the xilinx library inside the EDK folder on the hard > disk. Instead it marks all the components instantiated with a question > mark. Does there exist a possibility to tell the ISE, where to look up > for the library modules (a library path or something like that)? > > thanks a lot for your help > greetings, Lars SchreiberArticle: 119199
Marco T. wrote: > I wasn't asking about how to perform addition and multiplication. > > I was asking if there are other implementations or auto tuning- > techniques, in example if someone has made a loopback to perform it. That's *not* what you were asking. You were asking: "Which is the way to perform digital vgain and offset correction using a fpga?" How is anyone supposed to see that you want to now about loopback and auto-tuning from that? How are we supposed to give you decent answers if you don't state your question clearly? It's like calling your auto shop and asking "How do I fix a broken car?". No mechanic will be able to give you a decent answer, because he doesn't know what kind of car you are talking about, what is broken, what kind of tools you have to repair it and if you know how to use them. Without more information, your question is meaningless and much too vague to answer. That's why Antti reacted the way he did when you first asked this here. It was his ironic way of letting you know that your question doesn't really make sense. So: Without knowing what it is you want to do gain/offset correction for, noone will be able to give you a decent answer. If, for example, you want to do gain/offset-correction for a CMOS image sensor, it's different from doing GOC for RF receivers. In the end it all amounts to + and *, but how you get the values to add or multiply by differs a lot depending on the system you are looking at. So actually, you don't want to know about *PERFORMING* gain/offset-correction at all (because that's trivial, just + and *)... Instead, what you want to know is how one obtains the correction factors (maybe through auto-tuning and/or loopbacks), which is a totally different subject. -- My email address is only valid until the end of the month. Try figuring out what the address is going to be after that...
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