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 73900

Article: 73900
Subject: System Generator.
From: "Nirav Shah" <niravbsh@usc.edu>
Date: Thu, 30 Sep 2004 13:34:15 -0700
Links: << >>  << T >>  << A >>
Friends,
I was trying to install Xilinx System Generator v 6.2 (evaluation) on my
computer.
I have Xilinx webpack 6.2i SP 3 with IP Update 1.1 for it & Matlab 6.5 (R13)
But while installing it says "Can not find Code GENERATOR" installation.
i checked environmet variable, XILINX = c:\Xilinx & that's where my
installation is.
Any Suggetions?
Thanks
Nirav



Article: 73901
Subject: Re: MicroBlaze is no available as Open-Source!! (from independant 3rd
From: rickman <spamgoeshere4@yahoo.com>
Date: Thu, 30 Sep 2004 16:37:25 -0400
Links: << >>  << T >>  << A >>
"H. Peter Anvin" wrote:
> 
> Out of curiosity I ran a couple of syntheses+P&R using Quartus II
> 4.1SP2 Web Edition.  This is just synthesizing the mb_cpu as a top
> level, with all ports going to auto-assigned pins (presumably,
> internal use could be faster.)  Frequency is as reported by Quartus
> timing analysis.  I obviously didn't do anything fancy to try to make
> it any faster.
> 
> None of these inferred any memory or DSP blocks.
> 
> Device          Optimization    LEs used        Frequency
> 
> EP1C4F324C7     Balanced        2930             60.99 MHz
> EP1C4F324C7     Speed           3010             76.38 MHz
> EP1C4F324C6     Speed           3010             84.21 MHz
> 
> EP1S10F484C7    Area            2849             70.55 MHz
> EP1S10F484C7    Balanced        2931             71.89 MHz
> EP1S10F484C7    Speed           3011             71.60 MHz(!)
> EP1S10F484C5    Balanced        2931             90.88 MHz
> 
> EP2C8F256C8     Balanced        2993             59.27 MHz
> EP2C8F256C8     Speed           3075             60.72 MHz
> EP2C8F256C6     Speed           3085(?!)         81.27 MHz
> 
> EP2S15F484C5    Balanced        2502             94.79 MHz
> EP2S15F484C5    Speed           2580             92.83 MHz(!)
> EP2S15F484C3    Balanced        2504(?!)        126.04 MHz
> 
> A few surprises:
> 
> - Sometimes "Balanced" gives a faster design than "Speed"
> - Sometimes the number of LEs/ALUTs change when the only thing changed
>   is the speed grade of the devices.

Actually, I don't see that as such a surprise.  I expect that the
optimizations are structural and done before timing analysis.  So any
given structural change (such as duplicating a high fan out driver) may
or may not improve the speed after routing even though it increases the
amount of logic used.  

The fact that the number of LEs change with a change in speed grade
would say to me that there is *some* timing analysis being done during
synthesis and controls the ultimate result.  

-- 

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: 73902
Subject: Re: FPGA vs ASIC area
From: rickman <spamgoeshere4@yahoo.com>
Date: Thu, 30 Sep 2004 16:54:28 -0400
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> 
> This seemingly simple question does not have a simple answer. There are too
> many variables. Modern FPGAs are leaping ahead of ASICs in the use of the
> tightest technology ( 90 nm today). Some FPGA structures are inherently as
> efficient as in ASICs (BlockRAM, I/O, transceivers, hard microprocessors).
> In other respects FPGAs can be far less efficient in their silicon use. But
> FPGAs benefit from a very regular and tight chip-layout, and they are
> manufactured by the multi-millions (as opposed to most ASICs).
> And finally: Silicon is cheap, silicon area is not decisive, the total
> manufacturing and distribution cost is!
> Don't count the square microns, count the dollars.

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

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: 73903
Subject: Re: ASIC vs FPGA and In-Circuit Reconfigurability (ICR)?
From: Austin Lesea <austin@xilinx.com>
Date: Thu, 30 Sep 2004 14:14:02 -0700
Links: << >>  << T >>  << A >>
Craig,

In my 26 years in telecom systems manufacturing, I was not a happy 
camper until I could design, sell, and supply FPGA based products.

Almost every RFQ to FRP to product cycle had at least one class A recall 
(everything had to be field or factory retrofitted).  The pain of this 
was so high, that I had a rule, called "Austin's rule of tens."

Sell ten, recall, fix the bug.

Sell a hundred, find and fix the next bug.

Sell a thousand, find and fix the next bug.

And so on, and so forth.

One time I made it to 100,000 sold of one system, and sure enough, we 
had a bug that required a huge changeout of eproms (thank god it was the 
microprocessor code, and could be fixed by this method).

The interesting thing about the phone business, is that eventually 
someone will do something you never thought of, and break it.  And 
suddenly everyone will say "how could you have missed that?"

With FPGAs, we could now reconfigure over the network, so if there was a 
bug, we could download a new FPGA image, and we were back up and running 
with minimum (or no) down time.

Of course, many operating companies decided not to connect their systems 
to any network at all, so they still cost a lot of money to retrofit, as 
someone had to go to each system, and plug in their personal computer, 
and reload an image.

Good news is that they did not have to take it apart (as we had to in 
the 'old days').

The one time we used an ASIC (as the requirement was slam dunk, no 
issues) we ended up throwing all the ASICs away because the (bell) 
operating company notified us that the requirements doc had a patented 
technique that they did not know of at the time.  So rather than get a 
license for it ($$$), they removed it from the requirements document. 
Guess who paid for it?  Right, not the op company.  Read the contract.

Back to FPGAs.

As for writing reconfigurability into a product requirement, after 
awhile, it became pretty obvious that money could be saved, downtime 
could be avoided, by having such a feature.  You just had to network 
everything in your network (not an easy task at all).

Austin

CraigR wrote:

> In reviewing a specific requirement, my design team is debating the benefits 
> of in-field hardware upgradability.  In the communications space, wondering 
> if most system developers require and use ICR in production when 
> implementing FPGA (instead of ASIC)?
> 
> Craig 
> 
> 

Article: 73904
Subject: Re: embedded linux on FPGA?
From: hpa@terminus.zytor.com (H. Peter Anvin)
Date: Thu, 30 Sep 2004 21:34:53 +0000 (UTC)
Links: << >>  << T >>  << A >>
Followup to:  <415C6D4D.85048A9B@yahoo.com>
By author:    john@bluepal.net
In newsgroup: comp.arch.fpga
> 
> That is a self-perpetuating prophesy.  There is nothing inherently
> incomprehensible about Forth, especially vs. C.  It is a bit like saying
> Chinese is hard to learn because you learned English as a small child. 
> When people refuse to work in Forth because there aren't many who work
> in Forth, you can see how that perpetuates the problem.  
> 

Personally, I don't buy that.  I learned FORTH *way* before I learned
C, and I still find FORTH code written by others much harder to read.
The difference is that my brain just isn't capable of holding the
layout of the stack in my head, especially since it changes from verb
to verb.  C and most other 3G programming languages at least attempts
at forcing you to give your data items names.

> I can see some significant advantages to an interactive language that
> you can run on the target without an emulator.  

The main advantage to FORTH, in my opinion, is that it is one of the
very few languages which runs anywhere close to native speed, yet
requires only a handful of bytes for its compiler.  For embedded or
microcontroller-class programming, that can be a *huge* win over
having to cross-compile everything, especially, as you correctly point
out, you can use FORTH as an interactive language, which among other
things mean you can extract state and conduct experiments quickly.

	-hpa

Article: 73905
Subject: Re: MicroBlaze is no available as Open-Source!! (from independant
From: Jim Granville <no.spam@designtools.co.nz>
Date: Fri, 01 Oct 2004 09:45:59 +1200
Links: << >>  << T >>  << A >>
Uncle Noah wrote:
> jon@beniston.com (Jon Beniston) wrote in message news:<e87b9ce8.0409290048.63a5a067@posting.google.com>...
> 
>>"Antti Lukats" <antti@case2000.com> wrote in message news:<cjbrus$csk$02$1@news.t-online.com>...
>>
>>>Hi All
>>>
>>>finally today the project maintainer at opencores uploaded the verilog
>>>design files for MicroBlaze compliant IP-Core. Download is available at
>>>opencores.com - as project aeMB !!
>>
>>How long before Xilinx try to get them to remove it do we reckon?
>>
>>Cheers,
>>Jon
> 
> 
> If Xilinx can establish a case against aeste (the developer of aeMB is
> working for that company) it will be removed. The question is how much
> information he had in his possession so that he produced  a
> (reportedly) successful MB implementation.
> 
> If he didn't infringe any of Xilinx hardware patents, he should be OK.
> BTW is the MicroBlaze instruction set patented??? If it is, it is very
> sad, this can be prohibit you from e.g. implementing a GPL'ed
> simulator???

  I don't see a big issue with the opcodes, or Xilinx's possible 
reaction, but such reaction will be proportional to their preceived lost
revenue.

# 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.

  Altera would not want to promote this, as they have NIOS.

  So, in terms of lost revenues of any signifincance, that leaves the 
ASIC business, and there it is a trade off of the cost to license the MB 
from Xilinx, vs do the whole chain 'in house', using the OS as a portion 
of that.

Q: What does it cost to license MB for an ASIC ?

-jg


Article: 73906
Subject: Re: MicroBlaze is no available as Open-Source!! (from independant
From: Austin Lesea <austin@xilinx.com>
Date: Thu, 30 Sep 2004 15:29:37 -0700
Links: << >>  << T >>  << A >>
Jim,

The license includes rights to use in an ASIC:

http://www.xilinx.com/xlnx/xebiz/designResources/ip_product_details.jsp?sGlobalNavPick=&sSecondaryNavPick=Design+Tools&iLanguageID=1&key=DO-DI-MBLAZE-SC

http://tinyurl.com/4qpqb

Read the licensing agreement terms for details.

You are correct: the more microblazes (microblazing?), the better.

Austin

Jim Granville wrote:
> Uncle Noah wrote:
> 
>> jon@beniston.com (Jon Beniston) wrote in message 
>> news:<e87b9ce8.0409290048.63a5a067@posting.google.com>...
>>
>>> "Antti Lukats" <antti@case2000.com> wrote in message 
>>> news:<cjbrus$csk$02$1@news.t-online.com>...
>>>
>>>> Hi All
>>>>
>>>> finally today the project maintainer at opencores uploaded the verilog
>>>> design files for MicroBlaze compliant IP-Core. Download is available at
>>>> opencores.com - as project aeMB !!
>>>
>>>
>>> How long before Xilinx try to get them to remove it do we reckon?
>>>
>>> Cheers,
>>> Jon
>>
>>
>>
>> If Xilinx can establish a case against aeste (the developer of aeMB is
>> working for that company) it will be removed. The question is how much
>> information he had in his possession so that he produced  a
>> (reportedly) successful MB implementation.
>>
>> If he didn't infringe any of Xilinx hardware patents, he should be OK.
>> BTW is the MicroBlaze instruction set patented??? If it is, it is very
>> sad, this can be prohibit you from e.g. implementing a GPL'ed
>> simulator???
> 
> 
>  I don't see a big issue with the opcodes, or Xilinx's possible 
> reaction, but such reaction will be proportional to their preceived lost
> revenue.
> 
> # 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.
> 
>  Altera would not want to promote this, as they have NIOS.
> 
>  So, in terms of lost revenues of any signifincance, that leaves the 
> ASIC business, and there it is a trade off of the cost to license the MB 
> from Xilinx, vs do the whole chain 'in house', using the OS as a portion 
> of that.
> 
> Q: What does it cost to license MB for an ASIC ?
> 
> -jg
> 

Article: 73907
Subject: Re: Xilinx Timing Constraints
From: "Jim Wu" <nospam@nospam.com>
Date: Thu, 30 Sep 2004 18:31:01 -0400
Links: << >>  << T >>  << A >>

"Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message
news:10llmgho78j6v6f@corp.supernews.com...
> There doesn't appear to be any way to put timing constraints on the
internal
> signals of a design.  I have a fast clock and a slow clock and it would be
> best if I could put a timing constraint on the fast signals.

You only need to constraint the fast clock. This constraint will be used to
place/route all the signals that are clocked by the fast clock.

HTH,
Jim
jimwu88NOOOSPAM@yahoo.com (remove capital letters)
http://www.geocities.com/jimwu88/chips






Article: 73908
Subject: Re: ASIC vs FPGA and In-Circuit Reconfigurability (ICR)?
From: "Rotund Phase" <rotund_phase@hotmail.com>
Date: Thu, 30 Sep 2004 15:37:36 -0700
Links: << >>  << T >>  << A >>
My bad Craig, just thought that as you and that other Guy guy appear to be
posting from the same IP address you might know him.
"CraigR" <craigra@pacbell.net> wrote in message
news:RLZ6d.4747$nj.3494@newssvr13.news.prodigy.com...
> Nope.  I did see that posting though.  I am weighing cost benefits of ASIC
> for field upgradability.
>
>
> "Rotund Phase" <rotund_phase@hotmail.com> wrote in message
> news:2s31qkF1furbmU1@uni-berlin.de...
> > Are you also guys@altera.com? From the 'NV on-chip memory' thread?
> > "CraigR" <craigra@pacbell.net> wrote in message
> > news:NbX6d.4661$nj.3114@newssvr13.news.prodigy.com...
> >> In reviewing a specific requirement, my design team is debating the
> > benefits
> >> of in-field hardware upgradability.  In the communications space,
> > wondering
> >> if most system developers require and use ICR in production when
> >> implementing FPGA (instead of ASIC)?
> >>
> >> Craig
> >>
> >>
> >
> >
>
>



Article: 73909
Subject: Re: MicroBlaze is no available as Open-Source!! (from independant
From: John Williams <jwilliams@itee.uq.edu.au>
Date: Fri, 01 Oct 2004 08:44:28 +1000
Links: << >>  << T >>  << A >>
Jim Granville wrote:
> Uncle Noah wrote:
> 
>> jon@beniston.com (Jon Beniston) wrote in message 
>> news:<e87b9ce8.0409290048.63a5a067@posting.google.com>...
>>
>>> "Antti Lukats" <antti@case2000.com> wrote in message 
>>> news:<cjbrus$csk$02$1@news.t-online.com>...
>>>
>>>> finally today the project maintainer at opencores uploaded the verilog
>>>> design files for MicroBlaze compliant IP-Core. Download is available at
>>>> opencores.com - as project aeMB !!
>>>
>>> How long before Xilinx try to get them to remove it do we reckon?
>>
>> If Xilinx can establish a case against aeste (the developer of aeMB is
>> working for that company) it will be removed. The question is how much
>> information he had in his possession so that he produced  a
>> (reportedly) successful MB implementation.
>>
>> If he didn't infringe any of Xilinx hardware patents, he should be OK.
>> BTW is the MicroBlaze instruction set patented??? If it is, it is very
>> sad, this can be prohibit you from e.g. implementing a GPL'ed
>> simulator???
> 
>  I don't see a big issue with the opcodes, or Xilinx's possible 
> reaction, but such reaction will be proportional to their preceived lost
> revenue.

To be honest I don't see this as a particularly big deal - the EDK is so 
cheap that it is a blip on the landscape for any serious commercial 
development work.  Would you avoid paying $500 to get a free but 
unsupported version of a processor that may or may not have legal 
encumberances?

For university/research purposes Xilinx are very reasonable in their 
donation of EDK licenses.

Finally, you asked how much it is to license Microblaze for ASIC fab - 
it is a drop in the ocean compared to the cost of actually fabbing the 
chip.

Microblaze is not like ARM - ARM is an IP company, Xilinx is a chip 
company.  ARM must vigourously protect the ARM brand to keep their 
business model alive.  Microblaze helps Xilinx sell FPGAs - there are no 
per-unit royalties for using it.

One thing that would probably upset Xilinx would be to see a 
high-fidelity Microblaze clone on Altera devices - that would surely get 
the lawyers' attention, even if it is a bizarre form of flattery (Xilinx 
processor design on Altera fabric)!

Regards,

John

Article: 73910
Subject: Re: embedded linux on FPGA?
From: hamilton <hamilton@deminsional.com>
Date: Thu, 30 Sep 2004 16:45:48 -0600
Links: << >>  << T >>  << A >>


H. Peter Anvin wrote:
>>When people refuse to work in Forth because there aren't many who work
>>in Forth, you can see how that perpetuates the problem.  
>>
> 
> 
> Personally, I don't buy that.  I learned FORTH *way* before I learned
> C, and I still find FORTH code written by others much harder to read.

	Here is the crux of the problem.

	The OP stated that he was looking for help on a embedded system.
	( orignal thread is gone and linix is not written in forth )

	Yes, having experience with any language is going to create a
	better environment for development. However, a beginner using
	forth without a safty net ( i.e. mentor) is just crazy.

	The projects I have followed up on were just that. Beginners
	trying to bet the farm an a "quick language".

	My first forth was on a 6502 over 20 years ago.

	Nothing has changed.

	If forth works for you, great. But, if I follow up on one of
	your projects. It will be converted to C.



hamilton AT dimensional DOT com

Article: 73911
Subject: Re: luts are optimized away
From: "Jim Wu" <nospam@nospam.com>
Date: Thu, 30 Sep 2004 18:47:41 -0400
Links: << >>  << T >>  << A >>
Try also adding "LOCK_PINS" constraint to the LUTs.

Jim
jimwu88NOOOSPAM@yahoo.com (remove capital letters)
http://www.geocities.com/jimwu88/chips



"van de Kerkhof" <bvdk@NOSPAMMoce.nl> wrote in message
news:1096438359.543142@news-ext.oce.nl...
> Hi.
>
> I made a programmable lut delay.
> Xilinx ise thinks it may optimize some luts away how can i prevent this.
>
> I use synplicity for synthesis.
>
> I already tried: keep keep_architecture syn_noprune syn_keep syn_preserve.
>
> Changing the lut init by making an other design will change the number of
> luts it will optimize but it
> should be possible to say dont touch the luts??
>
> Bram
>
>



Article: 73912
Subject: Re: MicroBlaze is no available as Open-Source!! (from independant
From: Jim Granville <no.spam@designtools.co.nz>
Date: Fri, 01 Oct 2004 11:05:43 +1200
Links: << >>  << T >>  << A >>
Austin Lesea wrote:
> Jim,
> 
> The license includes rights to use in an ASIC:
> 
> http://www.xilinx.com/xlnx/xebiz/designResources/ip_product_details.jsp?sGlobalNavPick=&sSecondaryNavPick=Design+Tools&iLanguageID=1&key=DO-DI-MBLAZE-SC 
> 
> 
> http://tinyurl.com/4qpqb
> 
> Read the licensing agreement terms for details.
> 
> You are correct: the more microblazes (microblazing?), the better.

Thanks for the clarify. Source code is $19,995.

  I think ASIC port is covered by this clause ::

"13. Non-Transferable. [] You may provide device programming files
 bit-stream files or PROM files  and you may provide the data required 
to implement a silicon mask set to third parties without prior approval 
solely in order to manufacture the Licensed Product."

and also by this WEB note

"Xilinx also sells Fully Synthesisable Behavioral Source code."

How much for the second pathway ?

-jg


Article: 73913
Subject: Re: FPGA vs ASIC area
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Thu, 30 Sep 2004 16:26:50 -0700
Links: << >>  << T >>  << A >>


Peter Alfke wrote:

(snip regarding FPGA vs. ASIC in silicon used.)

> But
> FPGAs benefit from a very regular and tight chip-layout, and they are
> manufactured by the multi-millions (as opposed to most ASICs).
> And finally: Silicon is cheap, silicon area is not decisive, the total
> manufacturing and distribution cost is!
> Don't count the square microns, count the dollars.

What I hear is even more important with current technology
is NRE costs, such as masks.   Stories are of mask sets in the
million dollar range.

-- glen


Article: 73914
Subject: Re: FPGA vs ASIC area
From: Peter Alfke <peter@xilinx.com>
Date: Thu, 30 Sep 2004 16:50:00 -0700
Links: << >>  << T >>  << A >>
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: 73915
Subject: Re: FPGA vs ASIC area
From: Peter Alfke <peter@xilinx.com>
Date: Thu, 30 Sep 2004 17:00:14 -0700
Links: << >>  << T >>  << A >>


> From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
> Organization: University of Washington
> Newsgroups: comp.arch.fpga
> Date: Thu, 30 Sep 2004 16:26:50 -0700
> Subject: Re: FPGA vs ASIC area
> 
> 
> 
> 
> What I hear is even more important with current technology
> is NRE costs, such as masks.   Stories are of mask sets in the
> million dollar range.
> 
> -- glen

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.

We in the FPGA business really know the price of ASICs, for (think about it)
we really design and produce circuits as if they were ASICs.
Our saving grace is that we sell them in large numbers to many customers.
Peter Alfke


> 


Article: 73916
Subject: Re: Altera SDRAM controller - Only 2 words burst???
From: zohargolan@hotmail.com (zg)
Date: 30 Sep 2004 17:15:54 -0700
Links: << >>  << T >>  << A >>
Hi Ken, 

Thank you for your response.
What frequncy are you running the NIOS? I tried simulating at 72MHz
and I got only 2 words bursts.
Are you using NIOS II? 

Regards, 
Zohar 

"Kenneth Land" <kland_not_this@neuralog_not_this.com> wrote in message news:<10lg0aca67jseaa@news.supernews.com>...
> "zg" <zohargolan@hotmail.com> wrote in message
> news:e24ecb44.0409241455.340ba130@posting.google.com...
> > Hi All,
> >
> > I am trying to use the SDR SDRAM controller that is comming with the
> > NIOS II development package. In the simulation it looks like this core
> > supports only 2 words bursts. I couldn't find anything in the
> > documentations.
> > Am I correct?
> > If this core supports bigger bursts then 2 words, any ideas what am I
> > doing wrong?
> >
> > Thank you all
> > Zohar
> 
> Zohar,
> 
> I'm working on a design that uses one 16MB sdram chip for most of its
> instruction and data memory.  I rely heavily on dma and other burst reads
> and writes (ie cache) to get the performance I need.
> 
> The sdram controller you're talking about is good enough to burst 480 32 bit
> words in under 485 cpu clocks.  It's a beautiful thing to watch in Signal
> Tap as I get this performance.  (Haven't explored the lenght limits above
> 480 - my external fifo's AlmostFull level)
> 
> I'm hammering that sdram (through the Altera sdram controller) nines ways to
> Sunday and it performs flawlessly.
> 
> I have some serious issues with the whole NiosI/II chain, but the sdram
> controller has been a champ.
> 
> Ken

Article: 73917
Subject: Re: ASIC vs FPGA and In-Circuit Reconfigurability (ICR)?
From: "bh" <spam_not@nosuch.com>
Date: Fri, 01 Oct 2004 00:21:52 GMT
Links: << >>  << T >>  << A >>
If you're implementing different protocols on the same
electrical lines I would thing FPGAs would be very attractive.

However, I'm struggling with how to support new I/O requirements
(i.e. technology didn't exist at time of initial development) without
opening up our boxes to modify the line drivers/receivers.

My domain is not 'strictly' communications, but we frequently have
new requirements to add another RS422 channel or Ethernet or
wiZbang I/O of-the-day. So how do you get drivers that have
programable voltage swings, rise times, polarity, etc. so that
you don't have to send the box back to the factory to make changes.

Short of putting in DACs/ADCs on each signal line with waveform
memory, it's tough to figure out a good solution for the ultimate
in I/O flexibility. Perhaps rather than waveform memory, using
opamps and just having a DAC that sets the voltage for the rails
and receive threshold might work???

I've also been thinking about a special type of tiny connector 'insert' that
plugs in (almost like a multi-terminal fuse) which provides
translation from LSVD to real-world signal levels. This might work
would be tough for signals that have to be transformer coupled.

How is this problem solved?

-bh

"CraigR" <craigra@pacbell.net> wrote in message
news:NbX6d.4661$nj.3114@newssvr13.news.prodigy.com...
> In reviewing a specific requirement, my design team is debating the
benefits
> of in-field hardware upgradability.  In the communications space,
wondering
> if most system developers require and use ICR in production when
> implementing FPGA (instead of ASIC)?
>
> Craig
>
>



Article: 73918
Subject: Re: Quartus II annoyance
From: hpa@terminus.zytor.com (H. Peter Anvin)
Date: Fri, 1 Oct 2004 02:51:05 +0000 (UTC)
Links: << >>  << T >>  << A >>
Followup to:  <ca4d800d.0409301050.1c3d2339@posting.google.com>
By author:    sdatta@altera.com (Subroto Datta)
In newsgroup: comp.arch.fpga
> 
> Hope this helps.
> 
> - Subroto Datta
> Altera Corp.

Indeed it does.  Thank you!

	-hpa



Article: 73919
Subject: Re: System Generator.
From: Bernhard Holzmayer <holzmayer.bernhard@deadspam.com>
Date: Fri, 01 Oct 2004 07:18:11 +0200
Links: << >>  << T >>  << A >>
Nirav Shah wrote:

> Friends,
> I was trying to install Xilinx System Generator v 6.2 (evaluation)
> on my computer.
> I have Xilinx webpack 6.2i SP 3 with IP Update 1.1 for it & Matlab
> 6.5 (R13) But while installing it says "Can not find Code
> GENERATOR" installation. i checked environmet variable, XILINX =
> c:\Xilinx & that's where my installation is.
> Any Suggetions?
> Thanks
> Nirav

Sorry, if I cannot give you real help.
Once, when I was installing an old version (2.x) of XSG, this was a 
real ugly affair. Versions of Windows, Matlab, XSG must fit 
exactly, or nothing would have done.
Cost me about two weaks, until everything worked fine.
Then, Matlab upgraded to version 6.5, but I wasn't able to run XSG 
on that. Meanwhile I keep that ancient installation, and I don't 
upgrade at all.
Xilinx and Mathworks people promised me that they would try hard to 
improve the installation procedure.
You might want to contact Brent Milne from Xilinx 
(Brent.Milne@xilinx.com).
He was the only person who really cared and contributed help.

I'm really interested in your experience.
Bernhard


Article: 73920
Subject: Re: FPGA vs ASIC area
From: Kim Enkovaara <kim.enkovaara@tellabs.com>
Date: Fri, 01 Oct 2004 09:13:42 +0300
Links: << >>  << T >>  << A >>
totallyadmin wrote:

> I was just wondering *roughly* how much area is required for a design
> targetted to an fpga in comparsion to a standard cell asic? I'm really
> looking for a ball park figure here - 2x, 5x, 10x, 50x, 100x the area
> requirements? (I undersatand its heavily dependant on the particular
> design)

This is very dependent on the design (and process). One good question is also,
can you achieve the needed performance with FPGAs without huge effort in optimising
the design. FPGAs look very promising in data sheets but sometimes the reality
is completely different.

I have one good example I have seen. One big 0.13u design was scaled down
1/4, with 1/4 clock frequency to test an ASIC. This already needed 6* V2 6000
chips, and the 1/4 clock frequency was very difficult to achieve.

Some structures seem to be very hard for FPGAs. For example complex muxing with
normal synthesis can produce huge structures in FPGAs. One could optimise those
with some hand constructed LUT structures. But that is insane. That code is not
anymore portable across chip families or to ASICs. And the time and effort to
make things like that is huge.

Also power consumption is one real problem. If you would build an product with
10+ biggest FPGAs the power consumption would be huge (and PCB area). And if the
communication needs between the chips is large, also the PCB is going to be full
of signals and very hard to make.

Just food of tought. There are places for FPGAs, and sometims ASIC is the only sane
alternative for a sellable product. Prototypes are completely different, you don't
need profit from them :)

--Kim

Article: 73921
Subject: Re: Spartan-3 VCCIO ramp up time
From: hmurray@suespammers.org (Hal Murray)
Date: Fri, 01 Oct 2004 01:36:18 -0500
Links: << >>  << T >>  << A >>
>If you're trying to enable a regulator that doesn't include a current limit
>from a supply that's already steady, bulk capacitance won't provide the
>predictable ramp rate.

"Hot swap" is probably the magic word to search on if you
are browsing vendors web sites.  There is a class of chips
intended to limit the startup current.  I think most of them
can be used to solve the ramp up problem.

-- 
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: 73922
Subject: Re: NV on-chip memory?
From: hmurray@suespammers.org (Hal Murray)
Date: Fri, 01 Oct 2004 01:43:01 -0500
Links: << >>  << T >>  << A >>
>That makes it much *less* useful.  When a CPU is put into an FPGA, it is
>a real encumbrance to use external memory and the internal FPGA memory
>is often not large enough for program storage.  Having a hunk of NV
>*rewritable* (such as flash) memory would be very useful for this sort
>of app.  When are SW programs *ever* mature???  My network router
>already has a code update waiting to go into the Flash.  

But why is NV more interesting than general purpose SRAM?

Are you looking for something big enough so that the normal
config loading mechanism can't handle the extra load?  (Say
10 times the config size.)

My straw man to compare with would be lots more RAM on the FPGA,
using current technology.  (My guess is the market isn't there
or somebody would have done it by now.)

-- 
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: 73923
Subject: Re: ASIC vs FPGA and In-Circuit Reconfigurability (ICR)?
From: hmurray@suespammers.org (Hal Murray)
Date: Fri, 01 Oct 2004 02:07:41 -0500
Links: << >>  << T >>  << A >>
 
>                                               The pain of this 
>was so high, that I had a rule, called "Austin's rule of tens."
>Sell ten, recall, fix the bug.
>Sell a hundred, find and fix the next bug.
>Sell a thousand, find and fix the next bug.
>And so on, and so forth.

I learned that rule over 15 years ago.  I was babysitting for
a large (for the time) email system that had just been hit
with that sort of bug.  (Fortunately, the guys who did the
initial work were good friends of mine.)

The rule was something like:
  "Every time the installed base goes up by a factor of 10
another fatal bug will crawl out of the woodwork."

I think it's been true for any system I've worked on.
For most sytems, you can get 10 in your lab and 100
with friendly customers.  Then it gets interesting...
(Scale by 10 one way or the other if that fits your
system better.)


> The one time we used an ASIC (as the requirement was slam dunk, no 
> issues) we ended up throwing all the ASICs away because the (bell) 
> operating company notified us that the requirements doc had a patented 
> technique that they did not know of at the time.  So rather than get a 
> license for it ($$$), they removed it from the requirements document.

Interesting point.  I remember a time when an FPGA saved my bacon.
Yup.  Spec change.  Just one bit.  Trival to fix.

So if you are considering FPGA vs ASIC, add the stability
of your requirements to the decision process.  Don't forget
to consider bugs in the spec.  Committees are great at writing
complicated documents that don't work in obscure corner cases.
Or don't specify what happens and 3 people make incompatible
assumptions.

-- 
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: 73924
Subject: Re: Spartan-3 VCCIO ramp up time
From: Sylvain Munaut <tnt_at_246tNt_dot_com@reducespam.com>
Date: Fri, 01 Oct 2004 09:12:49 +0200
Links: << >>  << T >>  << A >>

John_H, Austin, Uwe, Hal


Thanks for all your anwsers !



Sylvain



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