Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 56950

Article: 56950
Subject: Re: Dr. Leaky responds
From: Austin Lesea <Austin.Lesea@xilinx.com>
Date: Thu, 19 Jun 2003 08:45:30 -0700
Links: << >>  << T >>  << A >>
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
Subject: Re: applying SCHMITT_TRIGGER to CoolRunner-II CPLD's
From: Arthur <>
Date: Thu, 19 Jun 2003 08:52:29 -0700
Links: << >>  << T >>  << A >>
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 constraint


Article: 56952
Subject: Re: Xilinx ISE is putting this signal assignment in the wrong timing constraint group...
From: "Francisco Rodriguez" <prodrig@disca.upv.es>
Date: Thu, 19 Jun 2003 18:14:37 +0200
Links: << >>  << T >>  << A >>
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: 56953
Subject: Re: Spartan3 in WebPack
From: Steve Lass <lass@xilinx.com>
Date: Thu, 19 Jun 2003 11:03:25 -0600
Links: << >>  << T >>  << A >>
Uwe 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
Subject: Re: Dr. Leaky responds
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: Thu, 19 Jun 2003 17:07:58 +0000 (UTC)
Links: << >>  << T >>  << A >>
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.edu

Article: 56955
Subject: Re: Xilinx Spartan download with Parallel III cable
From: "Kasper Pedersen" <ngfilter@kasperkp.dk>
Date: Thu, 19 Jun 2003 21:42:25 +0200
Links: << >>  << T >>  << A >>

"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'.

/Kasper



Article: 56956
Subject: Re: Altera FPGA
From: Paul Cousoulis <paulcsouls@worldnet.att.net>
Date: Thu, 19 Jun 2003 19:47:21 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: How one specifies Icco, Iccint quiescent...
From: Austin Lesea <Austin.Lesea@xilinx.com>
Date: Thu, 19 Jun 2003 13:11:46 -0700
Links: << >>  << T >>  << A >>
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
Subject: 0.13u leakage
From: Austin Lesea <Austin.Lesea@xilinx.com>
Date: Thu, 19 Jun 2003 13:14:44 -0700
Links: << >>  << T >>  << A >>
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
Subject: Re: Cyclone vs. Acex consumption?
From: Eric Smith <eric-no-spam-for-me@brouhaha.com>
Date: 19 Jun 2003 13:51:52 -0700
Links: << >>  << T >>  << A >>
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,
Eric



Article: 56960
Subject: Re: Altera FPGA
From: "Leon Heller" <leon_heller@hotmail.com>
Date: Thu, 19 Jun 2003 20:53:28 +0000 (UTC)
Links: << >>  << T >>  << A >>

"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_heller



Article: 56961
Subject: Re: Tristate
From: smukthav@yahoo.com (Sandeep)
Date: 19 Jun 2003 14:35:01 -0700
Links: << >>  << T >>  << A >>
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
Subject: Re: Stapl Player vs. SVF Player
From: moyer119@yahoo.com (Mark Moyer)
Date: 19 Jun 2003 14:46:32 -0700
Links: << >>  << T >>  << A >>
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.com

Article: 56963
Subject: Re: Cyclone vs. Acex consumption?
From: Austin Lesea <Austin.Lesea@xilinx.com>
Date: Thu, 19 Jun 2003 14:54:03 -0700
Links: << >>  << T >>  << A >>
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,
> Eric


Article: 56964
Subject: Partial Reconfiguration
From: m_perez_gutierre@hotmail.com (=?ISO-8859-1?Q?Mois=E9s?=)
Date: 19 Jun 2003 15:08:48 -0700
Links: << >>  << T >>  << A >>
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
Subject: Re: Spartan3 in WebPack
From: Lukasz Salwinski <lukasz@mbi.ucla.edu>
Date: Thu, 19 Jun 2003 15:17:49 -0700
Links: << >>  << T >>  << A >>
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
Subject: Re: Cyclone vs. Acex consumption?
From: rickman <spamgoeshere4@yahoo.com>
Date: Thu, 19 Jun 2003 18:31:08 -0400
Links: << >>  << T >>  << A >>
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 FAX

Article: 56967
Subject: Re: Dr. Leaky responds
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Fri, 20 Jun 2003 10:36:20 +1200
Links: << >>  << T >>  << A >>
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 ?

-jg

Article: 56968
Subject: Re: No longer talking about power consumption....
From: rickman <spamgoeshere4@yahoo.com>
Date: Thu, 19 Jun 2003 18:45:37 -0400
Links: << >>  << T >>  << A >>
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 FAX

Article: 56969
Subject: Re: PC-104 dev Boards
From: H. Peter Anvin <hpa@zytor.com>
Date: 19 Jun 2003 17:19:37 -0700
Links: << >>  << T >>  << A >>
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-64

Article: 56970
Subject: Re: PC-104 dev Boards
From: H. Peter Anvin <hpa@zytor.com>
Date: 19 Jun 2003 17:20:24 -0700
Links: << >>  << T >>  << A >>
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-64

Article: 56971
Subject: Re: Dr. Leaky responds
From: Peter Alfke <peter@xilinx.com>
Date: Thu, 19 Jun 2003 17:26:58 -0700
Links: << >>  << T >>  << A >>
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
Subject: Re: XCV 6000 data sheets
From: prashantj@usa.net (Prashant)
Date: 19 Jun 2003 17:40:02 -0700
Links: << >>  << T >>  << A >>
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,
> > Prashant

Article: 56973
Subject: Re: XST verilog problem
From: muthu_nano@yahoo.co.in (Muthu)
Date: 19 Jun 2003 20:13:44 -0700
Links: << >>  << T >>  << A >>
> 
> 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,
Muthu

Article: 56974
Subject: How to design an adaptive filter
From: Kuan Zhou <zhouk@rpi.edu>
Date: Thu, 19 Jun 2003 23:14:25 -0400
Links: << >>  << T >>  << A >>
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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search