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 102375

Article: 102375
Subject: Re: Virtex 5 announced
From: Kolja Sulimma <news@sulimma.de>
Date: Mon, 15 May 2006 21:27:44 +0200
Links: << >>  << T >>  << A >>
dscolson@rcn.com schrieb:

> Six input LUTs seem to be a long over due change.

Not really.
There were competitors with larger and smaller LUTs twelve years ago.
There has been anything from seas of AND gates over 2-LUTs up to 6-LUTs.
Until now 4-LUTs had by far the most success.

Larger LUTs also means fewer LUTs and slower LUTs. The area of a LUT
increases exponentially with the number of inputs and as the LUTs grow,
more and more inputs can't be used on avarage.

Research in the early ninetees suggested that 3-LUTs are better than
4-LUTs because there are so many adders in modern designs.
The addition of dedicated carry logic moved the sweet spot over to 4-LUTs.

The move to larger LUTs now is probably trigger by wiring:
The relative wiring delay is increasing dramatically for smaller
technologies so that it becomes more important to minimize the
interconnect than to minimize LUT delay.
Areawise Xilinx chose to support designs with a rather high rent
exponent. Therefore the larger circuit densities require a larger
amount of wiring. It probably turned out that after filling the chip
with wires and layouting the logic and configuration storage below
there was a significant amount of silicon area left under the wires.
In that situation blowing up the LUTs comes for free area wise.

Kolja Sulimma

Article: 102376
Subject: Re: Virtex 5 announced and sampling
From: Falk Brunner <Falk.Brunner@gmx.de>
Date: Mon, 15 May 2006 21:38:33 +0200
Links: << >>  << T >>  << A >>
Austin Lesea schrieb:

> V4 FX is not skipped.  It is most definitely being shipped right now. In 
> fact the backlog was just cleared.

So what is recommended if I want to use the MGTs, perhaps @ 6.3 Gbit/s

Virtex-II ProX or V4 ?

Are the Virtex-II ProX already available and how is the user feedback?

Regards
Falk

Article: 102377
Subject: Re: Virtex 5 announced and sampling
From: Kolja Sulimma <news@sulimma.de>
Date: Mon, 15 May 2006 21:42:11 +0200
Links: << >>  << T >>  << A >>
Ed McGettigan schrieb:
>  You can of course think of
> any LUT as being generated a 128-to-1 MUX, but that would be inefficient
> in actual hardware to build.
How is that? I do not see any other way of building it.
A MUX can be done in 130 transistors. For a function with 134 inputs
that is pretty good. And even if you instead chose a decoder/mux
combination to trade of area for speed the result is still a MUX, isn't it?

The only difference between a LUT and a MUX is, that in MUX you care
about input to ouput delay, in a LUT you only care bout select to output
delay.

Kolja Sulimma


Article: 102378
Subject: New Virtex4 Project, CoreGen
From: "Brandon" <killerhertz@gmail.com>
Date: 15 May 2006 12:48:50 -0700
Links: << >>  << T >>  << A >>
I want to instantiate some CoreGen modules to get some usage estimates
on some possible target platforms. I've never created a project from
scratch, I've only used vendor supplied projects to implement my
designs, so I'm lost .

Here's my entity w/ instantiation:
<SNIP>

library IEEE;
  use IEEE.STD_LOGIC_1164.ALL;
  use IEEE.STD_LOGIC_ARITH.ALL;
  use IEEE.STD_LOGIC_UNSIGNED.ALL;

LIBRARY unisim;
  USE unisim.vcomponents.ALL;

entity coreest is
  port (
    clk_in: in std_logic;
    reset: in std_logic;
    din: in std_logic_vector(15 downto 0);
    dout: out std_logic_vector(15 downto 0)
    );
end coreest;

architecture str_ar of coreest is

component BUFG is
   port (
     I : in std_logic;
     O : out std_logic
     );
end component;

component macfir
    port (
    CLK: IN std_logic;
    RESET: IN std_logic;
    ND: IN std_logic;
    RDY: OUT std_logic;
    RFD: OUT std_logic;
    DIN: IN std_logic_VECTOR(15 downto 0);
    DOUT: OUT std_logic_VECTOR(37 downto 0));
end component;

signal clk: std_logic;

signal macfir_nd: std_logic;
signal macfir_din: std_logic_vector(15 DOWNTO 0);
signal macfir_rdy: std_logic;
signal macfir_rfd: std_logic;
signal macfir_dout: std_logic_vector(37 DOWNTO 0);

begin

  clk_in_bufg_inst : BUFG
  port map(
    I => clk_in,
    O => clk
    );

  macfir_inst : macfir
  port map (
    CLK => clk,
    RESET => reset,
    ND => macfir_nd,
    DIN => macfir_din,
    RDY => macfir_rdy,
    RFD => macfir_rfd,
    DOUT => macfir_dout
    );

  macfir_nd <= '1';
  macfir_din <= din;
  dout <= macfir_dout(macfir_dout'high downto
macfir_dout'high-dout'length+1);

end str_ar;
</SNIP>

The 'macfir_inst' instance is a CoreGen entity, 'macfir (macfir.xco)'
generated from the Xilinx FIR core. I configured it correctly and
everything seems okay, except synthesis, which is not even recognizing
the global clock net:

<SNIP>
=========================================================================
*                          HDL Compilation
*
=========================================================================
WARNING:HDLParsers:3498 - No primary, secondary unit in the file
"C:/Work/HDL/CoreEst/macfir.vhd. Ignore this file from project file
"C:/Work/HDL/CoreEst/coreest_vhdl.prj".
Compiling vhdl file "C:/Work/HDL/CoreEst/coreest.vhd" in Library work.
Entity <coreest> compiled.
Entity <coreest> (Architecture <str_ar>) compiled.

=========================================================================
*                            HDL Analysis
*
=========================================================================
Analyzing Entity <coreest> (Architecture <str_ar>).
WARNING:Xst:766 - "C:/Work/HDL/CoreEst/coreest.vhd" line 67: Generating
a Black Box for component <BUFG>.
Entity <coreest> analyzed. Unit <coreest> generated.

Analyzing module <macfir>.
Module <macfir> is correct for synthesis.

WARNING:Xst:37 - Unknown property "black_box".

=========================================================================
*                           HDL Synthesis
*
=========================================================================

Synthesizing Unit <macfir>.
    Related source file is "macfir.v".
WARNING:Xst:647 - Input <CLK> is never used.
WARNING:Xst:647 - Input <DIN> is never used.
WARNING:Xst:647 - Input <RESET> is never used.
WARNING:Xst:647 - Input <ND> is never used.
WARNING:Xst:1305 - Output <RFD> is never assigned. Tied to value 0.
WARNING:Xst:1305 - Output <RDY> is never assigned. Tied to value 0.
WARNING:Xst:1305 - Output <DOUT> is never assigned. Tied to value
00000000000000000000000000000000000000.
Unit <macfir> synthesized.


Synthesizing Unit <coreest>.
    Related source file is "C:/Work/HDL/CoreEst/coreest.vhd".
WARNING:Xst:646 - Signal <macfir_dout<21:0>> is assigned but never
used.
WARNING:Xst:646 - Signal <macfir_rfd> is assigned but never used.
WARNING:Xst:646 - Signal <macfir_rdy> is assigned but never used.
Unit <coreest> synthesized.


=========================================================================
HDL Synthesis Report

Found no macro
=========================================================================

=========================================================================
*                       Advanced HDL Synthesis
*
=========================================================================


=========================================================================
Advanced HDL Synthesis Report

Found no macro
=========================================================================

=========================================================================
*                         Low Level Synthesis
*
=========================================================================
Loading device for application Rf_Device from file '4vsx55.nph' in
environment C:\Xilinx.

Optimizing unit <coreest> ...

Mapping all equations...
Building and optimizing final netlist ...
Found area constraint ratio of 100 (+ 5) on block coreest, actual ratio
is 0.

=========================================================================
*                            Final Report
*
=========================================================================
Final Results
RTL Top Level Output File Name     : coreest.ngr
Top Level Output File Name         : coreest
Output Format                      : NGC
Optimization Goal                  : Speed
Keep Hierarchy                     : NO

Design Statistics
# IOs                              : 34

Cell Usage :
# BELS                             : 1
#      GND                         : 1
# IO Buffers                       : 16
#      OBUF                        : 16
=========================================================================

Device utilization summary:
---------------------------

Selected Device : 4vsx55ff1148-12

 Number of bonded IOBs:                 16  out of    640     2%


=========================================================================
TIMING REPORT

NOTE: THESE TIMING NUMBERS ARE ONLY A SYNTHESIS ESTIMATE.
      FOR ACCURATE TIMING INFORMATION PLEASE REFER TO THE TRACE REPORT
      GENERATED AFTER PLACE-and-ROUTE.

Clock Information:
------------------
No clock signals found in this design

Timing Summary:
---------------
Speed Grade: -12

   Minimum period: No path found
   Minimum input arrival time before clock: No path found
   Maximum output required time after clock: No path found
   Maximum combinational path delay: No path found

Timing Detail:
--------------
All values displayed in nanoseconds (ns)
</SNIP>


Article: 102379
Subject: Re: Virtex 5 announced
From: Jim Granville <no.spam@designtools.co.nz>
Date: Tue, 16 May 2006 07:54:02 +1200
Links: << >>  << T >>  << A >>
Antti wrote:
> I am trying to be fair now, only asking LX questions :)
> 
> 1) Xilinx website says to the general public that 'start designing' NOW
> to my understanding it means that software support is available NOW, or
> is there is any other way to see it?

  Perhaps, 'start designing' means little, perhaps a better question 
would be when can one 'finish designing' (and ship) ! ;)
-jg


Article: 102380
Subject: Re: Virtex 5 announced and sampling
From: Austin Lesea <austin@xilinx.com>
Date: Mon, 15 May 2006 12:59:13 -0700
Links: << >>  << T >>  << A >>
Falk,

V4 FX goes to 6.25, and we have tested for some customers just slightly 
higher (up to 6.5) and not seen any real yield issues.  Work with your FAE.

V4 FX has so much more than V2 Pro X (which has only two devices).

Austin

Falk Brunner wrote:

> Austin Lesea schrieb:
> 
>> V4 FX is not skipped.  It is most definitely being shipped right now. 
>> In fact the backlog was just cleared.
> 
> 
> So what is recommended if I want to use the MGTs, perhaps @ 6.3 Gbit/s
> 
> Virtex-II ProX or V4 ?
> 
> Are the Virtex-II ProX already available and how is the user feedback?
> 
> Regards
> Falk

Article: 102381
Subject: Re: Virtex 5 announced and sampling ... and real!
From: Jim Granville <no.spam@designtools.co.nz>
Date: Tue, 16 May 2006 08:02:11 +1200
Links: << >>  << T >>  << A >>
John_H wrote:

> Kudos on the new release!
> 
> But I started to glaze over as you turned on your marketing engines.  I 
> sincerely prefer the technical Austin.

Yes, but this Austin can still be entertaining, as he waves his arms  :)

eg  I'm looking forward to just what exactly "equivalent static power"
can be ?

  Could that be like their equivalent LUTs, perhaps ?

-jg


Article: 102382
Subject: Re: reverse engineering ?
From: MikeShepherd564@btinternet.com
Date: Mon, 15 May 2006 21:15:20 +0100
Links: << >>  << T >>  << A >>
>The only way is to keep on deveoping new things faster than the
>old ones get copied. Witholding knowledge seems to be a "no-no"
>in evolutionary sense, this is how we are designed. The smarter
>a society, the more rewards it offers for knowledge creation.
> This is not to say I am all open, of course. The above strategy
>is probably optimized at an (inter?) species level, and I also am only
>an individual... This is part (not a predominant one, though) of
>the reason why I maintain a complete in-house tooling/development
>capability, once you do a design on a wintel machine it is
>anything but proprietary (can become public on a click
>beyond the control of the design owner).

I think your ideas are too abstract.  If I meet a lion, I need quick
thinking to stay alive.  I could stop to consider whether evolution
has equipped the lion better to deal with this meeting and whether, in
the long run, the chances of surviving an encounter with a lion make
it worthwhile or not to take evasive action.  I could prepare to
lecture the lion on the moral and practical advantages of a vegetarian
life, but I'd do better to defer these worthy pursuits until I'm out
of harm's way.

Substitute "lion" with "Chinese techno-pirate" and the same rules
apply.  Some designs will be copied, but this doesn't mean we should
abandon all protection.

Article: 102383
Subject: Xilinx Platform Cable USB protocol specifications and/or open-source firmware replacement
From: Laurent Pinchart <laurent.pinchart@skynet.be>
Date: Mon, 15 May 2006 22:15:23 +0200
Links: << >>  << T >>  << A >>
Hi everybody,

I recently bought a Xilinx Spartan-3E evaluation board, which comes with an
integrated Platform Cable USB. Looking for a Linux compatible solution to
program the FPGA, I found out that Impact requires the binary kernel driver
Jungo and is thus not an option.

As Xilinx decided to classify the cable USB protocol specifications as
"highly confidential", I started to reverse engineer the programmer to see
if I could write an open-source host software.

The programmer is made of a USB microcontroller (Cypress EZ-USB) and a CPLD.
After trying to understand the protocol from USB traces only without
success, I decided to disassemble the microcontroller firmware. The code
gave me more information regarding the protocol, but some USB commands are
forwarded to the CPLD through register read/write operations and/or general
purpose I/Os.

Not being able to understand the protocol, I thought I would write a
replacement firmware which would not require a kernel driver. I'm looking
for people interested in the project (or for people who have managed to
understand the Xilinx USB protocol :-)). I can take care of the Cypress
EZ-USB microcontroller, but needs someone with CPLD programming experience
to write a replacement for the Xilinx CPLD firmware.

Laurent Pinchart


Article: 102384
Subject: Re: Virtex 5 announced
From: "Peter Alfke" <peter@xilinx.com>
Date: 15 May 2006 13:24:15 -0700
Links: << >>  << T >>  << A >>
As far as chip area goes, the decision to go to LUT6 (as we call it)
was a no-brainer:

Extensive benchmarking shows that a LUT6 is 'worth" about 1.4 LUT4
(this is an average over almost 200 designs, your mileage may vary...)
Our designers found that the CLB size penalty for LUT6 compared to
using LUT4 in the same technology is only about 15% (Yes, the LUT takes
only a small portion of the silicon area)

Gaining 40% in functional density for a 15% price in larger area is, of
course, a win-win situation.
The higher performance due to fewer levels of LUTs and reduced
interconnects is just a bonus. Nice bonus, thank you!
Peter Alfke, Xilinx


Article: 102385
Subject: Re: Virtex 5 announced and sampling ... and real!
From: Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de>
Date: Mon, 15 May 2006 20:24:45 +0000 (UTC)
Links: << >>  << T >>  << A >>
Austin Lesea <austin@xilinx.com> wrote:
...
> Imitation is the sincerest form of flattery, as STM now also has a 
> triple oxide 90nm process.  I am sure they will also offer it at 65nm, 
> as they also realized how useful it was to their customers.

If using triple oxide is imitation and "Imitation is the sincerest form of
flattery" then the whole semiconductor industry is using this
"flattery". Did Xilinx invent the MOS transistor, self aligning gates, wire
bonding, etc. and all those other things they use to produce an IC?  Well,
as Newton said: "If I have seen a little further it is by standing on the
shoulders of Giants."

Is using a third oxid thickness really that great genuine invention nobody
thought of before. Didn't the engineers at Xilinx need to bang their head
fighting for this feature against many (d|m)amages seeing only the added
cost? Perhaps other engineers in other companies wheren't that succesfull on
the first try. Now perhaps their (d|m)amages see the light.

Otherwise congratulation to the new "baby".

And hopefully a faster release story to general availability then for 
XC3SE and ... and ...

Cheers
-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 102386
Subject: Re: Virtex 5 announced and sampling
From: "Antti Lukats" <antti@openchip.org>
Date: Mon, 15 May 2006 22:28:33 +0200
Links: << >>  << T >>  << A >>
"Ed McGettigan" <ed.mcgettigan@xilinx.com> schrieb im Newsbeitrag 
news:4468D3A2.7040600@xilinx.com...
> Antti wrote:
>> the basic LUT delay cant be much faster, it was pretty damn fast in V4 
>> already !
>> however the 6 input LUT is not true 6 input LUT but two 5 input LUTs and 
>> a mux
>> so if the mux delay is significant then 6 input function will we way 
>> slower than
>> 5 input function, sure there is still performance gain over plain 4 LUT
>> architecture.
>
> The Virtex-5 6-input LUT is a true 64-bit look-up-table.  Any 6 input
> function can be implemented in the LUT.  You can of course think of
> any LUT as being generated a 128-to-1 MUX, but that would be inefficient
> in actual hardware to build.
>
> As for the timing, the Virtex-5 data sheet is online with timing
> delays for all three speed grades so you can verify the performance
> differences.
>
> Ed McGettigan
> --
> Xilinx Inc.

Hi Ed,

well if you say so, but the datasheet shows

2 separate 5 input LUTs
1 output select MUX that combines the makes the 5 input LUTs to look like 
one 6 input LUT

if I look at that schematic from the datasheet then the 6 input function 
would include
LUT delay and MUX in series.

if you say it is not 2 LUTs and 1 MUX, but one LUT,
well then is the datasheet really confusing!!

Antti 



Article: 102387
Subject: Re: Virtex 5 announced and sampling
From: "Antti Lukats" <antti@openchip.org>
Date: Mon, 15 May 2006 22:31:01 +0200
Links: << >>  << T >>  << A >>
"Kolja Sulimma" <news@sulimma.de> schrieb im Newsbeitrag 
news:4468d210$0$11063$9b4e6d93@newsread4.arcor-online.net...
> Antti schrieb:
>
>> however the 6 input LUT is not true 6 input LUT but two 5 input LUTs
>> and a mux
>> so if the mux delay is significant then 6 input function will we way
>> slower than
>> 5 input function, sure there is still performance gain over plain 4 LUT
>> architecture.
>
> Hmm. There really is no difference between a MUX and a LUT.
> Same schematic symbol, same choice of implementations, same thing.
>
>> the basic LUT delay cant be much faster, it was pretty damn fast in V4
>> already !
>
> You can not really read the circuit speed from the datasheet or FPGA
> editor, as they use abstracted timing models.
> You can push delay around almost at will in a timing model.
> At any node of the timing model you can subtract a delay from all
> outgoing edges and add them to all incoming edges without changing the
> model. If you reduce the delay of some edges to zero you can merge
> nodes. You can even have negative delay edges in timing models.
>
> You can use this to simplify the model for your software or for the
> user. Or you can try to look better than your competitor this way
> because people tend to compare certain delays and ignore others.
>
> As a note: The value for the carry chain is pretty reliable beacuse each
> element is immediately preceeded and succeeded by an identical element.
> Not much pushing possible there.
>
> Kolja Sulimma
Hi Kolja

I am referring to my results of actual LUT delay measurements.
what I did before looking the datasheet info. I was almost not
to belive the lut delay (too small!) in V4. Only after seeing
it in real silicon i looked up the timing info in datasheet.

Antti








Article: 102388
Subject: Re: getting good deals on small qty?
From: "Peter Alfke" <peter@xilinx.com>
Date: 15 May 2006 13:32:46 -0700
Links: << >>  << T >>  << A >>
The distributor is not operating a charity. Selling you 5 chips for
about $ 50 is hardly a very profitable transaction, considering
paperwork etc. These are not little 7/11 stores...
Expecting to buy 5 chips at the million-quantity price is unrealistic.
The $40 difference between a real and a completely unrealistic price is
not too bad.

Now, if you complain that you cannot get the chips at all, that would
be a valid complaint.
$ 40 is not!
Peter Alfke, Xilinx


Article: 102389
Subject: Re: Virtex 5 announced and sampling
From: "Jon Beniston" <jon@beniston.com>
Date: 15 May 2006 13:40:00 -0700
Links: << >>  << T >>  << A >>

Austin Lesea wrote:
> lb,
>
> V4 FX is not skipped.  It is most definitely being shipped right now.
> In fact the backlog was just cleared.
> 

Are any FX40 parts at the fab yet?

Cheers,
Jon


Article: 102390
Subject: Re: Virtex 5 announced and sampling
From: "Peter Alfke" <peter@xilinx.com>
Date: 15 May 2006 13:46:10 -0700
Links: << >>  << T >>  << A >>
Antti, remember how a LUT is really constructed.
It contains 64 latches plus a 6-level 64-to-1 multiplexer, like a
christmas tree.
The data sheet just (for tutorial purposes) shows the final stage of
this big multiplexer separately.
If that bothers you, ignore it. But just do not believe that it costs
more than the extra delay of any multiplexer level.
There are 6 levels of multiplexing, nothing we can do about it.
Peter Alfke


Article: 102391
Subject: Re: Virtex 5 announced and sampling ... and real!
From: google@gornall.net
Date: 15 May 2006 14:18:25 -0700
Links: << >>  << T >>  << A >>
Quoth Uwe:

> Well, as Newton said: "If I have seen a little further it is by
> standing on the shoulders of Giants."

... yeah, but oft-forgotten is that Newton was being a dick. He wrote
that in a letter to Hooke, who was notoriously short of stature, while
they were arguing over who was the first for some discovery or other...


It's often quoted as if Newton was being humble, but what he was saying
was "I'm better than you, and nothing you have done was remotely useful
to science"...

Simon


Article: 102392
Subject: Re: Virtex 5 announced and sampling ... and real!
From: Austin Lesea <austin@xilinx.com>
Date: Mon, 15 May 2006 14:20:51 -0700
Links: << >>  << T >>  << A >>
Jim,

Basically, equivalent in this sense is "equal."

So if the static power was 1 watt before, it is still one watt (or less).

At 65nm, there is gate leakage.

Gate leakage does not vary with temperature.

So there is a component of the static power that remains the same at 
-40C, or at 25C, or even at 100C.

That factor is a significant part of the static leakage.  Basically, the 
cost of using 65nm.

What you will find is that the typical static current for Vccint 
(Iccint) for V5 is at first, larger than what you would expect. 
However, it will be on par, or below what the 100C number was for the 
V4.  If the worst case for V4 at 100C was X watts, then a similar sized 
V5 will be X watts or less over the entire tempeature range, without a 
huge difference from 25C to 100C (which was what folks are used to 
seeing before gate leakage became a dominant factor in 65nm).

Does this answer the question?

Austin

Jim Granville wrote:

> John_H wrote:
> 
>> Kudos on the new release!
>>
>> But I started to glaze over as you turned on your marketing engines.  
>> I sincerely prefer the technical Austin.
> 
> 
> Yes, but this Austin can still be entertaining, as he waves his arms  :)
> 
> eg  I'm looking forward to just what exactly "equivalent static power"
> can be ?
> 
>  Could that be like their equivalent LUTs, perhaps ?
> 
> -jg
> 

Article: 102393
Subject: Re: getting good deals on small qty?
From: shawnn@gmail.com
Date: 15 May 2006 14:22:39 -0700
Links: << >>  << T >>  << A >>
Thanks for the reply Peter.

As I stated earlier, I'm not so concerned about the extra cost of the
prototype parts, but rather about the cost of the 100-200 parts I may
buy later. $40 is obviously not worth complaining about.

Why is it that Newegg can get me the latest $300 AMD or Intel desktop
processor in qty. 1 without a 400% markup over list, yet such markups
are normal when buying $300 worth of FPGAs? Not a flame, I'm genuinely
curious to know.


Article: 102394
Subject: Re: Virtex 5 announced and sampling ... and real!
From: Austin Lesea <austin@xilinx.com>
Date: Mon, 15 May 2006 14:22:40 -0700
Links: << >>  << T >>  << A >>
Uwe,

Easy for you to say now.  But there was a time where the competition was 
selling against triple oxide as being too new, too risky, and too 
expensive (with no benefit).

So, humor me, name the chips that use a triple oxide process.

Austin

Uwe Bonnes wrote:

> Austin Lesea <austin@xilinx.com> wrote:
> ...
> 
>>Imitation is the sincerest form of flattery, as STM now also has a 
>>triple oxide 90nm process.  I am sure they will also offer it at 65nm, 
>>as they also realized how useful it was to their customers.
> 
> 
> If using triple oxide is imitation and "Imitation is the sincerest form of
> flattery" then the whole semiconductor industry is using this
> "flattery". Did Xilinx invent the MOS transistor, self aligning gates, wire
> bonding, etc. and all those other things they use to produce an IC?  Well,
> as Newton said: "If I have seen a little further it is by standing on the
> shoulders of Giants."
> 
> Is using a third oxid thickness really that great genuine invention nobody
> thought of before. Didn't the engineers at Xilinx need to bang their head
> fighting for this feature against many (d|m)amages seeing only the added
> cost? Perhaps other engineers in other companies wheren't that succesfull on
> the first try. Now perhaps their (d|m)amages see the light.
> 
> Otherwise congratulation to the new "baby".
> 
> And hopefully a faster release story to general availability then for 
> XC3SE and ... and ...
> 
> Cheers

Article: 102395
Subject: Re: Virtex 5 announced and sampling
From: "Antti Lukats" <antti@openchip.org>
Date: Mon, 15 May 2006 23:23:28 +0200
Links: << >>  << T >>  << A >>
"Peter Alfke" <peter@xilinx.com> schrieb im Newsbeitrag 
news:1147725970.779784.92570@u72g2000cwu.googlegroups.com...
> Antti, remember how a LUT is really constructed.
> It contains 64 latches plus a 6-level 64-to-1 multiplexer, like a
> christmas tree.
> The data sheet just (for tutorial purposes) shows the final stage of
> this big multiplexer separately.
> If that bothers you, ignore it. But just do not believe that it costs
> more than the extra delay of any multiplexer level.
> There are 6 levels of multiplexing, nothing we can do about it.
> Peter Alfke
>

Hi Peter,

in LUT4 world the mux that allows the LUT4 to be used 5 input function DOES 
add extra delay compared to plain LUT4 delay IMHO

if the MUX in datasheet that is drawn 'for tutorial purposes' allows the 
LUT6 to be as fast as LUT5 that doesnt use that final MUX, then ok.

I was blindly assuming that component drawn as MUX does add extra delay when 
it is included in signal path, versus timing where signal bypasses it.

as V5 can implement SRL32 and not SRL64 then IMHO it is clear that LUT6 is 
made up from 2 LUT5 exactly as it is drawn in the datasheet.

Antti 



Article: 102396
Subject: Re: Power for Spartan 3
From: Jim Granville <no.spam@designtools.co.nz>
Date: Tue, 16 May 2006 09:23:35 +1200
Links: << >>  << T >>  << A >>
Peter Mendham wrote:
>> The values in the TI data
>> sheet (figure 1) produce about 2.54 volts, 3.29 volts and of course,
>> 1.2 volts.
> 
> 
> I am indeed.  I am probably being stupid, but using the values in all 
> the TI example circuits (I have about 5 variations here) the Buck 2 
> potential divider uses values of 61K9 and 36K5 (or 319K and 365K).  By 
> equation 15 in the TI datasheet these values give a Vout of 3.343V. 
> Similarly, for the LDO the value 2.545V.  These are 43mV and 45mV over 
> spec respectively.  Now, it is extremely likely that I am either 
> worrying about nothing, or being very stupid.  Is this over-voltage 
> specified deliberately, or is it simply a product of using nearest-fit 
> resistor values?  Or have I done my calculations badly?  If you can 
> clarify that for me I would be very grateful.

The error on 3.3V is 1.3%, which will be nearest fit resistor values.
Normally, simplest design uses two resistors, and it is hard to nail
a value under 1% with available values.

If this is loosing you sleep, then move to a 3 resistor design, and
also be prepared to pay for resistors under 1% tolerance.

In a real design, you should measure/verify the voltage AT THE DEVICE,
which means a few mV high allows for some trace/choke IR drop.

Also check the dynamic power changes, and output impedance of your
regulators, as that is another error source.

-jg


Article: 102397
Subject: Microblaze dcm_module problems
From: andrew.hood@gmail.com
Date: 15 May 2006 14:26:13 -0700
Links: << >>  << T >>  << A >>
I am trying to increase the clock frequency of my microblaze processor
(currently 50 MHz) using the dcm_module frequency M/D outputs (CLKFX).
I have pasted the dcm_module portion of my system.mhs file here:

BEGIN dcm_module
 PARAMETER INSTANCE = dcm_module_0
 PARAMETER HW_VER = 1.00.a
 PARAMETER C_CLKFX_MULTIPLY = 12
 PARAMETER C_CLKFX_DIVIDE = 10
 PARAMETER C_CLKIN_BUF = TRUE
 PARAMETER C_CLK0_BUF = TRUE
 PARAMETER C_CLKFX_BUF = TRUE
 PARAMETER C_EXT_RESET_HIGH = 1
 PARAMETER C_CLKIN_PERIOD = 20.00000
 PARAMETER C_STARTUP_WAIT = TRUE

 PARAMETER C_FAMILY = spartan3
 PORT RST = net_gnd
 PORT CLKIN = sys_clk
 PORT CLKFB = dcm_module_0_CLKF0
 PORT CLK0 = dcm_module_0_CLKF0
 PORT LOCKED = system_dcm_LOCKED
 PORT CLKFX = sys_clk_s
END

For some reason, during the place and route phase, I get the following
errors:

--------------------------------------------------------------------------------
Constraint                                | Requested  | Actual     |
Logic
|            |            | Levels
--------------------------------------------------------------------------------
* NET "bufgp_73/IBUFG" PERIOD = 20 ns HIGH  | 20.000ns   | 69440.000ns
| 2
50%                                       |            |            |

--------------------------------------------------------------------------------
* PERIOD analysis for net "dcm_module_0/dcm | 15.384ns   | 46398.083ns
| 7
_module_0/CLKFX_BUF" derived from  NET "b |            |            |

ufgp_73/IBUFG" PERIOD = 20 ns HIGH 50%    |            |            |

--------------------------------------------------------------------------------

Why is the IBUFG being delayed for 69440 ns?!?!?!  I also saw this
warning a little earlier in the PAR:

WARNING:CLK Net:sys_clk_BUFGP
may have excessive skew because 1 NON-CLK pins
failed to route using a CLK template.

Can anyone give me any insight as to why I cannot increase the clock
frequency and I get these errors?  When I use this same wiring scheme
and use a 1X multiplier (M=10/D=10) I can pass the PAR just fine with a
15 ns delay at that IBUFG.  What am I missing?


Article: 102398
Subject: Re: Virtex 5 announced and sampling
From: Jim Granville <no.spam@designtools.co.nz>
Date: Tue, 16 May 2006 09:38:49 +1200
Links: << >>  << T >>  << A >>
Peter Alfke wrote:

> Antti, remember how a LUT is really constructed.
> It contains 64 latches plus a 6-level 64-to-1 multiplexer, like a
> christmas tree.
> The data sheet just (for tutorial purposes) shows the final stage of
> this big multiplexer separately.
> If that bothers you, ignore it. But just do not believe that it costs
> more than the extra delay of any multiplexer level.
> There are 6 levels of multiplexing, nothing we can do about it.

ISTR that Altera define differing delay times, for their LUT inputs.
Will Xilinx define to that level of detail now, as well ?

-jg


Article: 102399
Subject: Re: Virtex 5 announced and sampling
From: "Antti Lukats" <antti@openchip.org>
Date: Mon, 15 May 2006 23:38:59 +0200
Links: << >>  << T >>  << A >>
"Jim Granville" <no.spam@designtools.co.nz> schrieb im Newsbeitrag 
news:4468f4b4@clear.net.nz...
> Peter Alfke wrote:
>
>> Antti, remember how a LUT is really constructed.
>> It contains 64 latches plus a 6-level 64-to-1 multiplexer, like a
>> christmas tree.
>> The data sheet just (for tutorial purposes) shows the final stage of
>> this big multiplexer separately.
>> If that bothers you, ignore it. But just do not believe that it costs
>> more than the extra delay of any multiplexer level.
>> There are 6 levels of multiplexing, nothing we can do about it.
>
> ISTR that Altera define differing delay times, for their LUT inputs.
> Will Xilinx define to that level of detail now, as well ?
>
> -jg
>
yes Altera uses different LUT delays for different inputs to achive better 
timing

Antti 





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