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 74000

Article: 74000
Subject: Re: NV on-chip memory?
From: rickman <spamgoeshere4@yahoo.com>
Date: Sat, 02 Oct 2004 01:14:25 -0400
Links: << >>  << T >>  << A >>
Nicholas Weaver wrote:
> 
> In article <29f7d.3570$JG2.795@newssvr14.news.prodigy.com>,
> superfpga <superfpga@pacbell.net> wrote:
> >Paul-
> >you make some good points in your discussions especially about the $1 extra
> >cost compared to a $100 FPGA as well as highlighting the significance of
> >saving that same $1 if it was in a Cyclone low cost device.
> >
> >However, how would you change your mind if some of the newer developing NV
> >memory technologies were similar in size to flash cell/dram cell (<< area of
> >SRAM), also used standard leading edge CMOS process (unlike Flash or DRAM),
> >thus much more cost effective bulk memory without adding any process premium
> >to the rest of the chip?  Though maybe not the holy grail, don't you think
> >it provides a good amount of value as cited by some of Hals, Jim's and
> >Nicholas' posts?  There are probably even other ideas out there for value.
> 
> a)  I doubt it would come without a process penalty in the .13 or 90nm
> node (or the equivelent at a given point in time).  If it could, that
> might be another story.

That is what he is describing.  I don't know if he knows something we
don't, but certainly it is conceivable that a new NV type could be
process compatible with CMOS.  

> b)  If it could, it would need to be many times rewriteable to be
> acceptable to the FPGA companies.  One of the real advantages of the
> FPGAs over other technologies (antifuse, etc) is the unlimited rewrite
> capability.  THus a write once or limited write memory would be far
> less useful.

I don't know how many times you would feel the need to write your NV
ram.  But various formats of separate chips only provide anywhere from
1000 to 100,000 guaranteed.  I expect there are tons of apps for even
1000 time rewritable NV ram. 

> c) My point is that the security aspect of embedded NVram is
> significantly less when compared to using the existing SRAM-based
> bitfile encryption to protect a large external nonvolatile store.
> So I'm a naysayer on NVram.

But for the low end cost market, there is no built in encryption
hardware.  That is only on the expensive chips like Virtex-II and 4. 
Spartans don't have it and I believe we are talking about the low cost
chips.  If you are using the $100 FPGA, I don't think an external $1 NV
memory will be a problem.  With the low cost chips, the on board NV ram
is likely more secure than than an encrypted external NV store since the
encryption mechanism is not protected in any way. 

-- 

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: 74001
Subject: Re: JOP on Spartan-3 Starter Kit
From: hmurray@suespammers.org (Hal Murray)
Date: Sat, 02 Oct 2004 00:19:16 -0500
Links: << >>  << T >>  << A >>
>  Why do I need a parity bit for the block RAM?

They are often useful for other things.

On FIFOs/buffers:
  End of packet flag.
  In-band vs out-of-band signaling.

Used/free flags.

Just plane more bits (wider) for things like table driven state machines.


-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 74002
Subject: Re: Open-Source MicroBlaze IP-Core working in FPGA :)
From: rickman <spamgoeshere4@yahoo.com>
Date: Sat, 02 Oct 2004 01:20:01 -0400
Links: << >>  << T >>  << A >>
Antti Lukats wrote:
> 
> http://uclinux.openchip.org/forum/viewtopic.php?t=4
> 
> here is proof :)
> 
> the opensource version as available from opencores is not yet good enough to
> run uCLinux - well lets see if that will change,
> I think there is a wish to have an open-souce multi-vendor FPGA softcare
> capable to run uCLinux inside many people :)

I could be wrong, but I thought open source cores that run uCLinux were
already available for FPGAs.  The only difference is that this one is
code compatible with uBlaze.  Am I wrong about this? 

-- 

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: 74003
Subject: Re: NV on-chip memory?
From: nweaver@soda.csua.berkeley.edu (Nicholas Weaver)
Date: Sat, 2 Oct 2004 05:28:40 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <415E3568.DEA2A396@yahoo.com>, rickman  <john@bluepal.net> wrote:
>BTW, that brings up the issue of RAM cell size.  I recall that Mosys has
>a 1T sram cell using a single transistor and a capacitor.  This sounds
>like a DRAM to me.  Anyone know how this works?  To the best of my
>knowledge it does not require any refreshing or is that somehow done
>invisibly?  They don't call this peusdo-SRAM and I believe they have
>some patents on it.  

It is Pseudo-SRAM:  It provides an SRAM interface, and hides the
refreshing process, but underneeth it all, its a small bank fast DRAM
design.
-- 
Nicholas C. Weaver.  to reply email to "nweaver" at the domain
icsi.berkeley.edu

Article: 74004
Subject: Re: spartan-3 sram
From: hmurray@suespammers.org (Hal Murray)
Date: Sat, 02 Oct 2004 01:05:28 -0500
Links: << >>  << T >>  << A >>
> I have done read/write access to sram in a basic way in three cycles
> without any problem.

Good to hear.

You might get down to 2 cycles by using the other edge of the clock
for WE and putting it in the middle of the pair.  OE would go on the
second cycle.  (Probablby work fine in the middle too - bus would
just float a half cycle.)


>> What particular SRAM is on the board that started this thread?
> It is ISSI IS61LV25616AL.

Data sheet is at http://www.issi.com/pdf/61LV25616AL.pdf

The timing diagram for WE controlled writes is on page 9.  Numbers
are back on page 8.  Looks like pretty standard SRAM - 0 setup, 0 hold.

You can't do a single cycle write with simple/clean digital logic.
The problem is skew - you can't guarantee that address will get there
before WE to meet setup and also guarantee that it will get there
after WE to meet hold times. (Or at least I can't see how to do it.)

One solution is to make WE slightly less than a whole cycle.  You
could do something like generate WE as the AND of a WriteEnable
and the first half of the cycle.  That AND will be in a CLB.  There
will be delays (relative to clocking the address and data in IOBs)
so WE will come out in the middle of the cycle, right where you
want it.  That's if all the delays work out.  I don't know if
this is interesting for the initial question.

FPGAs may not be friendly for this sort of hacking - clocks don't
get routed to CLB inputs.  Better/cleaner to use a 2X clock.

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 74005
Subject: Re: FPGA vs ASIC area
From: Jim Granville <no.spam@designtools.co.nz>
Date: Sat, 02 Oct 2004 19:28:03 +1200
Links: << >>  << T >>  << A >>
Jon Beniston wrote:

> General Schvantzkoph <schvantzkoph@yahoo.com> wrote in message news:<pan.2004.10.01.14.16.37.467412@yahoo.com>...
> 
>>On Fri, 01 Oct 2004 06:18:58 -0700, Jon Beniston wrote:
>>
>>
>>>>Here are some numbers:
>>>>ASICS are only for extreme designs:
>>>>extreme volume, speed, size, low power
>>>>Cost of a mask set for different technologies:
>>>>250 nm:        $ 100 k
>>>>180 nm    :    $ 300 k
>>>>130 nm:        $ 800 k
>>>> 90 nm:        $1200 k
>>>> 65 nm:        $2000 k
>>>>plus design, verification and risk.
>>>>
>>>
>>>Hmm. Take those figures with a pinch of salt. At the higher
>>>geometries, you can definetly get much cheaper than that.
>>>
>>
>>Those figures are for pure ASICs, what are the costs for structured ASICs?
> 
> 
> I don't know much about <= 90nm, but if your paying $300k for 180nm
> you're getting robbed.
> 
> Structured-ASIC NRE is significantly less, say $40-70k depending on
> process and vendor.

For a glimpse of one approach to FPGA -> StructuredASIC, see

http://www10.edacafe.com/nbc/articles/view_article.php?section=ICNews&articleid=144528

A couple of interesting points here :

** they take a TSMC 0.15u sub-metal wafer, and add the metal themselves.
  [Metal layers are normally more relaxed rules]
  ( could give rise to interesting yield discussions between the two 
companies :)

** They offer dual port, initialisable memory.
  [Not clear if this is from a ROM, or from a serial loader ]

They target $20-$100 / 10K chip sales.

Also claim this
"Cost reduction and time-to-market are the basis of XPA-II's existence 
offering customers 0.15Ám technology at one quarter of the NRE cost of a 
cell-based ASIC and one-third the cost of an FPGA in production. 
Prototypes can be shipped in as little as 21 days compared to standard 
cell ASIC lead times of 50-60 days."

  These structured Metal-only ASICs are really MASK FPGAs.
The test will be how much revenue this segment can generate.

-jg



Article: 74006
Subject: Re: FPGA vs ASIC area
From: hmurray@suespammers.org (Hal Murray)
Date: Sat, 02 Oct 2004 03:26:37 -0500
Links: << >>  << T >>  << A >>
>Redundancy timing is a solved problem.

Thanks.  (Sorry if my post seemed insulting.)

I think I understand how to do it in the normal
design flow.  I was fishing for things around the edge
that might not have worked as expected.

Maybe I've been looking at too many "typical" columns
in the data sheets.


Could a customer write code that would detect when a
redundant section was used?  I'm thinking of something
like measuring the "typical" prop times on a part
and see if some section is way out of line.


-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 74007
Subject: Re: JOP on Spartan-3 Starter Kit
From: "Martin Schoeberl" <martin.schoeberl@chello.at>
Date: Sat, 02 Oct 2004 10:01:55 GMT
Links: << >>  << T >>  << A >>
> > In this particular case, your critical path appears to stretch from a
RAM to
> > a RAM (configured as a ROM) with little logic in-between.  Logic +
> > routing-rich paths tend to accentuate the speed differences between
the two
> > devices, while RAM-heavy paths show a smaller advantage.
>
>   Do you have tips for Martin on how to improve this for Cyclone
> specific cases ? - ie should the ROM change to logic-based, rather than
> RAM based, or would a pipeline stage help ?
>
The critical path is from bytecode RAM (the instruction cache for the
processor), which has registered address but unregistered data ,out
through a 'larg' table. A jump table to map bytecode instructions to
microcode addresses. I was thinking to add another pipeline stage in this
path. However, than the bytecode branches take one more cycle.
When I add a register in this stage the critical path moved to the ALU
and fmax was 106MHz. Not a big win and it showed that the pipeline is not
so bad balanced.

If you have another good idea, I would be happy to make JOP faster :-)

Martin
--
----------------------------------------------
JOP - a Java Processor core for FPGAs:
http://www.jopdesign.com/




Article: 74008
Subject: How to generate a signal on Xilinx Spartan II
From: srakesh@hotmail.com (Rakesh Sharma)
Date: 2 Oct 2004 03:02:08 -0700
Links: << >>  << T >>  << A >>
Hi,

   I wish to generate a frequency of approx 400 Hz using Xilinx
Spartan II(200 MHz)and send the 1 bit signal to a speaker output and
hope to hear some noise.
   My VHDL code, tested on PeakVHDL simulator does generate the
waveform and is pasted at the far bottom. The problem is that the code
does not compile on Xilinx because "WAIT for 2.5 ns" is not supported
on Xilinx Spartan II for a process. What would be the simplest way out
to generate 400 approx Hz on a Xilinx 200MHz device? I have used
200MHz/(2 to the power of 19) = 382 Hz approx. (Use MSB of 19 bits of
STD_LOGIC_VECTOR)

  Another thing which has confused me is: If I wish to write an
entity(below) for Spartan II, does the programmer worry about
generating the signal for "clk" input? Or simply connect it to the
correct pin of FPGA and I should get the signal of 200MHz?


ENTITY some_entity IS
	PORT (clk : IN BIT);
END some_entity;

 For my code tested on PeakVHDL, I have generated the 200MHz signal
using a test bed(music_tester) and then modified it to 400Hz.

 I apologise if the question is basic.

Thanks in advance





ENTITY music_tester IS
	PORT (clk : OUT STD_LOGIC; freq : IN STD_LOGIC);
END music_tester;

ARCHITECTURE behavioral OF  music_tester  IS
BEGIN
	process
	BEGIN
			clk <= '1';
                        -- 200MHz is 5ns cycle
			WAIT FOR 2.5 ns;
			clk <= '0';
			WAIT FOR 2.5 ns;
	END process;
END behavioral;

ENTITY music1 IS 
       PORT (clk : IN STD_LOGIC; pinout : OUT STD_LOGIC);
END music1;

ARCHITECTURE music1_structure OF music1 IS
BEGIN
			
	PROCESS(clk)
		VARIABLE  counter : STD_LOGIC_VECTOR(18 DOWNTO 0) :=
conv_std_logic_vector(0, 19);
		VARIABLE Aint : INTEGER RANGE 0 TO 524287 := 0; -- 19 bits

	BEGIN	
				IF RISING_EDGE(clk) THEN
					counter := conv_std_logic_vector(Aint, 19); 
					Aint  := Aint + 1;
                                        -- Divide 200 Mhz/(2*2*2...19
times)
                                        -- MSB has approx 382Hz
					pinout <= counter(18);     
			END IF;
END process;
END music1_structure;

ENTITY testbench IS
END testbench;
 
ARCHITECTURE structure OF testbench IS
	COMPONENT music_tester PORT (clk : OUT STD_LOGIC; freq : IN
STD_LOGIC); END COMPONENT;
	COMPONENT music1 	PORT (clk : IN STD_LOGIC; pinout : OUT STD_LOGIC);
END COMPONENT;
	SIGNAL a, b :STD_LOGIC;
BEGIN 
	tester: music_tester PORT MAP(a, b);
	UUT: music1 PORT MAP(a, b);
END structure;

Article: 74009
Subject: Re: Open-Source MicroBlaze IP-Core working in FPGA :)
From: thevlsiguru <thevlsiguru.1dhv3a@info@totallychips.com>
Date: Sat, 2 Oct 2004 05:12:00 -0500
Links: << >>  << T >>  << A >>

what is the use/future of dsprocessors in vlsi


-- 
thevlsiguruwww.totallychips.com  - VHDL, Verilog &amp; General Hardware Design discussion Forum


Article: 74010
Subject: Re: How to generate a signal on Xilinx Spartan II
From: "Leon Heller" <leon_heller@hotmail.com>
Date: Sat, 2 Oct 2004 11:55:50 +0100
Links: << >>  << T >>  << A >>
"Rakesh Sharma" <srakesh@hotmail.com> wrote in message 
news:17c0a468.0410020202.18cd41c9@posting.google.com...
> Hi,
>
>   I wish to generate a frequency of approx 400 Hz using Xilinx
> Spartan II(200 MHz)and send the 1 bit signal to a speaker output and
> hope to hear some noise.
>   My VHDL code, tested on PeakVHDL simulator does generate the
> waveform and is pasted at the far bottom. The problem is that the code
> does not compile on Xilinx because "WAIT for 2.5 ns" is not supported
> on Xilinx Spartan II for a process. What would be the simplest way out
> to generate 400 approx Hz on a Xilinx 200MHz device? I have used
> 200MHz/(2 to the power of 19) = 382 Hz approx. (Use MSB of 19 bits of
> STD_LOGIC_VECTOR)

The "WAIT..." statement is not synthesisable. You simply need a counter 
(ripple counter will do) to divide the clock down to 400 Hz or so. Write the 
VHDL for a toggle flip-flop and string lots of them together - not very 
elegant but it should work.

Leon 



Article: 74011
Subject: Re: MicroBlaze is no available as Open-Source!! (from independant 3rd party)
From: "David Brown" <david@no.westcontrol.spam.com>
Date: Sat, 2 Oct 2004 14:07:16 +0200
Links: << >>  << T >>  << A >>

"Antti Lukats" <antti@case2000.com> wrote in message
news:cjjtgn$mp6$03$1@news.t-online.com...
> "Jon Beniston" <jon@beniston.com> wrote in message
> news:e87b9ce8.0410010514.6fa501a@posting.google.com...
> > > # Xilinx benefit if MicroBlaze is in the news
> > >
> > > # Such efforts expand usage of, and research in, MicroBlaze
> > >
> > > # It can be a usefull second opinion / benchmark
> > >
> > > # Xilinx will have trademark rights to MicroBlaze, so they can
> > > restrict use of the name. Other examples of this are 6805 uC and i2c
> > > instances.
> > >
> > > # The open source core is only a tiny portion of system development:
> > > you also have compilers/SWdebuggers/HWDebuggers/Libraries, and all of
> > > those will have Xilinx license restrictions for Xilinx FPGAs.
> >
> > Actully, the compiler & I believe the debugger are open source. This
> > means that people are very close to having everything for free.
>
> 1) The compiler and binutils are GPL GNU stuff - that is Xilinx *must*
> provide the source of the those GNU tools in source code form at no
charge,
> what they are doing, the gnu source of the tools is freely available from
> Xilinx. And due to the GPL licensing they can not limit the access to that
> source code.

Xilinx don't have to provide the source free of charge.  What they have to
do is provide an offer to those who have access to the binaries, offering
them the source code for no more than a reasonable distribution fee.  They
have no obligation to make the source code available to anyone else, nor do
they have to make it free (as in beer), only free (as in speach).  However,
if someone buys a MicroBlaze development kit including the compiler, etc.,
then Xilinx must provide the source code to that someone, and they can then
pass it on freely if they want.  What this boils down to is that Xilinx has
no obligations to make the tools easily available, but if someone posts the
tools on opencores then Xilinx cannot complain (except perhaps regarding
trademarks on the name).

>
> 2) It is not of big news yet, but the new EDK software ide is based on
> Open-Source Eclipse Platform as well, but Eclipse licensing is different
so
> using Xilinx Eclipse tools is possible not free, but as Eclipse itself is
> free and Open-Source there are no limitations for 3rd parties to develop
> Eclipse based IDE for the Open-Source M*Blaze
>
> 3) uCLinux is Open-Source and free so if there is enough interest to get
the
> OpenSource M*Blaze to be able to be used in uCLinux, then we could have
> truly open multi-vendor environment for FPGA+SoftCore+OS
>
> antti
> http://uclinux.openchip.org
>
>
>



Article: 74012
Subject: Re: How to generate a signal on Xilinx Spartan II
From: Sylvain Munaut <tnt_at_246tNt_dot_com@reducespam.com>
Date: Sat, 02 Oct 2004 14:27:23 +0200
Links: << >>  << T >>  << A >>
Hi

>   Another thing which has confused me is: If I wish to write an
> entity(below) for Spartan II, does the programmer worry about
> generating the signal for "clk" input? Or simply connect it to the
> correct pin of FPGA and I should get the signal of 200MHz?

I'm not sure I understand the question but :

The CLK input MUST be provided by external means like a Crystal Oscillator and must be directed
to an appropriate pin on the FPGA.

Then you must use constrainsts so that your VHDL nets that should be connected to the outside are
locked onto the right pads of the FPGA (depends on your board design).


Sylvain

Article: 74013
Subject: Re: FPGA vs ASIC area
From: austin <austin@xilinx.com>
Date: Sat, 02 Oct 2004 08:39:43 -0700
Links: << >>  << T >>  << A >>
Rick,

Bad hair day?

Answers below,

Austin

rickman wrote:
> Austin Lesea wrote:
> 
>>Jon,
>>
>>Peter is right:  ASIC testing rarely gets more than 95% coverage.  The
>>best is about 98% coverage.
>>
>>We can get an arbitrarily high coverage by just increasing our patterns
>>(99.9%+) for 0 added silicon cost.  ASICs can not do that.
> 
> 
> But as Peter pointed out, silicon cost is not the only variable cost. 
> The longer testing adds to the unit cost just as larger silicon does.  
>

Completely different costs.  You can not change silicon every week, but 
you can change BIST patterns.  Patterns can be improved continually, 
which drives down costs.

> 
> 
>>To get any better, they either have to add more logic for BIST (30%+ of
>>a Pentium IV is BIST logic) which increases area and cost and decreases
>>yield, or just be happy with the coverage of the scan chain (which is
>>not all that good).
> 
> 
> Nonsense.  There are design techniques to measure testability to allow
> as high testing coverage as is required by improving the test.  If there
> is no way to determine a fault in a node, then by definition, it won't
> affect the operation of the chip!  Any fault that makes a difference in
> chip operation is observable, the only question is how to stimulate the
> chip to detect it.  That is a well understood problem.  
> 

So 98% is as good as you get in an ASIC, and we can get an arbritrariy 
higher coverage with no silicon area penalty.  Then we can take our time 
to improve the patterns till they take very little time to run.

What does "unobservable" error have to do with this?  I am talking about 
that last 2% of errors that ASICs do not catch, and could be observable 
(if they took infinite time, and infinite resources).

> 
> 
>>Each BIST or scan chain is unique, and software, test vectors, etc. muct
>>be developed each time anything is new or different.
> 
> 
> Yes, but that does not mean excess test development time.  Much of this
> process is automated. 
> 

True, but then you have to see what the automation missed.


> 
> 
>>FPGAs have 0% extra area for BIST (they are 100% BIST with a different
>>bitstream!).
> 
> 
> No, by definition an FPGA has extra area for BIST, that is what makes it
> an FPGA, all the *extra* stuff in it!!!  What is the area overhead for
> an FPGA vs. an ASIC; 10X, 20X?  Even if you build an ASIC that is two
> generations back such as 150 nm vs. 90 nm, the ASIC will be smaller,
> faster and therefore cheaper.  
> 
> 

Unfair.  ASICs do have fewer transistors to do the same job, but do not 
then use the fact that FPGAs have more to justify that ASICs have a 
better approach to testing:  they do not.

A certain very lasge ASIC manufacturer might be adding FPGA cores to 
their ASICs, not for any direct customer benefit, but because it might 
be easier and cheaper with more coverage to test them that way.

> 
>>You must understand that the 405PPC, MGT, DCM, and other "hardened IP"
>>are just like ASICs, so we already know everything there is to know
>>about ASICs, their design, and testing.  In fact Xilinx the 3rd largest
>>'ASIC' manufacturer in the world (behind IBM and NEC --
>>Gartner/Dataquest 'ASIC/FPGA Vendor Ranking 2003').
>>
>>FPGA vendors may be the last stronghold of full custom ASIC design left
>>in the world. ASIC houses are mostly standard cell, or structured
>>(basically same thing), with little or no full custom.
>>
>>Our customers tell us that if they want to play with the latest and
>>greatest technologies and designs (like 10 Gbs MGTs), they need to use
>>our FPGAs, because the ASIC cells are a generation behind.
> 
> 
> How is using the "latest and greatest technologies" an advantage when it
> comes with a 10X area premium???

Well, first off, the ppc, mgt, etc have no area (or cost) premium.  In 
fact some would consider them free.

And the 'premium' you claim for FPGAs must not be much, as we keep 
selling them for less $$, and have more features with each generation.

> 
> 

Article: 74014
Subject: XPower help.
From: ted644@hotmail.com (Ted)
Date: 2 Oct 2004 08:44:24 -0700
Links: << >>  << T >>  << A >>
Hi All,

I am using XPower and I encounter the following warnings:
WARNING:Power:762 - Only 61% of the design signals have been set.
WARNING:Power:763 - Only 49% of the design signals toggle.
INFO:Power:556 - Estimate is inaccurate based on analysis of the
design, user
   input and characterization data.

I am using the post-place-and-route simulation model and the
activities of all nodes are set by ModelSim using a vcd file
simulating up to 10000 cycles.

1) Specifically, how does it determine that the estimate is
inaccurate?

2) Are register-rich designs tend to be like that i.e. because
activities at varoius nodes has not been set properly?

3) WHAT CAN I DO?

The detailed report is below:

----------------------------------------------------------------
Release 6.3.01i - XPower SoftwareVersion:G.36
Copyright (c) 1995-2004 Xilinx, Inc.  All rights reserved.
Design:       stream
Preferences:  stream.pcf
VCD File:     stream.vcd
Part:         2v1000ff896-6
Data version: ADVANCED,v1.01,07-31-02

Power summary:                        I(mA)    P(mW)
----------------------------------------------------------------
Total estimated power consumption:               567
                               ---
                      Vccint 1.50V:      103      154
                      Vccaux 3.30V:      100      330
                      Vcco33 3.30V:       25       83
                               ---
                           Clocks:        1        1
                              IOs:        0       18
                           Inputs:        0        0
                            Logic:        1        1
                          Outputs:
                             Vcco33      19       62
                          Signals:        1        1
                               ---
           Quiescent Vccint  1.50V:      100      150
           Quiescent Vccaux  3.30V:      100      330
           Quiescent Vcco33  3.30V:        1        3
             Startup Vccint  1.5V:      250
             Startup Vccaux  3.3V:      100
             Startup Vcco33  3.3V:       50
                               ---
Package power limits, ambient 25C:              5085
                          250 LFM:              7317
                          500 LFM:              8955
                          750 LFM:             10169

Thermal summary:
----------------------------------------------------------------
   Estimated junction temperature:                32C
                      250 LFM    30C
                      500 LFM    29C
                      750 LFM    28C
                  Ambient temp:  25C
                     Case temp:  31C
                     Theta J-A:  12C/W
                               ---
Max ambient at junction max of  85C:  78C
                         250 LFM      80C
                         500 LFM      81C
                         750 LFM      82C

Decoupling Network Summary:      Cap Range (uF)      #
----------------------------------------------------------------
Capacitor Recommendations:    
Total for      Vccint :                             44
                                470.0  - 1000.0 :    1
                                 4.70  -  10.00 :    2
                                0.470  -  2.200 :    5
                               0.0470  - 0.2200 :    8
                               0.0100  - 0.0470 :   14
                               0.0010  - 0.0047 :   14
                                      ---
Total for      Vccaux :                              8
                                470.0  - 1000.0 :    1
                               0.0470  - 0.2200 :    1
                               0.0100  - 0.0470 :    2
                               0.0010  - 0.0047 :    4
                                      ---
Total for      Vcco33 :                             11
                                470.0  - 1000.0 :    1
                                0.470  -  2.200 :    1
                               0.0470  - 0.2200 :    2
                               0.0100  - 0.0470 :    3
                               0.0010  - 0.0047 :    4
                            -----------------------------
I/O Bank Details:             

Bank  0 (3.3V) :
                                470.0  - 1000.0 :    1
                                0.470  -  2.200 :    1
                               0.0470  - 0.2200 :    2
                               0.0100  - 0.0470 :    3
                               0.0010  - 0.0047 :    4
                                          Total :   11
                                      ---
----------------------------------------------------------------
For further information on Bypass/Decoupling Capacitors see
application note 623

WARNING:Power:762 - Only 61% of the design signals have been set.
WARNING:Power:763 - Only 49% of the design signals toggle.
INFO:Power:556 - Estimate is inaccurate based on analysis of the
design, user
   input and characterization data.

Power details:
-------------------------------------------------------------------------------
Outputs:1                        Loads  Loading(fF)  C(pF)  F(MHz) 
I(mA)  P(mW)
-------------------------------------------------------------------------------
Vcco33
  mpc_d<10>-E0                           35000        13      5.1   
0.8    2.7
  mpc_d<12>-E0                           35000        13      5.1   
0.8    2.7
  mpc_d<14>-E0                           35000        13      5.1   
0.8    2.7
  mpc_d<15>-E0                           35000        13      5.1   
0.8    2.7
  mpc_d<16>-E0                           35000        13      5.1   
0.8    2.7
  mpc_d<20>-E0                           35000        13      5.1   
0.8    2.7
  mpc_d<22>-E0                           35000        13      5.1   
0.8    2.7
  mpc_d<27>-E0                           35000        13      5.1   
0.8    2.7
  mpc_d<07>-E0                           35000        13      5.0   
0.8    2.6
  mpc_d<08>-E0                           35000        13      4.9   
0.8    2.6
-------------------------------------------------------------------------------
Logic:                           Loads  Loading(fF)  C(pF)  F(MHz) 
I(mA)  P(mW)
-------------------------------------------------------------------------------
CompRegD345<3>-E1                                      1     10.0   
0.0    0.0
CompRegB378-U1/SP.WSGEN                                0     10.0   
0.0    0.0
CompRegB378.WSGEN                                      0     10.0   
0.0    0.0
CompRegB381-U1/SP.WSGEN                                0     10.0   
0.0    0.0
CompRegB381.WSGEN                                      0     10.0   
0.0    0.0
CompRegB384-U1/SP.WSGEN                                0     10.0   
0.0    0.0
CompRegB384.WSGEN                                      0     10.0   
0.0    0.0
CompRegB387-U1/SP.WSGEN                                0     10.0   
0.0    0.0
CompRegB387.WSGEN                                      0     10.0   
0.0    0.0
CompRegB583-U1/SP.WSGEN                                0     10.0   
0.0    0.0
-------------------------------------------------------------------------------
Signals:                         Loads  Loading(fF)  C(pF)  F(MHz) 
I(mA)  P(mW)
-------------------------------------------------------------------------------
__ibuf_mpc_a<04>                   33                 19      2.8   
0.1    0.1
__ibuf_mpc_a<03>                   33                 19      2.8   
0.1    0.1
__ibuf_mpc_a<02>                   33                 19      2.5   
0.1    0.1
__ibuf_mpc_a<05>                   33                 17      2.2   
0.1   ~0.0
__ibuf_mpc_oe                      36                  9      3.2   
0.0   ~0.0
CompRegC216                        78                 23      0.9   
0.0   ~0.0
internal_mpc_d<15>                  1                  3      5.1   
0.0   ~0.0
internal_mpc_d<22>                  1                  2      5.1   
0.0   ~0.0
internal_mpc_d<01>                  1                  2      4.9   
0.0   ~0.0
internal_mpc_d<00>                  1                  2      4.8   
0.0   ~0.0
-------------------------------------------------------------------------------
Clocks:1                         Loads  Loading(fF)  C(pF)  F(MHz) 
I(mA)  P(mW)
-------------------------------------------------------------------------------
stream/clk/IBUFG
 Logic:
  stream/clk/BUFG                                      6     10.0   
0.1    0.1
 Nets:
  stream/clk                       94                 38     10.0   
0.6    0.9
  stream/clk/IBUFG                  1                  0     10.0   
0.0   ~0.0
-------------------------------------------------------------------------------
Inputs:                          Loads  Loading(fF)  C(pF)  F(MHz) 
I(mA)  P(mW)
-------------------------------------------------------------------------------
stream/clk/IBUFG                                       3     10.0   
0.1    0.1
__ibuf_mpc_oe                                          3      3.2   
0.0    0.0
__ibuf_mpc_a<00>                                       3      3.0   
0.0    0.0
__ibuf_mpc_a<03>                                       3      2.8   
0.0    0.0
__ibuf_mpc_a<04>                                       3      2.8   
0.0    0.0
__ibuf_mpc_a<07>                                       3      2.8   
0.0    0.0
__ibuf_mpc_we<3>                                       3      2.8   
0.0    0.0
__ibuf_mpc_a<13>                                       3      2.7   
0.0    0.0
__ibuf_mpc_a<10>                                       3      2.6   
0.0    0.0
__ibuf_mpc_a<11>                                       3      2.5   
0.0    0.0
-------------------------------------------------------------------------------
IOs:1                            Loads  Loading(fF)  C(pF)  F(MHz) 
I(mA)  P(mW)
-------------------------------------------------------------------------------
Vcco33
  __ibuf_mpc_d<05>                                     3      5.3   
0.0    0.0
  mpc_d<05>-E0                           35000        13      5.2   
0.8    2.7
  __ibuf_mpc_d<06>                                     3      4.9   
0.0    0.0
  mpc_d<06>-E0                           35000        13      5.2   
0.8    2.7
  mpc_d<01>-E0                           35000        13      4.9   
0.8    2.6
  __ibuf_mpc_d<01>                                     3      5.5   
0.0    0.0
  __ibuf_mpc_d<00>                                     3      5.8   
0.0    0.0
  mpc_d<00>-E0                           35000        13      4.8   
0.8    2.5
  __ibuf_mpc_d<02>                                     3      5.2   
0.0    0.0
  mpc_d<02>-E0                           35000        13      4.8   
0.8    2.5
-------------------------------------------------------------------------------

Power improvement guide:
-------------------------------------------------------------------------------
 3 of 101 registers use an enable signal
-------------------------------------------------------------------------------
Signal                             Power when     Power when     Power
savings
                                   asserted(mW)   disabled(mW)   at
50%(mW)
-------------------------------------------------------------------------------
AddrInCount355/Start-E0            567.1          567.1          0.0


For further suggestions on power improvements see application note no.
421

Analysis completed: Sat Oct 02 16:28:00 2004
----------------------------------------------------------------

Article: 74015
Subject: Re: FPGA vs ASIC area
From: austin <austin@xilinx.com>
Date: Sat, 02 Oct 2004 08:45:51 -0700
Links: << >>  << T >>  << A >>
Rick,

Configuration of a test pattern can make efficient use of our partial 
reconfiguration capabilities.  I can not say how many seconds an FPGA 
spends in the tester, but it is less that an ASIC does.  There also may 
be much faster ways to configure that we can use, but do not offer to 
customers.

Why can we do 1,000's of BIST patterns faster?  Well one obvious reason 
is that a BIST pattern in a FPGA can run at the speed of the FPGA, which 
is often 10X to 100X faster than the tester.  It might have to run for 
1000 clocks to finish, and then go on to the next test, which might be 
different by the contents of a few LUTs.

If you are really curious of how we perform this magic, you can research 
all of our BIST patents and think about what you would do if you faced 
such a problem.

Again, Peter is right.

Austin

rickman wrote:

> You may be convinced, but that is not the same as having facts.  The
> simple fact that you "reconfigure tens and hundreds of times" means you
> take a lot of time just loading your tests into the chip before you can
> run them on the chip.  The test methods for ASIC testing has been around
> for a long time, it is the details of a particular test that is unique
> for a given ASIC.  This is not a new science, it is well understood and
> largely automated.  
> 
> Which question is meaningless and cute?  I didn't ask a question.  I was
> responding to *your* statements about total costs.  I believe your point
> was about the silicon area not being the sole or possibly even the
> largest part of chip costs.  Non-recurring costs can be large, but their
> per-unit cost depends on the volume.  However, the testing and silicon
> per-unit costs are the same regardless of volume.  So they are more
> important as the volume increases.  
> 
> 
> Peter Alfke wrote:
> 
>>I doubt that very much. I am convinced that FPGA testing is simpler and
>>cheaper than ASIC testing. The secet is in the reconfigurability. We do not
>>just apply external test vectors. We reconfigure tens and hundreds of times,
>>and we have a lot of self-test engines that run in parallel inside the chip.
>>And we can afford to spend a lot of engineering on our generic test
>>methodologies, since they are amortized across >1 billion dollars in annual
>>sales. ASICs have to develop new test methods for each design.
>>
>>But:
>>What was the original question really about ?
>>I think it was a meaningless "cute" question.
>>Peter Alfke
>>
>>
>>>From: rickman <spamgoeshere4@yahoo.com>
>>>Reply-To: john@bluepal.net
>>>Newsgroups: comp.arch.fpga
>>>Date: Thu, 30 Sep 2004 16:54:28 -0400
>>>Subject: Re: FPGA vs ASIC area
>>>
>>>
>>>Another large hunk of chip cost is testing.  And lets face it, testing a
>>>large, complex FPGA takes time on an expensive tester.  An ASIC that
>>>would fit on an FPGA will be a lot cheaper to test.  Of course Xilinx
>>>has that program that only tests FPGAs to the users test vectors, so I
>>>guess that can help limit that part of the total cost.
>>>
>>>--
>>>
>>>Rick "rickman" Collins
>>>
>>>
> 
> 

Article: 74016
Subject: Re: How to generate a signal on Xilinx Spartan II
From: nweaver@soda.csua.berkeley.edu (Nicholas Weaver)
Date: Sat, 2 Oct 2004 15:48:41 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <415e8938$0$2840$cc9e4d1f@news-text.dial.pipex.com>,
Leon Heller <leon_heller@hotmail.com> wrote:
>The "WAIT..." statement is not synthesisable. You simply need a counter 
>(ripple counter will do) to divide the clock down to 400 Hz or so. Write the 
>VHDL for a toggle flip-flop and string lots of them together - not very 
>elegant but it should work.

I know XST will infer a counter from

   reg [31:0] ctr
   always @(posedge clk)
   begin
      reg = reg + 1
   end

Far easier than stringing flops to get a binary countdown.

-- 
Nicholas C. Weaver.  to reply email to "nweaver" at the domain
icsi.berkeley.edu

Article: 74017
Subject: Re: FPGA vs ASIC area
From: austin <austin@xilinx.com>
Date: Sat, 02 Oct 2004 08:51:32 -0700
Links: << >>  << T >>  << A >>
GS,

You are correct.  FPGA devekopment can be done just as poorly as 
software code, and often is.

Austin

General Schvantzkoph wrote:

>>  The place where FPGAs win big is NRE, an FPGA design
>>
>>>costs millions less than an ASIC design. Even if you take out the cost
>>>of the mask set there is a big difference because you don't have to
>>>spend as much on verification on an FPGA design as on an ASIC.
>>
>>Even though you should (spend money on verification).  People do not.
>>
>>  With an FPGA you can
>>
>>>go into the lab with a design that's almost right because fixing the
>>>bug is cheap, with an ASIC you have to have a design that's completely
>>>right before you build it because you can't fix it later.
>>
>>Again, fixing it as it is shipped is not a way to run a company.  Not
>>cheap if you ship 10,000 that you later have to retrofit (reprogram).
>>But if it provides a competitive advantage, people will take advantage
>>of it.
> 
> 
> I didn't say no verification, I would never go into the lab with a design
> that hadn't been verified. The difference is that you can spend a few
> weeks to a couple of months simulating an FPGA and then go into the lab
> and run it in a real system at the real clock speed and get the last bugs.
> In big systems the bit patterns should be loaded by the software not by
> serial proms, if a bug crops up you rev the software. Everyone expects
> software to be buggy so no one blinks an eye if there is a new software
> release, let the software guys take the blame. In my experience the
> software guys feel so guilty about bugs that it's hard to convince them
> that it's not their fault. If a system can't be field upgraded then you
> have to test the hell out of it but you do that on the real hardware.
> Either way you are in the lab a full 12 to 18 months earlier with an
> FPGA then you are with an ASIC.
> 

Article: 74018
Subject: Re: JOP on Spartan-3 Starter Kit
From: "Martin Schoeberl" <martin.schoeberl@chello.at>
Date: Sat, 02 Oct 2004 16:03:36 GMT
Links: << >>  << T >>  << A >>
> As a quick aside, Cyclone has three speed grades, Spartan-3 only two.
In
> general, a speed grade represents about a 15% difference in
performance.
>
> Slowest vs. slowest speed grade would be interesting.

Ok, here it is:
Cyclone slowest (-8): 77.5MHz
Spartan slowest (-4): 77.8MHz
Looks now better for X....

And now let's throw in some price numbers. Prices are single units from
arrow.com and avnet.com, both devices in the same package (tqfp144):
Cyclone: EP1C6T144C6: $41.60
Cyclone: EP1C6T144C8: $27.70
Spartan-3: XC3S200-4TQ144C: $19.93
no price for -5 speed grade

And relate the price to density and speed in a 'funny' way:
price / 1000 LCs / MHz:

EP1C6-6: 41.60$ / 5.980 kLC / 98 MHz = 7.1 cent / kLC / MHz
EP1C6-8: 5.98 cent / kLC /MHz
XC3S200-T: $19.93 / 3.840 kLC / 77.8 MHz = 6.7 cent / kLC /MHz
and now it looks again better for A...

I did not take into account the multipliers and larger memories in the
Spartan, but also not the fact that the Cyclones are available for a
longer time (I got my first Cyclone samples 01/2003 and sold the first
boards 02/2003 :-)

Martin

--
----------------------------------------------
JOP - a Java Processor core for FPGAs:
http://www.jopdesign.com/





Article: 74019
Subject: Re: JOP on Spartan-3 Starter Kit
From: Sylvain Munaut <tnt_at_246tNt_dot_com@reducespam.com>
Date: Sat, 02 Oct 2004 18:32:38 +0200
Links: << >>  << T >>  << A >>

>>Slowest vs. slowest speed grade would be interesting.
>  
> Ok, here it is:
> Cyclone slowest (-8): 77.5MHz
> Spartan slowest (-4): 77.8MHz
> Looks now better for X....

I can't reproduces those numbers ( or any of the one you gave ) (for xilinx, I mean, I don't have quartus installed),
how do you proceed exactly ?


> Spartan-3: XC3S200-4TQ144C: $19.93
Huh ? I can buy XC3S400-4FT256 for 23$ piece for very small qty (6 pieces in my case) and that's from an avnet company.


> And relate the price to density and speed in a 'funny' way:
> price / 1000 LCs / MHz:
> 
> EP1C6-6: 41.60$ / 5.980 kLC / 98 MHz = 7.1 cent / kLC / MHz
> EP1C6-8: 5.98 cent / kLC /MHz
> XC3S200-T: $19.93 / 3.840 kLC / 77.8 MHz = 6.7 cent / kLC /MHz
> and now it looks again better for A...

For the XC3S400-4FT256 (assuming same frequency) : $23 / 7.680 kLC / 77.8Mhz = 3.85 cent / kLC / Mhz

Numbers ... you can make them tell anything you want ;)


> I did not take into account the multipliers and larger memories in the
> Spartan, but also not the fact that the Cyclones are available for a
> longer time (I got my first Cyclone samples 01/2003 and sold the first
> boards 02/2003 :-)

Yup, I think there are 200LC used for a booth multiplier, should be easy to lower that with a dedicated multiplier (and also go faster i would guess).



Btw, is there any networking available ? 
I have a Avnet Spartan 3 kit with an ethernet PHY on bard, that would be nice to get TCP/IP ;)


Sylvain

Article: 74020
Subject: Re: XPower help.
From: austin <austin@xilinx.com>
Date: Sat, 02 Oct 2004 10:28:00 -0700
Links: << >>  << T >>  << A >>

Ted,

It is trying to tell you that your simulation test bench doesn't cause 
much to happen.

The estimate is only as good as the test bench.

If all those nodes don't ever switch, then you can probably simplify 
your design!

The number of cycles is no measure of coverage.  If I hold a register in 
reset, and clock it a million times, I will not see much power.

So, without a test bench that exercises all of the registers, with the 
worst case transitions, the estimate isn't very good.

But only you can tell what the register values should be, the tool can't 
just guess.

Some people use a LFSR to generate pseudo random data as a stimulus. 
Might, or might not be appropriate in your case.

Austin

Ted wrote:

> Hi All,
> 
> I am using XPower and I encounter the following warnings:
> WARNING:Power:762 - Only 61% of the design signals have been set.
> WARNING:Power:763 - Only 49% of the design signals toggle.
> INFO:Power:556 - Estimate is inaccurate based on analysis of the
> design, user
>    input and characterization data.
> 
> I am using the post-place-and-route simulation model and the
> activities of all nodes are set by ModelSim using a vcd file
> simulating up to 10000 cycles.
> 
> 1) Specifically, how does it determine that the estimate is
> inaccurate?
> 
> 2) Are register-rich designs tend to be like that i.e. because
> activities at varoius nodes has not been set properly?
> 
> 3) WHAT CAN I DO?
> 
> The detailed report is below:
> 
> ----------------------------------------------------------------
> Release 6.3.01i - XPower SoftwareVersion:G.36
> Copyright (c) 1995-2004 Xilinx, Inc.  All rights reserved.
> Design:       stream
> Preferences:  stream.pcf
> VCD File:     stream.vcd
> Part:         2v1000ff896-6
> Data version: ADVANCED,v1.01,07-31-02
> 
> Power summary:                        I(mA)    P(mW)
> ----------------------------------------------------------------
> Total estimated power consumption:               567
>                                ---
>                       Vccint 1.50V:      103      154
>                       Vccaux 3.30V:      100      330
>                       Vcco33 3.30V:       25       83
>                                ---
>                            Clocks:        1        1
>                               IOs:        0       18
>                            Inputs:        0        0
>                             Logic:        1        1
>                           Outputs:
>                              Vcco33      19       62
>                           Signals:        1        1
>                                ---
>            Quiescent Vccint  1.50V:      100      150
>            Quiescent Vccaux  3.30V:      100      330
>            Quiescent Vcco33  3.30V:        1        3
>              Startup Vccint  1.5V:      250
>              Startup Vccaux  3.3V:      100
>              Startup Vcco33  3.3V:       50
>                                ---
> Package power limits, ambient 25C:              5085
>                           250 LFM:              7317
>                           500 LFM:              8955
>                           750 LFM:             10169
> 
> Thermal summary:
> ----------------------------------------------------------------
>    Estimated junction temperature:                32C
>                       250 LFM    30C
>                       500 LFM    29C
>                       750 LFM    28C
>                   Ambient temp:  25C
>                      Case temp:  31C
>                      Theta J-A:  12C/W
>                                ---
> Max ambient at junction max of  85C:  78C
>                          250 LFM      80C
>                          500 LFM      81C
>                          750 LFM      82C
> 
> Decoupling Network Summary:      Cap Range (uF)      #
> ----------------------------------------------------------------
> Capacitor Recommendations:    
> Total for      Vccint :                             44
>                                 470.0  - 1000.0 :    1
>                                  4.70  -  10.00 :    2
>                                 0.470  -  2.200 :    5
>                                0.0470  - 0.2200 :    8
>                                0.0100  - 0.0470 :   14
>                                0.0010  - 0.0047 :   14
>                                       ---
> Total for      Vccaux :                              8
>                                 470.0  - 1000.0 :    1
>                                0.0470  - 0.2200 :    1
>                                0.0100  - 0.0470 :    2
>                                0.0010  - 0.0047 :    4
>                                       ---
> Total for      Vcco33 :                             11
>                                 470.0  - 1000.0 :    1
>                                 0.470  -  2.200 :    1
>                                0.0470  - 0.2200 :    2
>                                0.0100  - 0.0470 :    3
>                                0.0010  - 0.0047 :    4
>                             -----------------------------
> I/O Bank Details:             
> 
> Bank  0 (3.3V) :
>                                 470.0  - 1000.0 :    1
>                                 0.470  -  2.200 :    1
>                                0.0470  - 0.2200 :    2
>                                0.0100  - 0.0470 :    3
>                                0.0010  - 0.0047 :    4
>                                           Total :   11
>                                       ---
> ----------------------------------------------------------------
> For further information on Bypass/Decoupling Capacitors see
> application note 623
> 
> WARNING:Power:762 - Only 61% of the design signals have been set.
> WARNING:Power:763 - Only 49% of the design signals toggle.
> INFO:Power:556 - Estimate is inaccurate based on analysis of the
> design, user
>    input and characterization data.
> 
> Power details:
> -------------------------------------------------------------------------------
> Outputs:1                        Loads  Loading(fF)  C(pF)  F(MHz) 
> I(mA)  P(mW)
> -------------------------------------------------------------------------------
> Vcco33
>   mpc_d<10>-E0                           35000        13      5.1   
> 0.8    2.7
>   mpc_d<12>-E0                           35000        13      5.1   
> 0.8    2.7
>   mpc_d<14>-E0                           35000        13      5.1   
> 0.8    2.7
>   mpc_d<15>-E0                           35000        13      5.1   
> 0.8    2.7
>   mpc_d<16>-E0                           35000        13      5.1   
> 0.8    2.7
>   mpc_d<20>-E0                           35000        13      5.1   
> 0.8    2.7
>   mpc_d<22>-E0                           35000        13      5.1   
> 0.8    2.7
>   mpc_d<27>-E0                           35000        13      5.1   
> 0.8    2.7
>   mpc_d<07>-E0                           35000        13      5.0   
> 0.8    2.6
>   mpc_d<08>-E0                           35000        13      4.9   
> 0.8    2.6
> -------------------------------------------------------------------------------
> Logic:                           Loads  Loading(fF)  C(pF)  F(MHz) 
> I(mA)  P(mW)
> -------------------------------------------------------------------------------
> CompRegD345<3>-E1                                      1     10.0   
> 0.0    0.0
> CompRegB378-U1/SP.WSGEN                                0     10.0   
> 0.0    0.0
> CompRegB378.WSGEN                                      0     10.0   
> 0.0    0.0
> CompRegB381-U1/SP.WSGEN                                0     10.0   
> 0.0    0.0
> CompRegB381.WSGEN                                      0     10.0   
> 0.0    0.0
> CompRegB384-U1/SP.WSGEN                                0     10.0   
> 0.0    0.0
> CompRegB384.WSGEN                                      0     10.0   
> 0.0    0.0
> CompRegB387-U1/SP.WSGEN                                0     10.0   
> 0.0    0.0
> CompRegB387.WSGEN                                      0     10.0   
> 0.0    0.0
> CompRegB583-U1/SP.WSGEN                                0     10.0   
> 0.0    0.0
> -------------------------------------------------------------------------------
> Signals:                         Loads  Loading(fF)  C(pF)  F(MHz) 
> I(mA)  P(mW)
> -------------------------------------------------------------------------------
> __ibuf_mpc_a<04>                   33                 19      2.8   
> 0.1    0.1
> __ibuf_mpc_a<03>                   33                 19      2.8   
> 0.1    0.1
> __ibuf_mpc_a<02>                   33                 19      2.5   
> 0.1    0.1
> __ibuf_mpc_a<05>                   33                 17      2.2   
> 0.1   ~0.0
> __ibuf_mpc_oe                      36                  9      3.2   
> 0.0   ~0.0
> CompRegC216                        78                 23      0.9   
> 0.0   ~0.0
> internal_mpc_d<15>                  1                  3      5.1   
> 0.0   ~0.0
> internal_mpc_d<22>                  1                  2      5.1   
> 0.0   ~0.0
> internal_mpc_d<01>                  1                  2      4.9   
> 0.0   ~0.0
> internal_mpc_d<00>                  1                  2      4.8   
> 0.0   ~0.0
> -------------------------------------------------------------------------------
> Clocks:1                         Loads  Loading(fF)  C(pF)  F(MHz) 
> I(mA)  P(mW)
> -------------------------------------------------------------------------------
> stream/clk/IBUFG
>  Logic:
>   stream/clk/BUFG                                      6     10.0   
> 0.1    0.1
>  Nets:
>   stream/clk                       94                 38     10.0   
> 0.6    0.9
>   stream/clk/IBUFG                  1                  0     10.0   
> 0.0   ~0.0
> -------------------------------------------------------------------------------
> Inputs:                          Loads  Loading(fF)  C(pF)  F(MHz) 
> I(mA)  P(mW)
> -------------------------------------------------------------------------------
> stream/clk/IBUFG                                       3     10.0   
> 0.1    0.1
> __ibuf_mpc_oe                                          3      3.2   
> 0.0    0.0
> __ibuf_mpc_a<00>                                       3      3.0   
> 0.0    0.0
> __ibuf_mpc_a<03>                                       3      2.8   
> 0.0    0.0
> __ibuf_mpc_a<04>                                       3      2.8   
> 0.0    0.0
> __ibuf_mpc_a<07>                                       3      2.8   
> 0.0    0.0
> __ibuf_mpc_we<3>                                       3      2.8   
> 0.0    0.0
> __ibuf_mpc_a<13>                                       3      2.7   
> 0.0    0.0
> __ibuf_mpc_a<10>                                       3      2.6   
> 0.0    0.0
> __ibuf_mpc_a<11>                                       3      2.5   
> 0.0    0.0
> -------------------------------------------------------------------------------
> IOs:1                            Loads  Loading(fF)  C(pF)  F(MHz) 
> I(mA)  P(mW)
> -------------------------------------------------------------------------------
> Vcco33
>   __ibuf_mpc_d<05>                                     3      5.3   
> 0.0    0.0
>   mpc_d<05>-E0                           35000        13      5.2   
> 0.8    2.7
>   __ibuf_mpc_d<06>                                     3      4.9   
> 0.0    0.0
>   mpc_d<06>-E0                           35000        13      5.2   
> 0.8    2.7
>   mpc_d<01>-E0                           35000        13      4.9   
> 0.8    2.6
>   __ibuf_mpc_d<01>                                     3      5.5   
> 0.0    0.0
>   __ibuf_mpc_d<00>                                     3      5.8   
> 0.0    0.0
>   mpc_d<00>-E0                           35000        13      4.8   
> 0.8    2.5
>   __ibuf_mpc_d<02>                                     3      5.2   
> 0.0    0.0
>   mpc_d<02>-E0                           35000        13      4.8   
> 0.8    2.5
> -------------------------------------------------------------------------------
> 
> Power improvement guide:
> -------------------------------------------------------------------------------
>  3 of 101 registers use an enable signal
> -------------------------------------------------------------------------------
> Signal                             Power when     Power when     Power
> savings
>                                    asserted(mW)   disabled(mW)   at
> 50%(mW)
> -------------------------------------------------------------------------------
> AddrInCount355/Start-E0            567.1          567.1          0.0
> 
> 
> For further suggestions on power improvements see application note no.
> 421
> 
> Analysis completed: Sat Oct 02 16:28:00 2004
> ----------------------------------------------------------------

Article: 74021
Subject: Re: How to get 27MHz from 10 MHz in FPGA???
From: "Subroto Datta" <sdatta@altera.com>
Date: Sat, 02 Oct 2004 17:32:35 GMT
Links: << >>  << T >>  << A >>

"H. Peter Anvin" <hpa@terminus.zytor.com> wrote in message 
news:cjcq0b$8g4$1@terminus.zytor.com...
>>
>> For either device, you do not need to compute the PLL values - if you
>> tell Quartus the requirements it will compute the PLL settings for
>> you.
>>
>
> I've had problems with Quartus II 4.1 (Web Edition SP0-2) and getting
> the PLL values to make sense.  In particular, if I feed it:
>
>     fin = 50 MHz
>     c0 = 4/1 = 200 MHz
>     c1 = 1/4 = 12.5 MHz
>
> ... it says it cannot make the desired PLL.  2.x and 3.x both did this
> correctly, and if I lie and specify fin = 75 MHz it builds the correct
> PLL and it works correctly with a 50 MHz input.  The timing analyzer
> spits out a message that the input frequency has been overridden (by
> specifying clkin = 50 MHz as a timing constraint) and does the right
> thing.
>
> This is for a Cyclone EP1C20F400C7 device.
>
> -hpa

Hello Peter,

Quartus configures PLLs that satisfy all the device constraints (e.g.
VCO range, PFD range, etc), which is why it cannot build the specific
configuration you suggested for a Cyclone device (though it can be built
in Stratix/StratixGX/StratixII devices).

In Cyclone devices, the VCO frequency must be between 490 Mhz and 1000
Mhz.  For the example you gave, the resulting PLL's VCO frequency for a
75 Mhz input would be 600 Mhz (since the M counter is 8, and N counter
is 1).  But if you manually bypass this safeguard and feed in a
frequency of 50 Mhz, the PLL's VCO frequency would be 400 Mhz, which is
outside the supported range for Cyclone PLLs.

In the situation described above (75 Mhz input selected, but
50Mhz actual) the PLL is operating outside the specified range, so
jitter performance and static phase shift may be adversely affected.
This limit was set in Quartus II 3.0 SP2 for the first time, as a result
of characterization of the Cyclone devices. Previously, in Quartus II
3.0, the limit was 300 Mhz, based on preliminary simulation results.

Hope this helps.
- Subroto Datta
Altera Corp.






Article: 74022
Subject: Re: JOP on Spartan-3 Starter Kit
From: "E.S." <emu@ecubics.com>
Date: Sat, 02 Oct 2004 11:34:06 -0600
Links: << >>  << T >>  << A >>
Martin Schoeberl wrote:

> For those who are interested in a short comparison between Cyclone and
> Spartan-3:
> 
> Cyclone EP1C6Q240C6:
>     fmax: 98 MHz, 2066 LC/Es (34% out of 5980)
> Spartan-3 XC3S200-5
>     fmax: 82 MHz, 2015 LC/Es (52% out of 3840)

Where did you get this numbers from ?
I get on ISE 6.2.03:
xc3s200-4 Minimum period: 10.428ns (Maximum Frequency: 95.896MHz)
xc3s200-5 Minimum period: 9.503ns (Maximum Frequency: 105.235MHz)

cheers



Article: 74023
Subject: Re: JOP on Spartan-3 Starter Kit
From: "Martin Schoeberl" <martin.schoeberl@chello.at>
Date: Sat, 02 Oct 2004 17:38:51 GMT
Links: << >>  << T >>  << A >>
Sylvain,

> >>Slowest vs. slowest speed grade would be interesting.
> >
> > Ok, here it is:
> > Cyclone slowest (-8): 77.5MHz
> > Spartan slowest (-4): 77.8MHz
> > Looks now better for X....
>
> I can't reproduces those numbers ( or any of the one you gave ) (for
xilinx, I mean, I don't have quartus installed),
> how do you proceed exactly ?

Set a time constraint for clk (in this case I used 12ns). However, this
should already be done in the UCF you downloaded with the project. Then
look at the 'text-based post-plcae & route static timing report'. At the
end you will find:

Design statistics:
   Minimum period:  12.848ns (Maximum frequency:  77.833MHz)

Don't let yourself be fooled by the maximum frequency from the synthesis
report. These are dummy numbers (in this case 96 MHz...).

> > Spartan-3: XC3S200-4TQ144C: $19.93
> Huh ? I can buy XC3S400-4FT256 for 23$ piece for very small qty (6
pieces in my case) and that's from an avnet company.

The list price for the XC3S400-5FT256C (they don't have the -4 on the
website) at avnet.com is $41. I just compared the prices that are
available 'online'. I also got the Cyclone (Q240 package) cheaper: EUR
22.75 instead of $ ??..... for this device there is a 'call for quote' at
arrow.com. The lead free costs $32.90, but these are more expensive in
general.

Btw, does somebody know why the lead free devices are more expensive. I
did'n know up to now that semiconductors contain lead. I only know that
it's part of the solder and when it's forbidden will probably increase
production cost of PCBs.

> > I did not take into account the multipliers and larger memories in
the
> > Spartan, but also not the fact that the Cyclones are available for a
> > longer time (I got my first Cyclone samples 01/2003 and sold the
first
> > boards 02/2003 :-)
>
> Yup, I think there are 200LC used for a booth multiplier, should be
easy to lower that with a dedicated multiplier (and also go faster i
would guess).

Yes that would drop the LC count and I could go with the next smaller
Spartan-3. Uups, where is the XC3S100?
The multiplication would be faster, but the multiplication (imul bytecode
in the JVM) has a dynamic instruction frequency of 0.24% in typicall Java
programs. That would not compensate for the clock frequency factor of 1.2
between the Cyclone and the Spartan-3.

> Btw, is there any networking available ?
> I have a Avnet Spartan 3 kit with an ethernet PHY on bard, that would
be nice to get TCP/IP ;)

Do you mean available with JOP? Yes, I have a small TCP/IP stack in Java
with drivers for the CS8900 (Ethernet), PPP and SLIP. Even a small
webserver is running on JOP: http://84.112.19.23 ;-)

Martin
----------------------------------------------
JOP - a Java Processor core for FPGAs:
http://www.jopdesign.com/




Article: 74024
Subject: Re: JOP on Spartan-3 Starter Kit
From: "Martin Schoeberl" <martin.schoeberl@chello.at>
Date: Sat, 02 Oct 2004 17:44:44 GMT
Links: << >>  << T >>  << A >>
> Martin Schoeberl wrote:
>
> > For those who are interested in a short comparison between Cyclone
and
> > Spartan-3:
> >
> > Cyclone EP1C6Q240C6:
> >     fmax: 98 MHz, 2066 LC/Es (34% out of 5980)
> > Spartan-3 XC3S200-5
> >     fmax: 82 MHz, 2015 LC/Es (52% out of 3840)
>
> Where did you get this numbers from ?
> I get on ISE 6.2.03:
> xc3s200-4 Minimum period: 10.428ns (Maximum Frequency: 95.896MHz)
> xc3s200-5 Minimum period: 9.503ns (Maximum Frequency: 105.235MHz)
>
Don't take the numbers from the Synthesizer! Use the frequency after P&R,
in the post P&R static timing report.
This mistake is done by many ISE users. Xilinx should change the text in
the synthesizer report to state it clearly that this number is an
estimation!

Martin





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