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 77100

Article: 77100
Subject: Re: low cost Altera MAX II development kit with more I/O pins?
From: "Leon Heller" <leon_heller@hotmail.com>
Date: Wed, 22 Dec 2004 16:35:54 -0000
Links: << >>  << T >>  << A >>
"Leon Heller" <leon_heller@hotmail.com> wrote in message 
news:41c996ba$0$19159$cc9e4d1f@news-text.dial.pipex.com...
> "vax, 9000" <vax9000@gmail.com> wrote in message 
> news:cqar69$5u0$1@charm.magnus.acs.ohio-state.edu...
>> Leon Heller wrote:
>>
>>>
>>> I have a supplier who can provide small quantities of Altera parts, but
>>> I'd have to order about 100 GBP worth, about $200 with shipping and tax.
>> Would you please quote the price for EPM1270? $200 could buy less than 10
>> pieces, I guess. So you (we) will have no problem to find enough people 
>> to
>> split the cost. The problem might be the shipping from the UK to the US.
>
> I've just been quoted 20.67 ($39.57) each for 25 pcs of EPM1270T144C5ES! 
> With VAT and carriage the total will be about $1200. I don't think it is 
> viable.

These people actually make what you are after: 
http://www.devboards.de/index.php?kategorie=10

Don't know if they can actually supply them, though.

Leon
-- 
Leon Heller, G1HSM
http://www.geocities.com/leon_heller
http://www.kasamba.com/viewExpert.asp?conMemID=105725&Catid=1111&banID=2100 



Article: 77101
Subject: Re: AHB master related
From: "Mike Lewis" <someone@micrsoft.com>
Date: Wed, 22 Dec 2004 11:54:40 -0500
Links: << >>  << T >>  << A >>

"san" <san_nasa@rediffmail.com> wrote in message 
news:1103713502.003743.71970@z14g2000cwz.googlegroups.com...
> question asked to arm on 22/12/2004
> -----------------------------------
> my questions are:
> 1) when the master on AHB bus is getting ready signal low from slave
> then is there any way the master start a new transaction on the bus.
> Also if slave give the error response after some predefined number of
> cycle to release the bus then is it a correct approach or is there any
> better approach to release the master and bus to do other operation.
> 2) when the slave give retry response to master then is it possible for
>
> the bus master to start a new transaction on the bus for same or
> different slave. Is it that the particular master is blocked on getting
> retry response
>

Have you looked at the amba spec supplied on the ARM website.
Proper protocol is described in that document.

I believe that once a master starts an access ... it can't do anything
else untl that transaction is completed. Split transacttions are available
but they are intended to free up the bus for other masters to use a bus
while the master that is split waits for the slave to be ready.

A retry is just that ... the master retries its cycle to that slave.

Again it is best to read the spec. ... I believe these types of transactions
are adequatly described.

Mike 



Article: 77102
Subject: Re: Using low-core-voltage devices in industrial applications
From: Jim Granville <no.spam@designtools.co.nz>
Date: Thu, 23 Dec 2004 08:36:40 +1300
Links: << >>  << T >>  << A >>
 > Vaughn Betz wrote:
 >
<snip>
 >> While other FPGA vendors only specify values for typical silicon at 25C,
 >> Altera provides start-up currents and operating power values at various
 >> temperatures and for both typical and worst-case power process corners.

Austin, why no comment on this point ?

Austin Lesea wrote:
> Vaughn,
> 
<snip>
> 
> Too bad, though. The LX200 is 3.3 amperes, worst case - leakage only, at 
> 85C.  Typical is 1.3 amperes at 85C.  No start up surge to worry about. 
>  And the LX200 is a lot more memory, LUTs and FFs than the EP2S180...

  Hmmm... When will we see the first thermal-runaway failures of FPGAs ?
Could be time to start teaching thermal-runaway again in the classes,
( and the data sheets... ) and perhaps the tools should  perform some 
'thermal spreading' to prevent hot spots (since thermal effects are non 
linear, and one can easily get an additional 40-50'C die above case ).

-jg


Article: 77103
Subject: Re: Using low-core-voltage devices in industrial applications
From: Austin Lesea <austin@xilinx.com>
Date: Wed, 22 Dec 2004 14:59:33 -0800
Links: << >>  << T >>  << A >>
Jim,

I did comment.

My numbers were for 85C typical and worst case.

Austin

Jim Granville wrote:
>  > Vaughn Betz wrote:
>  >
> <snip>
>  >> While other FPGA vendors only specify values for typical silicon at 
> 25C,
>  >> Altera provides start-up currents and operating power values at various
>  >> temperatures and for both typical and worst-case power process corners.
> 
> Austin, why no comment on this point ?
> 
> Austin Lesea wrote:
> 
>> Vaughn,
>>
> <snip>
> 
>>
>> Too bad, though. The LX200 is 3.3 amperes, worst case - leakage only, 
>> at 85C.  Typical is 1.3 amperes at 85C.  No start up surge to worry 
>> about.  And the LX200 is a lot more memory, LUTs and FFs than the 
>> EP2S180...
> 
> 
>  Hmmm... When will we see the first thermal-runaway failures of FPGAs ?
> Could be time to start teaching thermal-runaway again in the classes,
> ( and the data sheets... ) and perhaps the tools should  perform some 
> 'thermal spreading' to prevent hot spots (since thermal effects are non 
> linear, and one can easily get an additional 40-50'C die above case ).
> 
> -jg
> 

Article: 77104
Subject: Re: Open source FPGA EDA Tools
From: "tom" <tnbiggs@yahoo.com>
Date: 22 Dec 2004 18:06:43 -0800
Links: << >>  << T >>  << A >>

Adam Megacz wrote:
> BTW, has anybody compiled a bibliography on hardware evolution?  I'd
> like to read through a big stack of papers on it all at once to try
to
> get up to speed.
>
>   - a

There was an article on FPGA hardware evolution quite a few years ago
that I found fascinating. Unfortunately I could only find an abstract
of it on the net (search for 'evolution' on the page):
http://216.239.63.104/search?q=cache:AN3SMgtZ_DUJ:www.eet.com/news/96/hr913.html+EETIMES+hardware+evolution+Xilinx+frequency&hl=en

They wanted a certain frequency to come out of the FPGA. The evolution
created a unique solution with two internal oscillators were built and
combined into a beat frequency.
It doesn't give you your bibliography, but it is a small start.


Article: 77105
Subject: Re: DSOCM BRAM I/F Controller
From: Peter Ryser <peter.ryser@xilinx.com>
Date: Wed, 22 Dec 2004 18:25:49 -0800
Links: << >>  << T >>  << A >>
Include xpseudo_asm.h into your C source code to make mfdcr() and 
mtdcr() available.

- Peter


Voxer wrote:
> I have read the literature on the the Xilinx DSOCM IF Controller but have a
> question.
> 
> Does this piece of IP need to be connected to the DCR Bus in order to get at
> the DCR
> registers - currently in my EDK graphic I only have it attached to the BRAM
> it controls
> and straight into the PPC.
> 
> If not how do I access the DCR regs for this IP - I have tried mfdcr and
> mtdcr before
> from within my software but cannnot compile as there appears to be no ".obj"
> for
> them.
> 
> AM I being daft ?
> 
> 


Article: 77106
Subject: Re: Open source FPGA EDA Tools
From: Lukasz Salwinski <lukasz@ucla.edu>
Date: Wed, 22 Dec 2004 18:27:16 -0800
Links: << >>  << T >>  << A >>
tom wrote:
> Adam Megacz wrote:
> 
>>BTW, has anybody compiled a bibliography on hardware evolution?  I'd
>>like to read through a big stack of papers on it all at once to try
> 
> to
> 
>>get up to speed.
>>
>>  - a
> 
> 
> There was an article on FPGA hardware evolution quite a few years ago
> that I found fascinating. Unfortunately I could only find an abstract
> of it on the net (search for 'evolution' on the page):
> http://216.239.63.104/search?q=cache:AN3SMgtZ_DUJ:www.eet.com/news/96/hr913.html+EETIMES+hardware+evolution+Xilinx+frequency&hl=en
> 
> They wanted a certain frequency to come out of the FPGA. The evolution
> created a unique solution with two internal oscillators were built and
> combined into a beat frequency.
> It doesn't give you your bibliography, but it is a small start.
> 

try this one:

Thompson A, Layzell P, Zebulum RS
Explorations in design space: Unconventional electronics design through 
artificial evolution
IEEE TRANSACTIONS ON EVOLUTIONARY COMPUTATION 3 (3): 167-196 SEP 1999

Article: 77107
Subject: Re: Using low-core-voltage devices in industrial applications
From: "Vaughn Betz" <no_spam@altera.com>
Date: Thu, 23 Dec 2004 02:28:43 -0500
Links: << >>  << T >>  << A >>

"Austin Lesea" <austin@xilinx.com> wrote in message
news:41C99DA6.2090401@xilinx.com...
> Vaughn,
>
> Only 5.3 amperes surge?  How do you test for it?  Can you guarantee it?
>   Do you throw away the ones that don't pass?  Why was the initial surge
> set at 20 amperes, and then dropped to 16 amperes, and now down to 5.3
> amperes for the 180?

Austin,

I don't know where you're getting these surge numbers from.  To my knowledge
Altera never quoted surge currents that high for 2S180s.

The TI App note you quoted appears to be a miscommunication, since those
numbers are much too high to be either surge or leakage currents.

> Too bad, though. The LX200 is 3.3 amperes, worst case - leakage only, at
> 85C.  Typical is 1.3 amperes at 85C.  No start up surge to worry about.
>   And the LX200 is a lot more memory, LUTs and FFs than the EP2S180...

Altera's power tools take leakage into account in the power-up current they
display. So the 1.8 A to 5.3 A of ICC Inrush current is the total current
needed to power up the device, including both leakage and any surge current.

The 5.3 A value is power-up current for worst-case silicon characteristics,
at 85 C.  Is your 3.3 A leakage number for the worst-case power process
corner silicon at 85 C, or just typical or unspecified silicon at 85 C?  The
difference is significant. Leakage increases as threshold voltage drops (or
channel length decreases, etc.), so we have provided numbers for both
typical process and the highest power units.

Vaughn
Altera
v b e t z (at) altera.com  [remove spaces and use proper @ to reach me]


>
> Vaughn Betz wrote:

> > The ICC values listed for Stratix II in the TI reference guide above are
> > out-of-date.  Altera has requested that TI update this document.
> >
> > EP2S180 users can expect from 1.8A to 5.3A of ICCint current during FPGA
> > power-up, depending on the temperature and the silicon characteristics
> > (typical vs. the process corner that leads to maximum power).  Given the
> > high-density and high-performance of the 2S180, these values are below
the
> > operating current for the vast majority of customers.
> >
> > While other FPGA vendors only specify values for typical silicon at 25C,
> > Altera provides start-up currents and operating power values at various
> > temperatures and for both typical and worst-case power process corners.
> >
> > For a power estimate specific to your design, use the PowerPlay Early
Power
> > Estimator, available at
> >
http://www.altera.com/support/devices/estimator/st2-estimator/st2-power-esti
> > mator.html.  If you have a completed design, you can use the Power
Analyzer
> > built into Quartus for even more accurate answers.  See
> > http://www.altera.com/literature/hb/qts/qts_qii53013.pdf for details.
> >
> > Vaughn
> > Altera
> > v b e t z (at) altera.com [Remove spaces and insert proper @ to reach
me]
> >
> >
> >
> >



Article: 77108
Subject: Audio Codec '97...How big is the core size without pads with 0.18um?
From: "Fat Cat" <Fatcats1980@$$$$m$il.com>
Date: Thu, 23 Dec 2004 17:13:20 +0800
Links: << >>  << T >>  << A >>
Just curious. Is it likely that one implements that in same chip with a
bluetooth baseband
and phy together in same chip?
What is the estimated gate count? How big is the analog core?

Thanks.





Article: 77109
Subject: EDK Bug ?
From: Rudolf Usselmann <russelmann@hotmail.com>
Date: Thu, 23 Dec 2004 16:49:48 +0700
Links: << >>  << T >>  << A >>


When creating custom IP Cores for inclusion in to EDK projects, I stumbled
across the following problem:

If a custom core (in VHDL) does not have a generic section
as for example:

-----------------------------------------------------------
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
library UNISIM;
use UNISIM.VComponents.all;

entity my_inverter is
port (  I       : in STD_LOGIC;
        O       : out STD_LOGIC
     );
end my_inverter;

architecture arch_my_inverter of my_inverter is

begin
        O <= not I;
end arch_my_inverter;
-----------------------------------------------------------

EDK generates a wrapper WITH an EMPTY generic section:

-----------------------------------------------------------
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;

library UNISIM;
use UNISIM.VCOMPONENTS.ALL;

library my_inverter;
use my_inverter.all;

entity rst_inverter_wrapper is
  port (
    I : in std_logic;
    O : out std_logic
  );
end rst_inverter_wrapper;

architecture STRUCTURE of rst_inverter_wrapper is

  component my_inverter is
    generic (

    );
    port (
      I : in std_logic;
      O : out std_logic
    );
  end component;

begin

  rst_inverter : my_inverter
    generic map (

    )
    port map (
      I => I,
      O => O
    );

end architecture STRUCTURE;
-----------------------------------------------------------

And than complains when compiling the code it just generated:

Compiling vhdl file
/home/rudi/projects/system/synthesis/hdl/rst_inverter_wrapper.vhd in
Library work.
ERROR:HDLParsers:164 -
/home/rudi/projects/system/synthesis/hdl/rst_inverter_wrapper.vhd Line 25.
parse error, unexpected CLOSEPAR, expecting IDENTIFIER
-->


Is this a bug or am I doing something wrong ?

This occurs with EDK 6.2 and EDK 6.3 (both latest patch levels)
on a linux system.

Thanks !
rudi               
=============================================================
Rudolf Usselmann,  ASICS World Services,  http://www.asics.ws
Your Partner for IP Cores, Design, Verification and Synthesis

Article: 77110
Subject: Xilinx Hold constraint
From: Sylvain Munaut <tnt_at_246tNt_dot_com@reducespam.com>
Date: Thu, 23 Dec 2004 11:01:24 +0100
Links: << >>  << T >>  << A >>
Hello,

I'd like to ensure a <=0ns hold time to all input ( for a PCI design ).
But I don't see any way to specify such a constraint in ISE ...

Thanks for any pointer,



Sylvain



PS: Sorry if you received this twice. I tried to send it yesterday but
since it doesn't not show up in my newreader today I guess it didn't
make thru.

Article: 77111
Subject: Re: MAP failes after inserting ILA and ICON cores to the design
From: "ran" <ranshadmi@walla.co.il>
Date: 23 Dec 2004 02:26:31 -0800
Links: << >>  << T >>  << A >>
Thanks Marc for your answer.

1. I don't think my device is over-full. Here is a device utilization
summary of a successful MAP run (without the ChipScope cores and with
the "-timing" option):

****************************************************
START HERE
****************************************************
Release 6.3.02i Map G.31a
Xilinx Mapping Report File for Design 'pcix_3port_bridge'

Design Information
------------------
Command Line   : /usr/local/apps/xilinx62i/bin/lin/map -intstyle ise -p
xc2vp30-ff896-6 -ol high -timing -cm area -pr b -k 4 -c 100 -tx off -o
gtw_map.ncd gtw.ngd gtw.pcf
Target Device  : x2vp30
Target Package : ff896
Target Speed   : -6
Mapper Version : virtex2p -- $Revision: 1.16.8.2 $
Mapped Date    : Fri Dec 17 01:14:19 2004

Design Summary
--------------
Number of errors:      0
Number of warnings: 1213
Logic Utilization:
Total Number Slice Registers:    17,111 out of  27,392   62%
Number used as Flip Flops:                17,107
Number used as Latches:                        4
Number of 4 input LUTs:          20,728 out of  27,392   75%
Logic Distribution:
Number of occupied Slices:       13,655 out of  13,696   99%
Total Number 4 input LUTs:         24,290 out of  27,392   88%
Number used as logic:            20,728
Number used as a route-thru:      1,332
Number used for Dual Port RAMs:   2,140
(Two LUTs used per Dual Port RAM)
Number used as Shift registers:      90

Number of bonded IOBs:              416 out of     556   74%
IOB Flip Flops:                 1,035
IOB Dual-Data Rate Flops:          17
Number of PPC405s:                   0 out of       2    0%
Number of Block RAMs:                66 out of     136   48%
Number of GCLKs:                      8 out of      16   50%
Number of DCMs:                       6 out of       8   75%
Number of GTs:                        0 out of       8    0%
Number of GT10s:                      0 out of       0    0%

Total equivalent gate count for design:  4,941,440
Additional JTAG gate count for IOBs:  19,968
Peak Memory Usage:  521 MB
****************************************************
END HERE
****************************************************


2+3. I am using V2Pro-30 (package ff896, speed grade -6). I don't know
"how tall" is my device. What does that mean ?
I tried unchecking the "use RPM" checkbox of the ChipScope ILA
generator, but results were the same. ICON core doesn't have a "use
RPM" checkbox.

I did another run, this time with ISE 6.3 SP3, and got a different MAP
results (still failes):

****************************************************
START HERE
****************************************************
Release 6.3.03i Map G.38
Xilinx Mapping Report File for Design 'pcix_3port_bridge'

Design Information
------------------
Command Line   : /usr/local/apps/xilinx63i/bin/lin/map -intstyle ise -p
xc2vp30-ff896-6 -ol high -timing -cm area -pr b -k 4 -c 100 -tx off -o
gtw_map.ncd gtw.ngd gtw.pcf
Target Device  : x2vp30
Target Package : ff896
Target Speed   : -6
Mapper Version : virtex2p -- $Revision: 1.16.8.2 $
Mapped Date    : Thu Dec 23 17:18:07 2004

Design Summary
--------------
Number of errors   : 123
Number of warnings :   4

Section 1 - Errors
------------------
ERROR:Place -
Due to placement constraints, the following 2 components cannot be
placed.
The relative offsets of the components are shown in brackets next to
the
component names.
LUT
i_ila_rpm/i_no_d/u_ila/u_g2_sq/u_capctrl/u_cap_addrgen/cfg_data_4
(0, 0)     FF
i_ila_rpm/i_no_d/u_ila/u_g2_sq/u_capctrl/u_cap_addrgen/cfg_data_4
(0, 1)


>>>>>>> 1200 lines redacted


ERROR:Place:120 - There were not enough sites to place all selected
components
ERROR:Pack:1499 - The timing-driven packing phase encountered an error.

Section 2 - Warnings
--------------------
...
****************************************************
END HERE
****************************************************


Article: 77112
Subject: Re: making an fpga hot
From: "Symon" <symon_brewer@hotmail.com>
Date: Thu, 23 Dec 2004 03:45:03 -0800
Links: << >>  << T >>  << A >>
Hi Paul,
Firstly, I apologise if my nomenclature is slightly Xilinx biased, I don't 
get much chance to use your equally excellent Altera parts in my current 
work.
So, I think I had it in my head originally that _all_ the 8 FFs in a slice 
could be chosen from to drive _any_ of the LUTs in that slice, such that the 
delays from FF to LUT were evenly matched. At present this relies on routing 
outside the slice, and so the delays would be badly characterised. Then I 
thought it might be possible to up the number of FFs to (say) 16 in a slice 
to make this more viable. This gives you a 2:1 FF to LUT ratio. But, you 
need a big switching thingy to get the FFs to the LUTs. Some kind of subset 
might be fine though. Also, maybe you only need 2 registered inputs per LUT 
to get a big saving in glitch energy.
In thinking this, I assumed that the LUT takes up much more silicon area 
than the FF, after all the LUT has 16 bits, plus all that address muxing. 
(Indeed, it's the switching of all that LUT silicon that we want to reduce.) 
Is that a valid assumption? So, it doesn't make that big a difference to the 
LE area (see, I know a bit of Alteraese!).
In the end we're trading switching a load extra FFs, against saving the 
glitches in the LUTs.
Finally, what 'other power reduction circuitry' are you thinking of? Or is 
it secret? ;-)
Thanks, and Cheers, Syms.
p.s. Do you have any comment on my post on the 9th Dec about whether certain 
LUT inputs are more thirsty than others?

"Paul Leventis (at home)" <paulleventis-news@yahoo.ca> wrote in message 
news:JaednXpb4YTIrFfcRVn-3Q@rogers.com...
> Hi Symon,
>
>> > Hmm, that's very interesting. I wonder if the FPGA vendors have got
> their
>> > SLICEs back to front? I.e. the FFs should feed directly into the LUTs
> within
>> > the SLICEs, instead of the other way round that exists now. If it saved
> even
>> > 20% of the power, it'd be worth it. Instead of using all the FFs for
>> > pipelining, you use them to replicate signals within the SLICEs to
> prevent the
>> > glitchy power thing. Hmm, interesting indeed! Thanks Ray.
>
> You'd have to consider the cost of having 4 flops (if I understand
> correctly) vs. 1.  How often will 4 flops be used?  What if you instead
> spent that same silicon area on other things (other power reduction
> circuitry, etc.)?  How much more wiring cap will there be due to increased
> size of a LE?  How much more power are you burning by replicating clocks 
> and
> other signals?
>
> One thing I should point is that you *can* put FF in front of the LUT in
> Stratix/Cyclone/Max II/Cyclone II/Stratix II.  There is only one FF, but 
> it
> can directly feed the LUT instead of the other way around.
>
> Regards,
>
> Paul Leventis
> Altera Corp.
>
> 



Article: 77113
Subject: constraint for PCI & PCI-X core
From: nahum_barnea@yahoo.com
Date: 23 Dec 2004 04:40:38 -0800
Links: << >>  << T >>  << A >>

Hi,

I have a 100 MHz PCI-X core for Xilinx device.
As a part of PCI-X standard the core is also compliant with PCI 33 MHz.


Now I have a problem with the ucf clock frequency constraint.
Since I want it to work in PCI-X 100 MHz I constraint to clock of
100 MHz; but then the PCI 33 MHz logic fail to meet the timing
constraints.

I can identify the PCI 33 MHz critical paths as the path that goes
directly from pad (TRDY#) to a combinatorical logic, and the paths of
PCI-X as the paths that start at IOB registers.

How can I relax the constraints starting at a pad and ending in a CLB
register ?


ThankX ,
NAHUM


Article: 77114
Subject: Re: MAP failes after inserting ILA and ICON cores to the design
From: "Marc Randolph" <mrand@my-deja.com>
Date: 23 Dec 2004 04:59:55 -0800
Links: << >>  << T >>  << A >>
ran wrote:
> Thanks Marc for your answer.
>
> 1. I don't think my device is over-full. Here is a device utilization
> summary of a successful MAP run (without the ChipScope cores and with
> the "-timing" option):

Sorry, I had a typo in my previous response.  You need to run *without*
-timing, but with the chipscope cores, in order to get a utilization
estimate with the cores in place.  88% is a relatively high utilization
- certainly not full, but not that far away from full either.  I'd
certainly hope that your chipscope wouldn't take up 3000 LUTs, but
depending on your timing domains, I could see map getting into a bind
with considerably less than 3000 LUTs.

Does the generator give you a size of your core (either saying it is x
CLBs tall, or number of LUTs used)?

Have you tried removing a large block in your design to see if the ILA
core will then fit?

> Command Line   : /usr/local/apps/xilinx62i/bin/lin/map -intstyle ise
-p
> xc2vp30-ff896-6 -ol high -timing -cm area -pr b -k 4 -c 100 -tx off
-o
> gtw_map.ncd gtw.ngd gtw.pcf
> Target Device  : x2vp30
> Target Package : ff896
> Target Speed   : -6
> Mapper Version : virtex2p -- $Revision: 1.16.8.2 $
> Mapped Date    : Fri Dec 17 01:14:19 2004
>
> Design Summary
> --------------
> Logic Utilization:
> Total Number Slice Registers:    17,111 out of  27,392   62%
> Number of 4 input LUTs:          20,728 out of  27,392   75%
> Number of occupied Slices:       13,655 out of  13,696   99%
> Total Number 4 input LUTs:         24,290 out of  27,392   88%
> Number of Block RAMs:                66 out of     136   48%
>
> 2+3. I am using V2Pro-30 (package ff896, speed grade -6). I don't
know
> "how tall" is my device. What does that mean ?
> I tried unchecking the "use RPM" checkbox of the ChipScope ILA
> generator, but results were the same. ICON core doesn't have a "use
> RPM" checkbox.

The column called "CLB array" in the "Slice configurations" section of
the Xilinx datasheets outline the number of CLB's each device is
composed of (number of CLB's vertically vs. CLB's horizontally).
Although they don't have to be, RPM's are usually arranged vertically,
and it is possible for the RPM to exceed the available number of CLB's
in one of the two directions.  The 2VP30 has 80 CLBs vertically, which
is quite a few.

Good luck,

   Marc


Article: 77115
Subject: timer-interrupt not recognized
From: "Patrick Siegel" <mai99drh@studserv.uni-leipzig.de>
Date: 23 Dec 2004 08:13:06 -0800
Links: << >>  << T >>  << A >>
Hello,

i'm currently triing to get an opb-timer to work.
The timer is connected to the ppc via an opb-interruptcontroller.
I was (exactly) following the Xilinx-Tutorials (Chapter
"Memory-Management" in the Embedded Systems Tool Guide).
The problem is i won't recieve any interrupts generated by the timer.
When connecting the timer-interrupt-output to an led, the led stays
off.
I tried different combinations:
- with / without intermidiate interruptcontroller
- with dynamic-handler-registration (per programming-API) / with
harded   interrupt-handler-registration in system.mhs

Finally i took the example c-sources supplied in the
memory-management-chapter and compiled/executed them with an
appropriate edk-design (i was adding the neccesary components and
renamed the instances, so that no additional changes to the sources had
to be made, system.mhs and system.mss were edited accordingly).

But even with those examples provided by xilinx i wont get the timer to
work.
At the moment i've got ne idea what could be the reason.
I'm using EDK6.2 and a Virtex2Pro (P7V2) Developement Board
(Memec-Design).

So if anyone has had similar problems i'd be very thankful for a hint.
Regards
   Patrick Siegel


Article: 77116
Subject: Re: Using low-core-voltage devices in industrial applications
From: Austin Lesea <austin@xilinx.com>
Date: Thu, 23 Dec 2004 08:25:51 -0800
Links: << >>  << T >>  << A >>
Vaugn,

See below,

Austin

-snip-

> 
> Austin,
> 
> I don't know where you're getting these surge numbers from.  To my knowledge
> Altera never quoted surge currents that high for 2S180s.

Bellnix Power supply guide, TI power supply guide, ST power supply 
guide...basically your power supply parnters.  So, all I can conclude is 
that Altera told their power vendors what the start up surge was.

http://dkc3.digikey.com/PDF/Marketing/FPGA_Altera.pdf
http://focus.ti.com/lit/ml/slyb113/slyb113.pdf
http://www.bellnix.com/fpga/P-M-R-G1.pdf

...

all state 16 amperes.  So if you didn't tell them, who did?  If I am an 
engineer, and I need to design a power system, I would be using these 
guidelines.

> 
> The TI App note you quoted appears to be a miscommunication, since those
> numbers are much too high to be either surge or leakage currents.
> 

Very effective miscommunication there.  Better go talk to all your power 
vendors and let them know that they all quoted the wrong numbers.  I 
have supplied you with the list above, so you're welcome.

I could understand if your had an early ES version of the part, and 
perhaps this high current surge was due to fault on an errate sheet, but 
the 2S180 isn't sampling yet.  Maybe this was based on an extrapolation 
of the 2S60?

So, is there a surge, or no?  You imply that all that is needed is the 
leakage to be overcome (just like our parts since Virtex II).  Even your 
spreadsheet mentions the word "inrush" (6, 1 and 2 amperes for the three 
supplies).  The IO and PD supplies need 8 mA and 15 mA respectively 
(idle) so why do they need 1 and 2 amperes to start up?  I think that is 
called a Power On Surge (POS)?

> 
>>Too bad, though. The LX200 is 3.3 amperes, worst case - leakage only, at
>>85C.  Typical is 1.3 amperes at 85C.  No start up surge to worry about.
>>  And the LX200 is a lot more memory, LUTs and FFs than the EP2S180...
> 
> 
> Altera's power tools take leakage into account in the power-up current they
> display. So the 1.8 A to 5.3 A of ICC Inrush current is the total current
> needed to power up the device, including both leakage and any surge current.

That is as it should be.  Everyone here does like your power 
spreadsheet, it has nice formatting, and a clean look.  It does have 
some buggy pop-up windows that tend to stick around and annoy, but 
otherwise it is a really good and useful spreadsheet tool.  Now the only 
question is:  is it accurate?

> 
> The 5.3 A value is power-up current for worst-case silicon characteristics,
> at 85 C.  Is your 3.3 A leakage number for the worst-case power process
> corner silicon at 85 C,

Yes, it is.

  or just typical or unspecified silicon at 85 C?

No, it is not.

   The
> difference is significant. Leakage increases as threshold voltage drops (or
> channel length decreases, etc.), so we have provided numbers for both
> typical process and the highest power units.

And so did I.

Interesting you bring this up.  A customer demanded to see proof of our 
LX60 leakage numbers, as they had designed in the 2S60.

They frankly could not belive the numbers.  All of the 90nm products 
they were familiar with had horrible leakage.  When we told them that we 
used a triple oxide technology, and that is how we controlled the 
leakage, they basically still couldn't believe it.

When we not only provided them with parts and demo boards, and 
characterization data on leakage, they decided they had to switch to the 
lower leakage power product.

Article: 77117
Subject: Re: making an fpga hot
From: "Paul Leventis" <paul.leventis@utoronto.ca>
Date: 23 Dec 2004 08:26:47 -0800
Links: << >>  << T >>  << A >>
> So, I think I had it in my head originally that _all_ the 8 FFs in a
slice
> could be chosen from to drive _any_ of the LUTs in that slice, such
that the
> delays from FF to LUT were evenly matched. At present this relies on
routing
> outside the slice, and so the delays would be badly characterised.
Then I
> thought it might be possible to up the number of FFs to (say) 16 in a
slice
> to make this more viable. This gives you a 2:1 FF to LUT ratio. But,
you
> need a big switching thingy to get the FFs to the LUTs. Some kind of
subset
> might be fine though. Also, maybe you only need 2 registered inputs
per LUT
> to get a big saving in glitch energy.

I *think* you mean a CLB everywhere you say a slice (a slice is 2 LUTs
+ 2 FFs + Goo, I believe).  I am not too familiar with Xilinx's
interslice routing.  However, in our products you can get from a FF of
one Logic Element (FF + LUT pair) to any other LE/LUT in the same Logic
Array Block or LAB (a set of 8/10/16 LEs).  The delay from any flop to
any LUT in the same LAB is very similar -- for the purposes of power &
glitching you could consider these paths to be matched.

Now adding additional FFs... FFs are area hungry (and power hungry...),
and it is rare for a design to use all (or even half) the FFs that are
already in our parts (with a 1:1 LUT/FF ratio).  So these additional
FFs would be wasteful of area, and you'd have to ask whether that area
was better spent in other ways, or not at all (thus reducing Si cost).


> In thinking this, I assumed that the LUT takes up much more silicon
area
> than the FF, after all the LUT has 16 bits, plus all that address
muxing.
> (Indeed, it's the switching of all that LUT silicon that we want to
reduce.)
> Is that a valid assumption? So, it doesn't make that big a difference
to the
> LE area (see, I know a bit of Alteraese!).

Once you add in all the goo that comes with a FF (sync clear, asynch
clear, clock selection, sync load, etc.) they become surprisingly
large.  But the second (or more FFs) would not need to be fully
featured and so I'll grant you that they wouldn't be huge.  But you'd
be surprised at the lengths we go to cut even 1% area out of the LE.

> Finally, what 'other power reduction circuitry' are you thinking of?
Or is
> it secret? ;-)

Which ones am I thinking of?  That's secret :-)  But you can do a
literature search on low-power design in FPGAs and ASICs and you'll see
there are oodles of ideas out there, some or all of which cause some
area bloat in exchange for better power.

> p.s. Do you have any comment on my post on the 9th Dec about whether
certain
> LUT inputs are more thirsty than others?

Sorry, my news server has been really flaky this month.  I've had to
resort to using Google groups now.  I'll take a look when I get a
chance.

Paul Leventis
Altera Corp.


Article: 77118
Subject: Re: Newbie: Read from Compact Flash using System ACE
From: pcalvert@radiancetech.com
Date: 23 Dec 2004 09:10:34 -0800
Links: << >>  << T >>  << A >>
Hello,

I too want to be able to do this too--but I want to do it before the
vxWorks OS is up--actually, I want to use this capability to copy a
vxWorks image off of the CF into RAM and then jump to the RAM image. I
am not certain of the CF formatting--I want to use it just like Xilinx
provides on the ML310 development board.

I've not been able to find any Xilinx driver/info that supports file IO
at the Xilinx level. I saw some earlier posts of persons trying to use
FILE* and standard file IO things--but I haven't found anything that
indicates this level of file IO is supported. Can anyone clarify or if
you've done something similar, share?

Thanx,

Paul


Article: 77119
Subject: Re: making an fpga hot
From: "Symon" <symon_brewer@hotmail.com>
Date: Thu, 23 Dec 2004 09:40:04 -0800
Links: << >>  << T >>  << A >>
"Paul Leventis" <paul.leventis@utoronto.ca> wrote in message 
news:1103819207.873804.224540@c13g2000cwb.googlegroups.com...
>
> I *think* you mean a CLB everywhere you say a slice (a slice is 2 LUTs
> + 2 FFs + Goo, I believe).  I am not too familiar with Xilinx's
> interslice routing.  However, in our products you can get from a FF of
> one Logic Element (FF + LUT pair) to any other LE/LUT in the same Logic
> Array Block or LAB (a set of 8/10/16 LEs).  The delay from any flop to
> any LUT in the same LAB is very similar -- for the purposes of power &
> glitching you could consider these paths to be matched.
<snipped interesting stuff>
Yes, I did mean CLB, thanks for working that out!
Thanks for your comments, Syms. 



Article: 77120
Subject: Re: Using low-core-voltage devices in industrial applications
From: Austin Lesea <austin@xilinx.com>
Date: Thu, 23 Dec 2004 10:10:41 -0800
Links: << >>  << T >>  << A >>
Vaughn,

And:

http://www.national.com/appinfo/power/files/NationalAlteraDesignGuide.pdf

For yet another power vendor who just got those darned numbers wrong.

Austin

Austin Lesea wrote:
> Vaugn,
> 
> See below,
> 
> Austin
> 
> -snip-
> 
>>
>> Austin,
>>
>> I don't know where you're getting these surge numbers from.  To my 
>> knowledge
>> Altera never quoted surge currents that high for 2S180s.
> 
> 
> Bellnix Power supply guide, TI power supply guide, ST power supply 
> guide...basically your power supply parnters.  So, all I can conclude is 
> that Altera told their power vendors what the start up surge was.
> 
> http://dkc3.digikey.com/PDF/Marketing/FPGA_Altera.pdf
> http://focus.ti.com/lit/ml/slyb113/slyb113.pdf
> http://www.bellnix.com/fpga/P-M-R-G1.pdf
> 
> ...
> 
> all state 16 amperes.  So if you didn't tell them, who did?  If I am an 
> engineer, and I need to design a power system, I would be using these 
> guidelines.
> 
>>
>> The TI App note you quoted appears to be a miscommunication, since those
>> numbers are much too high to be either surge or leakage currents.
>>
> 
> Very effective miscommunication there.  Better go talk to all your power 
> vendors and let them know that they all quoted the wrong numbers.  I 
> have supplied you with the list above, so you're welcome.
> 
> I could understand if your had an early ES version of the part, and 
> perhaps this high current surge was due to fault on an errate sheet, but 
> the 2S180 isn't sampling yet.  Maybe this was based on an extrapolation 
> of the 2S60?
> 
> So, is there a surge, or no?  You imply that all that is needed is the 
> leakage to be overcome (just like our parts since Virtex II).  Even your 
> spreadsheet mentions the word "inrush" (6, 1 and 2 amperes for the three 
> supplies).  The IO and PD supplies need 8 mA and 15 mA respectively 
> (idle) so why do they need 1 and 2 amperes to start up?  I think that is 
> called a Power On Surge (POS)?
> 
>>
>>> Too bad, though. The LX200 is 3.3 amperes, worst case - leakage only, at
>>> 85C.  Typical is 1.3 amperes at 85C.  No start up surge to worry about.
>>>  And the LX200 is a lot more memory, LUTs and FFs than the EP2S180...
>>
>>
>>
>> Altera's power tools take leakage into account in the power-up current 
>> they
>> display. So the 1.8 A to 5.3 A of ICC Inrush current is the total current
>> needed to power up the device, including both leakage and any surge 
>> current.
> 
> 
> That is as it should be.  Everyone here does like your power 
> spreadsheet, it has nice formatting, and a clean look.  It does have 
> some buggy pop-up windows that tend to stick around and annoy, but 
> otherwise it is a really good and useful spreadsheet tool.  Now the only 
> question is:  is it accurate?
> 
>>
>> The 5.3 A value is power-up current for worst-case silicon 
>> characteristics,
>> at 85 C.  Is your 3.3 A leakage number for the worst-case power process
>> corner silicon at 85 C,
> 
> 
> Yes, it is.
> 
>  or just typical or unspecified silicon at 85 C?
> 
> No, it is not.
> 
>   The
> 
>> difference is significant. Leakage increases as threshold voltage 
>> drops (or
>> channel length decreases, etc.), so we have provided numbers for both
>> typical process and the highest power units.
> 
> 
> And so did I.
> 
> Interesting you bring this up.  A customer demanded to see proof of our 
> LX60 leakage numbers, as they had designed in the 2S60.
> 
> They frankly could not belive the numbers.  All of the 90nm products 
> they were familiar with had horrible leakage.  When we told them that we 
> used a triple oxide technology, and that is how we controlled the 
> leakage, they basically still couldn't believe it.
> 
> When we not only provided them with parts and demo boards, and 
> characterization data on leakage, they decided they had to switch to the 
> lower leakage power product.

Article: 77121
Subject: Re: PCI doubt
From: "Shreyas Kulkarni" <shyran@gmail.com>
Date: 23 Dec 2004 10:23:13 -0800
Links: << >>  << T >>  << A >>
the thing that created this mess of mis-understanding is the fact that
- nearly all the pci cards that an end-user like me uses, are target
only devices. (there is another category called bus-maters, which i was
unaware of.)

so naturally i thought - if all devices are targets then the master
must be the arbitar; and as it initiates the transaction, i could call
it as an initiator!

the right thing is (plz verify) -
1. nearly all devices are target-only.
2. bus-maters are also pci cards that can initiate transaction.
3. usually the cpu itself is the bus master or simply the master.
4. the arbiter controls these targets and masters.

so in short (in general) -
target-only pci card = slave
cpu = master
arbiter = controller

i think i have put it right this time!
(have i really ? ;-) )
anyway, thanks for all the replies and help.

regards,
Shreyas Kulkarni


Article: 77122
Subject: Re: Using low-core-voltage devices in industrial applications
From: Eric Smith <eric-no-spam-for-me@brouhaha.com>
Date: 23 Dec 2004 11:45:10 -0800
Links: << >>  << T >>  << A >>
Austin Lesea <austin@xilinx.com> writes:
> "Large" is not in S3 vocabulary.  They (Spartan) have no "large"
> devices.....by definition.  If it is "large" then it belongs to the
> Virtex family.....also by definition.
> 
> That said, the 3S5000 is a pretty "large" part, but still a lot
> smaller than the XCV4LX200 (largest V4 basic logic device).

OK.  Having used so many smaller parts in the past, I still have a
hard time not thinking of the XC3S1000 and XC3S1500 as "large".

Article: 77123
Subject: VGA timing
From: randomdude@gmail.com (Alan Randomdude)
Date: 23 Dec 2004 14:15:58 -0800
Links: << >>  << T >>  << A >>
Hi there.

I'm new to PLD devices, and thought that building a VGA controller
would be fairly simple. I can't for the life of me get the damn thing
to work though, more specifically I can't get the monitor to sync.
I've disconnceted Green and Red and have tied Blue high. I'm trying to
spit out 640x480 at 52Hz.

I'm hoping that I've done something really simple wrong with the
timings, so I've uploaded the output of a simulation - can anyone have
a look at it and tell me if I have? Thanks..

Simulation output is at http://82.147.17.182/vga.vwf . Thanks.

Article: 77124
Subject: Re: VGA timing
From: Dave Vanden Bout <devb@xess.com>
Date: Fri, 24 Dec 2004 00:32:47 GMT
Links: << >>  << T >>  << A >>
randomdude@gmail.com (Alan Randomdude) wrote in 
news:d2b05bc6.0412231415.13412387@posting.google.com:

> http://82.147.17.182/vga.vwf

Here's a document that we wrote on a VGA generator.  Maybe it will help you 
get your sync timing correct.

http://www.xess.com/appnotes/an-101204-vgagen.pdf

-- 
----------------------------------------------------------------
Dave Van den Bout
XESS Corp.
PO Box 33091
Raleigh NC 27636
Phn: (919) 363-4695
Fax: (801) 749-6501
devb@xess.com
http://www.xess.com




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

Threads starting:
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