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
Jim, I weigh in here to help Peter, as I am the one closest to the technology group. A comment anbout Pentium: did you know that it starts dropping clock cycles when the Tj > 55C and turns itself OFF totally when the Tj>90C? So you get the 2.4GHz all right, but only if the heatsinking solution can keep that Tj below 55C. Else, you basically have a 1GHz processor (or even slower). Since we are in no way in the same league as Intel (they rule the motherboard, and I mean rule), we have to make chips that mere mortals can actually use. See below, Austin -snip- > Darn, my 150mW guess was a bit low, tho I could claim that was meaning > the core only, and not the Iccaux :) > > A couple of questions appear in these numbers. > > Q: I can understand the core has junctions by the truckload, but > why the Icc aux - where is this going ? Iccaux is used for: the DCM delay lines, IO predrivers, LVDS bias circuits, and the pass gate supply (which is a few hundred mV higher than Vccint). Most of this is analog stuff: op-amps, band gap references, regulators, and doesn't increase with temp. This is in a technical answer on our website. > Q: numbers are 3:1 for 50:1000, suggests a junction-count ratio of > only 3:1 between 50 & 1000 device - sounds low ? Hey, what can we say? It is based on a combiantion of actual measurement of real parts, and projections to the ones we haven't seen yet. We have the 50 and the 1000 for months now, so those are real... > Q: how do these scale with Temp ? The subthreshold drain source leakage can increase by as much as 10:1 from room temp to > 100C in theory. Theory (ie the spice models) have never been quite as bad as reality once the process is stable and running smoothly. But given that folks like the fastest parts, that results in a push for lower Vts, and that results in more leakage. Wheras we used to be able to squeeze lots more performance out of a process, it is more like getting blood from a stone now. Have to be really careful how we decide to go with the process. Lucky for us, our fabs have absolutely suberb process control. --end snip--Article: 56951
Is this a schematic design? Check the fitter report to see if sw1_ibuf is the top level port name. I suspect that sw1_ibuf may be the name that you applied to the net driven by the IBUF in the design. Name the net between the pad and the input of the IBUF and use that for your Schmitt trigger constraintArticle: 56952
Hello Ken
"Ken" <aeu96186_MENOWANTSPAM@yahoo.co.uk> escribió en el mensaje
news:bcpmji$qlp$1@dennis.cc.strath.ac.uk...
>
> Hello folks,
>
> I am having some trouble with multi-cycle constraints and ISE considering
> some paths in the wrong timing group - I have quoted the relevant VHDL -
it
> is short and very simple RTL so shouldn't take much to look at I hope
:-)
> . Thanks very much for your time.
>
> I have a signal H1_V_1_P0 that is assigned like this on each rising edge
of
> CLK:
>
> _______________________________
> DeMux_Proc : process (CLK)
>
> begin
>
> if (CLK'event and CLK='1') then
>
> case InputMUX_Cnt is
>
> when 0 => H1_V_1_P0 <= signed(X); -- ***********
> when 1 => H0_V_1_P0_D1 <= signed(X);
> when others => H0_V_1_P0_D1 <= (others => '0');
>
> end case;
>
> end if;
>
> end process;
> __________________________
>
> then, H1_V_1_P0 is used in the 2nd addition line below to assign the
> H1_V_9_P1 signal - this assignment takes place using a clock enable CLKEN
> which is enabled every two rising edges of CLK (CLKEN is derived directly
> from CLK via a counter).
>
> AssignProc : process (CLK, CLKEN)
>
> begin
>
> if (CLK'event and CLK='1') then
>
> if (CLKEN = '1') then
>
> H1_V_1_P1 <= H1_V_1_P0;
>
> -- ***********
> H1_V_9_P1 <= RESIZE((H1_V_1_P0 & "000") + RESIZE(H1_V_1_P0,16),16);
>
> end if;
>
> end if;
>
> end process;
>
> __________________________
>
> I synthesise my code (there is a lot more than the snippets above) in
> Synplify 7.2 targetting a xc2v3000fg676-5 and then place and route in ISE
> 5.2.03i using the following constraints:
>
> NET "CLK*" TNM_NET = "CLK";
> TIMESPEC "TS_CLK" = PERIOD "CLK" 4.1 ns HIGH 50 %;
> NET "clken*" TNM_NET = "CLKEN";
> TIMESPEC "TS_CLKEN" = FROM "CLKEN" TO "CLKEN" "TS_CLK" * 2;
If I understand your point correctly, you want specify a multipath cycle
starting at H1_V_1_P0 and ending at H1_V_1_P1, right?
Then, your TIMESPEC should not use CLKEN, but those signals.
That is, you're telling the synthesizer that all paths starting
at CLKEN and ending at CLKEN are 2-cycle path, but telling nothing
about those paths from H1_V_1_P0 to H1_V_1_P1.
That is, I think your second constraint should be (following the Answer
Record #9416)
NET "H1_V_1_P0*" TNM_NET = "MULTICYCLE_FROM";
NET "H1_V_1_P1*" TNM_NET = "MULTICYCLE_TO";
TIMESPEC "TS_CLKEN" = FROM "MULTICYCLE_FROM" TO "MULTICYCLE_TO" "TS_CLK" *
2;
Hope this helps.
It would be interesting to know if this is indeed the correct way to specify
multicycle paths,
so tell us if this work for you.
>
> So, CLK is about 240MHz and CLKEN is about 120MHz.
>
> The TS_CLKEN timing constraint analyses 39487 items with no timing errors
at
> all.
>
> The TS_CLK constraint analyses 1326 items and finds one failing path (full
> report at end of message):
>
> ===============================================================
> Timing constraint: TS_CLK = PERIOD TIMEGRP "CLK" 4.100 nS HIGH
50.000000
> % ;
>
> 1326 items analyzed, 1 timing error detected. (1 setup error, 0 hold
> errors)
> Minimum period is 4.441ns.
> --------------------------------------------------------------------------
--
> ----
> Slack: -0.341ns (requirement - (data path - clock skew))
> Source: h1_v_1_p0[3] (FF)
> Destination: h1_v_9_p1[12] (FF)
> _______________________________________
>
> You've guessed it - h1_v_1_p0 to h1_v_9_p1 is failing...
>
> THE BIG QUESTION
>
> Why is this path being considered under the TS_CLK constraint when the
> process in which this path belongs (AssignProc) is enabled using CLKEN and
> should hence come under the TS_CLKEN constraint?
>
> There are several other processes in the code enabled using CLKEN in the
> same manner as the AssignProc process and they are not complaining (and
must
> be being considerd as being under TS_CLKEN since these processes form the
> majority of the code and 39487 items come under TS_CLKEN.
>
> Can anyone shed any light or point me in the right direction?
>
> Thanks very much again for your time,
>
> Ken
>
Regards,
Francisco Rodriguez
================================================================
Francisco Rodriguez Ballester (prodrig@disca.upv.es)
Postal address: Dept. DISCA, EUI - Univ. Politecnica de Valencia
c/Camino de Vera s/n, E-46022, VALENCIA (SPAIN)
tlf: +(34) 96 387 70 07 ext. 75759 - fax: +(34) 96 387 75 79
================================================================
>
>
>
>
>
> START full post par static timing report:
>
>
============================================================================
> ====
> Timing constraint: TS_CLK = PERIOD TIMEGRP "CLK" 4.100 nS HIGH
50.000000
> % ;
>
> 1326 items analyzed, 1 timing error detected. (1 setup error, 0 hold
> errors)
> Minimum period is 4.441ns.
> --------------------------------------------------------------------------
--
> ----
> Slack: -0.341ns (requirement - (data path - clock skew))
> Source: h1_v_1_p0[3] (FF)
> Destination: h1_v_9_p1[12] (FF)
> Requirement: 4.100ns
> Data Path Delay: 4.439ns (Levels of Logic = 5)
> Clock Skew: -0.002ns
> Source Clock: CLK_c rising at 0.000ns
> Destination Clock: CLK_c rising at 4.100ns
>
> Data Path: h1_v_1_p0[3] to h1_v_9_p1[12]
> Location Delay type Delay(ns) Physical Resource
> Logical Resource(s)
> ------------------------------------------------- -------------------
> SLICE_X15Y20.XQ Tcko 0.493 h1_v_1_p0(3)
> h1_v_1_p0[3]
> SLICE_X14Y16.F4 net (fanout=3) 0.509 h1_v_1_p0(3)
> SLICE_X14Y16.COUT Topcyf 0.755 h1_v_9_p1(3)
> un7_h1_v_9_p1_axb_0
> un7_h1_v_9_p1_cry_0
> un7_h1_v_9_p1_cry_1
> SLICE_X14Y17.CIN net (fanout=1) 0.000
un7_h1_v_9_p1_cry_1/O
> SLICE_X14Y17.COUT Tbyp 0.092 h1_v_9_p1(5)
> un7_h1_v_9_p1_cry_2
> un7_h1_v_9_p1_cry_3
> SLICE_X14Y18.CIN net (fanout=1) 0.000
un7_h1_v_9_p1_cry_3/O
> SLICE_X14Y18.COUT Tbyp 0.092 h1_v_9_p1(7)
> un7_h1_v_9_p1_cry_4
> un7_h1_v_9_p1_cry_5
> SLICE_X14Y19.CIN net (fanout=1) 0.000
un7_h1_v_9_p1_cry_5/O
> SLICE_X14Y19.COUT Tbyp 0.092 h1_v_9_p1(9)
> un7_h1_v_9_p1_cry_6
> un7_h1_v_9_p1_cry_7
> SLICE_X14Y20.CIN net (fanout=1) 0.000
un7_h1_v_9_p1_cry_7/O
> SLICE_X14Y20.Y Tciny 1.257 h1_v_9_p1(11)
> un7_h1_v_9_p1_cry_8
> un7_h1_v_9_p1_s_9
> SLICE_X15Y23.BY net (fanout=1) 0.827 un7_h1_v_9_p1_s_9
> SLICE_X15Y23.CLK Tdick 0.322 h1_v_9_p1(12)
> h1_v_9_p1[12]
> ------------------------------------------------- -------------------
--
> ------
> Total 4.439ns (3.103ns logic,
> 1.336ns route)
> (69.9% logic, 30.1%
> route)
>
> --------------------------------------------------------------------------
--
> ----
> Slack: -0.340ns (requirement - (data path - clock skew))
> Source: h1_v_1_p0[2] (FF)
> Destination: h1_v_9_p1[12] (FF)
> Requirement: 4.100ns
> Data Path Delay: 4.438ns (Levels of Logic = 4)
> Clock Skew: -0.002ns
> Source Clock: CLK_c rising at 0.000ns
> Destination Clock: CLK_c rising at 4.100ns
>
> Data Path: h1_v_1_p0[2] to h1_v_9_p1[12]
> Location Delay type Delay(ns) Physical Resource
> Logical Resource(s)
> ------------------------------------------------- -------------------
> SLICE_X15Y20.YQ Tcko 0.493 h1_v_1_p0(3)
> h1_v_1_p0[2]
> SLICE_X14Y17.F2 net (fanout=2) 0.687 h1_v_1_p0(2)
> SLICE_X14Y17.COUT Topcyf 0.668 h1_v_9_p1(5)
> un7_h1_v_9_p1_axb_2
> un7_h1_v_9_p1_cry_2
> un7_h1_v_9_p1_cry_3
> SLICE_X14Y18.CIN net (fanout=1) 0.000
un7_h1_v_9_p1_cry_3/O
> SLICE_X14Y18.COUT Tbyp 0.092 h1_v_9_p1(7)
> un7_h1_v_9_p1_cry_4
> un7_h1_v_9_p1_cry_5
> SLICE_X14Y19.CIN net (fanout=1) 0.000
un7_h1_v_9_p1_cry_5/O
> SLICE_X14Y19.COUT Tbyp 0.092 h1_v_9_p1(9)
> un7_h1_v_9_p1_cry_6
> un7_h1_v_9_p1_cry_7
> SLICE_X14Y20.CIN net (fanout=1) 0.000
un7_h1_v_9_p1_cry_7/O
> SLICE_X14Y20.Y Tciny 1.257 h1_v_9_p1(11)
> un7_h1_v_9_p1_cry_8
> un7_h1_v_9_p1_s_9
> SLICE_X15Y23.BY net (fanout=1) 0.827 un7_h1_v_9_p1_s_9
> SLICE_X15Y23.CLK Tdick 0.322 h1_v_9_p1(12)
> h1_v_9_p1[12]
> ------------------------------------------------- -------------------
--
> ------
> Total 4.438ns (2.924ns logic,
> 1.514ns route)
> (65.9% logic, 34.1%
> route)
>
> --------------------------------------------------------------------------
--
> ----
> Slack: -0.315ns (requirement - (data path - clock skew))
> Source: h1_v_1_p0[0] (FF)
> Destination: h1_v_9_p1[12] (FF)
> Requirement: 4.100ns
> Data Path Delay: 4.412ns (Levels of Logic = 5)
> Clock Skew: -0.003ns
> Source Clock: CLK_c rising at 0.000ns
> Destination Clock: CLK_c rising at 4.100ns
>
> Data Path: h1_v_1_p0[0] to h1_v_9_p1[12]
> Location Delay type Delay(ns) Physical Resource
> Logical Resource(s)
> ------------------------------------------------- -------------------
> SLICE_X15Y18.YQ Tcko 0.493 h1_v_1_p0(1)
> h1_v_1_p0[0]
> SLICE_X14Y16.F1 net (fanout=2) 0.482 h1_v_1_p0(0)
> SLICE_X14Y16.COUT Topcyf 0.755 h1_v_9_p1(3)
> un7_h1_v_9_p1_axb_0
> un7_h1_v_9_p1_cry_0
> un7_h1_v_9_p1_cry_1
> SLICE_X14Y17.CIN net (fanout=1) 0.000
un7_h1_v_9_p1_cry_1/O
> SLICE_X14Y17.COUT Tbyp 0.092 h1_v_9_p1(5)
> un7_h1_v_9_p1_cry_2
> un7_h1_v_9_p1_cry_3
> SLICE_X14Y18.CIN net (fanout=1) 0.000
un7_h1_v_9_p1_cry_3/O
> SLICE_X14Y18.COUT Tbyp 0.092 h1_v_9_p1(7)
> un7_h1_v_9_p1_cry_4
> un7_h1_v_9_p1_cry_5
> SLICE_X14Y19.CIN net (fanout=1) 0.000
un7_h1_v_9_p1_cry_5/O
> SLICE_X14Y19.COUT Tbyp 0.092 h1_v_9_p1(9)
> un7_h1_v_9_p1_cry_6
> un7_h1_v_9_p1_cry_7
> SLICE_X14Y20.CIN net (fanout=1) 0.000
un7_h1_v_9_p1_cry_7/O
> SLICE_X14Y20.Y Tciny 1.257 h1_v_9_p1(11)
> un7_h1_v_9_p1_cry_8
> un7_h1_v_9_p1_s_9
> SLICE_X15Y23.BY net (fanout=1) 0.827 un7_h1_v_9_p1_s_9
> SLICE_X15Y23.CLK Tdick 0.322 h1_v_9_p1(12)
> h1_v_9_p1[12]
> ------------------------------------------------- -------------------
--
> ------
> Total 4.412ns (3.103ns logic,
> 1.309ns route)
> (70.3% logic, 29.7%
> route)
>
> --------------------------------------------------------------------------
--
> ----
>
>
============================================================================
> ====
> Timing constraint: TS_CLKEN = MAXDELAY FROM TIMEGRP "CLKEN" TO TIMEGRP
> "CLKEN" TS_CLK * 2.000 ;
>
> 39487 items analyzed, 0 timing errors detected. (0 setup errors, 0 hold
> errors)
> Maximum delay is 8.142ns.
> --------------------------------------------------------------------------
--
> ----
>
>
> --
> To reply by email, please remove the _MENOWANTSPAM from my email address.
>
>
Article: 56953Uwe Bonnes wrote: >Steve Lass <lass@xilinx.com> wrote: >: Lukasz Salwinski wrote: > >:> Amontec Team, Laurent Gauch wrote: >:> >:>> Steve Lass wrote: >:>> >:>>> The 3S50, 3S200 and 3S400 will be included in the 6.1i WebPACK >:>>> (coming this Fall). >:>> >:> >:> Is this new WebPack going to run under Linux > >: Not in the 6.1i release. Even though ISE will run on Linux, we will >: probably wait until 7.1 for the WebPACK. > >Okay, wine still needed. > >:> (at least, with Wine) >:> I'm particularly interested in getting iMPACT there. > >: It depends on which cable you are using. The parallel 3 and 4 cables >: will not run under Linux because the drivers >: are different. We haven't tested it yet, but serial cables (Multilinx) >: should work under Wine. The iMPACT gui >: should run on Wine as well. > >Steve, any chance that Xilinx delivers the Linux Windriver with webpack or >in any other way? > WinDriver comes from a company named Jungo (http://www.jungo.com). They say they support Linux, but I don't think we have tried it. Steve > >That way I could write an indirection layer in Wine, that accepts the >Windows IOCTRL and resubmits them to the Linux kernel as Linux IOCTRLs?(*) > >I would resubmit to CVS wine... > >Bye > >(*) Despite that: The concept of "Windriver" is totally broken from a security >point of view. E.g. with the parport/ppdev device, on Linux there is a >generic and transparent way to handle the parallel port without breaking all >seciurity. > >Article: 56954
In article <3EF1DA9A.8D313F92@xilinx.com>, Austin Lesea <Austin.Lesea@xilinx.com> wrote: > A comment anbout Pentium: did you know that it starts dropping clock > cycles when the Tj > 55C and turns itself OFF totally when the > Tj>90C? So you get the 2.4GHz all right, but only if the > heatsinking solution can keep that Tj below 55C. Else, you > basically have a 1GHz processor (or even slower). Well, the Pentium 4. The P Pro-P3 family did not have this feature. IMO, its a useful one, especially given the environment those chips go in, and it would be nice if the Xilinx thermal diodes (DXP/DXN) could be internally read, and were scattered more throughout the die, to enable similar functionality. But probably not WORTH it per se, because people should have the cooling solution sufficient for their designs with Xilinx, and Xilinx can (hopefully) count on that, because end consumers aren't assembling systems and swapping out heatsinks. There was a great video a couple years back of removing the heatsink from a running P4 (it clocked back quickly) and an Athlon (the athlon nearly exploded!). -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 56955
"Falk Brunner" <Falk.Brunner@gmx.de> wrote in message news:bbt805$d2uka$2@ID-84877.news.dfncis.de... > > "David Kinsell" <kinsell@poboxyz.com> schrieb im Newsbeitrag > news:6kdEa.891727$Zo.202680@sccrnsc03... > > > I've seen multiple computers where the P-III cable would not > > load a Spartan part through JTAG, but just tacking the small cap > > on TCK fixed the problem. Totally fair side-by-side comparison. > > > The schmitt-triggers are cheap and bullet-proof. And a fully academic > recognized solution ;-) I know the thread is out of date, but I have something to add that might be of value to some. First, the parallel port itself is a problem on some systems: In times past, there existed something called the ISA bus, and the parallel port today is still typically on ISA (although on a bridge, even on systems that don't have ISA slots), and this bus asserts write before data is stable. Some ports use(d) transparent latches, resulting in spurious transitions when you write to the port. When you attach a fast TAP device, nothing good happens. Even if the port uses edge triggered latches as it's supposed to, there may still be a cable crosstalk/reflection problem. The original Xilinx cable has terrible groundbounce and crosstalk, so RC filters (250 ns is good, the write cycle takes 1+ us in existing chipsets) AND schmitt-triggers are a very good thing. Then it also copes with almost any pc-side cable, and I've had to use some long ones. If one uses flying leads or ditto probes, consider not using HC/HCT or similar devices directly: Although slow by today's standards, they still have fast risetimes, and cause groundbounce between the target and the interface. I have used 100 ohm, 4 uH, 470p output RLC filters and 75 ohm series termination for driving long flyleads, and limiting the slewrate to 37V/us (still fast enough to satisfy the device) like this has allowed me to use rather long wires while not putting out too much RF. I hope they don't stop supporting the *simple* Parallel-3 interface. I've seldomly used the original cable, but I've built a lot of odd implementations, including a fiberoptic version, and knowing the above, I've never had problems at the 'physical layer'. /KasperArticle: 56956
You can build your own ByteBlaster(BitBlaster? The one that connects to the Parallel Port). The circuit is in the Application notes. It's just a '244 buffer. I think the MAX7000's are very friendly chips. Paul Christopher wrote: > > Hi! > > Does anyone know or have used the Quartus II? If so, I am looking for > an inexpensive FPGA such that I can build a cable to communicate with > the chip directly. I don't want to purchase the programmer. Some of > these kits are $150. I am on a budget and just want to get my feet > wet. > > Can someone recommend an FPGA (or CPLD if it's best) such that I can > use Quartus II VHDL or if that application is not the best please > recommend one. > > My goal is to program an FPGA with free software and a simple cable I > can construct. Once I get the hang of it, I'll be willing to buy > something better. I don't want to spend 100s of $ on something that > doesn't work with me well. > > Can someone please give me some hints? > > Thanks!Article: 56957
Iode, In our data sheets we attempt to impart both the typical and the worst case quiescent current numbers. For example, page 3, Table 4, of http://direct.xilinx.com/bvdocs/publications/ds031-3.pdf If the data is not listed in the data sheet, it is because the product is new (or we weren't specifying a typical back when the product was released), and we haven't finished characterizing it yet. In any case, call the hotline, and open a case to get the answer (and you will get one). It is always best to get with your distributor, or representative and talk with the Field Applications Engineers for any part selection, as there are many things which could be specified, but are not (as the specification still has to be printable/downloadable in less than a few hours). Austin Iode wrote: > This is quite a remarkable info. Do you mean the "Quiescent supply current" > (Icco in the data-sheets)? And why do you report only the maximum value (3 > or 6mA, document DS06 v1.6) and not also a typical one? Basing on these > values we renounced to try a porting from Acex to Spartan in a project in > which the standby current was a very important factor. > > So I am now stuck with the Cyclone (it costs a lot less than Acex), which I > fear in standby could require a significant current. > > Iode > > "Austin Lesea" <Austin.Lesea@xilinx.com> ha scritto nel messaggio > news:3EF08BA4.19E96043@xilinx.com... > > Rick, > > > > SpartanXL is still the best FPGA when it comes to quiescent leakage > current. Most > > parts come in below 100 uA. We have customers who use the SpartanXL for > > applications where they need this extrememly low standby current. Note > that we do > > not specify this current (as it is a low cost product, and leakage current > is not > > supposed to be a limiting factor for yield). > > > > Also, don't forget startup current. SpartanXL has none, and Virtex II, II > Pro, > > and Spartan 3 have no startup current that is any larger than the standby > > current. This can not be said for other FPGAs (from X as well as ....). > > > > Austin > > > > rickman wrote: > > > > > Iode wrote: > > > > > > > > Hi to everyone, > > > > > > > > Has anyone had experience porting a design from Acex to Cyclone? What > should > > > > I expect from the point of view of power consumption? Using the > calculator > > > > tools give worrying results: comparing a c30 with a 1k50 I have 33.5mA > of > > > > standby current for Cyclone, 5 mA for Acex; I/Os consumption also > seems to > > > > be higher in Cyclone; core consumption seems to be less but, all in > all, am > > > > I going to need more or less power using Cyclone? > > > > > > > > Perhaps less power while the clock is running but more power when in > > > > stand-by? > > > > > > I am very glad you posted this question. I had been looking at using a > > > CPLD in this design for the PC/104 bus interface, but all of the parts I > > > was considering had limitations. But the ACEX 1K parts seem to meet all > > > the needs and are still relatively low power. 5 mA standby is better > > > than some of the CPLDs! I estimated a max power consumption of 40 mA > > > running at 50 Mhz so this part hangs in there with the CPLDs in terms of > > > dynamic power as well. > > > > > > If I can get a decent price, this part will solve a lot of my problems. > > > > > > BTW, I suggest that you call Altera support at 800-800-3753. I have > > > found them to be very helpful and they even answer the phone fairly > > > quickly. > > > > > > -- > > > > > > Rick "rickman" Collins > > > > > > rick.collins@XYarius.com > > > Ignore the reply address. To email me use the above address with the XY > > > removed. > > > > > > Arius - A Signal Processing Solutions Company > > > Specializing in DSP and FPGA design URL http://www.arius.com > > > 4 King Ave 301-682-7772 Voice > > > Frederick, MD 21701-3110 301-682-7666 FAX > >Article: 56958
Iode, Also, it is no secret that the 0.13u process node has significant leakage. And the leakage can be 10 times its value at 25C at 100C. Good luck, Austin Iode wrote: > This is quite a remarkable info. Do you mean the "Quiescent supply current" > (Icco in the data-sheets)? And why do you report only the maximum value (3 > or 6mA, document DS06 v1.6) and not also a typical one? Basing on these > values we renounced to try a porting from Acex to Spartan in a project in > which the standby current was a very important factor. > > So I am now stuck with the Cyclone (it costs a lot less than Acex), which I > fear in standby could require a significant current. > > Iode > > "Austin Lesea" <Austin.Lesea@xilinx.com> ha scritto nel messaggio > news:3EF08BA4.19E96043@xilinx.com... > > Rick, > > > > SpartanXL is still the best FPGA when it comes to quiescent leakage > current. Most > > parts come in below 100 uA. We have customers who use the SpartanXL for > > applications where they need this extrememly low standby current. Note > that we do > > not specify this current (as it is a low cost product, and leakage current > is not > > supposed to be a limiting factor for yield). > > > > Also, don't forget startup current. SpartanXL has none, and Virtex II, II > Pro, > > and Spartan 3 have no startup current that is any larger than the standby > > current. This can not be said for other FPGAs (from X as well as ....). > > > > Austin > > > > rickman wrote: > > > > > Iode wrote: > > > > > > > > Hi to everyone, > > > > > > > > Has anyone had experience porting a design from Acex to Cyclone? What > should > > > > I expect from the point of view of power consumption? Using the > calculator > > > > tools give worrying results: comparing a c30 with a 1k50 I have 33.5mA > of > > > > standby current for Cyclone, 5 mA for Acex; I/Os consumption also > seems to > > > > be higher in Cyclone; core consumption seems to be less but, all in > all, am > > > > I going to need more or less power using Cyclone? > > > > > > > > Perhaps less power while the clock is running but more power when in > > > > stand-by? > > > > > > I am very glad you posted this question. I had been looking at using a > > > CPLD in this design for the PC/104 bus interface, but all of the parts I > > > was considering had limitations. But the ACEX 1K parts seem to meet all > > > the needs and are still relatively low power. 5 mA standby is better > > > than some of the CPLDs! I estimated a max power consumption of 40 mA > > > running at 50 Mhz so this part hangs in there with the CPLDs in terms of > > > dynamic power as well. > > > > > > If I can get a decent price, this part will solve a lot of my problems. > > > > > > BTW, I suggest that you call Altera support at 800-800-3753. I have > > > found them to be very helpful and they even answer the phone fairly > > > quickly. > > > > > > -- > > > > > > Rick "rickman" Collins > > > > > > rick.collins@XYarius.com > > > Ignore the reply address. To email me use the above address with the XY > > > removed. > > > > > > Arius - A Signal Processing Solutions Company > > > Specializing in DSP and FPGA design URL http://www.arius.com > > > 4 King Ave 301-682-7772 Voice > > > Frederick, MD 21701-3110 301-682-7666 FAX > >Article: 56959
Austin Lesea <Austin.Lesea@xilinx.com> writes: > Also, don't forget startup current. SpartanXL has none, and Virtex > II, II Pro, and Spartan 3 have no startup current that is any larger > than the standby current. This can not be said for other FPGAs (from > X as well as ....). Are you sure that Spartan-XL has none? On page 53 of the data sheet (ds060 v1.7 dated 27-jun-2002), there's a spec for Iccpo, Total Vcc supply current required during power-on, with a minimum of 100 mA. I've got a low-power application for which I'd love to use a Spartan-XL based on the low quiescent supply current (Icco, 2.5 mA max for commercial). I can't find any Iccpo spec for Spartan. Did you mean that Spartan (not -XL) doesn't require startup current? Thanks, EricArticle: 56960
"Christopher" <blackpack3000@yahoo.com> wrote in message news:a993b408.0306181714.75e51d4e@posting.google.com... > Hi! > > Does anyone know or have used the Quartus II? If so, I am looking for > an inexpensive FPGA such that I can build a cable to communicate with > the chip directly. I don't want to purchase the programmer. Some of > these kits are $150. I am on a budget and just want to get my feet > wet. I've got the PCB design files for my version of the ByteBlaster on my web site. Leon -- Leon Heller, G1HSM leon_heller@hotmail.com http://www.geocities.com/leon_hellerArticle: 56961
c <= a when (tristate_enable = '1') else ( others => 'Z' ); b <= c; This will create a BUFT in Virtex device. kalimuddin@hotmail.com (Muhammad Khan) wrote in message news:<7d350237.0306180215.645aa5f6@posting.google.com>... > HI Fellows, > The process given below is to read and write to Vertex device ( only > vhdl part is shown here not C ). I want to tristate SR_DATA_IO_int > when not driven as read. > First of all the code below for write and read is correct or not!!!! > SR_DATA_IO_int pins ( which are 32 , I am using upper 7 bits only ) > will be acting as bi directional pins. While writing these will take > bits from PCI interface to device and while reading they will exactly > opposite. But while writing I have to tristate SR_DATA_IO_int so as to > avoid short circuiting. Any help on tristate will be highly > appreciated. > > process(CLK_2X,SR_ADDR_IO_int,SR_DATA_IO_int,SR_IRD_int,SR_IWR_int,SR_IVCS_V3_int) > begin > if RISING_EDGE(CLK_2X) then > if SR_IVCS_V3_int = '0' then > if SR_IWR_int = '0' then > if SR_ADDR_IO_int = "001100" then > RESULT <= SR_DATA_IO_int(6 downto 0); > End if ; > Elsif SR_IRD_int = '0' then > if SR_ADDR_IO_int = "001101" then > SR_DATA_IO_int(6 downto 0)<=RESULT ; > End if; > End if; > End if; > End if;Article: 56962
The majority of CPLD devices out there don't need all of the capabilities in STAPL. If your CPLD has a non-deterministic programming time then you could take advantage of the benefits of STAPL because you could get some devices programmed more quickly than others. The downside to this is that it could become difficult to predict throughput on a manufacturing line because some devices will program faster than others and if the device is already on the board then that changes the overall test time for that board. Another downside to STAPL is that only Altera is actively creating STAPL (aka JAM) file for their devices at this point. SVF is supported by the majority of test vendors (as is STAPL) but is really only a solution for Altera devices. For devices from other vendors you will probably want to use SVF or maybe even look into IEEE 1532. That is the new standard for in-system programming that is quickly being adopted. It was originally pushed for by the tester vendors, where STAPL was proposed by the device vendors, and it is based on the existing IEEE 1149.1 standard (JTAG) so long term it will probably be a better solution. Having worked on both the STAPL and the 1532 committees, I believe the 1532 solution is better. gregs@altera.com (Greg Steinke) wrote in message news:<5c1de958.0306051700.37d03e73@posting.google.com>... > Cheny <wucheny@netscape.net> wrote in message news:<bbike4$3td$1@news.storm.ca>... > > leon qin wrote: > > > Are they the same ? > > > > > > > > > > > they are different that SVF player accepts SVF files while stapl player > > accepts jam files. > > SVF and STAPL players are very different, but both can be used to > program CPLDS: > > SVF (serial vector format) is a file format used by in-circuit > testers. The programming data and algorithm for a CPLD can be written > into SVF format so in-circuit testers can program CPLDs via JTAG > during in-circuit test flow. An SVF player/interpreter, as it > pertains to PCs, would "play" the SVF file's algorithm and program the > device through a PC's parallel port during prototype. The problems > with SVF is that was not created for programming CPLDs but rather for > in-circuit test. SVF does not support branching in its language > constructs resulting in longer programming times for CPLDs. It's also > a sequential text file format - it does not support loops, resulting > in very large sequential based files. As a whole SVF would really > only be used if you were planning to production program devices > through in-circuit testers that do not support STAPL. > > STAPL is a high level language designed specifically for CPLD ISP > programming. It supports branching - which means faster programming > times. A CPLDs programming algorithm and data is stored in ASCII STAPL > or compressed byte code STAPL format. STAPL language also supports > loops (e.g. FOR). This combined with compressed byte code means very > small files. This is ideal for embedded programming where an > intelligent host or microprocessor can use the STAPL > player/interpreter to ISP program CPLDs. The STAPL player is also > available to play through DOS executable or through Altera's MAX+PLUS > II or Quartus tools in windows or UNIX environment. The Altera > MAX+PLUS II or Quartus software Programmer Tools support "playing" > STAPL files. Altera also supports generating SVF files. > > The original name of STAPL was Jam (as in Jam Player). STAPL is the > name assigned to this language during the JEDEC standardization > process. > > Sincerely, > Greg Steinke > Altera Applications > gregs@altera.comArticle: 56963
Eric, SpartanXL is the only Spartan family that has low startup, and low leakage. The Icco required for power on is actually a fairly old leftover from the non-XL process days. The Spartan XL that is now being manufactured, is actually a different animal, and has no measurable startup current requirement. Austin Eric Smith wrote: > Austin Lesea <Austin.Lesea@xilinx.com> writes: > > > Also, don't forget startup current. SpartanXL has none, and Virtex > > II, II Pro, and Spartan 3 have no startup current that is any larger > > than the standby current. This can not be said for other FPGAs (from > > X as well as ....). > > Are you sure that Spartan-XL has none? On page 53 of the data sheet > (ds060 v1.7 dated 27-jun-2002), there's a spec for Iccpo, Total Vcc > supply current required during power-on, with a minimum of 100 mA. > > I've got a low-power application for which I'd love to use a > Spartan-XL based on the low quiescent supply current (Icco, 2.5 mA > max for commercial). > > I can't find any Iccpo spec for Spartan. Did you mean that Spartan > (not -XL) doesn't require startup current? > > Thanks, > EricArticle: 56964
Does anybody knows what kind of devices actually support partial reconfiguration. I know that the Xilinx Virtex do it and I'm not sure if the Spartan3 will suppport it. Thanks in advance.Article: 56965
Steve Lass wrote: > Lukasz Salwinski wrote: > >> Amontec Team, Laurent Gauch wrote: >> >>> Steve Lass wrote: >>> >>>> The 3S50, 3S200 and 3S400 will be included in the 6.1i WebPACK >>>> (coming this Fall). >>> >>> >> >> Is this new WebPack going to run under Linux > > > Not in the 6.1i release. Even though ISE will run on Linux, we will > probably wait until 7.1 for the WebPACK. > >> (at least, with Wine) >> I'm particularly interested in getting iMPACT there. > > > It depends on which cable you are using. The parallel 3 and 4 cables > will not run under Linux because the drivers > are different. We haven't tested it yet, but serial cables (Multilinx) > should work under Wine. The iMPACT gui > should run on Wine as well. > > Steve uh.. i guess i've got to wait till 7.1 then (or find a third-party iMPACT substitute). thanks for the response lukasz >> Or, is there >> a functional iMPACT equivalent capable of programing at least SII >> devices (say Digilent boards).... >> >> >> lukasz >> >>>> John wrote: >>>> >>>>> Hello, >>>>> Does anyone know when Spartan3 devices other than the 50K will be >>>>> supported by ISE WebPack. Also, does anybody know what the largest >>>>> Spartan3 supported by the WebPack tools will be? >>>>> >>>>> Thanks >>>>> >>>>> >>>> >>> Nice feedback >>> >>> ------------ And now a word from our sponsor ------------------ >>> Do your users want the best web-email gateway? Don't let your >>> customers drift off to free webmail services install your own >>> web gateway! >>> -- See http://netwinsite.com/sponsor/sponsor_webmail.htm ---- >> >> >> >> > -- ------------------------------------------------------------------------- Lukasz Salwinski E-MAIL: lukasz@mbi.ucla.edu DOE-MBI Center for Genomics and Proteomics PHONE : 310-825-1402 UCLA, Los Angeles FAX : 310-206-3914 -------------------------------------------------------------------------Article: 56966
Iode wrote: > > This is quite a remarkable info. Do you mean the "Quiescent supply current" > (Icco in the data-sheets)? And why do you report only the maximum value (3 > or 6mA, document DS06 v1.6) and not also a typical one? Basing on these > values we renounced to try a porting from Acex to Spartan in a project in > which the standby current was a very important factor. > > So I am now stuck with the Cyclone (it costs a lot less than Acex), which I > fear in standby could require a significant current. Would you mind sharing your pricing with us (or at least me by email)? I am looking at using an ACEX part for the 5 volt tolerance and low power, but it takes time to get real prices vs. the "standard" prices. The standard price is too high on the part. I would like to know what other people have gotten this part at. I am also looking at using the Cyclone in a different socket on the same board. This part is *very* inexpensive compared to other similar parts. Until they get into full production later next year, the Spartan 3 parts will be too high for our boards. The pricing I am getting for 1Q04 is still twice that of other similar parts. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 56967
Austin Lesea wrote: > <snip> > > Q: I can understand the core has junctions by the truckload, but > > why the Icc aux - where is this going ? > > Iccaux is used for: the DCM delay lines, IO predrivers, LVDS bias circuits, and the > pass gate supply (which is a few hundred mV higher than Vccint). Most of this is > analog stuff: op-amps, band gap references, regulators, and doesn't increase with > temp. This is in a technical answer on our website. Thanks, and I guessed as much. An interesting thread indeed. Q : Are these things not 'enabled as needed' ? Sub-threshold current is a device-core issue, and until the new process tricks like Toshiba et al are talking about ripple thru to mere mortals, perhaps there is room for a solution like was used in older CPLDs: This is to use a powerdown approach (some used a dedicated PIN), that removes core power, but keeps the IO Vcc, and their static latched IO values. Everything is held at CMOS drive levels, and floating pin power issues are avoided. It is a static-DC deep sleep mode. An S3 has some problems with that (PWRaux dominates PWRcore), but what about the various older FPGA families ? -jgArticle: 56968
I understand what you are saying. A company has to hit the "sweet" spot on IO vs. core size for all of the parts. After all, companies are in business to make money and you do that by *optimizing* your products, not by selling everything anyone would want to buy. But in terms of size, you can value a part by the IO count, the core size (slices) or by die size. I have learned that what a company charges for a product is related to the utility of the product, not the cost. So some customers will pay more for IO count, others for core size, but no one cares about die size. My projects typically need more IOs than slices compared to your VII parts. The Spartan 3 400 is an example. I am happy with the slices in the XC2S150E, but in the XC3S line I need the 400 to get enough IO. So I am buying twice as much logic in the newer part. Unfortunately the price is about twice as high so I won't be using it at all. The EP1C4 is a fairly small member of the Cyclone family, but they used a staggered IO cell arrangement. Xilinx might consider doing an XC3S200 like this with a higher IO count. I assume this could be done and still keep the price much lower than the XC3S400. BTW, I still find it very irritating that Xilinx can't publish a real count of the number of FFs or LUTs in their data sheets. They still publish the "Logic Cell" count which does not count anything physical inside the chip. So every time I need a count of the LUTs and FFs, I have to try to remember how many there are in the CLBs and then do my own multiplication. On the positive side, I can use the practice multiplying by 4 and 8 in my head. Austin Lesea wrote: > > Rick, > > The question of IO vs logic is always an issue here. Thanks for the feedback on the subject. > It is something that we can never make everyone happy with. It is also something that if we > add more IO, we directly increase the die size (at these sub micron geometries) as the IO > doesn't shrink, but the core does. > > If you have some suggestions on a "family" of parts with IOs and logic sizes, I would > appreciate hearing about it. > > In fact, if anyone has a strong opinion about LUT/IO/part, fill it out and email it to me: > > (for example- need more family members, but you get the idea) > > part LUTs IOs > smallest 1500 200 > mid 15,000 500 > large 60,000 1000 > > ???? > > Austin > > rickman wrote: > > > Austin Lesea wrote: > > > > > > Rick, > > > > > > All true and accurate obsevations. > > > > > > SpartanXL has such a large following, that it is not going anywhere soon (ie it is fully > > > supported for new designs). > > > > > > For example, we still support and manufacture the 3000A and 3100A FPGAs (although not > > > recommended for new designs). Who else has support for designs that are this old? By > > > Peter's IC time scale, these are ancient history! > > > > > > Have you looked at the small Virtex II parts recently (ie for price)? The 2V40, 2V80, > > > 2V250 are all still there, and might be a good choice (no startup current)? > > > > Thanks for the ideas. I guess I had forgotten that the startup current > > was fixed in the XC2V parts. Sometimes it is hard to keep it all > > straight. But they require 1.5 volt power which is not present in that > > part of the board. The board has three separate power zones and this > > one has 5, 3.3 and 2.5 volts. I don't really want to add another > > regulator. Also 65 mA typ Iccintq is not so low. I am trying to keep > > the total FPGA power to about 50 mA or less. > > > > But the main problem is the price. Unless the web pricing is way out of > > whack, I can't afford $80 for the XC2V250 which I need to get the IO > > count. The Coolrunner starts lower than that and I still have not been > > able to get disti prices to my $20 target. The XC2V40 is really tiny > > and the XC2V80 is only a bit better. > > > > > Just because it is in the Virtex line doesn't automatically mean that it isn't used for > > > volume or low cost applications. It was the intent of the APD group here to cover the > > > smaller and higher volume applications with a more advanced product when we created the > > > smaller Virtex II parts. > > > > That sounds good to me, but the prices are way up there still. The > > XC2V40 might have some applications, but I can't use it at $25. > > > > > As with any smaller geometry, the leakage is going up (fast), so I am beginning to think > > > of Virtex II as something like "classic cola" which represents a really good > > > price/performance/feature point in the FPGA space, and one that is hard to improve upon > > > (but we never stop trying). > > > > I know it is hard to make much money on the smaller, low cost parts. > > But those are what most of our boards need. The XC3S400 fits our needs > > because of the IO count, not the slice count. For our needs it is > > actually large by any other measure. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 56969
Followup to: <3EF1C96A.448B85D6@yahoo.com> By author: rickman <spamgoeshere4@yahoo.com> In newsgroup: comp.arch.fpga > > Even so. How can you handle 88 signals with two 32 bit parts? There > are > 16 Data > 27 Addr > 11 IRQ > 14 DMA > 8 Cntl > 12 MISC > -------- > 88 Total > > Slave mode > 16 IO (Data) > 42 In > 30 Out > This is the ISA side. We're using the PCI side. -hpa -- <hpa@transmeta.com> at work, <hpa@zytor.com> in private! "Unix gives you enough rope to shoot yourself in the foot." Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64Article: 56970
Followup to: <bcs52h$ad9$1@news.tu-darmstadt.de> By author: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de> In newsgroup: comp.arch.fpga > > : I'm surprised you think they take up that much space. I'm sitting in > : front of a PC-104+ board which uses quickswitches for the voltage > : conversion and the whole set of level converters takes up a rectangle > : of about 6x40 mm. It's not insignificant, but it's quite tiny > : compared to the PC-104+ connector itself. On our board it is more > : than well compensated for by being able to use a more advanced FPGA. > > Any source for those quick switches in small quantities? > Avnet seems to have them in quantity 25 listing for $1.60 for a 32-wide part. -hpa -- <hpa@transmeta.com> at work, <hpa@zytor.com> in private! "Unix gives you enough rope to shoot yourself in the foot." Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64Article: 56971
This is Peter, so you may get answers in stereo, each channel with a slightly different pitch: Jim Granville wrote: > > Q : Are these things not 'enabled as needed' ? No, most of these things are needed whenever the part is "on". > > Sub-threshold current is a device-core issue, and until the new process > tricks like Toshiba et al are talking about ripple thru to mere mortals, > perhaps there is room for a solution like was used in older CPLDs: > > This is to use a powerdown approach (some used a dedicated PIN), > that removes core power, but keeps the IO Vcc, and their static > latched IO values. Everything is held at CMOS drive levels, and > floating pin power issues are avoided. > It is a static-DC deep sleep mode. > Well, we used power-down in the olden days of XC3000, but that just meant we disabled all inputs, and the core was left to do nothing. But such a trick would not eliminate the sub-threshold leakage current which you cannot turn off with a gate. The logic is already doing nothing, and still it consumes current! The only cure is grounding Vcc. And there are several reasons not to do that. :-) Peter Alfke >Article: 56972
Thanks guys. I guess I had the number wrong. Prashant Peter Alfke <peter@xilinx.com> wrote in message news:<3EF08C98.5309EC1D@xilinx.com>... > Sorry, I did not see the V. :-( > You are looking for the XC2V6000, the next-to-largest member of the > Virtex-II family. You find it at > http://direct.xilinx.com/bvdocs/publications/ds031-1.pdf > > Peter Alfke > ===================== > Prashant wrote: > > > > Hi, > > > > I have been unable to find a data sheet for the XCV6000 device. Have I > > got the number wrong ? Does such a device exist ? If so, where can I > > find a data sheet for this device. > > > > Thanks, > > PrashantArticle: 56973
> > That isn't quite the same, crrst is a synchronous clear in the original. I > had seen a Xilinx suggestion of moving logic expressions outside the always > block to work around the problem. What Xilinx Suggests? Can you give the modified piece of code? Regards, MuthuArticle: 56974
Hi, I want to design an adaptive bandpass filter. The filter can change its banwidth by shifting the roots based on the inputs.Does anyone know any good resources descripting that? Thank you very much! sincerely ------------- Kuan Zhou ECSE department
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