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
The Spartan-3E Web Power tool can give you a first estimate. It's generally quite conservative and, as with all estimators, depends on the quality of the information provided. I'm assuming that your 300 mW power budget is for dynamic power consumption. Is this correct? Your total power will be the quiescent (standby) power + dynamic power consumption. With dynamic power consumption, you have a few levers to control the final result. The two easier levers are input clock frequency and voltage. Lowering the input clock frequency directly lowers the dynamic power. Turn off functions when not using them, for example, with a clock enable. Power consumption goes up with the square of the voltage, so using a lower voltage, if possible, provides an advantage. The quiescent or standby number is always there but is more critical for designs powered from a battery and wake up occasionally to perform some function. A question to also ask is wether for power consumption reasons you want to consider absolute worst-case quiescent (i.e., all devices are below this level) or typical case. There can be significant differences in battery lifetime. The choice may be driven by the system design requirements. In extreme cases, you can even turn off power to the FPGA, essentially creating a "Hibernate" mode. --------------------------------- Steven K. Knapp Applications Manager, Xilinx Inc. General Products Division Spartan-3/-3E FPGAs http://www.xilinx.com/spartan3e --------------------------------- The Spartan(tm)-3 Generation: The World's Lowest-Cost FPGAs.Article: 100176
Here's an important missing item from my previous post! Xilinx Spartan-3E Web Power Tool Version 8.1.01 http://www.xilinx.com/cgi-bin/power_tool/power_Spartan3eArticle: 100177
Perfect Steve thanks. Thanks everyone! - CraigArticle: 100178
Steve Knapp (Xilinx Spartan-3 Generation FPGAs) wrote: > Craig Yarbrough wrote: > >>Thanks for the responses. That clears things up quite a bit. One >>followup question, is the ratio of tap increment/decrement to the CLKIN >>frequency fixed at DCM creation, or is it dynamic? If during normal >>operation I increase CLKIN from 39.063MHz to 51.723MHz will the ratio >>remain the same? Or will I see a proportionally larger phase shift with >>the faster clock? >> >>- Craig > > > For Spartan-3 FPGAs, the VARIABLE phase shift is _always_ a fraction > (1/256th) of the input clock period--the equivalent of about 1.4 > degrees or pi/128 radians. In Spartan-3 FPGAs, the DCM logic converts > this value to the appropriate number of tap delays, with each tap being > between 30 to 60 ps. > > Assume a 166.667 MHz clock, which has a 6 ns clock period. Each > PSINCDEC increment/decrement step is 6/265 ns = ~23 ps, less than a tap > delay. The DCM control logic will decide wether or not to actually > shift when the shift value falls below the tap resolution. > > Or, let's take your specific example. > > If CLKIN is 39.063 MHz, then the clock period is ~26 ns. Each PSINCDEC > value is 26/256 ns = ~102 ps. > > If you changed the input clock to 51.723 MHz (please reset the DCM when > changing input frequencies please), then the clock period shrinks to > ~19.33 ns. Now each PSINCDEC value is 19.33/256 ns = ~75.5 ps. On > Spartan-3, the size of the PSINCDEC value changes according to the > input clock frequency. Would it be correct to also add this ? - Chooses the nearest physical [~40ns] tap, to the desired delay (N x 102ps, or N x 75.5ps) - Saturates at nom 10ns >Spartan-3E FPGAs behave differently. Whilst we are on this subject, to this detail, can you give some info on how does Spartan 3E differ, and why ? -jgArticle: 100179
In article <qhd5fxdn27.fsf@ruckus.brouhaha.com>, Eric Smith <eric@brouhaha.com> wrote: >ptkwt@aracnet.com (Phil Tomson) writes: >> Just got an Athlon64 system. I want to be able to run the Xilinx ISE tool >> suite on this box under Linux. I'd also like to install a 64-bit Linux on it - >> are there any issues with running xst under 64-bit linux? I suspect there >> might be driver issues with downloading bitstreams, but I'm thinking of >> using one of the open source tools for downloading bitstreams. > >XST works fine, but the ISE Simulator is not available in the 64-bit That's fine. I use ghdl. >version, nor, as you suspected, are cable drivers for programming. > >I'm hoping that they can get the 64-bit cable drivers into the next release >(8.2i? 9.0i?). I looked into building them myself, but it's not feasible >because even though the WinDriver demo kit supports 64-bit, Xilinx supplies >their portion of the driver as a 32-bit object file. > >If Xilinx would release docs on the driver API, I expect that an open >source version would get developed quickly. I don't see what down side >this would have for Xilinx; anything that makes it easier for people to >develop using Xilinx parts should be a good thing. I seem to recall that there are some open source bitstream downloaders available for Linux... don't have any URL handy right at the moment, though. PhilArticle: 100180
Ok, thanks Joey, I just wanted to make sure I wasn't missing something obvious with this OCM problem. At least it works on your system! What I'll probably try is to do a place-and-route with just the PowerPC's and OCMs in the system. The last time I tried that on an otherwise empty system the memory worked just fine. Then, I can use the FPGA editor to capture that routing to a UCF file and just lock the placement down. (Some other post mentioned a "Directed Routing Constraints" command to try). Wish me luck... Jeff "Joseph" <joeylrios@gmail.com> wrote in message news:1144180875.234496.109560@j33g2000cwa.googlegroups.com... > Jeff, > > Well, your surprise at my clocking was warranted... I checked and I > seem to be running everything at 100Mhz now. Now I am curious if I can > get the speeds up as well. My processors do communicate well over the > OCM still. I think what happened for me was that I saw the 4:1 ratio > in the block reference guide and realized that my different clocks were > causing a problem. I probably, at that point, made everything run at > 100Mhz and gave BRAMDSOCMCLK the same clock as the processor to be > certain I would get 1:1. When I posted to the group, I got the ratio > backwards (upside-down?). Thanks for setting me straight! > > Like you, I have moved on and around this problem a bit. I was > surprised to see the clock values I had in my system. If I get time, I > may adjust them... maybe try the whole system at 200Mhz and see what > happens. Or just try 4:1 to see if things work. Speed isn't as > important in my system as it seems to be in yours, just the coherent > communcation is what matters. Oh, those touchy OCMs... > > Joey >Article: 100181
Thanks,300mw is the total power,include the quiescent and the dynamic powers,and the prequncy I use is not high,about 20Mhz,The LUTs I use are about 5k for look up table,2k registers.I want to know if I can make it work under 300mvw.Article: 100182
Craig, Remains the same. Austin Craig Yarbrough wrote: > Thanks for the responses. That clears things up quite a bit. One > followup question, is the ratio of tap increment/decrement to the CLKIN > frequency fixed at DCM creation, or is it dynamic? If during normal > operation I increase CLKIN from 39.063MHz to 51.723MHz will the ratio > remain the same? Or will I see a proportionally larger phase shift with > the faster clock? > > - Craig >Article: 100183
Jim, Yes, nearest tap to actual value, and as for how Spartan stuff works, I have to defer to those engineers (as they did things differently). Austin Jim Granville wrote: > Steve Knapp (Xilinx Spartan-3 Generation FPGAs) wrote: > >> Craig Yarbrough wrote: >> >>> Thanks for the responses. That clears things up quite a bit. One >>> followup question, is the ratio of tap increment/decrement to the CLKIN >>> frequency fixed at DCM creation, or is it dynamic? If during normal >>> operation I increase CLKIN from 39.063MHz to 51.723MHz will the ratio >>> remain the same? Or will I see a proportionally larger phase shift with >>> the faster clock? >>> >>> - Craig >> >> >> >> For Spartan-3 FPGAs, the VARIABLE phase shift is _always_ a fraction >> (1/256th) of the input clock period--the equivalent of about 1.4 >> degrees or pi/128 radians. In Spartan-3 FPGAs, the DCM logic converts >> this value to the appropriate number of tap delays, with each tap being >> between 30 to 60 ps. >> >> Assume a 166.667 MHz clock, which has a 6 ns clock period. Each >> PSINCDEC increment/decrement step is 6/265 ns = ~23 ps, less than a tap >> delay. The DCM control logic will decide wether or not to actually >> shift when the shift value falls below the tap resolution. >> >> Or, let's take your specific example. >> >> If CLKIN is 39.063 MHz, then the clock period is ~26 ns. Each PSINCDEC >> value is 26/256 ns = ~102 ps. >> >> If you changed the input clock to 51.723 MHz (please reset the DCM when >> changing input frequencies please), then the clock period shrinks to >> ~19.33 ns. Now each PSINCDEC value is 19.33/256 ns = ~75.5 ps. On >> Spartan-3, the size of the PSINCDEC value changes according to the >> input clock frequency. > > > Would it be correct to also add this ? > - Chooses the nearest physical [~40ns] tap, to the desired delay (N x > 102ps, or N x 75.5ps) > - Saturates at nom 10ns > > >> Spartan-3E FPGAs behave differently. > > > Whilst we are on this subject, to this detail, > can you give some info on how does Spartan 3E differ, and why ? > > -jg >Article: 100184
Ralf Hildebrandt has described a dual-edge D-FF in his March 28th post - one page PDF is available at http://www.ralf-hildebrandt.de/publication/pdf_dff/pde_dff.pdf I'd like to hear opinions on the reliability of this circuit - can anyone see any issues with using this circuit. PeterC.Article: 100185
Hi, For power estimation, Altera provides two tools. The most accurate estimates are obtained from the Quartus II Power Play Power Analyzer (as mentioned by Ben), especially if you provide simulation vectors. We also have an Early Power Estimator spreadsheet that can be used for estimates pre-HDL; once you have a design, you're better off estimating the power in Quartus. As of Quartus II 5.1, Quartus will perform push-button dynamic power optimization. It does this by reducing the capacitance of highly toggling nets in your design, and by restructuring RAM and other logic. Results vary depending the type of design, how tight your timing constraints are (the tool will do its best to continue to meet timing), the power optimization effort level you set, and the availability of simulation vectors (you don't need them thought to get some benefit). For designs with some timing margin and simulation vectors, we see on average 25% reduction in dynamic power as compared to the same designs compiled in earlier versions of Quartus II. You can find some tips on optimizing the dynamic power of your design and how to run Quartus to analyze and optimize your power at: http://www.altera.com/literature/hb/qts/qts_qii51016.pdf You can download the Early Power Estimator for Cyclone II at: http://www.altera.com/support/devices/estimator/pow-powerplay.html Altera's Power Analysis & Optimization capabilities are summarized at: http://www.altera.com/products/software/products/quartus2/design/qts-power_analysis.html And I wouldn't be doing my job if I didn't mention that Cyclone II has lower static power, lower dynamic power, and lower I/O than any competing device, so its certainly worth your time to check it out. Regards, Paul Leventis Altera Corp.Article: 100186
Hi again, You should easily fit under 300 mW. For a Cyclone II 2C8, a quick Altera Early Power Estimator calculation comes out at ~161 mW, at 85C junction temperature and assuming worst-case static power. Other assumptions here: 5000 LUTs, 2000 FFs toggling 25% of the time at 20 Mhz 50 3.3V LVTTL inputs and outputs driving 10 pFs of external loading 25% of the time at 20 Mhz (100% enable rate) 1.20V supply voltage 85C junction temperature (depends on your cooling solution and ambient temperature -- lower worst-case temperatures = better static power) Worst-case silicon It's also likely your design would fit in a EP2C5, which would come out around ~125 mW. Regards, Paul Leventis Altera Corp.Article: 100187
On Fri, 31 Mar 2006 21:57:49 +0100, "Slurp" <slip@slop.slap> wrote: > >Here is an example I dropped together inside 3 mins, ready to synthesise. >Only needs the pins and device defining before I can drop it straight into a >part. > >http://www.wheelnut.plus.com/Block1_bdf.pdf Here is my verilog take on it: module block1_bdf(sysck, a, b, c, d, e, result); input sysck; input [17:0] a, b, c, d, e; output [37:0] result; reg [17:0] dataa, datab, datac, datad, datae; always @(posedge sysck) begin dataa <= a; datab <= b; datac <= c; datad <= d; datae <= e; end wire [37:0] data3 = dataa * datab; wire [37:0] data2 = datab * datac; wire [37:0] data1 = datac * datad; wire [37:0] data0 = datad * datae; reg [37:0] data; always (posedge sysck) data <= data0 + data1 + data2 + data3; reg [37:0] result; always (posedge sysck) result <= data / 20'd109456; endmodule I certainly have not been working on it since you posted your pdf ;-)Article: 100188
Hi, According to the link (1) below, Stratix II LVDS I/Os are rated at 1.04 Gbps. If you look at link (2) below, we show some nice eye diagrams at 1.0 Gbps. And that's not Stratix II GX. Stratix II GX is shipping now, and its clock-data recovery (CDR) I/Os are operating beautifully at 6.375 Gbps and 3.125 Gbps. See link (3) for some characterization results. In addition, SII GX will operate at 1 Gbps just like Stratix II (4). Referenced links: (1) http://www.altera.com/products/devices/stratix2/features/io/st2-source_synch.htm (2) http://www.altera.com/technology/signal/devices/stratix2/st2-signal-performance.html (3) http://www.altera.com/technology/signal/devices/stratix2gx/character/sgl-s2gx-character.html (4) http://www.altera.com/products/devices/stratix2gx/features/io/s2gx-source_synch.html Regards, Paul Leventis Altera Corp.Article: 100189
A somewhat related question: I have simulated (behavioural) a Spartan 3 DCM with the PHASE_SHIFT parameter initialized to zero. I am using the DCM in Variable phase shift mode. Input frequency is 100 MHz. However, the behavioural simulation shows that once the core asserts LOCKED_OUT high, there is still a significant (approx. 3 ns) phase shift between the input clock and clk0_out. Is this clk_in to clk0_out phase relationship shown in the behavioural simulation accurate? (Apologies for tagging onto the end of this thread, I wanted to get an answer efficiently and a few of the DCM gurus are likely to still be looking at this thread.)Article: 100190
Ira, I don't believe you will be able to specify the internal intermediate results precision, the only way to do this would be to design the complete filter from scratch. I don't believe Xilinx would provide you with synthesizable RTL code to do a modification of the core. Also, in the case of Spartan devices, there is a MAC (multiply accumulate) and DA (distributed arithmetic) version of the FIR core , althought I don't know if this is true for the XC2VP series of devices. You may like to experiment with both cores to compare resource requirements. Finally, in the Spartan 3 device I would try enabling coefficient storage in BRAM instead of LUTs to save slices - there is likely a similar option for your core. Good luck! PeterC.Article: 100191
PeterC wrote:
> Ralf Hildebrandt has described a dual-edge D-FF in his March 28th post
> - one page PDF is available at
> http://www.ralf-hildebrandt.de/publication/pdf_dff/pde_dff.pdf
>
> I'd like to hear opinions on the reliability of this circuit - can
> anyone see any issues with using this circuit.
If you have to do it to save power, that's as clean a way as any.
If you don't have to, just double the clock rate
and use the standard tools of synchronous design.
The main downside to dual-edge clocking is
the new sensitivities added to static timing analysis.
These include clock duty cycle and Tcq differences
between the rising and falling flops.
-- Mike Treseler
Article: 100192On 4 Apr 2006 20:00:24 -0700, "PeterC" <peter@geckoaudio.com> wrote: > >Ralf Hildebrandt has described a dual-edge D-FF in his March 28th post >- one page PDF is available at >http://www.ralf-hildebrandt.de/publication/pdf_dff/pde_dff.pdf > >I'd like to hear opinions on the reliability of this circuit - can >anyone see any issues with using this circuit. > >PeterC. This looks like the circuit that Gabor posted last May. It should work just fine. Bob Perlman Cambrian Design WorksArticle: 100193
http://www.fpgajournal.com/articles_2006/20060404_nios.htmArticle: 100194
On 4 Apr 2006 21:02:31 -0700, "PeterC" <peter@geckoaudio.com> wrote: > >A somewhat related question: I have simulated (behavioural) a Spartan 3 >DCM with the PHASE_SHIFT parameter initialized to zero. I am using the >DCM in Variable phase shift mode. Input frequency is 100 MHz. > >However, the behavioural simulation shows that once the core asserts >LOCKED_OUT high, there is still a significant (approx. 3 ns) phase >shift between the input clock and clk0_out. > >Is this clk_in to clk0_out phase relationship shown in the behavioural >simulation accurate? > >(Apologies for tagging onto the end of this thread, I wanted to get an >answer efficiently and a few of the DCM gurus are likely to still be >looking at this thread.) It's meant to make the phase of the feedback input (clkfb) the same as the clock input (clkin). If you have an external (to the DCM) delay between the clk0 output and the feedback input, you will see a phase shift between clkin and clk0. Does this match your configuration? Regards, AllanArticle: 100195
Hi, I'm working on a board of V2P70 and a flash memory. I didn't have any problems programming the FPGA however all of a sudden I receive an error of 'done pin didn't go high' while I'm trying to program the FPGA in Boundary Scan Mode. I still can initialize the noundary scan chain and assign the bit file to the FPGA yet I cannot program it. I hope someone can help meArticle: 100196
Thanks Allan. That makes sense. I did not have the clkfb input enabled as I am not trying to compensate for skew. I have just added it to the core, re-compiled and re-simulated and there is still the same phase shift between clkin and clk0 (=clkfb). Admittedly I do not reset the core (as is recommended following the inclusion of clkfb). Must I reset the core? Obviously I am still missing something or there is a discrepancy between the behavioural model of the DCM and its real operation - but I very much doubt that this is the case given the maturity of the S3 device. Any other hints?Article: 100197
fpga_toys@yahoo.com wrote: > http://www.fpgajournal.com/articles_2006/20060404_nios.htm Let us know what you think, if you get a chance to try it ? -jgArticle: 100198
Hi, We have to interface a V2Pro with a DSP's communication ports which have LVDS links up to 500Mhz ( taken from datasheet ). We have some experience on V2Pro LVDS I/O but at slow speed and we are wondering what speed we will be able to reach with this LVDS DSP link. DSP and FPGA are on the same board at a reasonnable distance ( something like 10-15 cm ). Does someone has a feedback on V2P high speed LVDS IO implementation ? Are there special tips to use ? Any link is welcomed. Thanks for your help. Stephane.Article: 100199
Jim Granville wrote: > fpga_toys@yahoo.com wrote: > > http://www.fpgajournal.com/articles_2006/20060404_nios.htm > > Let us know what you think, if you get a chance to try it ? I was pretty impressed with the degree of integration for RC they talk about delivered to the field today, as compared to half measures that are scheduled for 1Q07. Maybe RC has a chance given the strategies of several A-Team vendors. Would love to eval it, and even contribute to their project if they wanted to donate a couple boards and software sets to the FpgaC team's project. It's that kind of vision that would almost make me just dump my Xilinx inventory and redesign with their product.
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