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 78700

Article: 78700
Subject: Re: Exportability of EDA industry from North America?
From: weingart@cs.ualberta.ca (Tobias Weingartner)
Date: Sun, 6 Feb 2005 16:59:40 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <4205FE3C.AE4D86E2@earthlink.net>, Robert Baer wrote:
> "Gary J. Tait" wrote:
> > 
> > On Sat, 05 Feb 2005 14:23:50 GMT, Robert Baer
> > <robertbaer@earthlink.net> wrote:
> > 
> > >
> > >  France??
> > 
> > No Canada, where ATI and Matrox hail from.
> 
>   I understood that.
>   However, when one hears French over the phone on such a call, it is
> possible that the help desk could also be in France...or in parts of
> Africa (theoretically).

And no US citizens speak french, and happen to work at a call centre
in the states?  In today's world, it helps not to have any notions about
where you are getting service from.  Wheater state, or country, or even
company.

-- 
 [100~Plax]sb16i0A2172656B63616820636420726568746F6E61207473754A[dZ1!=b]salax

Article: 78701
Subject: Re: See Peter's High-Wire Act next Tuesday
From: "Paul Leventis \(at home\)" <paulleventis-news@yahoo.ca>
Date: Sun, 6 Feb 2005 12:19:15 -0500
Links: << >>  << T >>  << A >>
Hi Peter,

> There are three ingredients to this "surprise":

All are reasonable comments/questions which I will address below.  But let's 
first step away from Altera's direct Stratix II to Virtex-4 result, and like 
good engineers sanity check the +39% number by trying to compare things 
another way.

Virtex-4 vs. Virtex II-Pro is around 5% faster (I don't have the exact 
result on hand).  Whatever perceived bias there may be, this is the result 
we get when we run those two chips head-to-head, using the same designs, 
same software, and same methodology.  And we've heard this from Xilinx users 
who have been surprised at the lack of performance increase when comparing 
the two chips.  There have been postings on this subject in this very 
newsgroup.  Yes, some IP blocks have got faster, and there have been changes 
to various aspects of the chip, but the basic logic + routing fabric really 
hasn't improved much.  As an architect, I am not surprised at the lack of 
performance increase.  Nothing has changed in V-4 on the logic or routing 
front vs. VIIpro that would lead to speed.  The stripping of SRL16s from the 
M slices should lead only to some area reduction.  And going to 90 nm from 
130 nm doesn't automatically confer a speed advantage, since this depends on 
choices of exactly where you target the process, what gate lengths you use, 
what threshold voltages you use (and where), and even things like using slow 
thick-oxide transistors.  As an example of this, moving from Cyclone (130 
nm) to Cyclone II (90 nm), we're only seeing somewhere in the neighbourhood 
of a 10% performance advantage.

Contrast this to Stratix II.  Stratix II is 45-50% faster than Stratix. 
Again, same designs, same methodology, same tools.  Perhaps we cannot be 
trusted to run Xilinx tools fairly, but we had better know how to run our 
own tools and chips.  Why are we seeing this much advantage?  A small part 
comes from process.  But most of it is as a result of the new logic 
architecture -- to first order, larger LUTs mean fewer logic levels with 
roughly equivalent delay per level, thus faster overall performance.  And 
there are numerous other changes under-the-hood relating to the routing 
architecture and electrical design that lead to further performance 
improvements.  If we had not innovated, we also would have been left with a 
product that was not much faster than its predecessor.

So is a performance advantage in the 39% range that difficult to believe? 
Well, unless you think that Virtex II Pro was way faster than Stratix 
(numerous head-to-head battles in the field do not support this), a big 
advantage for Stratix II is reasonable to expect.

> 1. Altera used its fastest (of three) speed grade against the middle of
> three Xilinx speed grades.

I guess you could say that's the marketing of our results.  The science 
behind the +39% is valid -- we clearly state what we are comparing to and 
why we are comparing that way.  And from a customer (today) perspective, 
that is what they would see too.  There are no speed files for -12 and no 
entries in the data sheet.  Assuming your fastest speed grade (whenever it 
finally comes out) is 10-15% faster than the middle speed grade, we'll still 
be talking about a ~25-30% advantage for Stratix II.

> 2. Altera did not exercise the Xilinx software as strongly as they
> pushed their own. The software tools are quite different, and require a
> different approach if absolute highest speed is the goal. Which it was.

I disagree.  We spent months trying the default settings, the best settings, 
and every combination of settings we could in order to maximize the 
performance of designs run on ISE.  The performance of ISE is difficult to 
compare against, since it tends to do a crappy job when over-constrained or 
under-constrained.  This means we have to spend a lot of time finding just 
the right set of constraints to determine the best (per-domain) performance. 
To get a result for a Virtex-4 design, we run the tool ~15 times on average 
in order to find the best constraints for that design.

Please publicly post the best-effort methodology you would like us (and your 
customers) to employ, or be more specific about what about our approach 
leads to a tool bias.  I would be happy to discuss the merits of various 
benchmarking approachs.

> 3. It is reasonable to assume that Altera's stored designs are more
> Stratix-friendly.

I'll agree that there *could* be some unintentional bias here.  Its 
tricky -- a lot of our benchmark designs come from customers who engage with 
us because they are having troubles, sometimes with meeting performance. 
This may be on an older chip (say, APEX) or it may be that they were having 
tool issues.  What this means is part of our benchmark set comprises designs 
that *did not* do well on our chips.  Some of our designs are targetted 
originally at Xilinx devices and we've been called in to try to hit 
performance in an Altera part because the customer was having availability 
issues.  And yes, some of our designs are just plain old design-to-Stratix 
designs.  So its a bit of a mess to try to decipher whether or not we have a 
bias based on the benchmark set...

One point I would make is that Stratix II's logic architecture is radically 
different from Stratix's.  So even if we had a bias towards Stratix designs, 
I'm not sure that would mean we should automatically see an advantage for 
Stratix II vs. Virtex-4 since in many ways Virtex-4 and Stratix are more 
similar than is Stratix II to either architecture.

> So, don't you guys play the surprised innocent onlookers. Nobody
> expected Altera to be fair.

I don't think I've ever expressed surprise at the response.  I sometimes 
wonder whether we should have screwed being fair and instead just posted 
totally unfair results like +60% or +70%, or to take a page from Xilinx's 
books, "up to +230%" so that once people de-rate for assumed unfairness, 
they'd end up somewhere near the right result.

> Hell, I think the whole business of competitive benchmarks being run
> and promoted by an interested party is a sham and a disgusting
> deception. That's why I refused to enter the mudbath...

And Xilinx has never dared to make any performance claims in the past?  At 
least our +39% result is a step forward in that we are using averages (real, 
geometric averages with a full data set) and not "up to" numbers, and we are 
posting details on our methodology, and are doing our best not to stack the 
deck.

Regards,

Paul Leventis
Altera Corp. 



Article: 78702
Subject: Re: See Peter's High-Wire Act next Tuesday
From: "Paul Leventis \(at home\)" <paulleventis-news@yahoo.ca>
Date: Sun, 6 Feb 2005 12:28:14 -0500
Links: << >>  << T >>  << A >>
Hi Rick,

> Correct me if I am wrong, but didn't Altera use the most current speed 
> file data that was available at the time?  Or was the data available in 
> the speed file and just the parts are not available?  Lets face it.

You are correct.  No speed files are available for -12.  No numbers are in 
the datasheet.  So we compare to -11.

> Even if the speed file data was available, data based on estimates is 
> pretty pointless.  We have seen significant changes in speed files even 
> *after* a chip is in production.  So the data is pretty meaningless 
> *before* the parts are in production.

I think performance comparisons based on preliminary timing models are still 
valid.  Regardless of how correct speed files are, that is the performance a 
customer will see, and is what customers are using to select devices and 
speed grades.  Of course, performance comparisons need to be updated with 
each release of speed files (and cad software too -- algorithms are always 
improving).

I cannot speak for Xilinx and their speed files.  But on the Altera side of 
things, I would not expect much change in core performance.  For all 
families I've been involved with (Stratix, Cyclone, and beyond), our core 
performance predictions made in the preliminary timing models have been very 
close (within 5%) of final production numbers.  Stratix II core (logic + 
routing) speed will not be changing more than a few % in the future.  Our 
models have already been correlated to silicon and compare very well.  The 
toggle rate limitations on DSP and memory blocks will likely increase 
(again) since we're still in the process of finishing off our 
characterization of these blocks and we like to stick with conservative 
limits until that characterization is completed.

Regards,

Paul Leventis
Altera Corp. 



Article: 78703
Subject: How to fix this synthese warnings?
From: "Philipp" <sportfreund@gmx.at>
Date: Sun, 6 Feb 2005 18:01:30 -0000
Links: << >>  << T >>  << A >>
Hello

I have implemented an multiplier in the following way: I always take 4 bits 
of my first operand and multiply it with the second operand. So in every 
step I generate 4 partial products which have to be added. This sum is 
stored in the accumulator. In the next clock cycle I take the next 4 bits, 
multiply it with the second operand, sum up the partial products and add 
this to my accumulator. This is performed a few times until I have processed 
all the bits of operand one. Then my result is stored in the accu.
My implementation works fine but when I synthesize it I get a lot of 
"warnings", can somebody tell me what went wrong here?

Mapping all equations...
Building and optimizing final netlist ...
Register outp_0 equivalent to accu1_8 has been removed
Register outp_1 equivalent to accu1_9 has been removed
Register outp_2 equivalent to accu1_10 has been removed
Register outp_3 equivalent to accu1_11 has been removed
Register outp_4 equivalent to accu1_12 has been removed
Register outp_5 equivalent to accu1_13 has been removed
Register outp_6 equivalent to accu1_14 has been removed
Register outp_7 equivalent to accu1_15 has been removed
Register outp_8 equivalent to accu1_16 has been removed
Register outp_9 equivalent to accu1_17 has been removed
and so on...

The code for accu1 and outp looks the following:

 if rst = '1' then
     op1 <= (others => '0');
     op2 <= (others => '0');
     outp <= (others => '0');
     accu1 <= (others => '0');

  elsif clk'event and clk = '1' then
       if load = '1' then
          op1 <= inp0;
          op2 <= inp1;
       end if;
       if shift = '1' then
          op2 <= op2((2*width-10 downto 0) & (7 downto 0 => '0');
       end if;
       if acc = '1' then
          accu1 <= accu((2*width-1) downto 0) & (7 downto 0 => '0');
          outp<= "00" & accu((2*width-3) downto 0);
       end if;
  end if;
  end process;

accu represents always the newest Accumulator value. Hope somebody can 
explain me how to get rid of all these warnings

Cheers
Philipp 



Article: 78704
Subject: warning messages,NgdBuild:454,DesignRules:331
From: "Jack" <JEmoderatz@yahoo.com>
Date: 6 Feb 2005 10:05:43 -0800
Links: << >>  << T >>  << A >>
dear all

I encountered tremendous of warning messages (2 types). First type is

------------------------------------------------------------------------------
WARNING:NgdBuild:454 - logical net 'microblaze_0/Trace_Instr_EX<30>'
has no load
------------------------------------------------------------------------------

In xilnx answer browser,

------------------------------------------------------------------------------
This warning indicates that the signal referenced in the warning has no
load and will be removed during implementation.
-------------------------------------------------------------------------------

What does this mean? In case the signal is removed, what heppens? How
can we avoid this warning?

Second type is

------------------------------------------------------------------------------
WARNING:DesignRules:331 - Blockcheck: Dangling G output. G of comp
microblaze_0/microblaze_0/Data_Flow_I/Register_File_I/Register_File_Bit_I15/R
egFile_X2/microblaze_0/microblaze_0/Data_Flow_I/Register_File_I/Register_File
_Bit_I15/RegFile_X2/SP.G is configured, but output is not used.
------------------------------------------------------------------------------

I could not find the answer browser, but similar answer browser,

-----------------------------------------------------------------------------
To check for this, search for these components in FPGA Editor, and see
if they are configured
-----------------------------------------------------------------------------

If this is a problem, how can we configure in FPGA editor?


Article: 78705
Subject: Re: How to fix this synthese warnings?
From: "Paul Leventis \(at home\)" <paulleventis-news@yahoo.ca>
Date: Sun, 6 Feb 2005 13:09:29 -0500
Links: << >>  << T >>  << A >>
outp and accu have many bits which will always have the same value.  The 
synthesis tool notices this, and thus decides to reusue the accu register to 
feed whatever the corresponding bits of the outp register feed.

For example, outp(0) is always accu(0).  So is accu1(8).  So using accu1(8) 
everywhere that outp(0) is used is logically equivalent, and uses fewer 
resources.

- Paul

"Philipp" <sportfreund@gmx.at> wrote in message 
news:36n438F50qb8bU1@individual.net...
> Hello
>
> I have implemented an multiplier in the following way: I always take 4 
> bits of my first operand and multiply it with the second operand. So in 
> every step I generate 4 partial products which have to be added. This sum 
> is stored in the accumulator. In the next clock cycle I take the next 4 
> bits, multiply it with the second operand, sum up the partial products and 
> add this to my accumulator. This is performed a few times until I have 
> processed all the bits of operand one. Then my result is stored in the 
> accu.
> My implementation works fine but when I synthesize it I get a lot of 
> "warnings", can somebody tell me what went wrong here?
>
> Mapping all equations...
> Building and optimizing final netlist ...
> Register outp_0 equivalent to accu1_8 has been removed
> Register outp_1 equivalent to accu1_9 has been removed
> Register outp_2 equivalent to accu1_10 has been removed
> Register outp_3 equivalent to accu1_11 has been removed
> Register outp_4 equivalent to accu1_12 has been removed
> Register outp_5 equivalent to accu1_13 has been removed
> Register outp_6 equivalent to accu1_14 has been removed
> Register outp_7 equivalent to accu1_15 has been removed
> Register outp_8 equivalent to accu1_16 has been removed
> Register outp_9 equivalent to accu1_17 has been removed
> and so on...
>
> The code for accu1 and outp looks the following:
>
> if rst = '1' then
>     op1 <= (others => '0');
>     op2 <= (others => '0');
>     outp <= (others => '0');
>     accu1 <= (others => '0');
>
>  elsif clk'event and clk = '1' then
>       if load = '1' then
>          op1 <= inp0;
>          op2 <= inp1;
>       end if;
>       if shift = '1' then
>          op2 <= op2((2*width-10 downto 0) & (7 downto 0 => '0');
>       end if;
>       if acc = '1' then
>          accu1 <= accu((2*width-1) downto 0) & (7 downto 0 => '0');
>          outp<= "00" & accu((2*width-3) downto 0);
>       end if;
>  end if;
>  end process;
>
> accu represents always the newest Accumulator value. Hope somebody can 
> explain me how to get rid of all these warnings
>
> Cheers
> Philipp
> 



Article: 78706
Subject: Re: See Peter's High-Wire Act next Tuesday
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 6 Feb 2005 10:37:13 -0800
Links: << >>  << T >>  << A >>
This is getting tedious, but Paul did write " we were so surprised that

Virtex-4 came out so poorly." That's where I got the SURPRISE from.
:-)

It looks like everybody agrees: the evolution from 130 nm to 90 nm does
not automatically give a big performance boost. (it lowers the cost,
though).
So Altera and Xilinx used additional means to improve Stratix-II and
Virtex-4 performance, but the two companies did this in very different
ways.
Altera changed the LUT structure significantly, and I can believe that
this makes certain applications faster, if they can tolerate shared
inputs. But  Altera made no systems-oriented functional changes, added
no new functions or structures.
Xilinx did the opposite, leaving the LUT structure pretty much as
before, but adding and improving functionality in many ways (as I
emphasized in the web-seminar).
What does that mean for the old benchmarks?
Since all Altera benchmark use established legacy designs, and only
designs available to Altera, they will benefit from LUT-level
improvements, but will of course have no clue about major structural
and functional improvements, as introduced by Virtex-4.

I bet there are no dual-clock FIFOs in the Altera benchmarks, or 32-tap
FIR filters, or Gigabit SerDes, or microprocessors, or even SRL16s or
LUT-RAMs. Such applications do not exist in the old designs, or they
are implemented in such different, less efficient ways that they do not
migrate.

Altra evolved Stratix-II in a direction that old legacy benchmarks can
easily take advantage of. Xilinx evolved Virtex-4 into a more
systems-oriented direction. I am convinced the Virtex-4 innovations
provide a bigger performance boost for new designs that can take
advantage of the new features. Who cares about porting obsolete
designs?

This also answers the quest for public benchmarks: There is no way that
otherwise nice guys like Paul and Peter would ever agree on such
benchmarks. I would insist on SRL16s, FIFOs etc, and Paul would load up
with applications that are favored by the complex LUTs with their
shared inputs. Both of us would have to be selfish, since there is so
much at stake.
There can be no common ground, since there is no "typical benchmark".

Benchmarks are dead, long live performance!
Peter Alfke


Article: 78707
Subject: Re: How to fix this synthese warnings?
From: "Philipp" <sportfreund@gmx.at>
Date: Sun, 6 Feb 2005 18:37:45 -0000
Links: << >>  << T >>  << A >>
Thanks Paul, is this okay when I leave it this waz and let the synthese tool 
do the work to get rid of the redundant information?

cheers
Philipp


"Paul Leventis (at home)" <paulleventis-news@yahoo.ca> wrote in message 
news:Tf6dnecnorC8wJvfRVn-jA@rogers.com...
> outp and accu have many bits which will always have the same value.  The 
> synthesis tool notices this, and thus decides to reusue the accu register 
> to feed whatever the corresponding bits of the outp register feed.
>
> For example, outp(0) is always accu(0).  So is accu1(8).  So using 
> accu1(8) everywhere that outp(0) is used is logically equivalent, and uses 
> fewer resources.



Article: 78708
Subject: Re: See Peter's High-Wire Act next Tuesday
From: rickman <spamgoeshere4@yahoo.com>
Date: Sun, 06 Feb 2005 14:57:26 -0500
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> This is getting tedious, but Paul did write " we were so surprised that
> 
> Virtex-4 came out so poorly." That's where I got the SURPRISE from.
> :-)
> 
> It looks like everybody agrees: the evolution from 130 nm to 90 nm does
> not automatically give a big performance boost. (it lowers the cost,
> though).
> So Altera and Xilinx used additional means to improve Stratix-II and
> Virtex-4 performance, but the two companies did this in very different
> ways.
> Altera changed the LUT structure significantly, and I can believe that
> this makes certain applications faster, if they can tolerate shared
> inputs. But  Altera made no systems-oriented functional changes, added
> no new functions or structures.
> Xilinx did the opposite, leaving the LUT structure pretty much as
> before, but adding and improving functionality in many ways (as I
> emphasized in the web-seminar).
> What does that mean for the old benchmarks?
> Since all Altera benchmark use established legacy designs, and only
> designs available to Altera, they will benefit from LUT-level
> improvements, but will of course have no clue about major structural
> and functional improvements, as introduced by Virtex-4.
> 
> I bet there are no dual-clock FIFOs in the Altera benchmarks, or 32-tap
> FIR filters, or Gigabit SerDes, or microprocessors, or even SRL16s or
> LUT-RAMs. Such applications do not exist in the old designs, or they
> are implemented in such different, less efficient ways that they do not
> migrate.
> 
> Altra evolved Stratix-II in a direction that old legacy benchmarks can
> easily take advantage of. Xilinx evolved Virtex-4 into a more
> systems-oriented direction. I am convinced the Virtex-4 innovations
> provide a bigger performance boost for new designs that can take
> advantage of the new features. Who cares about porting obsolete
> designs?
> 
> This also answers the quest for public benchmarks: There is no way that
> otherwise nice guys like Paul and Peter would ever agree on such
> benchmarks. I would insist on SRL16s, FIFOs etc, and Paul would load up
> with applications that are favored by the complex LUTs with their
> shared inputs. Both of us would have to be selfish, since there is so
> much at stake.
> There can be no common ground, since there is no "typical benchmark".
> 
> Benchmarks are dead, long live performance!
> Peter Alfke

I think most of what Peter has said is very reasonable.  But I think you 
*can* have common public benchmarks if you start at a higher level 
rather than try to share HDL code.  Typically, a project will know which 
vendor is going to be used and can design their architecture to fit.  So 
why not spec a design function and let the vendor write their own code 
to implement it?

-- 

Rick Collins

rick.collins@XYarius.com

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design       http://www.arius.com
4 King Ave.                               301-682-7772 Voice
Frederick, MD 21701-3110     GNU tools for the ARM http://www.gnuarm.com

Article: 78709
Subject: Re: See Peter's High-Wire Act next Tuesday
From: Jim Granville <no.spam@designtools.co.nz>
Date: Mon, 07 Feb 2005 09:45:19 +1300
Links: << >>  << T >>  << A >>
Paul Leventis (at home) wrote:
<snip>
> I cannot speak for Xilinx and their speed files.  But on the Altera side of 
> things, I would not expect much change in core performance.  For all 
> families I've been involved with (Stratix, Cyclone, and beyond), our core 
> performance predictions made in the preliminary timing models have been very 
> close (within 5%) of final production numbers.  Stratix II core (logic + 
> routing) speed will not be changing more than a few % in the future.  Our 
> models have already been correlated to silicon and compare very well. 
<snip>

Funny, I was sure this was an Altera link ( you have seen this ? )

http://www.altera.com/corporate/news_room/releases/products/nr-perf_power.html

To me that looks rather more than a 5% nudge ?

Does this mean the prelim models were not as good as you claim, or are
you more carefully qualifying the best ones, to better compete with
Xilinx's claims ?

In all this speed/benchmark hoopla, I see one thing that is never 
mentioned is price.

  Will we see a 'bragging rights' bin, that is the
three sigma yield limit, and so very expensive, but hey, look how
fast we are !!

-jg


Article: 78710
Subject: Re: See Peter's High-Wire Act next Tuesday
From: Jim Granville <no.spam@designtools.co.nz>
Date: Mon, 07 Feb 2005 09:56:55 +1300
Links: << >>  << T >>  << A >>
rickman wrote:

> Peter Alfke wrote:
<snip>
>> This also answers the quest for public benchmarks: There is no way that
>> otherwise nice guys like Paul and Peter would ever agree on such
>> benchmarks. I would insist on SRL16s, FIFOs etc, and Paul would load up
>> with applications that are favored by the complex LUTs with their
>> shared inputs. Both of us would have to be selfish, since there is so
>> much at stake.
>> There can be no common ground, since there is no "typical benchmark".
>>
>> Benchmarks are dead, long live performance!
>> Peter Alfke
> 
> 
> I think most of what Peter has said is very reasonable.  But I think you 
> *can* have common public benchmarks if you start at a higher level 
> rather than try to share HDL code.  Typically, a project will know which 
> vendor is going to be used and can design their architecture to fit.  So 
> why not spec a design function and let the vendor write their own code 
> to implement it?

  Exactly, this is the 'optimised' branch I was talking about.

  Uses do not care what tricks you use, they want to know the peak MHz, 
MHz/$, or mW/MHz or whatever, for a particular application.

  They EXPECT differences in fit and ideal usage, by end application, but
right now, this type of information is sparse indeed.

  They also are more interested in a design broadly in their field, than
in how fast one node can spin.

  FPGAs are getting more complex, with the dedicated blocks, so HDL 
designers need vendor-tuned examples of how to efficently use those blocks.

  -jg



Article: 78711
Subject: Re: See Peter's High-Wire Act next Tuesday
From: hmurray@suespammers.org (Hal Murray)
Date: Sun, 06 Feb 2005 16:04:14 -0600
Links: << >>  << T >>  << A >>
There is a lot of negative baggage associated with the term Benchmark.

Yet there is a lot of performance related info that would help
designers, both in choosing between chips and when working on
a design.

I'm thinking of things like the speed of a 32 bit counter.
It's a reasonably basic building block.  It's not the whole
story, but it's one very useful data point.

The next question is how many variations make sense?  Do they
have major impacts on the speed and/or take extra resources?
  Enable, load, overflow flag, ...

Maybe the info I'm looking for should be printed in
green if there is a good fit with the hardware (sweet spot)
and flagged with red if the answer might surprise you (say
because it takes an extra level of logic).

Other basic things I'd like to see...
  Data rate between 2 chips (same type/speed).
  Routing delays to go N steps H or V.


Maybe that's all BS because most engineering time is
spent working at a higher level.  (But I always get involved
with the details.)

Maybe a handful of medium size tasks would be interesting.
Maybe library elements.  Maybe just good examples.
  Pulse width modulators - fixed and programmable parameters.
  FIR filters.
  State machines - need several examples.
  DRAM controller


>I think most of what Peter has said is very reasonable.  But I think you 
>*can* have common public benchmarks if you start at a higher level 
>rather than try to share HDL code.  Typically, a project will know which 
>vendor is going to be used and can design their architecture to fit.  So 
>why not spec a design function and let the vendor write their own code 
>to implement it?

I was thinking about that too.  One complication is that you
can push some things off to the non-FPGA parts of the system
or pull things in.

What sort of problem would be a good whole-system example?

Vendor neutral would be nice, but I'm also interested in
good examples that take advantage of special features,
and I'm willing to push things around and/or change the
problem if that makes things fit better for the total
system.


-- 
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: 78712
Subject: problem with xilinx platform studio 6.2i
From: "Ram" <dotexe@gmail.com>
Date: 6 Feb 2005 14:10:01 -0800
Links: << >>  << T >>  << A >>
Hello, I'm working on a simple hardware design lab -Microblaze.When I
start a new project with BSB in Xilinx Platform Studio(XPS)and select
target development board I face a problem. The board which I have is
Spartan-3 and the lab exercise is based on Spartan-3. But the
software(XPS) 6.2i which i have in system does'nt show all the xilinx
board names. When i select Xilinx in the board vendor, it shows only 2
names in Board Names(AFX Virtex and Virtex II). I wish to select
Spartan-3 which isnt there. how to include Spartan-3? . Is there any
alternative way to include spartan-3 board name?  please help me
Thank you


Article: 78713
Subject: Re: How to fix this synthese warnings?
From: Walter Dvorak <use-reply-to@gruebel.invalid>
Date: Sun, 6 Feb 2005 22:53:16 +0000 (UTC)
Links: << >>  << T >>  << A >>
Philipp <sportfreund@gmx.at> wrote:
> is this okay when I leave it this waz and let the synthese tool 
> do the work to get rid of the redundant information?

	yes, that's ok. But keep care about other warnings. One 
drawback of XST is the generation of warnings: if your project 
grow it is near to impossible to avoid warnings. Some of them
are harmless and more "informative". But other could be 
essential and it is possible that you overlook some.

WD
-- 

Article: 78714
Subject: Re: problem with xilinx platform studio 6.2i
From: Shalin Sheth <Shalin.Sheth@xilinx.com>
Date: Sun, 06 Feb 2005 15:04:52 -0800
Links: << >>  << T >>  << A >>
The Xilinx Spartan-3 Starter Kit board was released after EDK 6.2.  Have 
you installed EDK 6.2 service pack 2?  The service pack should include 
board support for the Spartan-3 Starter Kit board.

The service pack can be downloaded from:
http://www.xilinx.com/ise/embedded/edk_download.htm

Cheers,
Shalin-

Ram wrote:
> Hello, I'm working on a simple hardware design lab -Microblaze.When I
> start a new project with BSB in Xilinx Platform Studio(XPS)and select
> target development board I face a problem. The board which I have is
> Spartan-3 and the lab exercise is based on Spartan-3. But the
> software(XPS) 6.2i which i have in system does'nt show all the xilinx
> board names. When i select Xilinx in the board vendor, it shows only 2
> names in Board Names(AFX Virtex and Virtex II). I wish to select
> Spartan-3 which isnt there. how to include Spartan-3? . Is there any
> alternative way to include spartan-3 board name?  please help me
> Thank you
> 

Article: 78715
Subject: Re: See Peter's High-Wire Act next Tuesday
From: Jim Granville <no.spam@designtools.co.nz>
Date: Mon, 07 Feb 2005 12:07:10 +1300
Links: << >>  << T >>  << A >>
Hal Murray wrote:
<snip>
> What sort of problem would be a good whole-system example?

How about:

Frequency/Pulse Counter  [24/32/40/48 bits ]
  This needs counters, and capture. Counters can be either
  Decimal, or Binary, with some Bin-BCD post conversion, for
display of the results.

DDS - same widths, this needs wide adders
Expanding to Waveform generation, and pulse generation...

These are complex enough to push the FPGA, have easily
verifiable output everyone can relate to, and would
be genuinely usefull for education..
Some would be simple enough for the MAX II or
smallest ProASIC3...


and more ambitious: a Storage Oscilloscope, that needs
a timebase, and wide data path pumping, [assume external
fast-enough ADC] to any choices of USB / Firewire / ATA / SerialATA
(etc) for the results.

> Vendor neutral would be nice, but I'm also interested in
> good examples that take advantage of special features,
> and I'm willing to push things around and/or change the
> problem if that makes things fit better for the total
> system.

Of course..
-jg


Article: 78716
Subject: ISE6.x/iMPACT, JTAG fails after any completed command
From: "AugustoEinsfeldt" <aee@terra.com.br>
Date: 6 Feb 2005 15:21:14 -0800
Links: << >>  << T >>  << A >>
I am seeing a very strange behavior. Till last week I was using
ISE6.1i03 succesfully in any design. Before I start a new design I did
upgrade it to ISE6.3i03 and while debuging the new design's PCB I
noticed when using iMPACT after any sucessfull device command like
Erase, blank check or Program the XCF02S, or Programming the XC2S200E
on board, the next JTAG command returns error (ERROR:iMPACT:1210 -
'2':Boundary-scan chain test failed at bit position '1').
In the FPGA command case, the configuration is sucessfull (DONE goes
high) but I/O pins still in Hi-Z. Mode pins are in JTAG. XCF02S memory
is erased.
When JTAG starts with this problem I have to cycle power in the
design's PCB to have JTAG access again.
Power supply (1.8V and 3.3V) is ok and no voltage dip is seen.
I returned to ISE6.1i03 to see if there were something wrong with
ISE6.3 under Windows XP+SP2 but there still the same problem (note that
the old installed ISE6.1i03 was working perfectly under XP+SP2).
I am using Xilinx original Parallel Download Cable-III.
Now I am wondering if ISE6.3i installation did change some XP's system
file (not returned by re-installation of ISE6.1i) that could lead to
this error.
I am currently two days under this fault and customer is already asking
why a simple board test (to be sure all devices are working properly)
cannot be done.
Any clue will help a lot.
Best regards,


Article: 78717
Subject: Re: See Peter's High-Wire Act next Tuesday
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 6 Feb 2005 15:42:51 -0800
Links: << >>  << T >>  << A >>
Jim, I like your idea, but it is not all that straightforward.
I mentioned in the seminar that there is a loadable synchronous counter
inside every DSP Slice, and it runs at 500 MHz, no ifs, no buts.
Now, I will build a 5 GHz counter using the MGT. Is that allowed?
DDS obviously runs at 500 MHz in the DSP slice, but I will run a
virtual 8 GHz DDS either by using 16 accumulators, or by doing some
clever math. Is that kosher?
If you saw my seminar, I mentioned those things, and there will be app
notes, etc.
Storage oscilloscope is dear to my heart, but it has many arbitrary
parameters.
Its performance and cost are determined by the A/D at the input, not
the FPGA.

I suggest we keep generating creative app notes, reference designs, and
evaluation boards, without calling them benchmarks.

BTW:
Choosing between X and A isn't all that difficult, it's only between
two suppliers. Selecting between umpteen brands of breakfast cereals,
washing mashines, cars, or colleges for your kids is a much tougher
task. ( Life in NZ may be simpler, but the choices in the US are
mindboggling. ;-)
Peter Alfke


Article: 78718
Subject: GND and VCC pins
From: "Mouarf" <moi@chezmoi.fr>
Date: Mon, 7 Feb 2005 01:54:30 +0100
Links: << >>  << T >>  << A >>
hello all,

I'm drawing the layout of my Xilinx XC9572XL (TQ100)evaluation board but I 
wonder wether it is necessary to connect all GND and VCC pins to the power 
tracks. Could somebody tell me that?

Thanks by advance.



Article: 78719
Subject: Re: GND and VCC pins
From: "Bob" <nimby1_notspamm_@earthlink.net>
Date: Mon, 07 Feb 2005 00:59:27 GMT
Links: << >>  << T >>  << A >>

"Mouarf" <moi@chezmoi.fr> wrote in message
news:4206bc40$0$17118$626a14ce@news.free.fr...
> hello all,
>
> I'm drawing the layout of my Xilinx XC9572XL (TQ100)evaluation board but I
> wonder wether it is necessary to connect all GND and VCC pins to the power
> tracks. Could somebody tell me that?
>
> Thanks by advance.
>
>

Yes. Don't try to second-guess the chip designers.

Bob



Article: 78720
Subject: Re: GND and VCC pins
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 6 Feb 2005 17:13:20 -0800
Links: << >>  << T >>  << A >>
Yes, connect all. On-chip and going of-chip current transitions ( di/dt
) are so fast, that they create v=L di/dt ground bounce voltage over
the unavoidable inductance between chip and pc-board. You must keep
this inductance as small as possible = connect all supply pins.
Peter Alfke, Xilinx Applications


Article: 78721
Subject: Re: Digilent JTAG cable parallel port pinout (Spartan 3)
From: "C3" <_>
Date: Mon, 7 Feb 2005 12:15:25 +1100
Links: << >>  << T >>  << A >>
Then we must be in a similar position, as I was also browsing that website
(albeit before getting my board).

:-)


C3



Article: 78722
Subject: Re: GND and VCC pins
From: "Mouarf" <moi@chezmoi.fr>
Date: Mon, 7 Feb 2005 02:45:39 +0100
Links: << >>  << T >>  << A >>
OK, I'll connect all power pins but are all GND (and VDD) pins connected 
together inside ?


"Peter Alfke" <alfke@sbcglobal.net> a écrit dans le message de news: 
1107738800.425885.182090@g14g2000cwa.googlegroups.com...
> Yes, connect all. On-chip and going of-chip current transitions ( di/dt
> ) are so fast, that they create v=L di/dt ground bounce voltage over
> the unavoidable inductance between chip and pc-board. You must keep
> this inductance as small as possible = connect all supply pins.
> Peter Alfke, Xilinx Applications
> 



Article: 78723
Subject: Re: GND and VCC pins
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 6 Feb 2005 17:50:03 -0800
Links: << >>  << T >>  << A >>
Yes, they are. But you should not rely on this. It's your job to
minimize the resistance and inductance.
Peter Alfke


Article: 78724
Subject: Quality of Xilinx ML401 video output?
From: "Pete Fraser" <pfraser@covad.net>
Date: Sun, 6 Feb 2005 17:58:57 -0800
Links: << >>  << T >>  << A >>
Just got round to firing up my ML401 last weekend.

The quality of the video output is terrible.
Do I have a faulty board, or is it a design/layout issue?

The video out has asynchronous resonant spikes running
through it. The spikes are about 100 mV p-p, and have a
resonant frequency of about 250 MHz, with about 6 half-cycles
present.

There is also about 15 mV p-p of pixel clock and harmonics.

Jitter is about 5ns p-p.

I have not yet poked around with a scope or stared at
the layout. I was hoping this is a board rather than
a design problem, as I had intended to use the board for
some video tests.

Also, the V4 is quite toasty. After running the slideshow
for a few minutes the temperature is in the high 60s.
Is this reasonable? (It's an ES part).

Thanks

Pete






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