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 73500

Article: 73500
Subject: Re: Stratix II vs. Virtex 4 - features and performance
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 22 Sep 2004 15:57:05 -0400
Links: << >>  << T >>  << A >>
Nicholas Weaver wrote:
> 
> And THIS is why you should push the volatile solution.  You have a
> group of nonvolatile cells.  The work in reverse engineering is going
> to be a strong O(1) operation, as once it is done, it is simply a
> matter of delidding the chip, probing in the right places, and reading
> the results.
> 
> Compared with the volatile solution: you are probably going to need to
> do power or signal analysis on the encryption in action.  Which means
> you are probably going to need to add probes to the power/ground pins,
> on a live board, without disrupting the power supply to the
> configuration loader (which can be made even harder by potting the
> FPGA with wires for the config voltage around it).

I once learned how to use an electron microscope to probe signals on a
chip.  Once you figure out where the volatile bits are stored, wouldn't
it be a simple matter to read them out with an electron microscope? 
Just pop the lid and stick the board (assuming it is small enough) under
the scope.  Probe it with a very low beam current and you should be able
to see which bits are powered and which bits are off.  

-- 

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: 73501
Subject: Re: Stratix II vs. Virtex 4 - power
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 22 Sep 2004 15:59:15 -0400
Links: << >>  << T >>  << A >>
Austin Lesea wrote:
> 
> Further,
> 
> We used:
> 
> - low Vt transistors
> - architectural improvements
> - design improvements
> - three oxides
> 
> Why?  Because we have to in order to meet our customer's needs.
> 
> So do not compare us with a "gas guzzler" using old technology, old
> design, and old architectures.
> 
> No comparison, no contest.
> 
> Austin

Another well thought out discussion.   Thanks Austin!  ;)


-- 

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: 73502
Subject: Re: Stratix II vs. Virtex 4 - power
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 22 Sep 2004 16:05:44 -0400
Links: << >>  << T >>  << A >>
John_H wrote:
> 
> Thanks for the dissertation.  I'm afraid I miss your point, though.
> 
> You've done a great job analyzing the tradeoffs from your view.  As
> engineers, I'm sure we can all appreciate that different tradeoffs are
> "better" to different people from direct experience, knowledge, and
> expectations (such as the troubles the industry had bringing up the low-K
> dielectric).
> 
> If parts from any manufacturer run hotter and cost more, the market will
> gravitate away from those devices.  If there are cool, fast, cheap,
> feature-rich devices, we won't give a Vt whether there are extra process
> steps or yield issues that could have produced a "better" part if another
> approach were taken.
> 
> Particularly troublesome to me is the conclusion that brand-X apparently has
> their head up their triple oxide because non-FPGA vendors are implementing
> their application-specific hardware on other processes.  I don't SEE the
> connection.
> 
> I love to see input from all vendors, but I see more competitor negatives
> than company positives here.  Lets find out how good our new parts are, not
> how bad their chips are.  Maybe we're temporarily stuck in the political
> mindset here in the US.

This whole discussion in pretty pointless.  As you say, a user does not
care about *how* you make the chips, just how well they work.  So when
Austin and Dave argue about the tradeoffs in each vendor's choice of
implementations, there is *no* point.  The only useful info is (1) how
much it costs (not even per LUT/SLICE/ALM but the real cost of the chip
you need to implement *your* design *AFTER* you get through all the
sales BS a dickering [which the engineer typcially does not get into]),
(2) how long the lead times are, and (3) how long it takes to get your
design to run in that part with the available software.  

Anything else is just noise...

-- 

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: 73503
Subject: NIOS II / Cyclone II - Multiply, Barrel Shift and Divide
From: jon@beniston.com (Jon Beniston)
Date: 22 Sep 2004 13:10:58 -0700
Links: << >>  << T >>  << A >>
Hi,

When targeting the Cyclone II, the NIOS II/f configuration in SOPC
builder doesn't seem to list support for either multipler,
barrel-shifter or divide. Support for these only seems to be available
when the target is a Stratix  device. Is this correct? Is it not
possible to get h/w multiply support on the Cyclone II?

I'm using the eval version of NIOS II.

Cheers,
Jon

Article: 73504
Subject: Re: [ALTERA] NIOS-II + MMU + FPU
From: Buddy Smith <buddy@tpac.gatech.edu>
Date: Wed, 22 Sep 2004 20:14:03 +0000 (UTC)
Links: << >>  << T >>  << A >>
In comp.arch.embedded Markus Meng <meng.engineering@bluewin.ch> wrote:
<snip>
> This would make it possible to run standard
> unix like Linux (MMU required) ...

FYI:
Linux is not unix.  Also, linux does not require an MMU. 
http://www.uclinux.org

--buddy

Article: 73505
Subject: Re: Verilog vs VHDL for Loops
From: Bassman59a@yahoo.com (Andy Peters)
Date: 22 Sep 2004 13:18:35 -0700
Links: << >>  << T >>  << A >>
Nicolas Matringe <nicolasmatringe001@numeri-cable.fr> wrote in message news:<414FD415.5080508@numeri-cable.fr>...
> Andre Bonin a écrit:
> > Ken McElvain wrote:
> > 
> >> This loop should compile fine in Synplify.
> > 
> > 
> > I'me using quartus2.  What is synplify?
> 
> QuertusII doesn't like VHDL while loops. I replaced one with a for loop 
> and an exit statement and it worked OK.
> I don't know if it is the same with Verilog while loops though.

I haven't used Synplify in ages, but I use Precision all the time. 
According to the Precision manual, "Loops must be bounded by constants
or contain [a] @(posedge clk) statement."

The original poster's code:

    integer X = 0;
    always begin
        while (X < 30) begin
           X = X + 1;
        end // while
    end // always

has a couple of problems.  First, if one were to simulate this, one
would see that it actually would execute in zero time.  How SHOULD
this be implemented in hardware?

The initializer is ignored (think about it: what's the synthesizer
supposed to do with it?).  The while statement isn't bounded like the
usual for loop:

    for (x = 0; x < 30; x = x + 1) begin ... end //

Note the constants in that for loop, tho'.  Say you had:

    integer first, last;

    for (x = first; x < last; x = x + 1) begin

those values aren't bounded, either, so the synthesizer wouldn't know
what to do with it.

The manual does say that the two loop conditions are ORed, so it one
modified the original poster's code as follows:

    always @(posedge clk) begin
        while (X < 30) begin
           X = X + 1;
        end // while
    end // always

then one would expect things to "work."  (It's a simple incrementer
that stops when it hits the value 30.  Not very useful unless it can
be reset!)

Think hardware ...

-a

Article: 73506
Subject: Re: question about types in VHDL
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 22 Sep 2004 16:25:01 -0400
Links: << >>  << T >>  << A >>
kofeyok wrote:
> 
> Thanks for the reply rickman.
> 
> That makes sence now.
> I see that passing of values between modules is done using slv.. but you
> can can convert (not cast) inside of each module. The signed port gives
> non-synthesizable code. At least my simulator refuses to simulate.

I don't know that it matters what types you use when passing signals
between modules.  Signed types should be just as synthesizable as any
others.  Also, simulators should work with code that is not
synthesizable.  My test benches are seldom synthesizable and they run
just fine.  

I expect you have some other problem that changing the type is masking
rather than fixing.  The only issues with various types is when you want
to mix them in assignments or other expressions.  I don't think there
are any arithmetic operators defined for slv while signed and unsigned
do have operators such as +, -, <, >...  Otherwise they are the same,
no?  

-- 

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: 73507
Subject: Re: Mr. Greenfield, spare us the propaganda !
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 22 Sep 2004 16:27:55 -0400
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> 
> Mr Greenfield was not an anonymous spammer, he posted properly under his
> Altera address, and he was on-topic. Very much so, too much !
> He just made a bunch of unsubstantiated, opinionated, inflammatory and wrong
                         !------------------------------------------!
> statements, and he violated the spirit and the unwritten rules of this
> newsgroup. And I hope he and his ilk will never do that again.

I am confused, are you talking about Greenfield or Austin?  

-- 

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: 73508
Subject: Re: [ALTERA] NIOS-II + MMU + FPU
From: Jim Stewart <jstewart@jkmicro.com>
Date: Wed, 22 Sep 2004 13:44:17 -0700
Links: << >>  << T >>  << A >>
Buddy Smith wrote:
> In comp.arch.embedded Markus Meng <meng.engineering@bluewin.ch> wrote:
> <snip>
> 
>>This would make it possible to run standard
>>unix like Linux (MMU required) ...
> 
> 
> FYI:
> Linux is not unix.  Also, linux does not require an MMU. 
> http://www.uclinux.org


Is uclinux the same as Linux?  I thought the kernel
and the executables were considerably different.



Article: 73509
Subject: Re: How To Synchronize FPGAs
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 22 Sep 2004 16:46:27 -0400
Links: << >>  << T >>  << A >>
Yes, you *are* missing something...  ;)

Don Golding wrote:
> 
> Maybe I am missing something, but wouldn't you just drive all the chips with
> one onboard clock then in your code trigger the processes on the rising
> edge?
> 
> Don
> 
> "Leroy Tanner" <ikeepthespiritalive@freenet.de> wrote in message
> news:cirft3$j4c$1@mamenchi.zrz.TU-Berlin.DE...
> > Hello newsreaders,
> >
> > For a while I have been confronted with the following task which I find
> > quite challenging but unfortuantely didn't manage to solve it, yet.
> > What I want to do is to use 2-4 FPGAs (Xilinx Virtex 2 Pro) together on
> > one
> > printed circuit board (PCB). They are used to process a large amount of
> > incoming serial data (data rates of several GHz's). My idea is to handle
> > that data parallel by the 2-4 FPGAs. But now there arises the problem how
> > to
> > adequately split the data and how to synchronize the FPGAs among one
> > another, in particular?
> > Is it possible or first of all a realistic idea to synchronize multiple
> > FPGAs in the GHz range? How can this be done without much protocoll
> > overhead? I would like to do it without applying an extra transfer
> > protocoll
> > among the FPGAs just for that purpose! Up to this date I didn't find a
> > proper solution, yet.
> > Maybe someone can give me a hint? Any ideas how to solve that problem?
> >
> > Regards,    Leroy Tanner
> >
> >

-- 

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: 73510
Subject: Re: Mr. Greenfield, spare us the propaganda !
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 22 Sep 2004 16:49:26 -0400
Links: << >>  << T >>  << A >>
Pete Fraser wrote:
> 
> "Chris Alexander" <info@bostonsemiconductor.com> wrote in message
> news:376c28cd.0409220408.5da521d7@posting.google.com...
> > Just so!  There is more marketing jive going on here than just from
> > Altera.  Being new to this group, I thought this was a Xilinx only
> > area until the "infamous posts" showed up.
> >
> > I look forward to the technical threads, but the hype from anyone
> > (including Austin) I skip over.
> >
> > One more poster to add to the "skip-over-list".
> 
> Much of Austin's stuff is worth reading.
> Occasionally though, he goes into over-the-top marketing mode.

That is true.  Perhaps Austin should pass his posts through an editor
who will make him write out the emotional marketing stuff.  Then I can
see his techical posts rising to the quality level of Dr. Howard Johnson
perhaps.  

-- 

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: 73511
Subject: Re: How To Synchronize FPGAs
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Wed, 22 Sep 2004 14:02:35 -0700
Links: << >>  << T >>  << A >>


Leroy Tanner wrote:

 >  But now there arises the problem how to
> adequately split the data and how to synchronize the FPGAs among one
> another, in particular?

> Is it possible or first of all a realistic idea to synchronize multiple
> FPGAs in the GHz range? How can this be done without much protocoll
> overhead? 

I believe most important is to first latch the signals in the IOB
to minimize clock skew problems.   Otherwise, an external shift
register to generate bit parallel signals for input to the FPGA.

-- glen


Article: 73512
Subject: Re: Stratix II vs. Virtex 4 - features and performance
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 22 Sep 2004 14:11:36 -0700
Links: << >>  << T >>  << A >>
Rick, don't forget, there are ten layers of metal above the transistors that
store the key or the configuration...
Peter A

>> 
> I once learned how to use an electron microscope to probe signals on a
> chip.  Once you figure out where the volatile bits are stored, wouldn't
> it be a simple matter to read them out with an electron microscope?
> Just pop the lid and stick the board (assuming it is small enough) under
> the scope.  Probe it with a very low beam current and you should be able
> to see which bits are powered and which bits are off.
> 
> -- 
> 
> 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: 73513
Subject: Re: [ALTERA] NIOS-II + MMU + FPU
From: John Williams <jwilliams@itee.uq.edu.au>
Date: Thu, 23 Sep 2004 07:38:51 +1000
Links: << >>  << T >>  << A >>
Jim Stewart wrote:
> Buddy Smith wrote:
> 
>> In comp.arch.embedded Markus Meng <meng.engineering@bluewin.ch> wrote:
>> <snip>
>>
>>> This would make it possible to run standard
>>> unix like Linux (MMU required) ...
>>
>>
>>
>> FYI:
>> Linux is not unix.  Also, linux does not require an MMU. 
>> http://www.uclinux.org
> 
> Is uclinux the same as Linux?  I thought the kernel
> and the executables were considerably different.

99% of the kernel code is identical.  From 2.6 onwards, uClinux (ie 
nommu) support is integrated into Linus' root source tree.  For 2.4 
kernels, uClinux is a patch that *adds* to Linux, nothing is removed.

In the microblaze port for example, we take drivers written by 
MontaVista for the PPC/V2Pro kernel, and drop them in directly.  Some 
small modifcations are required usually due to differences in kernel 
configuration mechanisms, not fundamental architectural issues.

 From an application programming perspective, much of the time apps are 
source compatible between linux and uClinux.  I recently took some ntp 
(network time protocol) tools and had then running on my microblaze 
uClinux board in under half an hour.  No source code changes required.

nommu means no fork(), you use vfork instead.  Many Linux/Unix programs 
use the sequence fork()/exec() - this is easily ported to vfork.  Other, 
more complex uses can be a bit trickier.  pthreads works on uClinux 
platforms.

uClinux uses a different executable file format (called flat binaries), 
rather than ELF.  However, the build environment and tools automatically 
handles the creation of these files.  Once your board has booted, they 
are just executables, same as any other.

Read the following excellent article by Dave McCullough if you'd like to 
learn more about the differences (and lack thereof):

http://www.linuxjournal.com/article.php?sid=7221

Regards,

John

Article: 73514
Subject: Re: Stratix II vs. Virtex 4 - features and performance
From: "Symon" <symon_brewer@hotmail.com>
Date: Wed, 22 Sep 2004 14:38:54 -0700
Links: << >>  << T >>  << A >>
..and dissolving them off with hydrofluoric acid while the chip's battery
backed bit stays powered up would be a very neat trick indeed!
Cheers, Syms.
"Peter Alfke" <peter@xilinx.com> wrote in message
news:BD773898.8C85%peter@xilinx.com...
> Rick, don't forget, there are ten layers of metal above the transistors
that
> store the key or the configuration...
> Peter A
>
> >>
> > I once learned how to use an electron microscope to probe signals on a
> > chip.  Once you figure out where the volatile bits are stored, wouldn't
> > it be a simple matter to read them out with an electron microscope?
> > Just pop the lid and stick the board (assuming it is small enough) under
> > the scope.  Probe it with a very low beam current and you should be able
> > to see which bits are powered and which bits are off.
> >
> > -- 



Article: 73515
Subject: Can Map and Par still handle the XC4000e family?
From: "B. Joshua Rosen" <bjrosen@polybus.com>
Date: Wed, 22 Sep 2004 18:18:30 -0400
Links: << >>  << T >>  << A >>
I just had a query from a potential client who has a large number of very
old systems that they need to support. The systems use the XC4013e and
XC4010e. Assuming that there is a synthesis tool that still supports the
XC4000E family (I'm pretty sure that Synplify can still do it), will the
current versions of map and par be able to place and route a 4000E design?


Article: 73516
Subject: Re: spartan-3 sram
From: "Steven K. Knapp" <steve.knappNO#SPAM@xilinx.com>
Date: Wed, 22 Sep 2004 15:35:53 -0700
Links: << >>  << T >>  << A >>

"mete" <mete@ieee.org> wrote in message
news:acc68109.0409220755.6012e358@posting.google.com...
> Hi,
>
> Can you provide me a code piece to use async. sram e.g. in spartan-3
> starter kit ? I could not get it work.
>
You may have found these already, but there are a few example applications
available for download from the Xilinx Spartan-3 Starter Kit Board web site.
http://www.xilinx.com/products/spartan3/s3boards.htm#RF

In specific, the Digital Clock PCB Monitor design and the MicroBlaze Master
System both read and write to the 1Mbyte of external SRAM on the board.  The
PCB Monitor design uses the free PicoBlaze 8-bit controller core.
---------------------------------
Steven K. Knapp
Applications Manager, Xilinx Inc.
General Products Division
Spartan-3/II/IIE FPGAs
http://www.xilinx.com/spartan3
---------------------------------
Spartan-3:  Make it Your ASIC



Article: 73517
Subject: Re: Reconfigure Spartan 3 without losing BRAM?
From: "Steven K. Knapp" <steve.knappNO#SPAM@xilinx.com>
Date: Wed, 22 Sep 2004 15:40:31 -0700
Links: << >>  << T >>  << A >>

"rickman" <spamgoeshere4@yahoo.com> wrote in message
news:414E7D8D.7C56BCE3@yahoo.com...

[snip]

> I have been meaning to send you an email to ask if the Spartan 3s are
> supported for modular reconfiguration yet.  How is that going?  I seem
> to recall that there were a couple of things that had to be resolved
> before the work could even begin.  One was a "bug" or some aspect of the
> ISE software and the other was a work around for the fact that Spartan
> 3s don't have any tristate buffers.  Have either of these issues been
> worked?  How close are we to having a solution?

The modular support using bus macros is not supported currently.  It is
supported via the "bitgen -r" approach, as described in the following Answer
Record.

Is partial reconfiguration supported on Spartan-3 devices?
http://support.xilinx.com/xlnx/xil_ans_display.jsp?getPagePath=18416

---------------------------------
Steven K. Knapp
Applications Manager, Xilinx Inc.
General Products Division
Spartan-3/II/IIE FPGAs
http://www.xilinx.com/spartan3
---------------------------------
Spartan-3:  Make it Your ASIC



Article: 73518
Subject: Re: Can Map and Par still handle the XC4000e family?
From: "Steven K. Knapp" <steve.knappNO#SPAM@xilinx.com>
Date: Wed, 22 Sep 2004 15:46:17 -0700
Links: << >>  << T >>  << A >>

"B. Joshua Rosen" <bjrosen@polybus.com> wrote in message
news:pan.2004.09.22.22.18.28.667446@polybus.com...
> I just had a query from a potential client who has a large number of very
> old systems that they need to support. The systems use the XC4013e and
> XC4010e. Assuming that there is a synthesis tool that still supports the
> XC4000E family (I'm pretty sure that Synplify can still do it), will the
> current versions of map and par be able to place and route a 4000E design?
>

Oh, were it that easy.  :-)

The current version of the Xilinx software no longer supports the XC4000E
family.

Fortunately, the XC4000E and Spartan families are still supported via ISE
Classic, freely downloadable from the web.
http://www.xilinx.com/webpack/classics/spartan_4k/index.htm
---------------------------------
Steven K. Knapp
Applications Manager, Xilinx Inc.
General Products Division
Spartan-3/II/IIE FPGAs
http://www.xilinx.com/spartan3
---------------------------------
Spartan-3:  Make it Your ASIC



Article: 73519
Subject: Re: Stratix II vs. Virtex 4 - power
From: Austin Lesea <austin@xilinx.com>
Date: Wed, 22 Sep 2004 15:49:17 -0700
Links: << >>  << T >>  << A >>
Rick,

Good words to live by.

I am concerned with:

- quiescent power (which is a direct advantage to some, not all in V4)
- performance in V4 (~5% faster in raw speed at slowest speed grade) 
something that is design dependent, and subject to lots of variations, 
so it is up to the software folks, and each individual to compare their 
design and make their own decision if it is a big item for them
- yield (obviously, if it doesn't yield, it is a moot story for all 
concerned).  Yield = cost to customer.  Better cost, better yield.  We 
have 1 M units of 90nm shipped in Spartan 3 (today's press release), so 
no issues there.
- dynamic power savings (directly benefits almost everyone to have 1/2 
the power and less in hardened block in V4 than in V2P).

No BS:  we are better in all of these categories.  Why claim it, if we 
did not have data to show it is true?  No marketing, great engineering 
by the IC Design group, fllowed by great engineering work by our 
verification and charaterization lab.  Am I proud of the work we do? 
You bet:  it is our contribution to the IC Design group, and the overall 
excellence of the product.  I will try not to be too proud of the work, 
and clutter up my posts.

Do I 'trash' S2? Absolutely not.  Do I spread FUD?  Nope (although I am 
guilty of subtle FUD on occason, but Peter usually keeps me 
honest....and I am working on it).  Do I intentionally present the best, 
and not mention any mediocre or less than perfect stuff?  Sure, don't we 
all?  But if you want the errata list, it is something you get with ES 
delivery (or from your FAE prior to delivery -- who does their laundry 
in public? No one), and all I will say is that you can go and compare 
our errata with anyone else's anytime you want, and you make your own 
decision what is important to you.

Austin




rickman wrote:
> John_H wrote:
> 
>>Thanks for the dissertation.  I'm afraid I miss your point, though.
>>
>>You've done a great job analyzing the tradeoffs from your view.  As
>>engineers, I'm sure we can all appreciate that different tradeoffs are
>>"better" to different people from direct experience, knowledge, and
>>expectations (such as the troubles the industry had bringing up the low-K
>>dielectric).
>>
>>If parts from any manufacturer run hotter and cost more, the market will
>>gravitate away from those devices.  If there are cool, fast, cheap,
>>feature-rich devices, we won't give a Vt whether there are extra process
>>steps or yield issues that could have produced a "better" part if another
>>approach were taken.
>>
>>Particularly troublesome to me is the conclusion that brand-X apparently has
>>their head up their triple oxide because non-FPGA vendors are implementing
>>their application-specific hardware on other processes.  I don't SEE the
>>connection.
>>
>>I love to see input from all vendors, but I see more competitor negatives
>>than company positives here.  Lets find out how good our new parts are, not
>>how bad their chips are.  Maybe we're temporarily stuck in the political
>>mindset here in the US.
> 
> 
> This whole discussion in pretty pointless.  As you say, a user does not
> care about *how* you make the chips, just how well they work.  So when
> Austin and Dave argue about the tradeoffs in each vendor's choice of
> implementations, there is *no* point.  The only useful info is (1) how
> much it costs (not even per LUT/SLICE/ALM but the real cost of the chip
> you need to implement *your* design *AFTER* you get through all the
> sales BS a dickering [which the engineer typcially does not get into]),
> (2) how long the lead times are, and (3) how long it takes to get your
> design to run in that part with the available software.  
> 
> Anything else is just noise...
> 

Article: 73520
Subject: Re: Stratix II vs. Virtex 4 - features and performance
From: nweaver@soda.csua.berkeley.edu (Nicholas Weaver)
Date: Wed, 22 Sep 2004 23:02:39 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <2re9nhF199f5gU1@uni-berlin.de>,
Symon <symon_brewer@hotmail.com> wrote:
>..and dissolving them off with hydrofluoric acid while the chip's battery
>backed bit stays powered up would be a very neat trick indeed!
>Cheers, Syms.

And don't forget that the V4 is a flip-chip package, so you need to
depackage and delid it without disrupting the power.
-- 
Nicholas C. Weaver.  to reply email to "nweaver" at the domain
icsi.berkeley.edu

Article: 73521
Subject: Quartus II v4.1 & GNU
From: "bta3" <bta3@iname.com>
Date: Wed, 22 Sep 2004 23:09:32 GMT
Links: << >>  << T >>  << A >>
BlankHi,
   I have a problem generating the "hello" example in QuartusII V4.1 for
excaliber (epxa1 chip with the ARM cpu). This project complied and linked
without any errors in v3.0. In v4.1 (or v4.0), I keep getting a linking
error - something to the effect "cannot load ld : -lgcc.." when I perform a
software build. I do have the directory of libgcc in the path in the linker
setup menu. The folks at Altera do not seem to have seen this problem.
Anyone else has come across this? I think it may be in my setup. To make
sure that I do not have some legacy effect (due to previous versions of
Quartus), I installed v4.1 (with SP1) on a new machine, but to no avail.
BTW, this is on M'soft XP machine. Any Ideas? Thanks
-Ravi



Article: 73522
Subject: Re: Using C++ on NIOS
From: nigelmerritt@hotmail.com (Nigel)
Date: 22 Sep 2004 16:51:11 -0700
Links: << >>  << T >>  << A >>
nigelmerritt@hotmail.com (Nigel) wrote in message news:<cf7f0f95.0409211915.7d9f40e5@posting.google.com>...
> We have just started writing a small application on the NIOS IDE II
> (version 1.0.0, build 316).  I want to develop it in C++, but it won't
> recognise C++ syntax, (class, new etc), so clearly I need to do
> something to enable C++, but I can't find anything.  I have found
> similar problems on the forums/groups, but none with any answers.  The
> closest one was to use "extern "C"{...} around the #includes, but this
> made no difference.
> Any help would be appreciated.

Now solved... it was simply that the 'main' file was created as a ".c"
file, not a ".cpp" (all template projects are  for the NIOS).

Article: 73523
Subject: Re: [ALTERA] NIOS-II + MMU + FPU
From: hpa@terminus.zytor.com (H. Peter Anvin)
Date: Thu, 23 Sep 2004 00:00:29 +0000 (UTC)
Links: << >>  << T >>  << A >>
Followup to:  <cismeb$85u$1@news-int.gatech.edu>
By author:    Buddy Smith <buddy@tpac.gatech.edu>
In newsgroup: comp.arch.embedded
>
> In comp.arch.embedded Markus Meng <meng.engineering@bluewin.ch> wrote:
> <snip>
> > This would make it possible to run standard
> > unix like Linux (MMU required) ...
> 
> FYI:
> Linux is not unix.  Also, linux does not require an MMU. 
> http://www.uclinux.org
> 

However, if you take "Unix-like" as an adjectival phrase, and the
parenthesis as definitional (therefore avoiding arguments about its
validity), it makes sense:

"This would make it possible to run the standard Unix-like Linux,
i.e. the one which requires an MMU."

Desipire ucLinux, there is clearly still a win in having an MMU for
running Linux.

	-hpa



Article: 73524
Subject: using both edges of clocks in a design - effects on synthesis
From: hardwareengineer@gmail.com (hardwareengineer)
Date: 22 Sep 2004 18:24:28 -0700
Links: << >>  << T >>  << A >>
Hi,

I am working on a design where there are different components coded by
different people. I am integrating all of these into a single top
module.

Different components have transitions on different edges of the
clock.For eg: a FIFO in the design waits for the negative edge of the
clock whereas another component waits for the positive edge of the
clock...

My question is...will it lead to synthesis problems if I make the code
work keeping the different clock transitions or should I make all of
them(including the subcomponents) transition on the same edge of the
clock..


I am synthesizing to Virtex XC2V 4000 FPGA and am planning to download
the bitstream and show a working proof

Thanks,
Hardware Engineer



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