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
2017JanFebMarApr2017

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 41125

Article: 41125
Subject: Re: XPOWER accuracy?
From: Brendan Cullen <bcullen@xilinx.com>
Date: Thu, 21 Mar 2002 12:53:20 +0000
Links: << >>  << T >>  << A >>
Hi Theron,

> I have gotten numbers from XPOWER for current requirements.  Has anyone any
> experience as to what the accuracy of the estimates is?  In my case, the
> estimate is about 360mA for my design.  The vast majority of that is the
> 300mA quiescent current.  Is that a reliable number?  The chip is a
> spartan2e (2s50etq144-6).

I'm part of the XPower team and I was wondering if you could advise on what
version of XPower you are using.  The quiescent power for the 2s50e is indeed
200mA (as Patrick has indicated) - and the current (4.2i) and previous (4.1i)
versions of XPower do use that 200mA value.

Regards,

Brendan


Article: 41126
Subject: Re: Fixed Point Library
From: "Jun Jiang" <jacke_jiang@hotmail.com>
Date: Thu, 21 Mar 2002 13:30:00 -0000
Links: << >>  << T >>  << A >>
Fixed point Multiplier, Divider etc.
"Jay" <kayrock66@yahoo.com> wrote in message
news:d049f91b.0203201707.60c4cba4@posting.google.com...
> Huh? Isn't fixed point implicit in the HDL?  What operations are you
looking for?
>
> magz@citiz.net (Jacke) wrote in message
news:<4f071e35.0203191744.1bfd4668@posting.google.com>...
> > Hi,
> > Do you know where I can find the open source code of Fixed Point Math
Library?
> >
> > thanks, :-)



Article: 41127
Subject: Re: simulation issues
From: Ray Andraka <ray@andraka.com>
Date: Thu, 21 Mar 2002 13:50:39 GMT
Links: << >>  << T >>  << A >>
Post map simulation will catch any synthesis mistakes without the added
penalty of a timing simulation.  Once you become good at coding, synthesis
mistakes subtle enough to make it through place and route with out complaints
are very rare.  The Place and route tools also do a good job at not messing up
your logic (placement and timing are a different story).

Kelvin Hsu wrote:

> better to perform post-PAR simu in case the synthesizer make mistakes.
>
> --
> Best Regards,
> -----------------------------------------------------------------
> Xu Qijun
> Engineer
> OKI Techno Centre (S) Pte Ltd
> Tel: 770-7049 Fax: 779-1621
> Email: qijun@okigrp.com.sg
> "H.L" <alphaboran@yahoo.com> wrote in message
> news:a7cbc9$1d4f$1@ulysses.noc.ntua.gr...
> > Hello all,
> > I have already searched in google for past posts regarding post-PAR and
> > post-map simulation in modelsim but I still have a question. Post-map
> > simulation includes the block delays (worst case) for the design but not
> the
> > routing delays, so if the post-map simulation is OK and the timing
> analyzer
> > after PAR reports no timing errors is it necessary to simulate the
> post-PAR
> > simulation model?
> >
> > Greetings,
> > Harris
> >
> >


Article: 41128
Subject: Re: A petition for Synplify's new fature (FPGA synthesis tool)
From: "Paul Butler" <Paul.Butler@ni.com>
Date: Thu, 21 Mar 2002 07:59:18 -0600
Links: << >>  << T >>  << A >>
"David Bishop" <dbishop@vhdl.org> wrote:

> In VHDL, all you need to do is to set the output type to
> "std_ulogic_vector", which is unresolved (thus it really
> can't tristate).  That prevents this from happening in VHDL.


Std_ulogic can be 'Z'.  In my example below, the output has only one
driver - the FF.  I don't think a resolution function has anything to do
with the output.

As an experiment, I modified the code below to use std_ulogic and
std_ulogic_vector.  Synplify 7.0.3 doesn't seem to mind that the FF input
ldout is unresolved and has multiple drivers - I get no errors!  The RTL
view still indicates a tristate output.

For the example below, I think declaring "din" to be 7 downto 0 is the most
obvious way to remove the tristate output.

Paul Butler
Paul.Butler@ni.com


library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity tristate_test is
  port(
    clk : in std_logic;
    reset : in std_logic;

    muxsel : in unsigned(2 downto 0);
    din : in std_ulogic_vector(6 downto 0);

    dout : out std_ulogic
  );
end tristate_test;

architecture rtl of tristate_test is
  signal ldout : std_ulogic;
begin

  TristateMux:
  for i in din'range generate
    ldout <= din(i) when muxsel = i else 'Z';
  end generate;

  process(reset, clk)
  begin
    if reset='1' then
      dout <= '0';
    elsif rising_edge(clk) then
      dout <= ldout;
    end if;
  end process;

end rtl;




Article: 41129
Subject: Re: XPOWER accuracy? Commendations
From: Theron Hicks <hicksthe@egr.msu.edu>
Date: Thu, 21 Mar 2002 09:25:23 -0500
Links: << >>  << T >>  << A >>
I want to commend Brendan (and all the other Xilinx people who continuously
monitor this newsgroup).  While the version of Xpower I was using was not quite
up to date, Brendan _very_ quickly responded to my question with an response that
he was able to duplicate my response with the version of Xpower that I was using
and responded within minutes via phone that he was able to duplicate my results.
The correct quiescent current for this part is indeed 200 mA.  The newest
versions of Xpower give the appropriate response.

Thanks,
Theron

Brendan Cullen wrote:

> Hi Theron,
>
> > I have gotten numbers from XPOWER for current requirements.  Has anyone any
> > experience as to what the accuracy of the estimates is?  In my case, the
> > estimate is about 360mA for my design.  The vast majority of that is the
> > 300mA quiescent current.  Is that a reliable number?  The chip is a
> > spartan2e (2s50etq144-6).
>
> I'm part of the XPower team and I was wondering if you could advise on what
> version of XPower you are using.  The quiescent power for the 2s50e is indeed
> 200mA (as Patrick has indicated) - and the current (4.2i) and previous (4.1i)
> versions of XPower do use that 200mA value.
>
> Regards,
>
> Brendan


Article: 41130
Subject: Re: Possibility of RTL and Gate-level simulation dont match?
From: spam_hater_7@email.com (Spam Hater)
Date: Thu, 21 Mar 2002 15:13:07 GMT
Links: << >>  << T >>  << A >>

I see two problems here:

    "i am experienced HDL designer anyway"

No, you're not.  Sorry, but an experienced HDL designer has fought his
way through many pre-post synthesis mismatches.

    "I still don't know what problem the design was intended to solve"

This is also a serious problem.  If you don't know what it is to do,
how can you tell if it's doing it?

And as to your last question: "how can I detect fatal bugs in my code"
the answer is:  Knowledge, and experience.


On Thu, 21 Mar 2002 09:35:14 +0800, "Kelvin Hsu" <qijun@okigrp.com.sg>
wrote:

>sure it's possible since i need to match the result with a C program, while
>i tried best
>to match the C result, gate level simulation is not correct. One constraint
>is that after I
>finished RTL and everything, I still don't know what problem the design was
>intended to
>solve...faint!
>While RTL simulation and synthesis all pass, w/o major error or warning...i
>am experienced
>HDL designer anyway...prob is gate-level won't pass.
>I want to know how can I detect fatal bugs in my code, besides RTL simu and
>warning in ISE 4.1?
>
>
>
>
>
>"Jay" <kayrock66@yahoo.com> wrote in message
>news:d049f91b.0203201704.55c58ac8@posting.google.com...
>> How possible is it?  Well if you're a new HDL guy then it's very
>> possible, and if you're not, then its still possible.  You should be
>> able to run the same test bench on RTL or gates and have them both
>> pass.
>>
>> "Kelvin Hsu" <qijun@okigrp.com.sg> wrote in message
>news:<3c97f13b@news.starhub.net.sg>...
>> > Hi,
>> >
>> > I am using Spartan-II chip, I want to know how much possibility that
>> > the RTL and gate-level simulation don't match?
>> > When they don't match, how can I detect that? It seemed that the
>synthesis
>> > report in ISE 4.1 doesn't give me a warning or error?
>
>


Article: 41131
Subject: Re: 1,5V power supply?
From: "Ian Smith" <ian_smith@hotmail.com>
Date: Thu, 21 Mar 2002 15:17:11 -0000
Links: << >>  << T >>  << A >>
We have successfully used devices like the MAX1775 switcher. Take the layout
carefully from their datasheet.

Also be very careful that you have just the low-ESR capacitor from the PSU
datasheet and don't add the ones Xilinx recommend as well. The one device
should be enough for both. If you do this by mistake, it can make the PSU go
unstable. (If you don't believe me, put the parts on the layout and don't
fit them.)



Article: 41132
Subject: Maximum device usage for successful PAR
From: Stephanie McBader <mcbader@neuricam.com>
Date: Thu, 21 Mar 2002 17:01:53 +0100
Links: << >>  << T >>  << A >>
Hi,

I'm sorry if this issue's been brought up before, I've tried searching
for similar queries but to no avail.

I would like to know if there's a defined maximum device usage
percentage which guarantees successful Place and Route phases,
particularly for Virtex-E FPGAs. If so, what is it?

I would have thought that - ideally - a device should be able to use
100% of its resources, but we live in a world far from ideal, and PAR
software is probably incapable of matching such idealistic usage!

I use Foundation ISE 4.2 with the latest service pack, and have tried
both XST and FPGA Express for synthesising a design that came up to 93%
and 95% of a V600E, respectively. The Map process was successful, but
Placing failed even if I set it to try with highest effort...

Am I asking for too much? :)

Thanks!

Stephanie McBader
Researcher/Design Engineer
NeuriCam S.p.A


Article: 41133
Subject: Re: High speed clock routing
From: bobsrefusebin@hotmail.com (Bob Perlman)
Date: 21 Mar 2002 08:10:50 -0800
Links: << >>  << T >>  << A >>
Rick - 

rickman <spamgoeshere4@yahoo.com> wrote in message news:<3C9970F9.47305AEC@yahoo.com>...
> Bob Perlman wrote:
> > 
> > Rick -
> > 
> > rickman <spamgoeshere4@yahoo.com> wrote in message news:<3C98D60E.859D5A1A@yahoo.com>...
> > > Bob Perlman wrote:
> > > >
> > > > Rick -
> > > >
> > > > A few comments/observations:
> > > >
> > > > 1) If your board stackup is at all conventional, trace impedances will
> > > > fall somewhere in the range of 45 to 65 ohms.  You can, with effort,
> > > > get other impedances, but getting to 200 ohms will require tricks that
> > > > you won't want to play.
> > >
> > > I am not at all clear on how you can guestimate the trace impedance to
> > > be in such a narrow range.  I was under the impression that it varied
> > > directly with trace width.  I could be using trace widths anywhere from
> > > 4 mil to 10 mil.  Further, the board stackup depends entirely on layer
> > > count vs. power plane count.  What were you assuming for these?
> > 
> > I'm assuming that you're using a multi-layer board in which the height
> > of the trace off the nearest plane is roughly the same as the trace
> > width.  For a 5-mil trace, for example, you'd be 5 mils from the
> > nearest plane.  You can violate this rule and make the height greater,
> > thus increasing the impedance, but then crosstalk will bite you unless
> > your trace-to-trace spacings are wide.  And increasing the height of
> > the trace above the plane does not increase the impedance rapidly.
> > Here's a question that I ask students when I hold signal integrity
> > courses: Suppose I'm in the space shuttle and I have a length of #30
> > AWG wire, and there's an infinitely wide ground plane sitting on the
> > earth's surface 160 miles below.  What's the impedance?  Zillions of
> > ohms?  Any guesses?
> 
> I would not have a clue.  But I want to know how you plan to measure it
> and verify your answer!

It's about 1300 ohms.  I'll take the space shuttle flight if you'll
set up the ground plane (and remove it before the shuttle hits it).
 
> > I'm also assuming that traces are narrow enough to fit between the
> > vias for fine-pitch parts; this means they're not going to be
> > extremely wide.  These factors tend to put a bound on the practical
> > range of achievable trace impedances.
> 
> I don't know if that is a valid assumption.  We are not talking about a
> bus of many signals.  This is the clock route and it can be made any
> impedance or width I want.  There is also not much point in using
> extremely narrow traces since many of the finer pitch parts can not be
> rounted between the pins unless you go to unmanufacturable line/space
> widths.  
 
Fair enough.  Do the board, and let me know what impedances you end up
with.  One other observation: if for whatever reason you decide to
fatten out the traces to get lower-than-normal impedances (below 50
ohms), make sure you have a driver that can drive them.
 
> > > I think I can afford to be accomodating in the skew since my daisy
> > > chained route would be about 3 inches or ~500 ps.  However the longest
> > > single trace in a star configuration is only 1.4 inches or ~240 ps.  The
> > > driver spec gives a max of 2 ns (no min) for the rise time, so even if
> > > it is 1 ns, my round trip is half the rise time.  This is not ideal, but
> > > I think it will likley work without termination.
> > 
> > What happens when TI spins the die and the nominal risetime goes from
> > 1ns to 0.6ns?
> 
> If they respin the die, the max clock rate will go up and I will be
> reexamining the board for many reasons.  

If they respin the die, they may sell you the faster die in the
existing speed grade.  That ground bounce problem I mentioned in an
earlier message happened just that way.  The vendor revved the die,
used the new die on lower speed grades--it was cheaper to make, after
all--and what had been a perfectly acceptable clock signal was now
corrupted by ground bounce from faster neighbor signals.

And you don't even need a die spin.  What if you get a batch of
fast-corner parts for the existing die?  If you're making one or two
boards, no problem; you hunt around for parts that are slower.  But if
you're planning to manufacture a number of boards over the long term,
you could suddenly find yourself with a batch of boards that don't
work.
 
> > You can do surprisingly useful simulations with nothing more than the
> > student version of PSpice.  It's nowhere near as convenient as
> > Hyperlynx, but it's free (or at least it used to be).
> > 
> > Bob Perlman
> > Cambrian Design Works
> > http://www.cambriandesign.com
> 
> You can, but it takes a lot of time and effort to get the input data
> right.  I was willing to do some testing with Hyperlynx, but I think
> pSpice will be a rather large effort to ramp up on.  I think that a good
> book will help me more easily and quickly. 

Books are very useful; I particularly like Hall, Hall, and McCall.

Good luck with the board.

Bob Perlman
Cambrian Design Works
http://www.cambriandesign.com

Article: 41134
Subject: Re: High speed clock routing
From: rickman <spamgoeshere4@yahoo.com>
Date: Thu, 21 Mar 2002 11:26:54 -0500
Links: << >>  << T >>  << A >>
Bob Perlman wrote:
> 
> Rick -
> 
> rickman <spamgoeshere4@yahoo.com> wrote in message news:<3C9970F9.47305AEC@yahoo.com>...
> > Bob Perlman wrote:
> > >
> > > Rick -
> > >
> > > What happens when TI spins the die and the nominal risetime goes from
> > > 1ns to 0.6ns?
> >
> > If they respin the die, the max clock rate will go up and I will be
> > reexamining the board for many reasons.
> 
> If they respin the die, they may sell you the faster die in the
> existing speed grade.  That ground bounce problem I mentioned in an
> earlier message happened just that way.  The vendor revved the die,
> used the new die on lower speed grades--it was cheaper to make, after
> all--and what had been a perfectly acceptable clock signal was now
> corrupted by ground bounce from faster neighbor signals.

I understand that the die can get faster even with the slower spec'd
parts.  But we would replace our earlier design with a new design to
take advantage of the speed and would not be buying the slower speed
part (at least that is the most likely senario).  

When you say "ground bounce", that is not an issue that can be addressed
by terminators and such, is it?  I thought that ground bounce was purely
a matter of decoupling the power and ground planes.  


> And you don't even need a die spin.  What if you get a batch of
> fast-corner parts for the existing die?  If you're making one or two
> boards, no problem; you hunt around for parts that are slower.  But if
> you're planning to manufacture a number of boards over the long term,
> you could suddenly find yourself with a batch of boards that don't
> work.

If they really can get that fast.  Xilinx once provided info on
calculating min times from max specs and they essentially came up with a
multiplier that was something like 25% or so.  This included process,
temp and power variations, and I think even typical process improvements
over the life of a product.  So there is a lower bound.  But I expect
that they would not need to make the edge rates significantly faster, so
I am not sure you should even include process improvements.  

-- 

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: 41135
Subject: Re: RAM initialization
From: John_H <johnhandwork@mail.com>
Date: Thu, 21 Mar 2002 16:28:00 GMT
Links: << >>  << T >>  << A >>
The module fo type ram_1024_4 doesn't look like a standard Xilinx RAM
instantiation.  Where did that module come from?  If it's a module you (or
someone) put together as a wrapper for the RAM primitives, then the INT_xx
parameters need to be included or the attribute attached to the primitive in the
hierarchy.


Wolfgang Pieper wrote:

> Hi all,
>
> I would like to initialize my ramb4_S4 with the following expression:
>
> attribute INIT_00: string;
> attribute INIT_00 of INST_RAMB4_S4: label
> is"1F1E1D1C1B1A191817161514131211100F0E0D0C0B0A0980706050403020100";
>
> Syntesizing is passed without error/warning, but translating tells:
>
>     WARNING:NgdBuild:526 - On the RAMB4_S4 symbol
>         "inst_ramb4_s4/Mram_mem_inst_ramb_0", the following properties are
> undefined:
>         INIT_00, INIT_01, INIT_02, INIT_03, INIT_04, INIT_05, INIT_06,
> INIT_07,
>         INIT_08, INIT_09, INIT_0A, INIT_0B, INIT_0C, INIT_0D, INIT_0E,
> INIT_0F. A
>         default value of all zeroes will be used.
>
>     WARNING:NgdBuild:486 - Attribute "INIT_00" is not allowed on symbol
>         "inst_ramb4_s4" of type "ram_1024_4".  This attribute will be
> ignored.
>
> Is it right, that XST (the Syntsize-tool in Xilinx free ISE WebPack) ignores
> others than predefined attributes? Or what's wrong?
>
> Thank's a lot!


Article: 41136
Subject: Re: Difference between two mulplications?
From: John_H <johnhandwork@mail.com>
Date: Thu, 21 Mar 2002 16:32:04 GMT
Links: << >>  << T >>  << A >>
What are the dimensions of the elements you're working with?  Verilog doesn't
automatically sign-extend, so a result with beta_tmp>32 could produce bizarre
results in the second instance.


Kelvin Hsu wrote:

> What makes them different in ISE 4.1?
>
> Case A:
> assign beta_X_x = beta_tmp * x;
> assign beta_X_y = beta_tmp * y;
> assign meanpos_temp1 = {y, {5'h00}} + beta_X_x - beta_X_y;
>
> Case B:
> assign meanpos_temp1 = beta_tmp * x + (6'd32 - beta_tmp) * y;
>
> What did happen was that the gate level simulation of the two are different.
> Case A is same as RTL simulation, Case B differnet.
>
> Any comments?
>
> --
> Email: qijun@okigrp.com.sg


Article: 41137
Subject: synplify, quartus II 2.0
From: "kudla" <kudla@fuw.edu.pl>
Date: Thu, 21 Mar 2002 17:32:44 +0100
Links: << >>  << T >>  << A >>
My Synplify (Leonardo Spectrum OEM2002a_Altera_NIGHTLY_14) crashes soon
after start.
(License passes - that I can see before window disapears). I have w2k sp2
and Quartus II 2.0.
Does somebody know what I can do?
Maciek



Article: 41138
Subject: Re: spartan 2e, 5V i/o
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Thu, 21 Mar 2002 08:33:57 -0800
Links: << >>  << T >>  << A >>
Emanual,

If it is open collector, then you do need a pullup to 3.3 V.  The internal
pullup may not strong enough to meet your speed requirements.

I did not look up that particular part, I just used the generic 74ALS output
driver (is used a 74ALS04) to show that the pullup was to ~ 3.3 V when powered
from 5V (typical of a bipolar transistor ALS device).

Austin

emanuel stiebler wrote:

> Austin Lesea wrote:
> >
> > Emanual,
> >
> > Why do you need any pullup at all?
>
> the als641 is an open collector ?
> And, I remember reading sowething that I shouldn't use the internal
> pullups for that purpose. But I could be mixing up something. I have to
> read
> it again I guess ;-)
>
> > If the 74ALS powered from 5Vdc pulls to less than 3.3 Vdc for the high, so
> > no series resistor to/from the Spartan IIE is required (simulated the IBIS
> > models for the 74ALS outputs at 5Vdc driving high into a Spartan IIE).
>
> Great ! Save me a lot of troubles here ...
>
> > Sounds like the right IOB standard, and just connecting things up is the
> > right way to go.
> > Austin
>
> Cheers & thanks again.
>
> > emanuel stiebler wrote:
> >
> > > Hi,
> > >
> > > I hope a little problem.
> > > Trying to connect a 74als641 to a spartan 2e i/o pin.
> > > And, it is bidirectional ...
> > >
> > > My idea is something like:
> > >
> > > (74als641 OC) -- (4k7 pullup to 3.3V) -- (100 Ohm resistor in series) --
> > > (fpga pin)
> > >
> > > Does it work this way ? Any better ideas ?
> > >
> > > And if it is of any help, there are around 50-60 pins I have to use this
> > > way ...
> > >
> > > cheers & thanks in advance,
> > > emanuel


Article: 41139
Subject: Re: High speed clock routing
From: John_H <johnhandwork@mail.com>
Date: Thu, 21 Mar 2002 16:48:53 GMT
Links: << >>  << T >>  << A >>
Bob,

Isn't the upper limit of intrinsic impedance that of free space?  Squareroot of (absolute
permittivity divided by absolute permeability) is about 377 ohms, isn't it?  I thought one
couldn't get any higher than that.

Your insights into why 1300 ohms would be the better answer are much appreciated.

- John_H


Bob Perlman wrote:

> > > Here's a question that I ask students when I hold signal integrity
> > > courses: Suppose I'm in the space shuttle and I have a length of #30
> > > AWG wire, and there's an infinitely wide ground plane sitting on the
> > > earth's surface 160 miles below.  What's the impedance?  Zillions of
> > > ohms?  Any guesses?
> >
> > I would not have a clue.  But I want to know how you plan to measure it
> > and verify your answer!
>
> It's about 1300 ohms.  I'll take the space shuttle flight if you'll
> set up the ground plane (and remove it before the shuttle hits it).


Article: 41140
Subject: Re: Maximum device usage for successful PAR
From: Paul Glover <paul.glover@xilinx.com>
Date: Thu, 21 Mar 2002 10:03:50 -0700
Links: << >>  << T >>  << A >>
Why did PAR fail? It will not fail based upon utilization, unless it is 
greater than 100%. Did the timing constraints fail?

Paul

Stephanie McBader wrote:

>Hi,
>
>I'm sorry if this issue's been brought up before, I've tried searching
>for similar queries but to no avail.
>
>I would like to know if there's a defined maximum device usage
>percentage which guarantees successful Place and Route phases,
>particularly for Virtex-E FPGAs. If so, what is it?
>
>I would have thought that - ideally - a device should be able to use
>100% of its resources, but we live in a world far from ideal, and PAR
>software is probably incapable of matching such idealistic usage!
>
>I use Foundation ISE 4.2 with the latest service pack, and have tried
>both XST and FPGA Express for synthesising a design that came up to 93%
>and 95% of a V600E, respectively. The Map process was successful, but
>Placing failed even if I set it to try with highest effort...
>
>Am I asking for too much? :)
>
>Thanks!
>
>Stephanie McBader
>Researcher/Design Engineer
>NeuriCam S.p.A
>


Article: 41141
Subject: Re: High speed clock routing
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Thu, 21 Mar 2002 09:04:19 -0800
Links: << >>  << T >>  << A >>
John,

Nope.  You can make higher impedance guided wave structures that the impedance of free space.

The most common WWII transmission lines in an Army base field station was 600 ohm line, two
wires about 6" apart.

Much higher than that isn't very practical (spacing is too large, or wire diameter too small).

Basically, there are 'magic' impedances, like 75 ohm Cable TV coax, or 50 ohm coax for radio
systems, or 50 to 65 ohm pcb traces, or 300 ohm TV ladder line.  They are magic because 75
ohms uses the least amout of material, and has the least loss per mile (kilometer).  50 ohms
uses the least amount of material, and has the best power handling capacity.  50 to 65 ohms on
a pcb can be done with the usual spacings, thickness, and widths.   TV ladder line is the
lowest loss at 50 MHz to almost 1 GHz with the least cost for receiving only.

Oh, those 600 ohm ladder lines were neat because of their very low loss, very high power
handling capacity, and their ability to be fixed, built, patched, repaired with nothing more
than some copper wire and some wooden sticks.

So what comes first is the application (transmit, receive?), and the constraints (cost,
material, least copper, shielding, etc), and then you use Maxwell's Equations to find a
structure that meets all of your needs....or you just pick something from the catalog.

Austin

John_H wrote:

> Bob,
>
> Isn't the upper limit of intrinsic impedance that of free space?  Squareroot of (absolute
> permittivity divided by absolute permeability) is about 377 ohms, isn't it?  I thought one
> couldn't get any higher than that.
>
> Your insights into why 1300 ohms would be the better answer are much appreciated.
>
> - John_H
>
> Bob Perlman wrote:
>
> > > > Here's a question that I ask students when I hold signal integrity
> > > > courses: Suppose I'm in the space shuttle and I have a length of #30
> > > > AWG wire, and there's an infinitely wide ground plane sitting on the
> > > > earth's surface 160 miles below.  What's the impedance?  Zillions of
> > > > ohms?  Any guesses?
> > >
> > > I would not have a clue.  But I want to know how you plan to measure it
> > > and verify your answer!
> >
> > It's about 1300 ohms.  I'll take the space shuttle flight if you'll
> > set up the ground plane (and remove it before the shuttle hits it).


Article: 41142
Subject: Re: simulation issues
From: Paul Glover <paul.glover@xilinx.com>
Date: Thu, 21 Mar 2002 10:10:25 -0700
Links: << >>  << T >>  << A >>
Harris,

It depends. Did the timing constraints cover 100% of the design? If not, 
you will need to perform a post-PAR timing simulation to verify the 
entire design timing.

Paul


H.L wrote:

>Hello all,
>I have already searched in google for past posts regarding post-PAR and
>post-map simulation in modelsim but I still have a question. Post-map
>simulation includes the block delays (worst case) for the design but not the
>routing delays, so if the post-map simulation is OK and the timing analyzer
>after PAR reports no timing errors is it necessary to simulate the post-PAR
>simulation model?
>
>Greetings,
>Harris
>
>


Article: 41143
Subject: Re: High speed clock routing
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Thu, 21 Mar 2002 18:31:11 +0100
Links: << >>  << T >>  << A >>
"Bob Perlman" <bobsrefusebin@hotmail.com> schrieb im Newsbeitrag
news:c05c992c.0203210810.5bf073fd@posting.google.com...

> > > AWG wire, and there's an infinitely wide ground plane sitting on the
> > > earth's surface 160 miles below.  What's the impedance?  Zillions of
> > > ohms?  Any guesses?
> >
> > I would not have a clue.  But I want to know how you plan to measure it
> > and verify your answer!
>
> It's about 1300 ohms.  I'll take the space shuttle flight if you'll

Are you sure? Do the field models (where all fromulaes are based on) take
this dimensions into account? AFAIK, most formulaes only account for the
near fields of some inches, maybe feet (dam, why do I use this sick
dimensions and not centimeter ?? :-)

My guess of this space transmission line would have been 377 ohm, the wave
resistance of free space. But field theory was never a strong subject of
mine . . . ;-)

--
MfG
Falk





Article: 41144
Subject: Re: XPOWER accuracy?
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Thu, 21 Mar 2002 18:36:41 +0100
Links: << >>  << T >>  << A >>
"Brendan Cullen" <bcullen@xilinx.com> schrieb im Newsbeitrag
news:3C99D7C0.8391AF20@xilinx.com...
> Hi Theron,
> I'm part of the XPower team and I was wondering if you could advise on
what
> version of XPower you are using.  The quiescent power for the 2s50e is
indeed
> 200mA (as Patrick has indicated) - and the current (4.2i) and previous
(4.1i)

Damm, where does all this power go? All leakage? But the Exel-sheet for
Virtex/E use different numbers than the datasheets.
Is the Exel-sheet totally outdated?

--
MfG
Falk





Article: 41145
Subject: Re: Maximum device usage for successful PAR
From: John_H <johnhandwork@mail.com>
Date: Thu, 21 Mar 2002 17:45:11 GMT
Links: << >>  << T >>  << A >>
Paul, haven't you ever had routing fail?  Power and ground routing is just
one example of where a congested part can experience routing troubles.

Stephanie, I seem to racall graphs on P&R performance in marketing slides
that suggest 80% is pretty solid while 90% utilization starts to get ugly...
93-95% is tough.  Was it indeed the placing that failed or was it the
route?  If placement is indeed the problem, Paul's confusion with your
result is understandable.  Routing is what historically got me.  One thing
that isn't obvious to designers new to (highly utilized) Xilinx devices is
that the mapper allocates slices;  if your design uses 93% of the LUTs or
registers, it may use 120% of the slices because many registers don't pack
nicely together due to unusual resets or clock enables or other
signals/configurations that affect both registers of the slice.  The slice
utilization is the important number.


Paul Glover wrote:

> Why did PAR fail? It will not fail based upon utilization, unless it is
> greater than 100%. Did the timing constraints fail?
>
> Paul
>
> Stephanie McBader wrote:
>
> >Hi,
> >
> >I'm sorry if this issue's been brought up before, I've tried searching
> >for similar queries but to no avail.
> >
> >I would like to know if there's a defined maximum device usage
> >percentage which guarantees successful Place and Route phases,
> >particularly for Virtex-E FPGAs. If so, what is it?
> >
> >I would have thought that - ideally - a device should be able to use
> >100% of its resources, but we live in a world far from ideal, and PAR
> >software is probably incapable of matching such idealistic usage!
> >
> >I use Foundation ISE 4.2 with the latest service pack, and have tried
> >both XST and FPGA Express for synthesising a design that came up to 93%
> >and 95% of a V600E, respectively. The Map process was successful, but
> >Placing failed even if I set it to try with highest effort...
> >
> >Am I asking for too much? :)
> >
> >Thanks!
> >
> >Stephanie McBader
> >Researcher/Design Engineer
> >NeuriCam S.p.A
> >


Article: 41146
Subject: cpga : Converting PAL design
From: Tibor <tibi@mail.intruder.hu>
Date: Thu, 21 Mar 2002 09:46:40 -0800
Links: << >>  << T >>  << A >>
How can i convert PAl design equation, for 9572

best regards Tibor

Article: 41147
Subject: Re: High speed clock routing
From: John_H <johnhandwork@mail.com>
Date: Thu, 21 Mar 2002 17:52:24 GMT
Links: << >>  << T >>  << A >>
Thanks for the info, Austin - I'd forgotten a couple of the detail points and didn't know some
others.  If I had to guess to save my life, I would've said the upper limit for differential
transmission lines would be twice the intrinsic impedance of free space - about 753 ohms.  It's
great to know some of the background for the things we use today.


Austin Lesea wrote:

> John,
>
> Nope.  You can make higher impedance guided wave structures that the impedance of free space.
>
> The most common WWII transmission lines in an Army base field station was 600 ohm line, two
> wires about 6" apart.
>
> Much higher than that isn't very practical (spacing is too large, or wire diameter too small).
>
> Basically, there are 'magic' impedances, like 75 ohm Cable TV coax, or 50 ohm coax for radio
> systems, or 50 to 65 ohm pcb traces, or 300 ohm TV ladder line.  They are magic because 75
> ohms uses the least amout of material, and has the least loss per mile (kilometer).  50 ohms
> uses the least amount of material, and has the best power handling capacity.  50 to 65 ohms on
> a pcb can be done with the usual spacings, thickness, and widths.   TV ladder line is the
> lowest loss at 50 MHz to almost 1 GHz with the least cost for receiving only.
>
> Oh, those 600 ohm ladder lines were neat because of their very low loss, very high power
> handling capacity, and their ability to be fixed, built, patched, repaired with nothing more
> than some copper wire and some wooden sticks.
>
> So what comes first is the application (transmit, receive?), and the constraints (cost,
> material, least copper, shielding, etc), and then you use Maxwell's Equations to find a
> structure that meets all of your needs....or you just pick something from the catalog.
>
> Austin
>
> John_H wrote:
>
> > Bob,
> >
> > Isn't the upper limit of intrinsic impedance that of free space?  Squareroot of (absolute
> > permittivity divided by absolute permeability) is about 377 ohms, isn't it?  I thought one
> > couldn't get any higher than that.
> >
> > Your insights into why 1300 ohms would be the better answer are much appreciated.
> >
> > - John_H
> >
> > Bob Perlman wrote:
> >
> > > > > Here's a question that I ask students when I hold signal integrity
> > > > > courses: Suppose I'm in the space shuttle and I have a length of #30
> > > > > AWG wire, and there's an infinitely wide ground plane sitting on the
> > > > > earth's surface 160 miles below.  What's the impedance?  Zillions of
> > > > > ohms?  Any guesses?
> > > >
> > > > I would not have a clue.  But I want to know how you plan to measure it
> > > > and verify your answer!
> > >
> > > It's about 1300 ohms.  I'll take the space shuttle flight if you'll
> > > set up the ground plane (and remove it before the shuttle hits it).


Article: 41148
Subject: Re: XPOWER accuracy? Commendations
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Thu, 21 Mar 2002 09:59:36 -0800
Links: << >>  << T >>  << A >>
Thanks, Theron.
The original question was about XPOWER accuracy, especially in a situation where
leakage current dominates.
You can trust that the current and power values will not be exceeded, but I am sure
they are not "accurate". "Typically", the leakage current will be a small fraction,
less than 20% ofthe specified value.
Why?
1.
This is not the normal diode leakage current. It is called sub-threshold leakage
current, I call it cross-current through an inverter. In the olden days of >0.35
micron technology, any Low or High level inside the chip would completely cut off
either the n-channel or the p-channel transistor. That means there was no dc current
through the transistor pair, all current was used to charge and discharge
capacitors.
At <0.2 micron technology, this is no longer true. The off-transistor cannot be
completely shut off, and this creates the sub-threshold leakage current.
It may be only a few nA per transistor, but with millions of transistors, this adds
up.
2.
The IC designer can select a threshold voltage to trade off speed vs leakage
current. When the transistors are completely shut off, they take longer to turn on.
And in the marketing battle of the ns/MHz against the milliamps of leakage current,
speed requirements usually win.
3.
This is a "secondary" parameter that is sensitive to processing variations, Vcc and
temperature. So we characterize and measure it at well above the usual 85 degrees,
at max Vcc, and then we guardband the test value, so that we don't have to throw
away good parts because of slightly elevated leakage current.
And, although the current is inherently proportional to the "gate count", we do not
specify it exactly that way.
4.
As a conscientious designer, you must assume that the data sheet guarantees are
valid. But you should also know that this particular leakage-current parameter is
usually much lower than the guaranteed spec.

Peter Alfke
=================================
Theron Hicks wrote:

> I want to commend Brendan (and all the other Xilinx people who continuously
> monitor this newsgroup).  While the version of Xpower I was using was not quite
> up to date, Brendan _very_ quickly responded to my question with an response that
> he was able to duplicate my response with the version of Xpower that I was using
> and responded within minutes via phone that he was able to duplicate my results.
> The correct quiescent current for this part is indeed 200 mA.  The newest
> versions of Xpower give the appropriate response.
>
> Thanks,
> Theron
>
> Brendan Cullen wrote:
>
> > Hi Theron,
> >
> > > I have gotten numbers from XPOWER for current requirements.  Has anyone any
> > > experience as to what the accuracy of the estimates is?  In my case, the
> > > estimate is about 360mA for my design.  The vast majority of that is the
> > > 300mA quiescent current.  Is that a reliable number?  The chip is a
> > > spartan2e (2s50etq144-6).
> >
> > I'm part of the XPower team and I was wondering if you could advise on what
> > version of XPower you are using.  The quiescent power for the 2s50e is indeed
> > 200mA (as Patrick has indicated) - and the current (4.2i) and previous (4.1i)
> > versions of XPower do use that 200mA value.
> >
> > Regards,
> >
> > Brendan


Article: 41149
Subject: Re: low cost PCI spartan board needed
From: Eric Crabill <eric.crabill@xilinx.com>
Date: Thu, 21 Mar 2002 10:27:37 -0800
Links: << >>  << T >>  << A >>

In general, if you are implementing the PCI interface in the
FPGA, this is not an easy thing to do -- although it is possible
if:

1.  Your board design supports it 
2.  Your device driver supports it

If you want an example of someone doing this, you can check out
the VCC HOT-II board.  I think they allow you to load an external
configuration "storage" area through the PCI interface, and then
provide a mechanism for you to re-configure the FPGA with that
data.

However, the FPGA goes "dead" during the reconfiguration, because
it is a full-reconfiguration process.  I don't know how they handle
it, but I would imagine the device driver has to be aware of what
is going on, otherwise any access to the device would result in a
master abort.  Also, I would think there is some requirement that
you keep the PCI interface parameters the same (number and size
of BARs, device and vendor ID, etc...) the same between reconfigs
otherwise you will get the O/S very confused.

Eric

Jimmy Zhang wrote:
> 
> A question from a newbie,
> 
>  Can I program the FPGA via PCI interface thru device calls?
> 
> Jimmy
> Kevin Brace wrote in message ...
> >Who is "they" in this case?
> >You mean, Insight Electronics?
> >All the reference design's software is for Windows 9x/NT/2000.
> >Another thing I should add is that according to another person who was
> >interested in this board said Insight Electronics discontinued the
> >board.
> >Supposedly, they are going to release a new one at some point.
> >
> >
> >
> >Kevin Brace (In general, don't respond to me directly, and respond
> >within the newsgroup.)
> >
> >
> >
> >Jimmy Zhang wrote:
> >>
> >> Just curious if they have a Linux version of the driver or not?
> >>
> >> Jimmy



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
2017JanFebMarApr2017

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