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 95600

Article: 95600
Subject: Verilog tutorial by John Sanguinetti
From: "Eric Crabill" <eric.crabill@xilinx.com>
Date: Tue, 24 Jan 2006 10:41:42 -0800
Links: << >>  << T >>  << A >>
Hi,

I'm looking for a functional URL that hosts the Verilog tutorial by John
Sanguinetti.  Neither of these seem to work:

http://turing.une.edu.au/~comp283/cdrom/Content/Tutorials/Verilog/

http://vol.verilog.com/

I have tried contacting what appears to be the primary/official site
(vol.verilog.com) and have received no responses.

Is anyone aware of other URLs or how to get this tutorial hosted on one's
own site?

Thanks,
Eric





Article: 95601
Subject: Re: Verilog tutorial by John Sanguinetti
From: "Mahmoud" <mahmoud.kassem@gmail.com>
Date: 24 Jan 2006 11:17:23 -0800
Links: << >>  << T >>  << A >>
I do not see what's the problem with these sites?
Both works here.. Although vol.verilog.com requires registration.

Eric Crabill wrote:
> Hi,
>
> I'm looking for a functional URL that hosts the Verilog tutorial by John
> Sanguinetti.  Neither of these seem to work:
>
> http://turing.une.edu.au/~comp283/cdrom/Content/Tutorials/Verilog/
>
> http://vol.verilog.com/
>
> I have tried contacting what appears to be the primary/official site
> (vol.verilog.com) and have received no responses.
>
> Is anyone aware of other URLs or how to get this tutorial hosted on one's
> own site?
> 
> Thanks,
> Eric


Article: 95602
Subject: Re: Verilog tutorial by John Sanguinetti
From: "John_H" <johnhandwork@mail.com>
Date: Tue, 24 Jan 2006 19:25:52 GMT
Links: << >>  << T >>  << A >>
"Eric Crabill" <eric.crabill@xilinx.com> wrote in message 
news:dr5sd6$ng22@cliff.xsj.xilinx.com...
> Hi,
>
> I'm looking for a functional URL that hosts the Verilog tutorial by John
> Sanguinetti.  Neither of these seem to work:

<snip>

It may just be your network that's having troubles.  Access to your 
company's web pages from outside is a bit dodgey right now. 



Article: 95603
Subject: Re: Xilinx padding LC numbers, how do you really feel about it?
From: fpga_toys@yahoo.com
Date: 24 Jan 2006 11:30:51 -0800
Links: << >>  << T >>  << A >>

John_H wrote:
> For anyone using a PCI add-in FPGA, the FPGA still needs to be configured.
> If they're using Xilinx P&R tools, they're responsible for substantial
> engineering aspects of the design.

Since there is no other P&R for current xilinx parts, this is a given,
not a conditional.

> The board manufacturer should have
> specific published design limits for the board.

I'm not aware of, or have used one, that does. The norm is to ship you
a board with some vendors FPGA on it, provide some minimal
documentation for the board, and a pointer to the fpga's data sheets
and that's it ... other than that the sales dept may wish you good luck
too. This is true to PCI RC boards, student boards, and proto boards
from all sources.

> Armed with the
> junction-to-ambiant thermal resistance of the realized design and the
> engineering tools provided with the Xilinx toolset, proper engineering
> analysis can be done.

You must be a far better engineer than most if armed with the data
sheets, user manual, and this magical "Xilinx toolset" do a proper
engineering analysis. I'm amazed, dumb founded.

Interesting how you might do it ... I've yet to figure out a way to
determine peak ground path current for a specific device/package to get
a clue about die observed vccint and ground ripple voltages. No where
do I see a V4 spec for max ground currents, or even vccint currents for
that matter, in order to make sure the die sees the spec'd min 1.14v
between vccint and gnd on die after the drops on the carrier/package.
The V4 users guide discussion is VERY general about max I/O switching
per bank, nothing about peak currents, but does allows us to sum up the
estimated ground currents for the I/O's. Peaks for I/O's are probably
several times that.  But I would love to know where you found the peak
current for clb/ff/bram switching currents following a clock. I'd also
like to see where you found the voltage drop between the balls and the
die for this aggregate (IO + VccInt) current for both the vccint and
gnd paths in terms of both resistance and the via inductance of the
chip carrier from balls to die.

Last time I went into power estimator for xc4vlx200 and put in 200mhz
25% toggle for luts/ff's for 97% of the device, there was not a viable
thermal solution where the die remained within spec at 125C. The
extimated power with very modest I/O was well about 40W generating
ground currents that would most likely peak currents well above 120A at
clock edges. I suspect the part will not work even derated this much,
much less at a clock rate that would be expect or a higher utilization
than 25%.  Admittedly that was a long time ago, maybe it's better
today.

So, since you are cluefull about all this, what are the numbers?  Is it
really necessary to derate the device better than 50% in rated clock
performance just to get these over thermal worst case numbers? Can the
large FF packages handle a better than 100A peak current at clocks
without leaving the device unstable? What is the die ripple at these
values?

For that matter, none of the board vendors disclose what their gnd/pwr
plane to ball resistance and inductance is either, so the end user is
double stuck ... no detailed board data, no detailed fpga vendor data,
to do a "proper engineering job" to figure out just how much the board
needs to be derated and not violate power limits.

These are the easy questions :(

So, where did you find any RC vendor that managed to do their own P&R?

> If the RC is provided through alternative tools, those tools should be able
> to deal with the design limits of the device; in this case the person
> reconfiguring the PCI add-in board certainly won't be able to draw useful
> information from the data sheet and may not know which data sheet values
> even apply to them.  They're dealing with the board, not the part.  The
> board data is what guides them.


Article: 95604
Subject: Re: OT:Shooting Ourselves in the Foot
From: Chris Hills <chris@phaedsys.org>
Date: Tue, 24 Jan 2006 19:39:32 +0000
Links: << >>  << T >>  << A >>
In article <F8fBf.15030$Jd.5425@newssvr25.news.prodigy.net>, Joerg
<notthisjoergsch@removethispacbell.net> writes
>Hello Chris,
>
>Laws, regulations, more laws. One trait of engineers is or at least 
>should be that they know where their limits are. Not because they are 
>told by bureaucrats

You keep going on about bureaucrats setting the rules and every reply
has told you that the rules are set by qualified and experienced
ENGINEERS. 

You seem to have a problem of being judged by your peers.
-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/




Article: 95605
Subject: Re: Xilinx package/PDS
From: Austin Lesea <austin@xilinx.com>
Date: Tue, 24 Jan 2006 12:01:20 -0800
Links: << >>  << T >>  << A >>
toys,

A comment about modeling the FPGA and package:

Look up Howard Johnson's presentations.  Ball/pad inductance is useless 
(last year's solution).  I am surprised you bring it up.  HJ proves that 
it is the loops and their topology that matter.  And without a 3D field 
solver, you have no hope of learning anything at all.

Except if you use our FPGAs:  we do the hard stuff so you don't have to 
(e.g ParseChevron (tm), patents pending).

The number of planes, and bumps/balls for Vcc's and ground ensure that 
the voltage drops are kept within the required limits, even for your 40 
watt design.  It is up to you to design the PDS for your board, and we 
have applications notes to help you in that regard.

Comments we have received include folks who now tell us that the 
SparseChevron packages(tm) are superior to IBM's "cross" design.

I'm happy to just be in the same league.

http://www.xilinx.com/products/silicon_solutions/fpgas/virtex/virtex4/advantages/sipi.htm

http://www.xilinx.com/bvdocs/appnotes/xapp623.pdf

Austin

Article: 95606
Subject: Re: Xilinx package/PDS
From: Austin Lesea <austin@xilinx.com>
Date: Tue, 24 Jan 2006 12:02:07 -0800
Links: << >>  << T >>  << A >>
Oops,

SparseChevron(tm).

Austin

Austin Lesea wrote:

> toys,
> 
> A comment about modeling the FPGA and package:
> 
> Look up Howard Johnson's presentations.  Ball/pad inductance is useless 
> (last year's solution).  I am surprised you bring it up.  HJ proves that 
> it is the loops and their topology that matter.  And without a 3D field 
> solver, you have no hope of learning anything at all.
> 
> Except if you use our FPGAs:  we do the hard stuff so you don't have to 
> (e.g ParseChevron (tm), patents pending).
> 
> The number of planes, and bumps/balls for Vcc's and ground ensure that 
> the voltage drops are kept within the required limits, even for your 40 
> watt design.  It is up to you to design the PDS for your board, and we 
> have applications notes to help you in that regard.
> 
> Comments we have received include folks who now tell us that the 
> SparseChevron packages(tm) are superior to IBM's "cross" design.
> 
> I'm happy to just be in the same league.
> 
> http://www.xilinx.com/products/silicon_solutions/fpgas/virtex/virtex4/advantages/sipi.htm 
> 
> 
> http://www.xilinx.com/bvdocs/appnotes/xapp623.pdf
> 
> Austin

Article: 95607
Subject: Re: Xilinx padding LC numbers, how do you really feel about it?
From: Ray Andraka <ray@andraka.com>
Date: Tue, 24 Jan 2006 15:03:49 -0500
Links: << >>  << T >>  << A >>
fpga_toys@yahoo.com wrote:

> 
> :) for traditional state machine & data path designs sure, old accepted
> numbers everyone uses as a rule of thumb. For packed hand crafted RC
> application accelerators I think it's a lot worse than 15%, as my not
> so hand crafted demos have easily done better.
> 
> 
> 
> An RC5 pipelined cracking demo I did last year easily got the
> XCV2000E's on the Dini board HOT quickly. Even after adding heat sinks
> with forced air they were HOT. I was only using a little over half the
> device for the demo. Similar experience with XC2V6000's. That's not
> "some cases" from my view, and we have a very different view of
> "typical" for RC uses. I haven't gotten my hands on XC4VLX200's yet,
> but static analysis suggest similar problems.
> 
> And yes, I've since cooked a couple XCV800's, so I have the sense now
> to check FPGA's when testing a new application or demo. When RC cards
> do not even have the temp diode monitor IC connected to the FPGA, it's
> difficult for an RC programmer even to be able and check the chip temp
> when it's stuffed in a box, and automatically shut the app down or
> throttle back the clocks.
> 
> So that brings us back to "typically" and "worst case" for acceptable
> design standards for RC boards. Allowing the end user to easily toast
> $10K boards, and returning them to mfgr as warranty replairs, isn't
> good design practice. Nor does such poor reliability reflect well on
> the supplier chain for the devices, or the industry in general.
> 

Numeric apps will not exceed about 15% by the nature of the number 
system, unless you are alternating positive and negative numbers on 
alternate clock cycles.  It isn't so much a function of the design, it 
is a function of the properties of the number system.

Yes, I know you can make a part hot with an average design, been there 
done that many times.  However, that was not what I was arguing. I was 
refuting your claim of near 100% utilization with near 100% toggle 
rates. I think if you evaluate the average toggle rates in your designs, 
you aren't going to find them to be much above 15% unless for some 
reason you are alternating the sign on alternate cycles.  If that is the 
case, you can substantially reduce your power consumption by moving to a 
sign-magnitude number representation instead of 2's complement. It is 
pretty easy to come up with a design that will abuse the part by 
toggling every flip-flop and SRL16 at 100% with a clock near the upper 
limit.  What does that prove?  Well, about all it proves is that you can 
exceed the design limits of the system your FPGA is installed in if the 
FPGA has not been adequately cooled for that abuse.

As to getting the FPGA too hot for the installation, that is not the 
fault of the FPGA, rather it is a fault of the board design.  If the 
board is designed for general purpose use, either the power supply 
should (virtually all FPGA boards now have on-board power supplies) 
should current limit at some value less than where the FPGA or board are 
physically damaged, or the design should make use of the temperature 
diodes.  These are provided for exactly that purpose.  BTW, limiting 
power supply output is a very effective way of limiting the power 
dissipation of the FPGAs.  The current limits are going to depend on how 
well the FPGA is cooled, so it is going to vary application to application.

As for predicting the FPGA dissipation, that is difficult enough to do 
when the design is completely known, placed and routed, especially for 
designs the process data sourced off the FPGA, as the power dissipation 
is very much data pattern dependent.  Xilinx provides tools for 
estimating power, which do about as good a job as they can given the 
constraints.  For the spreadsheet, you the designer is responsible for 
estimating toggle rates, routing complexity, and part utilization.  It 
is meant as a planning tool, although you can also back your completed 
design into it.  Since it has no knowledge of the routing or your actual 
data, or for that matter the actual circuit, it is just an estimate.  I 
find that it tends to be on the conservative side, especially with 
floorplanned designs, but as far as getting an actual number figure 
+/-12dB.  The XPower tool uses the actual netlist and simulation 
vectors, and will give you very accurate worst case power....for the 
test vectors given.  If the actual use doesn't match the test vectors 
exactly, the power will be different.  That makes even the awkward to 
use Xpower tool of only marginal usefulness in designs that process data 
from outside the FPGA, simply because you can't accurately model all the 
possible data sets (if you could, you could replace the FPGA with a ROM).

So my point is, the FPGA vendors give you the information they can about 
power dissipation.  They can't know your design to provide you better 
numbers without you actually simulating the post PAR design with vectors 
that accurately reflect the actual usage.  For a general purpose board, 
the board designer can limit the FPGA dissipation to whatever is safe 
for the board cooling environment by using thermal diodes or power 
supply current limits to avoid damage to the FPGA or board, and he can 
do that without knowing anything about your design.  Isn't that a better 
tree to bark up?

Article: 95608
Subject: Re: Xilinx padding LC numbers, how do you really feel about it?
From: fpga_toys@yahoo.com
Date: 24 Jan 2006 12:24:21 -0800
Links: << >>  << T >>  << A >>

Ray Andraka wrote:
> So my point is, the FPGA vendors give you the information they can about
> power dissipation.  They can't know your design to provide you better
> numbers without you actually simulating the post PAR design with vectors
> that accurately reflect the actual usage.  For a general purpose board,
> the board designer can limit the FPGA dissipation to whatever is safe
> for the board cooling environment by using thermal diodes or power
> supply current limits to avoid damage to the FPGA or board, and he can
> do that without knowing anything about your design.  Isn't that a better
> tree to bark up?

So, my point is, and nobody seems to disagree, that it's unrealistic to
assume that the devices can be 100% packed, use the marketing numbers
for system design clock speeds, at a modest toggle rate, and not blow
right thru the power the device can handle. Disagree?

If not, then the device HAS TO BE DERATED from marketing numbers for RC
use. Disagree?


Article: 95609
Subject: Re: OT:Shooting Ourselves in the Foot
From: Dave Hansen <iddw@hotmail.com>
Date: Tue, 24 Jan 2006 14:40:42 -0600
Links: << >>  << T >>  << A >>
On Tue, 24 Jan 2006 19:39:32 +0000 in comp.arch.embedded, Chris Hills
<chris@phaedsys.org> wrote:

>In article <F8fBf.15030$Jd.5425@newssvr25.news.prodigy.net>, Joerg
><notthisjoergsch@removethispacbell.net> writes
>>Hello Chris,
>>
>>Laws, regulations, more laws. One trait of engineers is or at least 
>>should be that they know where their limits are. Not because they are 
>>told by bureaucrats
>
>You keep going on about bureaucrats setting the rules and every reply
>has told you that the rules are set by qualified and experienced
>ENGINEERS. 
>
>You seem to have a problem of being judged by your peers.

That's not the impression I got at all.  

My impression is that Joerg has determined that the costs of
registration (not all of which are monetary, and which he's tried to
describe, but some people aren't listening) are too high for the
benefits obtained.

It also seems you feel his rejection of registration has somehow gored
your ox.  As you often point out yourself, this is an international
forum, and things aren't the same everywhere.

Regards,
                                        -=Dave

-- 
Change is inevitable, progress is not.

Article: 95610
Subject: Re: Xilinx package/PDS
From: fpga_toys@yahoo.com
Date: 24 Jan 2006 12:40:49 -0800
Links: << >>  << T >>  << A >>

Austin Lesea wrote:
> Look up Howard Johnson's presentations.  Ball/pad inductance is useless
> (last year's solution).  I am surprised you bring it up.  HJ proves that
> it is the loops and their topology that matter.  And without a 3D field
> solver, you have no hope of learning anything at all.

I've watched his presentation ... and it explained the horrible
problems I had
with Virtex and Virtex-II packages when pushing the power envelope.

> The number of planes, and bumps/balls for Vcc's and ground ensure that
> the voltage drops are kept within the required limits, even for your 40
> watt design.  It is up to you to design the PDS for your board, and we
> have applications notes to help you in that regard.

The point of the 40w design, is that it's derated. Doubling, or better,
the clock rate to get best possible device performance per P&R timings
with a netlist that is busier than 25% and you quickly hit the power
limits of even an active cooler. The data sheets imply clock rates that
would easily produce designs well over a 100w in this package ... and
that is where I start to seriously worry about the cross section of
copper/lead in the package.

Worry, is because none of the data is specified to know where the
limits are ... IE max currents for gnd and each power group, and what
those current profiles look like in rise times.

That provokes the question of is derating necessary, if so how much,
and can we easily get numbers to calculate that?  not currently.

John


Article: 95611
Subject: Re: OT:Shooting Ourselves in the Foot
From: Joerg <notthisjoergsch@removethispacbell.net>
Date: Tue, 24 Jan 2006 20:42:53 GMT
Links: << >>  << T >>  << A >>
Hello Chris,

>>
>>Laws, regulations, more laws. One trait of engineers is or at least 
>>should be that they know where their limits are. Not because they are 
>>told by bureaucrats
> 
> You keep going on about bureaucrats setting the rules and every reply
> has told you that the rules are set by qualified and experienced
> ENGINEERS. 
> 

Huh? Maybe in the UK, not so much here.


> You seem to have a problem of being judged by your peers.


I don't. I do have a problem with overly restrictive regulations and so 
does our industry.

Regards, Joerg

http://www.analogconsultants.com

Article: 95612
Subject: undefined reference to `xilkernel_main'
From: "david" <akhammad@yahoo.com>
Date: Tue, 24 Jan 2006 14:43:46 -0600
Links: << >>  << T >>  << A >>
I am usig xilkernel on microblaze spartan 3 board. I am getting an unusual
error that is

undefined reference to `xilkernel_main'

when i write the code below

int main (void) {
   print("-- Entering main() --\r\n");
   xilkernel_main();
   print("-- Exiting main() --\r\n");
   return 0;
}

Any idea what is wrong. I did configure input and output port (as RS232),
i am using timer1 as the sytem timer for xilkernel. I have statically
linked only two task using "software Platform Setting" in
'static_pthread_table' entry. There is no resource on this subject on
xilinx website. Please help.

David



Article: 95613
Subject: Re: Xilinx padding LC numbers, how do you really feel about it?
From: Ray Andraka <ray@andraka.com>
Date: Tue, 24 Jan 2006 15:55:34 -0500
Links: << >>  << T >>  << A >>
fpga_toys@yahoo.com wrote:

> Ray Andraka wrote:
> 
>>So my point is, the FPGA vendors give you the information they can about
>>power dissipation.  They can't know your design to provide you better
>>numbers without you actually simulating the post PAR design with vectors
>>that accurately reflect the actual usage.  For a general purpose board,
>>the board designer can limit the FPGA dissipation to whatever is safe
>>for the board cooling environment by using thermal diodes or power
>>supply current limits to avoid damage to the FPGA or board, and he can
>>do that without knowing anything about your design.  Isn't that a better
>>tree to bark up?
> 
> 
> So, my point is, and nobody seems to disagree, that it's unrealistic to
> assume that the devices can be 100% packed, use the marketing numbers
> for system design clock speeds, at a modest toggle rate, and not blow
> right thru the power the device can handle. Disagree?
> 
> If not, then the device HAS TO BE DERATED from marketing numbers for RC
> use. Disagree?
> 

Umm yes, I disagree.  I've got several designs that are 90%+ packed and 
are being clocked at clock rates well beyond typical design clock rates. 
  Many of these have active cooling, but it is certainly possible to 
fill up and use a device.

You won't get the density and performance without handcrafting to meet 
both the density and performance limits.  The typical user is going to 
run into place and route issues before he even gets close to the high 
density, high clock rate corner.  I don't care if it is an RC 
application or not, you just don't get into that corner unless you do a 
considerable amount of handcrafting on the design.  BTW, the 
handcrafting also helps tremendously with power, as a significant 
percentage of the power is dissipated in the routing rather than in the 
logic.  If you keep the routing short and the design is maximally 
pipelined (stops lgitch propagation), the power dissipated by the 
routing can be kept relatively small.  you can look at the designs on my 
gallery page for some older examples of designs that are dense and 
running near the limits of clock rate.  My point is, you'll probably 
need to derate for shortcomings of an RTL synthesis tool flow before 
derating for a full device, and as for derating for a full device the 
power dissipation is so dependent on the design and PAR solution that 
there is no way to accurately predict it.

Worst case numbers are totally meaningless in this scenario as well. 
You could generate a design that purposely toggles every ff and 
intentionally congests the routing by forcing poor placement, and have 
something that could easily melt the balls right off. With proper 
cooling and attention to I/O switching, you have a shot at making it 
actually work in silicon.  So where do you set the max based on circuit 
configuration?  The answer is you can't.  Instead, the best one can do 
is give the thermal characteristics of the package/die combo, maximum 
die temperature and provide the tools to allow someone to simulate this 
if they are concerned about it (like I said, the simulation is also 
meaningless unless it accurately models the data in the operational 
deisgn).  If you are using the spread sheet estimator, you may be 
setting it up wrong to get meaningful answers.  The routing complexity 
knobs have a lot of influence over the result, and are difficult to set 
in a meaningful way.  For a floorplanned design, setting those to low 
complexity often still gets power estimates that are 2-4x higher than 
what is measured on the board.  For a design with poor placement, and 
multiple levels of logic, I've seen the estimator come in with much less 
margin.  Again, for data designs, you will rarely see greater than a 15% 
average toggle rate, and as I said, that is a function of the number 
system more than of the design itself.  Anything much above that can be 
considered high toggle rates, not modest toggle rates as you propose.

A reminder too, it doesn't take many watts to make a chip without a 
heatsink feel hot to the touch.  5 watts is enough to burn your finger 
if the heat isn't dissipated.  The same chip can handle 30 watts or more 
with a decent heatsink without excessive effort spent on cooling.  The 
fact you burnt your fingers on an FPGA without a heatsink tells you very 
little about how close you were to the design corners for the FPGA, nor 
does the fact a device with a heatsink got warm to the touch.  All it 
tells you is that in the first case, you probably didn't have adequate 
cooling for the design, and in the second case not even that (a chip 
cooled to 105F will feel warm to the touch, even though the silicon will 
run at nearly double that (85C) without any derating).


Article: 95614
Subject: Re: Verilog tutorial by John Sanguinetti
From: "Stephen Craven" <scraven@vt.edu>
Date: 24 Jan 2006 13:13:47 -0800
Links: << >>  << T >>  << A >>
Access to Xilinx's web site always seems to be slow... and I've lost
count of the # of times I get the "We apologize...
A technical problem has interrupted your session. We apologize for the
inconvenience this has caused you."

I guess that's why you're a hardware company and not a software one :)
Stephen


Article: 95615
Subject: Re: Creating Multiple Configuration PROM File
From: Jim Granville <no.spam@designtools.co.nz>
Date: Wed, 25 Jan 2006 10:28:01 +1300
Links: << >>  << T >>  << A >>
Antti Lukats wrote:
> "Jim Granville" <no.spam@designtools.co.nz> schrieb im Newsbeitrag 
> news:43d60cb2$1@clear.net.nz...
> 
>>Antti Lukats wrote:
>>
>><snip>
>>
>>>You right Peter,
>>>
>>>I am not fair. The life isnt either.
>>>
>>>But I am not making anything up. This is something I do not do. (Sure I 
>>>am wrong sometimes, that has happened).
>>>
>>>1) All my latest WebCase's are handled from China or at least from people 
>>>with chinese names.
>>>2) someone else (I assume from US) reported the same for his 3 last 
>>>WebCases, he also called and reached answer machine in chinese.
>>>
>>>So thats why I assumed that the _global_ WebCase support has been moved 
>>>to China/chinese. What I said was/is true for me as to my best knowledge 
>>>of the time of my writing.
>>
>><snip>
>>
>> That's quite a large leap, Antti, from 'Chinese name' to 'Must live in 
>>China' - did you check the email time tags, that often gives a clue to the 
>>time zones you are working between ?
>> China <-> EU is not the most natural choice ?
>>
>>-jg
>>
> 
> 
> maybe I mis-judged. I havent checked the email header time tags. Some else 
> (also having Xilinx issues) was complaining about the answer machine on his 
> WebCase contact to respond in chinese, so I checked the names from emails 
> and found his assumptions about the WebCases now being handled by people 
> with chinese like names to be true.
> 
> Maybe I am too hard at (Xilinx WebCase support) as my issues are usually not 
> such that the WebCase assigned person has any chances to help. He always 
> needs to contact others and that makes it really long to get some meaningful 
> response. 

..and I am sure your web cases send a shudder down any novice support 
person.. :)


So I do not really have hopes that a WebCase helps if it is not
> 'accelerated' but then ah, it makes possible more sense to immediate 
> 'accelerate' the issue, and that is something that Xilinx doesnt like of 
> course. But if immediate acceleration of an issue brings the solution even a 
> few hours faster then it is a few hours won.
> 
> I am pretty sure that there are people at Xilinx who are thinking very 
> seriously how to actually improve the software, support and services so lets 
> hope it will get better. There is lots of space for improvements, in all 
> areas.

  I think your WEB Bug list is a good idea - Yes, we can understand
ISE 8.1i is new SW, and yes there will be issues, but the backward-steps
are the real 'eyebrow raisers'.

  Seems they suffer the big-company disease, and become too marketing
dominated ( and worse, start to believe their own PR spin... )

- so nice public examples of user base problems are things the engineers 
left within Xilinx can use as leverage to get more resources to do the 
job properly, are a good thing.

-jg



Article: 95616
Subject: Re: OT:Shooting Ourselves in the Foot
From: "Bo" <bo@cephus.com>
Date: Tue, 24 Jan 2006 15:43:06 -0600
Links: << >>  << T >>  << A >>

"Joerg" <notthisjoergsch@removethispacbell.net> wrote in message 
news:ykuBf.2827$2O6.1794@newssvr12.news.prodigy.com...
> Hello Bo,
>
>
>>>I just re-checked the application form here in CA. It looks like it's up 
>>>to four refs now and says "These individuals must be licensed as 
>>>professional engineers in the discipline for which you are applying". 
>>>That would rule out my CE friends. Also, it says you must have been 
>>>"engaged" with them, meaning a work relationship. Well, I never designed 
>>>any bridges for them ;-)
>>>
>>>That would make it all toast I guess. I never worked with any PEs, just 
>>>with one EIT.
>>
>> That sucks. The rules do vary from state to state a little. I guess Ca is 
>> more anal than most (?)
>>
>
> Well, as Ray said it may be best to talk to them. Last time I did they 
> wouldn't budge. Which makes the whole program kind of irrelevant because 
> they'll never reach critical mass.
>
>
>> Perhaps you could take the exam in a neighboring state instead? AZ/NV?
>>
>
> That won't help when you live in CA. The real paradox is that if you have 
> the certs in one state it still doesn't allow you to work under it in 
> another. So theoretically you'd need 51 registrations (with fees...) to be 
> able to work countrywide under PE. Makes no sense to me at all.
>
Not necessarily. Most states PE board have 'commity' licensure--ie 
recognition of PE from another state and will allow you to hang a shingle in 
their state if you pay the fees etc to have the license transferred--or 
maybe better stated "reissued in the commity state". A coworker of mine is 
PE in 3 states and only took exams in one.  (ie NC, GA, AL).

Bo



Article: 95617
Subject: Re: Xilinx padding LC numbers, how do you really feel about it?
From: Jim Granville <no.spam@designtools.co.nz>
Date: Wed, 25 Jan 2006 10:51:31 +1300
Links: << >>  << T >>  << A >>
fpga_toys@yahoo.com wrote:

> Ray Andraka wrote:
> 
>>So my point is, the FPGA vendors give you the information they can about
>>power dissipation.  They can't know your design to provide you better
>>numbers without you actually simulating the post PAR design with vectors
>>that accurately reflect the actual usage.  For a general purpose board,
>>the board designer can limit the FPGA dissipation to whatever is safe
>>for the board cooling environment by using thermal diodes or power
>>supply current limits to avoid damage to the FPGA or board, and he can
>>do that without knowing anything about your design.  Isn't that a better
>>tree to bark up?

Yes, it is better to train designers to check thermal levels - after 
all, everyones car has a temperature guage, so even the real HW novice
can relate to that !

There could be a case for multiple thermal diodes, in a FPGA die, to
avoid missing a hot area - or some way to 'route relative' to the
sense diode ? :)
Does anyone do that now ?


> So, my point is, and nobody seems to disagree, that it's unrealistic to
> assume that the devices can be 100% packed, use the marketing numbers
> for system design clock speeds, at a modest toggle rate, and not blow
> right thru the power the device can handle. Disagree?

That's correct. But apart from the thermal measurement, about all
you could do is something like a transistor SOAR ( Safe Operating ARea ) 
polygon, - and that will have some many caveats, it might confuse more
than it helps.

I would push for thermal verify - if you are doing RC designs, then
simply demand a PCB that HAS thermal management!


> If not, then the device HAS TO BE DERATED from marketing numbers for RC
> use. Disagree?

Not entirely - so long as a usable portion of the fabric runs at
Fmax, then that is a valid number.

The bottom line is thermal: so why not just focus on that ? - more 
accurate than any predictive clock usage based modeling, which will
be far more 'cockpit error' prone.

I also like the idea of Freq tracking cells, that use ring oscillators
to give Vcc/Temp/Process auto-correcting values, and allow you to
clock _really_ at the safe-limits, but I have not seen that deployed yet.

Do this, and the leading RC boards would quickly become VERY thermally
efficent, as that gives the best performance.

-jg



Article: 95618
Subject: Re: Newbie: xilinx vs arm
From: "motty" <mottoblatto@yahoo.com>
Date: 24 Jan 2006 13:58:39 -0800
Links: << >>  << T >>  << A >>
Spartan = FPGA
ARM = MicroProcessor

The difference between them is pretty extensive.

Yes, you can program an ARM uP using C/C++.  All you need is software
to compile that into assembly.

You can't write HDL for an ARM.  Why would you?  It would have to be
translated into assembly as well, which just doesn't make sense.  HDL's
are Hardware Definition Languages.  They are used to describe hardware,
not software.

The key feature of HDL's is that there is a subset of the language that
is synthesizable to hardware.  You don't have to spend time connecting
things at the gate level or macro level on a schematic.  You write code
that describes what you want your hardware to do.

It is possible to embed a microprocessor (even an ARM) into an FPGA and
have it control your hardware.  This gets complicated.  Quickly.

An FPGA allows you to design your own hardware logic.  A microprocessor
allows you to write code targeted to a specific device to perform some
function or functions.  You cannot create any more hardware than what
the ARM (or whatever you use) provides.  The Spartan, like all FPGA's,
are basically blank slates.  Save for some internal structures like
clock logic, RAM's, built-in DSP blocks, etc,  it is up to you to
create whatever you can realize in hardware, connect it all together
and see if it works.

It really depends on what you need to do.  Each device has its own
strengths and weaknesses.

Hope this helps.


Article: 95619
Subject: Re: help:dual-edge flip-flop possible using Verilog?
From: "Peter Alfke" <peter@xilinx.com>
Date: 24 Jan 2006 14:05:29 -0800
Links: << >>  << T >>  << A >>
I suggest we wait for the original poster to clarify.
I think there is no real need for a dual-edge triggered flip-flop.
Definitely not at the low frequenciesmentioned.
There is also a simple circuit that XOR differentiates the clock, thus
generating a clock pulse at both the rising and the falling edge. (See,
among others, at "Six Easy Pieces" in TechXclusives)
Peter Alfke


Article: 95620
Subject: Re: Raggedstone specifications ...
From: "Xavier T" <xavier.tastet@gmail.com>
Date: 24 Jan 2006 14:20:09 -0800
Links: << >>  << T >>  << A >>
Hi John !
I checked the XAPP 684, and don't see where it deals with fpga
programming...
Maybe I read it too fast 
X.


Article: 95621
Subject: Re: LVDS Input buffer in VHDL (ISE)
From: "Roger" <enquiries@rwconcepts.co.uk>
Date: Tue, 24 Jan 2006 22:21:07 GMT
Links: << >>  << T >>  << A >>
Brian,

Thanks, this was really useful.

I'm using version 7.1 of ISE and yes, I have the unisim library lines in the 
code.

I used the generic ... IOSTANDARD = LVDS_25_DT on an IBUFDS as you suggested 
and it worked! I don't know why and probably never will but it allows me to 
progress with the design now. Thanks again.

Roger.

"Brian Davis" <brimdavis@aol.com> wrote in message 
news:1138073412.403694.257500@o13g2000cwo.googlegroups.com...
> Roger wrote:
>> The part is Virtex IIPro. It's not the DCI I'm looking for, it's the 
>> on-chip
>> 100R termination.
>>
> What version of ISE?
>
> Are you using the unisim library like this:
> library unisim;
>   use unisim.vcomponents.all;
>
> Or, defining the component yourself?
>
> Instead of using the named suffix I/O buffer, try sticking an
> IO_STANDARD of LVDS_25_DT on an input buffer of type IBUF{G}DS
>
> See also Answer Record 17244
>
> Brian
> 



Article: 95622
Subject: Re: OT:Shooting Ourselves in the Foot
From: Joerg <notthisjoergsch@removethispacbell.net>
Date: Tue, 24 Jan 2006 22:21:51 GMT
Links: << >>  << T >>  << A >>
Hello Bo,


>>That won't help when you live in CA. The real paradox is that if you have 
>>the certs in one state it still doesn't allow you to work under it in 
>>another. So theoretically you'd need 51 registrations (with fees...) to be 
>>able to work countrywide under PE. Makes no sense to me at all.
> 
> Not necessarily. Most states PE board have 'commity' licensure--ie 
> recognition of PE from another state and will allow you to hang a shingle in 
> their state if you pay the fees etc to have the license transferred--or 
> maybe better stated "reissued in the commity state". A coworker of mine is 
> PE in 3 states and only took exams in one.  (ie NC, GA, AL).
> 

That's what I meant. Comity allows for mutual recognition to avoid 
having to sit through umpteen exams. But they all want the paperwork and 
their fees. I just wonder why the states can't just accept each others 
licenses at face value. Guess it's a turf issue and they all want the money.

Regards, Joerg

http://www.analogconsultants.com

Article: 95623
Subject: Re: ISE8.1 Service Packs Schedule
From: Neil Glenn Jacobson <n.e.i.l.j.a.c.o.b.s.o.n@x.i.l.i.n.x.c.o.m>
Date: Tue, 24 Jan 2006 15:30:29 -0800
Links: << >>  << T >>  << A >>
Jim Granville wrote:
> Neil Glenn Jacobson wrote:
>> Jim Granville wrote:
>>
>>> Neil Glenn Jacobson wrote:
>>> That's Spac 3 ?!  - did I miss Spac 1 and Spac 2 ? - and 8.1i is only
>>> days old....
>>>
>>> -jg
>>>
>>>
>> Jim,
>>
>> 8.1i was released December 5th, 2005. Service Pack 1 was released Jan 
>> 9th.  Service Pack 2 is making its way through the release process 
>> with a projected release date of Feb 9th.  Hope that helps.
> 
> Thanks Glenn, I've given this a new title, as it is usefull
> information for project planning.
> Do you have a tentative date for Sp3 [ Mar 9th :) ] ?
> 
> -jg
> 
Typically, service packs are released every 4 to 6 weeks.

Article: 95624
Subject: Re: Xilinx padding LC numbers, how do you really feel about it?
From: "Jerry Coffin" <jerry.coffin@gmail.com>
Date: 24 Jan 2006 15:43:08 -0800
Links: << >>  << T >>  << A >>
fpga_toys@yahoo.com wrote:

[ ... ]

> So, my point is, and nobody seems to disagree, that it's unrealistic to
> assume that the devices can be 100% packed, use the marketing numbers
> for system design clock speeds, at a modest toggle rate, and not blow
> right thru the power the device can handle. Disagree?
>
> If not, then the device HAS TO BE DERATED from marketing numbers for RC
> use. Disagree?

Looking in from the sidelines, it seems to me that quite a bit of this
conversation is taking place more or less cross-purposes.

First of all, I think "derating" is a poor term -- though I tend to
agree that they might be able to provide more useful numbers. One
possibility might be to more or less directly specify the heat output
from the chip (as a whole) per million (or whatever) transitions per
second. This might give a better idea about trade-offs between faster
clocks vs. more gates. Unfortunately, it has a substantial problem
(thats been alluded to elsethread): it's basically dealing with the
power consumed by logic, not by routing, so in any given design it
might be off by a fairly large factor. I can believe that it could be
reasonably useful for things like product selection though -- if you're
planning to encrypt at a rate of X gigabytes per second (for example)
it's fairly easy to figure a rough idea of the number of bit
transitions involved and see if you're at least in the right ballpark.
This wouldn't tell you that a design _will_ work, but it'd at least let
you separate things that stand a reasonable chance from those that
don't.

Second, in terms of providing a general-purpose computing resource, I
don't think anything Xilinx (or anybody else) can provide in a
datasheet is going to mean a whole lot. If you're providing a product
for end users (instead of engineers) you need to make it foolproof.
Nothing in the datasheet is going to

Whether Xilinx should provide a circuit like that on-chip (e.g. like
most CPUs now have) is open to some question -- it would likely add a
more or less fixed amount to the product price. An amount that would
hardly be noticeable in a big Virtex would be utterly prohibitive on a
small Spartan. Perhaps this would be a reasonable feature to add on the
next generation of Virtex chips though...

-- 
    Later,
    Jerry.




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