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
"Leon Heller" <leon_heller@hotmail.com> wrote in message news:41c996ba$0$19159$cc9e4d1f@news-text.dial.pipex.com... > "vax, 9000" <vax9000@gmail.com> wrote in message > news:cqar69$5u0$1@charm.magnus.acs.ohio-state.edu... >> Leon Heller wrote: >> >>> >>> I have a supplier who can provide small quantities of Altera parts, but >>> I'd have to order about 100 GBP worth, about $200 with shipping and tax. >> Would you please quote the price for EPM1270? $200 could buy less than 10 >> pieces, I guess. So you (we) will have no problem to find enough people >> to >> split the cost. The problem might be the shipping from the UK to the US. > > I've just been quoted £20.67 ($39.57) each for 25 pcs of EPM1270T144C5ES! > With VAT and carriage the total will be about $1200. I don't think it is > viable. These people actually make what you are after: http://www.devboards.de/index.php?kategorie=10 Don't know if they can actually supply them, though. Leon -- Leon Heller, G1HSM http://www.geocities.com/leon_heller http://www.kasamba.com/viewExpert.asp?conMemID=105725&Catid=1111&banID=2100Article: 77101
"san" <san_nasa@rediffmail.com> wrote in message news:1103713502.003743.71970@z14g2000cwz.googlegroups.com... > question asked to arm on 22/12/2004 > ----------------------------------- > my questions are: > 1) when the master on AHB bus is getting ready signal low from slave > then is there any way the master start a new transaction on the bus. > Also if slave give the error response after some predefined number of > cycle to release the bus then is it a correct approach or is there any > better approach to release the master and bus to do other operation. > 2) when the slave give retry response to master then is it possible for > > the bus master to start a new transaction on the bus for same or > different slave. Is it that the particular master is blocked on getting > retry response > Have you looked at the amba spec supplied on the ARM website. Proper protocol is described in that document. I believe that once a master starts an access ... it can't do anything else untl that transaction is completed. Split transacttions are available but they are intended to free up the bus for other masters to use a bus while the master that is split waits for the slave to be ready. A retry is just that ... the master retries its cycle to that slave. Again it is best to read the spec. ... I believe these types of transactions are adequatly described. MikeArticle: 77102
> Vaughn Betz wrote: > <snip> >> While other FPGA vendors only specify values for typical silicon at 25C, >> Altera provides start-up currents and operating power values at various >> temperatures and for both typical and worst-case power process corners. Austin, why no comment on this point ? Austin Lesea wrote: > Vaughn, > <snip> > > Too bad, though. The LX200 is 3.3 amperes, worst case - leakage only, at > 85C. Typical is 1.3 amperes at 85C. No start up surge to worry about. > And the LX200 is a lot more memory, LUTs and FFs than the EP2S180... Hmmm... When will we see the first thermal-runaway failures of FPGAs ? Could be time to start teaching thermal-runaway again in the classes, ( and the data sheets... ) and perhaps the tools should perform some 'thermal spreading' to prevent hot spots (since thermal effects are non linear, and one can easily get an additional 40-50'C die above case ). -jgArticle: 77103
Jim, I did comment. My numbers were for 85C typical and worst case. Austin Jim Granville wrote: > > Vaughn Betz wrote: > > > <snip> > >> While other FPGA vendors only specify values for typical silicon at > 25C, > >> Altera provides start-up currents and operating power values at various > >> temperatures and for both typical and worst-case power process corners. > > Austin, why no comment on this point ? > > Austin Lesea wrote: > >> Vaughn, >> > <snip> > >> >> Too bad, though. The LX200 is 3.3 amperes, worst case - leakage only, >> at 85C. Typical is 1.3 amperes at 85C. No start up surge to worry >> about. And the LX200 is a lot more memory, LUTs and FFs than the >> EP2S180... > > > Hmmm... When will we see the first thermal-runaway failures of FPGAs ? > Could be time to start teaching thermal-runaway again in the classes, > ( and the data sheets... ) and perhaps the tools should perform some > 'thermal spreading' to prevent hot spots (since thermal effects are non > linear, and one can easily get an additional 40-50'C die above case ). > > -jg >Article: 77104
Adam Megacz wrote: > BTW, has anybody compiled a bibliography on hardware evolution? I'd > like to read through a big stack of papers on it all at once to try to > get up to speed. > > - a There was an article on FPGA hardware evolution quite a few years ago that I found fascinating. Unfortunately I could only find an abstract of it on the net (search for 'evolution' on the page): http://216.239.63.104/search?q=cache:AN3SMgtZ_DUJ:www.eet.com/news/96/hr913.html+EETIMES+hardware+evolution+Xilinx+frequency&hl=en They wanted a certain frequency to come out of the FPGA. The evolution created a unique solution with two internal oscillators were built and combined into a beat frequency. It doesn't give you your bibliography, but it is a small start.Article: 77105
Include xpseudo_asm.h into your C source code to make mfdcr() and mtdcr() available. - Peter Voxer wrote: > I have read the literature on the the Xilinx DSOCM IF Controller but have a > question. > > Does this piece of IP need to be connected to the DCR Bus in order to get at > the DCR > registers - currently in my EDK graphic I only have it attached to the BRAM > it controls > and straight into the PPC. > > If not how do I access the DCR regs for this IP - I have tried mfdcr and > mtdcr before > from within my software but cannnot compile as there appears to be no ".obj" > for > them. > > AM I being daft ? > >Article: 77106
tom wrote: > Adam Megacz wrote: > >>BTW, has anybody compiled a bibliography on hardware evolution? I'd >>like to read through a big stack of papers on it all at once to try > > to > >>get up to speed. >> >> - a > > > There was an article on FPGA hardware evolution quite a few years ago > that I found fascinating. Unfortunately I could only find an abstract > of it on the net (search for 'evolution' on the page): > http://216.239.63.104/search?q=cache:AN3SMgtZ_DUJ:www.eet.com/news/96/hr913.html+EETIMES+hardware+evolution+Xilinx+frequency&hl=en > > They wanted a certain frequency to come out of the FPGA. The evolution > created a unique solution with two internal oscillators were built and > combined into a beat frequency. > It doesn't give you your bibliography, but it is a small start. > try this one: Thompson A, Layzell P, Zebulum RS Explorations in design space: Unconventional electronics design through artificial evolution IEEE TRANSACTIONS ON EVOLUTIONARY COMPUTATION 3 (3): 167-196 SEP 1999Article: 77107
"Austin Lesea" <austin@xilinx.com> wrote in message news:41C99DA6.2090401@xilinx.com... > Vaughn, > > Only 5.3 amperes surge? How do you test for it? Can you guarantee it? > Do you throw away the ones that don't pass? Why was the initial surge > set at 20 amperes, and then dropped to 16 amperes, and now down to 5.3 > amperes for the 180? Austin, I don't know where you're getting these surge numbers from. To my knowledge Altera never quoted surge currents that high for 2S180s. The TI App note you quoted appears to be a miscommunication, since those numbers are much too high to be either surge or leakage currents. > Too bad, though. The LX200 is 3.3 amperes, worst case - leakage only, at > 85C. Typical is 1.3 amperes at 85C. No start up surge to worry about. > And the LX200 is a lot more memory, LUTs and FFs than the EP2S180... Altera's power tools take leakage into account in the power-up current they display. So the 1.8 A to 5.3 A of ICC Inrush current is the total current needed to power up the device, including both leakage and any surge current. The 5.3 A value is power-up current for worst-case silicon characteristics, at 85 C. Is your 3.3 A leakage number for the worst-case power process corner silicon at 85 C, or just typical or unspecified silicon at 85 C? The difference is significant. Leakage increases as threshold voltage drops (or channel length decreases, etc.), so we have provided numbers for both typical process and the highest power units. Vaughn Altera v b e t z (at) altera.com [remove spaces and use proper @ to reach me] > > Vaughn Betz wrote: > > The ICC values listed for Stratix II in the TI reference guide above are > > out-of-date. Altera has requested that TI update this document. > > > > EP2S180 users can expect from 1.8A to 5.3A of ICCint current during FPGA > > power-up, depending on the temperature and the silicon characteristics > > (typical vs. the process corner that leads to maximum power). Given the > > high-density and high-performance of the 2S180, these values are below the > > operating current for the vast majority of customers. > > > > While other FPGA vendors only specify values for typical silicon at 25C, > > Altera provides start-up currents and operating power values at various > > temperatures and for both typical and worst-case power process corners. > > > > For a power estimate specific to your design, use the PowerPlay Early Power > > Estimator, available at > > http://www.altera.com/support/devices/estimator/st2-estimator/st2-power-esti > > mator.html. If you have a completed design, you can use the Power Analyzer > > built into Quartus for even more accurate answers. See > > http://www.altera.com/literature/hb/qts/qts_qii53013.pdf for details. > > > > Vaughn > > Altera > > v b e t z (at) altera.com [Remove spaces and insert proper @ to reach me] > > > > > > > >Article: 77108
Just curious. Is it likely that one implements that in same chip with a bluetooth baseband and phy together in same chip? What is the estimated gate count? How big is the analog core? Thanks.Article: 77109
When creating custom IP Cores for inclusion in to EDK projects, I stumbled
across the following problem:
If a custom core (in VHDL) does not have a generic section
as for example:
-----------------------------------------------------------
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
library UNISIM;
use UNISIM.VComponents.all;
entity my_inverter is
port ( I : in STD_LOGIC;
O : out STD_LOGIC
);
end my_inverter;
architecture arch_my_inverter of my_inverter is
begin
O <= not I;
end arch_my_inverter;
-----------------------------------------------------------
EDK generates a wrapper WITH an EMPTY generic section:
-----------------------------------------------------------
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
library UNISIM;
use UNISIM.VCOMPONENTS.ALL;
library my_inverter;
use my_inverter.all;
entity rst_inverter_wrapper is
port (
I : in std_logic;
O : out std_logic
);
end rst_inverter_wrapper;
architecture STRUCTURE of rst_inverter_wrapper is
component my_inverter is
generic (
);
port (
I : in std_logic;
O : out std_logic
);
end component;
begin
rst_inverter : my_inverter
generic map (
)
port map (
I => I,
O => O
);
end architecture STRUCTURE;
-----------------------------------------------------------
And than complains when compiling the code it just generated:
Compiling vhdl file
/home/rudi/projects/system/synthesis/hdl/rst_inverter_wrapper.vhd in
Library work.
ERROR:HDLParsers:164 -
/home/rudi/projects/system/synthesis/hdl/rst_inverter_wrapper.vhd Line 25.
parse error, unexpected CLOSEPAR, expecting IDENTIFIER
-->
Is this a bug or am I doing something wrong ?
This occurs with EDK 6.2 and EDK 6.3 (both latest patch levels)
on a linux system.
Thanks !
rudi
=============================================================
Rudolf Usselmann, ASICS World Services, http://www.asics.ws
Your Partner for IP Cores, Design, Verification and Synthesis
Article: 77110Hello, I'd like to ensure a <=0ns hold time to all input ( for a PCI design ). But I don't see any way to specify such a constraint in ISE ... Thanks for any pointer, Sylvain PS: Sorry if you received this twice. I tried to send it yesterday but since it doesn't not show up in my newreader today I guess it didn't make thru.Article: 77111
Thanks Marc for your answer. 1. I don't think my device is over-full. Here is a device utilization summary of a successful MAP run (without the ChipScope cores and with the "-timing" option): **************************************************** START HERE **************************************************** Release 6.3.02i Map G.31a Xilinx Mapping Report File for Design 'pcix_3port_bridge' Design Information ------------------ Command Line : /usr/local/apps/xilinx62i/bin/lin/map -intstyle ise -p xc2vp30-ff896-6 -ol high -timing -cm area -pr b -k 4 -c 100 -tx off -o gtw_map.ncd gtw.ngd gtw.pcf Target Device : x2vp30 Target Package : ff896 Target Speed : -6 Mapper Version : virtex2p -- $Revision: 1.16.8.2 $ Mapped Date : Fri Dec 17 01:14:19 2004 Design Summary -------------- Number of errors: 0 Number of warnings: 1213 Logic Utilization: Total Number Slice Registers: 17,111 out of 27,392 62% Number used as Flip Flops: 17,107 Number used as Latches: 4 Number of 4 input LUTs: 20,728 out of 27,392 75% Logic Distribution: Number of occupied Slices: 13,655 out of 13,696 99% Total Number 4 input LUTs: 24,290 out of 27,392 88% Number used as logic: 20,728 Number used as a route-thru: 1,332 Number used for Dual Port RAMs: 2,140 (Two LUTs used per Dual Port RAM) Number used as Shift registers: 90 Number of bonded IOBs: 416 out of 556 74% IOB Flip Flops: 1,035 IOB Dual-Data Rate Flops: 17 Number of PPC405s: 0 out of 2 0% Number of Block RAMs: 66 out of 136 48% Number of GCLKs: 8 out of 16 50% Number of DCMs: 6 out of 8 75% Number of GTs: 0 out of 8 0% Number of GT10s: 0 out of 0 0% Total equivalent gate count for design: 4,941,440 Additional JTAG gate count for IOBs: 19,968 Peak Memory Usage: 521 MB **************************************************** END HERE **************************************************** 2+3. I am using V2Pro-30 (package ff896, speed grade -6). I don't know "how tall" is my device. What does that mean ? I tried unchecking the "use RPM" checkbox of the ChipScope ILA generator, but results were the same. ICON core doesn't have a "use RPM" checkbox. I did another run, this time with ISE 6.3 SP3, and got a different MAP results (still failes): **************************************************** START HERE **************************************************** Release 6.3.03i Map G.38 Xilinx Mapping Report File for Design 'pcix_3port_bridge' Design Information ------------------ Command Line : /usr/local/apps/xilinx63i/bin/lin/map -intstyle ise -p xc2vp30-ff896-6 -ol high -timing -cm area -pr b -k 4 -c 100 -tx off -o gtw_map.ncd gtw.ngd gtw.pcf Target Device : x2vp30 Target Package : ff896 Target Speed : -6 Mapper Version : virtex2p -- $Revision: 1.16.8.2 $ Mapped Date : Thu Dec 23 17:18:07 2004 Design Summary -------------- Number of errors : 123 Number of warnings : 4 Section 1 - Errors ------------------ ERROR:Place - Due to placement constraints, the following 2 components cannot be placed. The relative offsets of the components are shown in brackets next to the component names. LUT i_ila_rpm/i_no_d/u_ila/u_g2_sq/u_capctrl/u_cap_addrgen/cfg_data_4 (0, 0) FF i_ila_rpm/i_no_d/u_ila/u_g2_sq/u_capctrl/u_cap_addrgen/cfg_data_4 (0, 1) >>>>>>> 1200 lines redacted ERROR:Place:120 - There were not enough sites to place all selected components ERROR:Pack:1499 - The timing-driven packing phase encountered an error. Section 2 - Warnings -------------------- ... **************************************************** END HERE ****************************************************Article: 77112
Hi Paul, Firstly, I apologise if my nomenclature is slightly Xilinx biased, I don't get much chance to use your equally excellent Altera parts in my current work. So, I think I had it in my head originally that _all_ the 8 FFs in a slice could be chosen from to drive _any_ of the LUTs in that slice, such that the delays from FF to LUT were evenly matched. At present this relies on routing outside the slice, and so the delays would be badly characterised. Then I thought it might be possible to up the number of FFs to (say) 16 in a slice to make this more viable. This gives you a 2:1 FF to LUT ratio. But, you need a big switching thingy to get the FFs to the LUTs. Some kind of subset might be fine though. Also, maybe you only need 2 registered inputs per LUT to get a big saving in glitch energy. In thinking this, I assumed that the LUT takes up much more silicon area than the FF, after all the LUT has 16 bits, plus all that address muxing. (Indeed, it's the switching of all that LUT silicon that we want to reduce.) Is that a valid assumption? So, it doesn't make that big a difference to the LE area (see, I know a bit of Alteraese!). In the end we're trading switching a load extra FFs, against saving the glitches in the LUTs. Finally, what 'other power reduction circuitry' are you thinking of? Or is it secret? ;-) Thanks, and Cheers, Syms. p.s. Do you have any comment on my post on the 9th Dec about whether certain LUT inputs are more thirsty than others? "Paul Leventis (at home)" <paulleventis-news@yahoo.ca> wrote in message news:JaednXpb4YTIrFfcRVn-3Q@rogers.com... > Hi Symon, > >> > Hmm, that's very interesting. I wonder if the FPGA vendors have got > their >> > SLICEs back to front? I.e. the FFs should feed directly into the LUTs > within >> > the SLICEs, instead of the other way round that exists now. If it saved > even >> > 20% of the power, it'd be worth it. Instead of using all the FFs for >> > pipelining, you use them to replicate signals within the SLICEs to > prevent the >> > glitchy power thing. Hmm, interesting indeed! Thanks Ray. > > You'd have to consider the cost of having 4 flops (if I understand > correctly) vs. 1. How often will 4 flops be used? What if you instead > spent that same silicon area on other things (other power reduction > circuitry, etc.)? How much more wiring cap will there be due to increased > size of a LE? How much more power are you burning by replicating clocks > and > other signals? > > One thing I should point is that you *can* put FF in front of the LUT in > Stratix/Cyclone/Max II/Cyclone II/Stratix II. There is only one FF, but > it > can directly feed the LUT instead of the other way around. > > Regards, > > Paul Leventis > Altera Corp. > >Article: 77113
Hi, I have a 100 MHz PCI-X core for Xilinx device. As a part of PCI-X standard the core is also compliant with PCI 33 MHz. Now I have a problem with the ucf clock frequency constraint. Since I want it to work in PCI-X 100 MHz I constraint to clock of 100 MHz; but then the PCI 33 MHz logic fail to meet the timing constraints. I can identify the PCI 33 MHz critical paths as the path that goes directly from pad (TRDY#) to a combinatorical logic, and the paths of PCI-X as the paths that start at IOB registers. How can I relax the constraints starting at a pad and ending in a CLB register ? ThankX , NAHUMArticle: 77114
ran wrote: > Thanks Marc for your answer. > > 1. I don't think my device is over-full. Here is a device utilization > summary of a successful MAP run (without the ChipScope cores and with > the "-timing" option): Sorry, I had a typo in my previous response. You need to run *without* -timing, but with the chipscope cores, in order to get a utilization estimate with the cores in place. 88% is a relatively high utilization - certainly not full, but not that far away from full either. I'd certainly hope that your chipscope wouldn't take up 3000 LUTs, but depending on your timing domains, I could see map getting into a bind with considerably less than 3000 LUTs. Does the generator give you a size of your core (either saying it is x CLBs tall, or number of LUTs used)? Have you tried removing a large block in your design to see if the ILA core will then fit? > Command Line : /usr/local/apps/xilinx62i/bin/lin/map -intstyle ise -p > xc2vp30-ff896-6 -ol high -timing -cm area -pr b -k 4 -c 100 -tx off -o > gtw_map.ncd gtw.ngd gtw.pcf > Target Device : x2vp30 > Target Package : ff896 > Target Speed : -6 > Mapper Version : virtex2p -- $Revision: 1.16.8.2 $ > Mapped Date : Fri Dec 17 01:14:19 2004 > > Design Summary > -------------- > Logic Utilization: > Total Number Slice Registers: 17,111 out of 27,392 62% > Number of 4 input LUTs: 20,728 out of 27,392 75% > Number of occupied Slices: 13,655 out of 13,696 99% > Total Number 4 input LUTs: 24,290 out of 27,392 88% > Number of Block RAMs: 66 out of 136 48% > > 2+3. I am using V2Pro-30 (package ff896, speed grade -6). I don't know > "how tall" is my device. What does that mean ? > I tried unchecking the "use RPM" checkbox of the ChipScope ILA > generator, but results were the same. ICON core doesn't have a "use > RPM" checkbox. The column called "CLB array" in the "Slice configurations" section of the Xilinx datasheets outline the number of CLB's each device is composed of (number of CLB's vertically vs. CLB's horizontally). Although they don't have to be, RPM's are usually arranged vertically, and it is possible for the RPM to exceed the available number of CLB's in one of the two directions. The 2VP30 has 80 CLBs vertically, which is quite a few. Good luck, MarcArticle: 77115
Hello, i'm currently triing to get an opb-timer to work. The timer is connected to the ppc via an opb-interruptcontroller. I was (exactly) following the Xilinx-Tutorials (Chapter "Memory-Management" in the Embedded Systems Tool Guide). The problem is i won't recieve any interrupts generated by the timer. When connecting the timer-interrupt-output to an led, the led stays off. I tried different combinations: - with / without intermidiate interruptcontroller - with dynamic-handler-registration (per programming-API) / with harded interrupt-handler-registration in system.mhs Finally i took the example c-sources supplied in the memory-management-chapter and compiled/executed them with an appropriate edk-design (i was adding the neccesary components and renamed the instances, so that no additional changes to the sources had to be made, system.mhs and system.mss were edited accordingly). But even with those examples provided by xilinx i wont get the timer to work. At the moment i've got ne idea what could be the reason. I'm using EDK6.2 and a Virtex2Pro (P7V2) Developement Board (Memec-Design). So if anyone has had similar problems i'd be very thankful for a hint. Regards Patrick SiegelArticle: 77116
Vaugn, See below, Austin -snip- > > Austin, > > I don't know where you're getting these surge numbers from. To my knowledge > Altera never quoted surge currents that high for 2S180s. Bellnix Power supply guide, TI power supply guide, ST power supply guide...basically your power supply parnters. So, all I can conclude is that Altera told their power vendors what the start up surge was. http://dkc3.digikey.com/PDF/Marketing/FPGA_Altera.pdf http://focus.ti.com/lit/ml/slyb113/slyb113.pdf http://www.bellnix.com/fpga/P-M-R-G1.pdf ... all state 16 amperes. So if you didn't tell them, who did? If I am an engineer, and I need to design a power system, I would be using these guidelines. > > The TI App note you quoted appears to be a miscommunication, since those > numbers are much too high to be either surge or leakage currents. > Very effective miscommunication there. Better go talk to all your power vendors and let them know that they all quoted the wrong numbers. I have supplied you with the list above, so you're welcome. I could understand if your had an early ES version of the part, and perhaps this high current surge was due to fault on an errate sheet, but the 2S180 isn't sampling yet. Maybe this was based on an extrapolation of the 2S60? So, is there a surge, or no? You imply that all that is needed is the leakage to be overcome (just like our parts since Virtex II). Even your spreadsheet mentions the word "inrush" (6, 1 and 2 amperes for the three supplies). The IO and PD supplies need 8 mA and 15 mA respectively (idle) so why do they need 1 and 2 amperes to start up? I think that is called a Power On Surge (POS)? > >>Too bad, though. The LX200 is 3.3 amperes, worst case - leakage only, at >>85C. Typical is 1.3 amperes at 85C. No start up surge to worry about. >> And the LX200 is a lot more memory, LUTs and FFs than the EP2S180... > > > Altera's power tools take leakage into account in the power-up current they > display. So the 1.8 A to 5.3 A of ICC Inrush current is the total current > needed to power up the device, including both leakage and any surge current. That is as it should be. Everyone here does like your power spreadsheet, it has nice formatting, and a clean look. It does have some buggy pop-up windows that tend to stick around and annoy, but otherwise it is a really good and useful spreadsheet tool. Now the only question is: is it accurate? > > The 5.3 A value is power-up current for worst-case silicon characteristics, > at 85 C. Is your 3.3 A leakage number for the worst-case power process > corner silicon at 85 C, Yes, it is. or just typical or unspecified silicon at 85 C? No, it is not. The > difference is significant. Leakage increases as threshold voltage drops (or > channel length decreases, etc.), so we have provided numbers for both > typical process and the highest power units. And so did I. Interesting you bring this up. A customer demanded to see proof of our LX60 leakage numbers, as they had designed in the 2S60. They frankly could not belive the numbers. All of the 90nm products they were familiar with had horrible leakage. When we told them that we used a triple oxide technology, and that is how we controlled the leakage, they basically still couldn't believe it. When we not only provided them with parts and demo boards, and characterization data on leakage, they decided they had to switch to the lower leakage power product.Article: 77117
> So, I think I had it in my head originally that _all_ the 8 FFs in a slice > could be chosen from to drive _any_ of the LUTs in that slice, such that the > delays from FF to LUT were evenly matched. At present this relies on routing > outside the slice, and so the delays would be badly characterised. Then I > thought it might be possible to up the number of FFs to (say) 16 in a slice > to make this more viable. This gives you a 2:1 FF to LUT ratio. But, you > need a big switching thingy to get the FFs to the LUTs. Some kind of subset > might be fine though. Also, maybe you only need 2 registered inputs per LUT > to get a big saving in glitch energy. I *think* you mean a CLB everywhere you say a slice (a slice is 2 LUTs + 2 FFs + Goo, I believe). I am not too familiar with Xilinx's interslice routing. However, in our products you can get from a FF of one Logic Element (FF + LUT pair) to any other LE/LUT in the same Logic Array Block or LAB (a set of 8/10/16 LEs). The delay from any flop to any LUT in the same LAB is very similar -- for the purposes of power & glitching you could consider these paths to be matched. Now adding additional FFs... FFs are area hungry (and power hungry...), and it is rare for a design to use all (or even half) the FFs that are already in our parts (with a 1:1 LUT/FF ratio). So these additional FFs would be wasteful of area, and you'd have to ask whether that area was better spent in other ways, or not at all (thus reducing Si cost). > In thinking this, I assumed that the LUT takes up much more silicon area > than the FF, after all the LUT has 16 bits, plus all that address muxing. > (Indeed, it's the switching of all that LUT silicon that we want to reduce.) > Is that a valid assumption? So, it doesn't make that big a difference to the > LE area (see, I know a bit of Alteraese!). Once you add in all the goo that comes with a FF (sync clear, asynch clear, clock selection, sync load, etc.) they become surprisingly large. But the second (or more FFs) would not need to be fully featured and so I'll grant you that they wouldn't be huge. But you'd be surprised at the lengths we go to cut even 1% area out of the LE. > Finally, what 'other power reduction circuitry' are you thinking of? Or is > it secret? ;-) Which ones am I thinking of? That's secret :-) But you can do a literature search on low-power design in FPGAs and ASICs and you'll see there are oodles of ideas out there, some or all of which cause some area bloat in exchange for better power. > p.s. Do you have any comment on my post on the 9th Dec about whether certain > LUT inputs are more thirsty than others? Sorry, my news server has been really flaky this month. I've had to resort to using Google groups now. I'll take a look when I get a chance. Paul Leventis Altera Corp.Article: 77118
Hello, I too want to be able to do this too--but I want to do it before the vxWorks OS is up--actually, I want to use this capability to copy a vxWorks image off of the CF into RAM and then jump to the RAM image. I am not certain of the CF formatting--I want to use it just like Xilinx provides on the ML310 development board. I've not been able to find any Xilinx driver/info that supports file IO at the Xilinx level. I saw some earlier posts of persons trying to use FILE* and standard file IO things--but I haven't found anything that indicates this level of file IO is supported. Can anyone clarify or if you've done something similar, share? Thanx, PaulArticle: 77119
"Paul Leventis" <paul.leventis@utoronto.ca> wrote in message news:1103819207.873804.224540@c13g2000cwb.googlegroups.com... > > I *think* you mean a CLB everywhere you say a slice (a slice is 2 LUTs > + 2 FFs + Goo, I believe). I am not too familiar with Xilinx's > interslice routing. However, in our products you can get from a FF of > one Logic Element (FF + LUT pair) to any other LE/LUT in the same Logic > Array Block or LAB (a set of 8/10/16 LEs). The delay from any flop to > any LUT in the same LAB is very similar -- for the purposes of power & > glitching you could consider these paths to be matched. <snipped interesting stuff> Yes, I did mean CLB, thanks for working that out! Thanks for your comments, Syms.Article: 77120
Vaughn, And: http://www.national.com/appinfo/power/files/NationalAlteraDesignGuide.pdf For yet another power vendor who just got those darned numbers wrong. Austin Austin Lesea wrote: > Vaugn, > > See below, > > Austin > > -snip- > >> >> Austin, >> >> I don't know where you're getting these surge numbers from. To my >> knowledge >> Altera never quoted surge currents that high for 2S180s. > > > Bellnix Power supply guide, TI power supply guide, ST power supply > guide...basically your power supply parnters. So, all I can conclude is > that Altera told their power vendors what the start up surge was. > > http://dkc3.digikey.com/PDF/Marketing/FPGA_Altera.pdf > http://focus.ti.com/lit/ml/slyb113/slyb113.pdf > http://www.bellnix.com/fpga/P-M-R-G1.pdf > > ... > > all state 16 amperes. So if you didn't tell them, who did? If I am an > engineer, and I need to design a power system, I would be using these > guidelines. > >> >> The TI App note you quoted appears to be a miscommunication, since those >> numbers are much too high to be either surge or leakage currents. >> > > Very effective miscommunication there. Better go talk to all your power > vendors and let them know that they all quoted the wrong numbers. I > have supplied you with the list above, so you're welcome. > > I could understand if your had an early ES version of the part, and > perhaps this high current surge was due to fault on an errate sheet, but > the 2S180 isn't sampling yet. Maybe this was based on an extrapolation > of the 2S60? > > So, is there a surge, or no? You imply that all that is needed is the > leakage to be overcome (just like our parts since Virtex II). Even your > spreadsheet mentions the word "inrush" (6, 1 and 2 amperes for the three > supplies). The IO and PD supplies need 8 mA and 15 mA respectively > (idle) so why do they need 1 and 2 amperes to start up? I think that is > called a Power On Surge (POS)? > >> >>> Too bad, though. The LX200 is 3.3 amperes, worst case - leakage only, at >>> 85C. Typical is 1.3 amperes at 85C. No start up surge to worry about. >>> And the LX200 is a lot more memory, LUTs and FFs than the EP2S180... >> >> >> >> Altera's power tools take leakage into account in the power-up current >> they >> display. So the 1.8 A to 5.3 A of ICC Inrush current is the total current >> needed to power up the device, including both leakage and any surge >> current. > > > That is as it should be. Everyone here does like your power > spreadsheet, it has nice formatting, and a clean look. It does have > some buggy pop-up windows that tend to stick around and annoy, but > otherwise it is a really good and useful spreadsheet tool. Now the only > question is: is it accurate? > >> >> The 5.3 A value is power-up current for worst-case silicon >> characteristics, >> at 85 C. Is your 3.3 A leakage number for the worst-case power process >> corner silicon at 85 C, > > > Yes, it is. > > or just typical or unspecified silicon at 85 C? > > No, it is not. > > The > >> difference is significant. Leakage increases as threshold voltage >> drops (or >> channel length decreases, etc.), so we have provided numbers for both >> typical process and the highest power units. > > > And so did I. > > Interesting you bring this up. A customer demanded to see proof of our > LX60 leakage numbers, as they had designed in the 2S60. > > They frankly could not belive the numbers. All of the 90nm products > they were familiar with had horrible leakage. When we told them that we > used a triple oxide technology, and that is how we controlled the > leakage, they basically still couldn't believe it. > > When we not only provided them with parts and demo boards, and > characterization data on leakage, they decided they had to switch to the > lower leakage power product.Article: 77121
the thing that created this mess of mis-understanding is the fact that - nearly all the pci cards that an end-user like me uses, are target only devices. (there is another category called bus-maters, which i was unaware of.) so naturally i thought - if all devices are targets then the master must be the arbitar; and as it initiates the transaction, i could call it as an initiator! the right thing is (plz verify) - 1. nearly all devices are target-only. 2. bus-maters are also pci cards that can initiate transaction. 3. usually the cpu itself is the bus master or simply the master. 4. the arbiter controls these targets and masters. so in short (in general) - target-only pci card = slave cpu = master arbiter = controller i think i have put it right this time! (have i really ? ;-) ) anyway, thanks for all the replies and help. regards, Shreyas KulkarniArticle: 77122
Austin Lesea <austin@xilinx.com> writes: > "Large" is not in S3 vocabulary. They (Spartan) have no "large" > devices.....by definition. If it is "large" then it belongs to the > Virtex family.....also by definition. > > That said, the 3S5000 is a pretty "large" part, but still a lot > smaller than the XCV4LX200 (largest V4 basic logic device). OK. Having used so many smaller parts in the past, I still have a hard time not thinking of the XC3S1000 and XC3S1500 as "large".Article: 77123
Hi there. I'm new to PLD devices, and thought that building a VGA controller would be fairly simple. I can't for the life of me get the damn thing to work though, more specifically I can't get the monitor to sync. I've disconnceted Green and Red and have tied Blue high. I'm trying to spit out 640x480 at 52Hz. I'm hoping that I've done something really simple wrong with the timings, so I've uploaded the output of a simulation - can anyone have a look at it and tell me if I have? Thanks.. Simulation output is at http://82.147.17.182/vga.vwf . Thanks.Article: 77124
randomdude@gmail.com (Alan Randomdude) wrote in news:d2b05bc6.0412231415.13412387@posting.google.com: > http://82.147.17.182/vga.vwf Here's a document that we wrote on a VGA generator. Maybe it will help you get your sync timing correct. http://www.xess.com/appnotes/an-101204-vgagen.pdf -- ---------------------------------------------------------------- Dave Van den Bout XESS Corp. PO Box 33091 Raleigh NC 27636 Phn: (919) 363-4695 Fax: (801) 749-6501 devb@xess.com http://www.xess.com
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