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 79650

Article: 79650
Subject: Re: Make program stop
From: AL <ann.lai@analog.com>
Date: Tue, 22 Feb 2005 12:25:39 -0800
Links: << >>  << T >>  << A >>
Hi Glen, I still don't understand what the problem is though. So when I changed RESET, shouldn't the register be changing as well???? Right now it's not doing that, I kept getting 21 out for some reason. If I change always @(posedge CLK_IN) to always @(CLK_IN), then it works, do you know why???? Thanks, Ann

Article: 79651
Subject: Re: Spartan3 Power Supply Circuits
From: "Antonio Pasini" <NOSPAM_pasini.a@tin.it>
Date: Tue, 22 Feb 2005 20:44:01 GMT
Links: << >>  << T >>  << A >>

> be perfectly covered by the TI TPS75003RHLR chip with adequate
>
> Has anyone heard about the current development and sampling status of
> that chip?

I asked the same question to the email address in the TI page.
They answered that samples and Evaluation modules are available now, but 
production at end of march.

I'm now waiting for an answer by EBV.




Article: 79652
Subject: Re: Hardcopy Vs ASIC
From: "Paul Hollingworth" <pholling@altera.com>
Date: 22 Feb 2005 13:08:27 -0800
Links: << >>  << T >>  << A >>
Dig,

glad to hear you like the look of the methodology. Regarding your
question, then it rather depends on whether you are talking vs
standard-cell ASIC, or Structured ASIC. All Structured ASICs have a
larger die size and less ultimate performance than standard-cell ASICs.
However, they make up for this (for the majority of applications) by
offering much lower NREs, lower minimum order quantities, reduced risk
and better time-to-market. For the current version of HardCopy that is
shipping today (HardCopy Stratix - based on the same 0.13um process we
use for Stratix FPGAs), then the only really meaningful performance
figure I can give you is that we tend to find an average of 50% speed
up from the Stratix FPGA. We have seen typical system speeds over
150MHz, though with pipelining, you could achieve more. Power is lower
than the FPGA, typically 25-40% or so. Last month we announced the next
generation, HardCopy II, based on the same 90nm process we are using
for the Stratix II and Cyclone II FPGAs. This will increase performance
significantly, typically doubling what is possible on the FPGA. We
expect "real" system performance figures of 350MHz. Power will also be
lower and we expect core figures of 50-70% lower than the FPGA.

By yield, I assume you really mean cost. The die-size of any chip is of
course what dominates the cost and in the case of Structured ASICs such
as HardCopy, the die-size is larger than a fully optimised standard
cell ASIC. However, the NRE charge will significantly lower and you
therefore need to look at the total cost. For HardCopy Stratix, we tend
to find above volumes of 50K-100K, standard cell ASIC tends to work out
more cost effective, though we have seen some memorable exceptions
where customers have gone well over these volumes, usually because
time-to-market matters a lot more. Because HardCopy II is significantly
more die-size optimised, (and because ASIC NREs are continuing to
increase) we expect that the volumes at which break-even makes sense
will increase significantly, to somewhere between 250K-500K units per
year.

So coming to time-to-market, Structured ASICs in general are typically
far faster to market than standard cell ASICs, because so much of the
back-end work is already done. HardCopy is a lot faster than any other
structured ASIC because we guarantee the migration from a working FPGA
to the HardCopy device. The typical turnaround time to protos is 10
weeks, including the migration in our design center and the fab and
assembly time.

If you're interested in learning more and can spare 40 mins to an hour,
(and can forgive a blatant plug), we did a Net Seminar on this last
week which includes information on the latest version - HardCopy II.
You can look at it here. (Registration required)
http://cmpnetseminars.com/TSG/default.asp?q=157&K=CALTERA1

I hope this helps answer your question.

Regards,
Paul Hollingworth
Altera Marketing

digari@dacafe.com wrote:
> I was going through the hard copy product from altera. Methodology
> seems really promising. I just wonder where hard copy products stands
> as compare to ASIC wrt performance, power, yield & Time to market


Article: 79653
Subject: Re: Frequence max: many question from a beginner
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Tue, 22 Feb 2005 22:32:42 +0100
Links: << >>  << T >>  << A >>

"KCL" <kclo4_NO_SPAM_@free.fr> schrieb im Newsbeitrag
news:421b902b$0$3103$8fcfb975@news.wanadoo.fr...

> 1)    how could I have the worst delay path in xilinx ise in a design?
> Because if i put a timing constraint it give me the worst paths if the
> constraints is not reach but if the constraint have been met  we haven't
the
> worth path.

Timing Analyzer is your friend. Tell him to check against tighter
constraints, and it will show you the failing paths.

> 2) When can we say that we have reached the max frequency possible for the
> design? In my mind it 's for when we made an IP with no timing constraint
> when can we say that we are fast enought?? Relative to time due to logic
and
> route , when we have more time due to route than logic or something else??

Again, timing analyzer is your friend. It will tell you exactly how much
time is spent in logic and routing.

> 3) Is it possible to put a part of the a design out of timing analyze?
> because a part of my design is only here for simulation (it generates
> stimuli when onboard) and the worst delay path is due to this part. Or
> should I analyze each part of my design separately without the test part??

Yes, you can exclude paths/parts from timing analyze. But why? Tell the
analyzer the real clock frequency of each part an everything is fine. Even
just for testing/simulation/emulation, you test logic must be fast enough.

Regards
Falk




Article: 79654
Subject: Is there any compatibility difference between The parallel JTAG PC4 and JTAG III??
From: jacklalo020@hotmail.com (jack lalo)
Date: 22 Feb 2005 13:44:17 -0800
Links: << >>  << T >>  << A >>
Hi all,
  I'm asking if there is any difference between the Xilinx JTAG III
and IV??? I saw that the speed of the second is 8 time quicker than
the first, but i need a JTAG cable and all the schematics are for the
old one. Is it matter if i use the JTAG III instead of the PC4???
  thanks

Article: 79655
Subject: Re: Hardcopy Vs ASIC
From: Austin Lesea <austin@xilinx.com>
Date: Tue, 22 Feb 2005 13:44:28 -0800
Links: << >>  << T >>  << A >>
Dig,

You really must listen to their presentation (completely).

For example, they do not recommend using S2 to prototype today for H2.

Prototyping with their FPGA means that there will be conversion issues 
that may affect the outcome.  They admit this, and wish you to succeed, 
so they want to train you how to avoid problems.  That is just good 
business.

By their own figures, somewhere between 16% and 70% of conversions will 
'suceed". (Or somewhere from 30 to 84% will FAIL).

(With EasyPath (XIlinx tm), they all succeed, and the cost is less, and 
the availability is immediate...but you are not interested in FPGAs, so 
I apologize for this digression).

With H or H2, it is just another ASIC, slightly larger, less optimal, 
but an ASIC none the less.

'Faster' is not usable, as there is no way to verify that 'faster' will 
actually work.  (In fact one high profile customer failed miserably 
because it was 'faster'!) Count on designing it for the speed you need, 
and making sure that if some delays are shorter than those in the FPGA, 
it will still work.

That said, for 2005, there are an estimated 1000 ASICs out there that 
need to be designed by the 11 vendors who do this (IBM, NEC, etc.). 
Most in 130 nm or larger (as perhaps only 3 to 5 of these will be rich 
enough to afford 90nm).  Structured ASICs are expected to capture a 
significant (you figure out what that means - 10% or 90%?  Who knows?) 
share of this market this year primarily because they allow advanced 
technologies (like 90nm) to be used.

'A' claims that are getting a design a week.  52/1000 =~ 5% of the 
designs.  That might be a lot of the $20 billion market for those 1000 
designs...

For example, LSI is advertising that their structured ASIC solution is 
more cost effective, and has a faster delivery that the A company's 
offering.

That is a real tribute to the 'A' company:  LSI considers them serious 
competition!  And, they are, as they are atempting to take LSI's bread, 
and butter from them.

That makes the 'A' company an ASIC company (as they move forward and 
start to derive revenue from this market).

Sad to see the only viable competitor leaving the field....for "greener 
grass" on the other side of the fence.

Austin

Paul Hollingworth wrote:
> Dig,
> 
> glad to hear you like the look of the methodology. Regarding your
> question, then it rather depends on whether you are talking vs
> standard-cell ASIC, or Structured ASIC. All Structured ASICs have a
> larger die size and less ultimate performance than standard-cell ASICs.
> However, they make up for this (for the majority of applications) by
> offering much lower NREs, lower minimum order quantities, reduced risk
> and better time-to-market. For the current version of HardCopy that is
> shipping today (HardCopy Stratix - based on the same 0.13um process we
> use for Stratix FPGAs), then the only really meaningful performance
> figure I can give you is that we tend to find an average of 50% speed
> up from the Stratix FPGA. We have seen typical system speeds over
> 150MHz, though with pipelining, you could achieve more. Power is lower
> than the FPGA, typically 25-40% or so. Last month we announced the next
> generation, HardCopy II, based on the same 90nm process we are using
> for the Stratix II and Cyclone II FPGAs. This will increase performance
> significantly, typically doubling what is possible on the FPGA. We
> expect "real" system performance figures of 350MHz. Power will also be
> lower and we expect core figures of 50-70% lower than the FPGA.
> 
> By yield, I assume you really mean cost. The die-size of any chip is of
> course what dominates the cost and in the case of Structured ASICs such
> as HardCopy, the die-size is larger than a fully optimised standard
> cell ASIC. However, the NRE charge will significantly lower and you
> therefore need to look at the total cost. For HardCopy Stratix, we tend
> to find above volumes of 50K-100K, standard cell ASIC tends to work out
> more cost effective, though we have seen some memorable exceptions
> where customers have gone well over these volumes, usually because
> time-to-market matters a lot more. Because HardCopy II is significantly
> more die-size optimised, (and because ASIC NREs are continuing to
> increase) we expect that the volumes at which break-even makes sense
> will increase significantly, to somewhere between 250K-500K units per
> year.
> 
> So coming to time-to-market, Structured ASICs in general are typically
> far faster to market than standard cell ASICs, because so much of the
> back-end work is already done. HardCopy is a lot faster than any other
> structured ASIC because we guarantee the migration from a working FPGA
> to the HardCopy device. The typical turnaround time to protos is 10
> weeks, including the migration in our design center and the fab and
> assembly time.
> 
> If you're interested in learning more and can spare 40 mins to an hour,
> (and can forgive a blatant plug), we did a Net Seminar on this last
> week which includes information on the latest version - HardCopy II.
> You can look at it here. (Registration required)
> http://cmpnetseminars.com/TSG/default.asp?q=157&K=CALTERA1
> 
> I hope this helps answer your question.
> 
> Regards,
> Paul Hollingworth
> Altera Marketing
> 
> digari@dacafe.com wrote:
> 
>>I was going through the hard copy product from altera. Methodology
>>seems really promising. I just wonder where hard copy products stands
>>as compare to ASIC wrt performance, power, yield & Time to market
> 
> 

Article: 79656
Subject: Re: Make program stop
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Tue, 22 Feb 2005 14:05:10 -0800
Links: << >>  << T >>  << A >>
AL wrote:

> Hi Glen, I still don't understand what the problem is though.
> So when I changed RESET, shouldn't the register be changing
> as well???? Right now it's not doing that, I kept getting 21
> out for some reason. If I change always @(posedge CLK_IN) to
> always @(CLK_IN), then it works, do you know why???? Thanks,

always @(CLK_IN) begin

means to do those operations on either edge of the clock.
As far as I know, real flip-flops don't do that, and the 
synthesis programs won't compile it, but it will simulate.

No, it does not sense change in RESET.  An asynchronous
reset should be

always @(posedge CLK_IN or posedge RESET) begin
    if(RESET) cnt <= 0;
    else cnt <= cnt+1;
end

Well, that is a counter with asynchronous reset, but you can
figure out the rest from there.  In this case, if RESET goes
high, or if RESET is high while CLK_IN goes high it sets cnt
to zero, which is the normal property of asynchronous reset.
(Except that it doesn't model metastability, but then simulation 
normally doesn't.)

(It should work with either blocking or non-blocking assignment,
but it is a little nicer with non-blocking.)

This is similar to what a 74LS74 flip-flop does, and what most
FPGA's do.

-- glen



Article: 79657
Subject: FPGA board with best cost/CLB ratio?
From: cpaar@crypto.rub.de (Christof)
Date: 22 Feb 2005 14:15:38 -0800
Links: << >>  << T >>  << A >>
For a university project we are looking for FPGA boards which offer
the best possible cost/CLB ratio. We are interested in realizing a
system with a large number (possibly hundreds) FPGAs running in
parallel. Both single FPGA or multiple FPGA boards are an option as
long as the price per logic function is "optimum".

Thanks a lot, Christof

Article: 79658
Subject: Re: XilKernel Problem on Spartan3 Board
From: Vasanth Asokan <vasanth.asokan@xilinx.com>
Date: Tue, 22 Feb 2005 14:44:27 -0800
Links: << >>  << T >>  << A >>
Paulo,

Unless your log is incomplete, there is no real error.

Your LibGen flow is being interrupted, because the make command is 
invoked by a TCL interpreter in this case, and it is treating the make 
command's return code as error.

Try adding a declaration,

int xilkernel_main ();

in your C source file, before main().

- Vasanth

paulojfonseca wrote:

>Hello everybody, i'm building up a system where i need to use a
>Microblaze uP with a RTOS, and my option was the XilKernel that comes
>with Xilinx EDK.
>I'm using a Spartan3 starter board to test my system.
>
>After reading the Xilinx documentation on XilKernel, and also after
>looking to some implementation examples i started to come my embbed
>program.
>
>I'm building a simple test program with an Uart ISR to recieve some
>messages, validate them in one task and send them back in another
>task.
>
>I've made all the Xilkernel configurations (just like in the working
>examples i've been looking to), OS defenition, OS configuration,
>Complier configuration  (-lxilkernel), and i also included the xmk.h
>header file.
>
>But i allways get the same compile error:
>
>TELEC/Master.C: In function `int
>main()':
>TELEC/Master.C:72: implicit declaration of function `int
>xilkernel_main(...)'
>make: *** [telec/executable.elf] Error
>1
>
>
>this is when in the main routine i call the xilkernel_main() function,
>and my main task is just like it follows:
>[code:1:9b095c3f06]
>int main(){
>    xilkernel_main();
>	return 0;
>}[/code:1:9b095c3f06]
>
>Hope someone can give me some hints.
>Thanks in advance
>
>
> Posted Via Usenet.com Premium Usenet Newsgroup Services
>----------------------------------------------------------
>    ** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
>----------------------------------------------------------        
>                http://www.usenet.com
>  
>

Article: 79659
Subject: Re: Hardcopy Vs ASIC
From: "Peter Alfke" <peter@xilinx.com>
Date: 22 Feb 2005 14:46:58 -0800
Links: << >>  << T >>  << A >>

digari@dacafe.com wrote:
> I was going through the hard copy product from altera. Methodology
> seems really promising. I just wonder where hard copy products stands
> as compare to ASIC wrt performance, power, yield & Time to market

Here is my, admittedly simplistic, look at the difference between X and
A.

Xilinx (EasyPath) wants to provide you with a significant cost
reduction, while eliminating any conversion issues and risks, for a
seamless transition from FPGA to EasyPath.

Altera (Hardcopy) wants to provide an ASIC that is somehow based on
your FPGA design, but does not guarantee painless (or even successful)
conversion. (If successful, the power might be lower.)

As Austin wrote, this moves Altera into the ASIC business, something
Xilinx does not want to touch with a ten-foot pole.  Been there, done
that, didn't like it at all. Just look at all the casualties...

Peter Alfke


Article: 79660
Subject: Re: Make program stop
From: AL <ann.lai@analog.com>
Date: Tue, 22 Feb 2005 15:16:01 -0800
Links: << >>  << T >>  << A >>
But the FPGA communicates with JTAG somehow, and JTAG is connected to the parallel port of the PC, so can't we use that connection to write code to get the PC to display something after some kind of event? Thanks, AL

Article: 79661
Subject: Re: Make program stop
From: AL <ann.lai@analog.com>
Date: Tue, 22 Feb 2005 15:16:58 -0800
Links: << >>  << T >>  << A >>
Hi Zerang Shah, But the FPGA communicates with JTAG somehow, and JTAG is connected to the parallel port of the PC, so can't we use that connection to write code to get the PC to display something after some kind of event? Thanks, AL

Article: 79662
Subject: Re: Make program stop
From: AL <ann.lai@analog.com>
Date: Tue, 22 Feb 2005 15:30:35 -0800
Links: << >>  << T >>  << A >>
Hi, I take that back, it works for always @(posedge CLK_IN) as well as always @(CLK_IN), but only for very simple logic, if else and case statement, etc. For harder logic such as a counter, it read back 00000000. Does anyone know why?

Article: 79663
Subject: Re: Make program stop
From: AL <ann.lai@analog.com>
Date: Tue, 22 Feb 2005 15:37:25 -0800
Links: << >>  << T >>  << A >>
Hi, I take that back, it works for always @(posedge CLK_IN) as well as always @(CLK_IN), but only for very simple logic, if else and case statement, etc. For harder logic, it doesn't work, only read back 00000000 . Does anyone know why?

Article: 79664
Subject: Re: Is Altera Cyclone a good choice ?
From: gregs@altera.com
Date: 22 Feb 2005 15:50:51 -0800
Links: << >>  << T >>  << A >>
The PLL in the Cyclone device works down to -40 C. However the lock pin
will not correctly show the PLL-locked status if junction temp is below
-20 C AND fIN/N is 200 MHz or less. This detail is shown in the Cyclone
datasheet and is what Alex Freed is referring to. N is the divider
between the PLL input and the phase frequency detector.

You can get a lock signal one of two ways:
1. Depending on your fIN/fOUT multiplier, set up the PLL so that fIN/N
is more than 200 MHz.
2. Construct a circuit from LEs that generates a lock signal. One way
of doing this is to have a counter driven by the non-PLL clock, and
another one driven by the PLL output. (Assuming frequency is the same.)
As long as the offset between the two is not changing then the PLL is
locked. There's many possible variations of course.

Greg Steinke
Altera Corporation


Article: 79665
Subject: Re: SD Card and FPGA
From: "Martin Schoeberl" <martin.schoeberl@chello.at>
Date: Tue, 22 Feb 2005 23:52:06 GMT
Links: << >>  << T >>  << A >>
>>
>> I think SD Cards are a very fine addition for an FPGA with a soft-core
>> processor to be used as file system. Than it's better to connect the
>> card direct with the 4-bit interface to the FPAG.
>> If you use it also for configuration all above approaches use the
>> SD Card in SPI mode. That maens 1/4 of the available bandwith.
>> And AFAIK you cannot swith to the SD bus mode without powering
>> off the card. And for a file system it can make a difference if your
>> transfer rate is 12MB/s or only 3MB/s [6].
>
> So perhaps the PLD, or 8-14 pin uC, could perform this power removal ?

The power removal is only an additional hardware cost (i.e. a transistor and
pcb place). It can be done by the FPGA after configuration/boot.

> Next generation FPGAs could include native boot in 4 bit mode option ?

I don't think so. The trend is more towards serial download. Parallel
configuration was availbale in the ACEX family, but is not availabel in
the Cyclone. It makes sense: Configuration time is not the issue, but pin
count.

> Is there a random access cost-hit in the 4 bit mode ?

I don't understand this question. The 4-bit mode simply results in a
four fold transfer bandwith compared to SPI.

Martin 



Article: 79666
Subject: Re: Hardcopy Vs ASIC
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Tue, 22 Feb 2005 15:56:19 -0800
Links: << >>  << T >>  << A >>
Austin Lesea wrote:

(snip)

> Prototyping with their FPGA means that there will be conversion issues 
> that may affect the outcome.  They admit this, and wish you to succeed, 
> so they want to train you how to avoid problems.  That is just good 
> business.

(snip)

> 'Faster' is not usable, as there is no way to verify that 'faster' will 
> actually work.  (In fact one high profile customer failed miserably 
> because it was 'faster'!) Count on designing it for the speed you need, 
> and making sure that if some delays are shorter than those in the FPGA, 
> it will still work.

As far as I know, for synchronous design and zero hold time FFs,
designs should still work with faster logic.  (Not counting 
interaction with external logic that may not be synchronous.)

There is still the case of different speed grades within an FPGA
family, and tolerance within the speed grade.  I always check 
for zero hold time FF's in any new logic family that I use.

(snip)

> For example, LSI is advertising that their structured ASIC solution is 
> more cost effective, and has a faster delivery that the A company's 
> offering.

In days not so long ago there was "sea of gates", also known as 
gate array, then standard cell, and then full custom.  For sea 
of gates, more accurately as I understood it sea of transistors,
only the metal layers were custom for the design, reducing mask 
costs.   I don't know if that still exists or not.

-- glen


Article: 79667
Subject: Re: FPGA board with best cost/CLB ratio?
From: "Martin Schoeberl" <martin.schoeberl@chello.at>
Date: Tue, 22 Feb 2005 23:56:46 GMT
Links: << >>  << T >>  << A >>
> For a university project we are looking for FPGA boards which offer
> the best possible cost/CLB ratio. We are interested in realizing a
> system with a large number (possibly hundreds) FPGAs running in
> parallel. Both single FPGA or multiple FPGA boards are an option as
> long as the price per logic function is "optimum".
>
Hundreds of FPGAs in parallel is cool.
You should consider to design your own boards ;-)

Martin

PS.: That's is not a joke. In that range it makes sense to build your
own solution (or let it build). 



Article: 79668
Subject: Re: Is Altera Cyclone a good choice ?
From: "Peter Alfke" <peter@xilinx.com>
Date: 22 Feb 2005 16:46:48 -0800
Links: << >>  << T >>  << A >>
Alessandro, there is nothing exotic about your requirements, and any
FPGA from a reputable manufacturer should meet it.
Plastic packages are very good in high-vibration environments,
25 years is a long time, but most people design for >10 years at
elevated temperature ( a description of how many years at what
temperature might help. Parts age at high temperature faster than at
cold.
High reliability is assumed today for all parts, but you might have to
pay extra for any assurance.
Low maintenance is the same as high reliability, i.e. long
mean-time-between-failure.
I do not know why you assume that Altera Cyclone fits this better than
Altera Stratix or Xilinx Spartan or Xilinx Virtex. They are all
candidates...
Peter Alfke, Xilinx Applications


Article: 79669
Subject: Re: Is Altera Cyclone a good choice ?
From: Jim Granville <no.spam@designtools.co.nz>
Date: Wed, 23 Feb 2005 14:38:27 +1300
Links: << >>  << T >>  << A >>
Alessandro Strazzero wrote:

> Dear everybody,
> 
> the goal of my post is to collect your opinions about the use of Altera Cyclone
> devices in a rugged environment. I have to design a board which should control
> a chopper based on GTOs. The environment is a railway vehicle and the following
> are the conditions I have to consider:
> 
> - extreme temperature range (-40°C to +85°C)
> - strong mechanical vibrations
> - long life duration (> 25 years)
> - high degree of reliability
> - very low frequency of maintenance
> 
> From the point of view of the design I think Altera Cyclone is the best choise
> for this kind of project beacuse its high flexibility. But I have some doubts
> about its functionality in a rugged environment like above.
> 
> Did you experience the use of Altera Cyclone in a rugged environment ? 
> What are your opinions about my choise ?

  You might also want to talk with Actel, as a GTO chopper is not likely 
to have massive gate counts, but you WILL want fairly quick power up,
and high EMC immunity levels.
  What sort of standards and guarantees do you have to meet ?
-jg


Article: 79670
Subject: Re: USB 1.1 core
From: Rudolf Usselmann <russelmann@hotmail.com>
Date: Wed, 23 Feb 2005 10:25:50 +0700
Links: << >>  << T >>  << A >>
stud_lang_jap@yahoo.com wrote:

> Hello Guys,
> I am interfacing the synopsys USB 1.1 core with the PHY. But the
> problem is the USB core side transreciever signal doesnot match the PHY
> signal. As any one interface USB core to PHY?. If so can you please
> provide more information about it.
> Is USB 1.1 also having UTMI interface to PHY? I searched the internet
> but could not get the information.
> 
> Thanks and regards
> Williams


I have written a free usb 1.1 IP Core that has a UTMI interface
to a USB 1.1 PHY (also freely available).
Look at www.opencores.org

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

Article: 79671
Subject: Re: FPGA board with best cost/CLB ratio?
From: "Marc Randolph" <mrand@my-deja.com>
Date: 22 Feb 2005 19:53:39 -0800
Links: << >>  << T >>  << A >>
Martin Schoeberl wrote:
> > For a university project we are looking for FPGA boards which offer
> > the best possible cost/CLB ratio. We are interested in realizing a
> > system with a large number (possibly hundreds) FPGAs running in
> > parallel. Both single FPGA or multiple FPGA boards are an option as
> > long as the price per logic function is "optimum".
> >
> Hundreds of FPGAs in parallel is cool.
> You should consider to design your own boards ;-)
>
> Martin
>
> PS.: That's is not a joke. In that range it makes sense to build your
> own solution (or let it build).

Except for the time it'd take (and for college students, money), I'd
agree with you, Martin.  When I first read the posting, I assumed they
would just build a proof-of-concept.  Or maybe that was me just being
hopeful that they aren't about to spend the money it would take to buy
*that* many demo/eval/prototyping boards.

Anyway, they need to find a board that is stuffed with as many Spartan
3 or Cyclone parts as possible.  They will cost less if they are in a
smallish package, and at least with Xilinx, the top device or two in
each family may not be the most cost effective (i.e., for Xilinx, I'll
bet either the XC3S2000 in the 676 pkg or XC3S1500 in the 320 or 456
pkg will be the most cost effective).  It's mostly dependant on which
part is running the highest volume.

But as we started out discussing, the per/device cost is going to
disappear due to using pre-made boards.  In this case, I'm afraid
they're just going to have to get quotes from each place and figure up
the cost/logic.  There are just too many variables: profit margins,
exchange rates, number of FPGA's per board, and exactly which FPGA is
on that board.  Not to mention finding boards that are easy to tie
together (using a backplane?  cables?).

   Marc


Article: 79672
Subject: Re: FPGA board with best cost/CLB ratio?
From: John Williams <jwilliams@itee.uq.edu.au>
Date: Wed, 23 Feb 2005 14:52:15 +1000
Links: << >>  << T >>  << A >>
Hi Christof,

Christof wrote:
> For a university project we are looking for FPGA boards which offer
> the best possible cost/CLB ratio. We are interested in realizing a
> system with a large number (possibly hundreds) FPGAs running in
> parallel. Both single FPGA or multiple FPGA boards are an option as
> long as the price per logic function is "optimum".

In addition to the other advice offered so far, it seems to me that 
unless your hundreds of FPGAs (or boards) are operating in complete or 
even relative isolation from each other (which is very unlikely), then 
suitability for interconnection should be a high-priority criteria in 
your search.

In fact, it should possible be higher even than your stated $/LUT 
metric.  If your architecture is as scaleable as you think it wil be, 
you can always just buy more boards.   What you can't do is redesign the 
IO on the 100 boards you've already bought...

Regards,

John

Article: 79673
Subject: Re: Hardcopy Vs ASIC
From: digari@dacafe.com
Date: 22 Feb 2005 21:57:01 -0800
Links: << >>  << T >>  << A >>
For me it really doesn't matter whether the solution is ASIC (hardcopy)
or FPGA (Easypath) because both are not (re)configurable.

But i see a performance and power gain in using hardcopy solution,
which is welcome in most of the cases. On the other hand   immediate
availability of easypath solution is a plus because structured
ASIC/FPGA user is always TTM hungry.

> By their own figures, somewhere between 16% and 70% of conversions
will
> 'suceed". (Or somewhere from 30 to 84% will FAIL).

this is what will increase the cost of hardcopy solution.

So a direct question:
If the volume is 30K-to -50K, who will be cheaper ??  Hardcopy or
easypath ???

An indirect question:
What is the volume range where hadrcopy is cheaper and what is the
volume range where easypath is cheaper, if I don't consider TTM and
power/performance gains.

-- Digari


Article: 79674
Subject: Re: Spartan3 Power Supply Circuits
From: abeaujean@gillam-fei.be (A Beaujean)
Date: 22 Feb 2005 23:46:26 -0800
Links: << >>  << T >>  << A >>
"Antonio Pasini" <NOSPAM_pasini.a@tin.it> wrote in message news:<lQMSd.578225$b5.26446081@news3.tin.it>...
> > be perfectly covered by the TI TPS75003RHLR chip with adequate
> >
> > Has anyone heard about the current development and sampling status of
> > that chip?
> 
> I asked the same question to the email address in the TI page.
> They answered that samples and Evaluation modules are available now, but 
> production at end of march.
> 
> I'm now waiting for an answer by EBV.

OK Thank you for the help. I am also waiting for an answer from
belgian distributors.



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