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 101825

Article: 101825
Subject: Re: The differences between behaviors of 'std_logic_vector' and 'unsigned'
From: "Weng Tianxiang" <wtxwtx@gmail.com>
Date: 7 May 2006 07:30:50 -0700
Links: << >>  << T >>  << A >>
Sorry! I found the error. The error is not related to what I have
thought,
it relates to situation:
std_logic => A(I),
In a generate loop as following:
Lable_A : for I in 0 to 3 generate
... port map (
  ...
  A => A(I),
  ...
);

A() must be declared as
signal A : unsigned(3 downto 0);

And it cannot be decleared as
signal A : unsigned(1 downto 0); <-- my error

Thank you.

Weng


Article: 101826
Subject: Re: flashing a led
From: "Weddick" <weddick@comcast.net>
Date: Sun, 7 May 2006 09:34:05 -0700
Links: << >>  << T >>  << A >>
Or does '0' turn the LED on?

"Jep" <Laurent.George@gmail.com> wrote in message 
news:1146997489.503620.68120@g10g2000cwb.googlegroups.com...
>I have a little problem with flashing a led.
>
> I want flash a led for indicating the status of my program.
>
> I do the following:
>
> LED1 <= '1', '0' after 200 us;
>
> But it burn all the time.
>
> Do you have a solution? ( wthout counters)
> 



Article: 101827
Subject: Re: Xilinx 3s8000?
From: Paul Hartke <phartke@Stanford.EDU>
Date: Sun, 07 May 2006 09:35:54 -0700
Links: << >>  << T >>  << A >>
With respect to connecting multiple boards, the XUPV2P "Using High Speed
Serial MGTs with the Aurora IP" Quickstart provides a good
infrastructure so the developer can focus on the partition itself.

Paul

c d saunter wrote:
> 
> Ron,
>    Perhaps you could partner with a local university and form an
> undergraduate project based on this?  I say this because universities
> have access to this rather nice board at an affordable price...
> 
> http://www.xilinx.com/univ/xupv2p.html
> 
> Unless you could shrink the design you'd need to join several boards...
> 
> Cheers
> cds

Article: 101828
Subject: Re: flashing a led
From: Ralf Hildebrandt <Ralf-Hildebrandt@gmx.de>
Date: Sun, 07 May 2006 18:48:30 +0200
Links: << >>  << T >>  << A >>
Jep wrote:


> LED1 <= '1', '0' after 200 us;
                ^^^^^^^^^^^^^^^^
This is not supported by synthesis.

> But it burn all the time.

... because the 2nd part of the code line is ignored.


> Do you have a solution? ( wthout counters)

Whats wrong with counters?

Ralf

Article: 101829
Subject: Re: Xilinx 3s8000?
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 7 May 2006 10:26:54 -0700
Links: << >>  << T >>  << A >>

Ron wrote:
> So to multiply two 704 bit numbers
> together (depending upon how it's implemented of course) would require
> roughly sixty 64-bit multiplies and a bunch of adds. ...

If I remember right, 704 is 11 times 64, so the multiplication would
take 121 of those 64-bit multipliers, not "roughly sixty"...

I am glad we got away from the obscenities, and now deal with basic
math...
Peter Alfke


Article: 101830
Subject: Re: FPGA-based hardware accelerator for PC
From: "JJ" <johnjakson@gmail.com>
Date: 7 May 2006 10:54:04 -0700
Links: << >>  << T >>  << A >>

Piotr Wyderski wrote:

snipping

> > If the 32 bit RISC was optimized for some specialized task, then it
> > might make sense to have it alongside a high-performance CPU.
>
> No, because in this case you are trying to outperform an out-of-order,
> highly parallel processor core able to complete ~6 simple instructions
> per cycle and clocked at 2+ GHz. Reasonable soft CPU cores run at
> about 200 MHz and complete only one instruction per cycle. It
> means that a cheap CPU you can buy anywhere has about 60 times
> higher performance in sequential processing. Even if you could provide
> the same performance (not to mention about outperforming it, which
> is the key idea, anyway), it would mean that you are at least Harry Potter.
> :-)
>

I have fantastic disbelief about that 6 ops /clock except in very
specific circumstances perhaps in a video codec using MMX/SSE etc where
those units really do the equiv of many tiny integer codes per cycle on
4 or more parallel 8 bit DSP values. Now thats looking pretty much like
what FPGA DSP can do pretty trivially except for the clock ratio 2GHz v
150MHz.

I look at my C code (compilers, GUI development, databases, simulators
etc) and some of the the critical output assembler and then time some
parts on huge 1M timed loops making sure no iteration benefits from
cacheing the previous run.  I always see a tiny fraction of that ~6
ops/cycle. SInce my code is most definitely not vector code or media
codec but is a mix of graph or tree traversal over large uncacheable
spans, I often see avg rates exactly 1 op per clock on Athlon TB at
1GHz and also XP2400 at 2GHz. My conclusion is that the claims for
wicked performance are mostly super hype that most punters accept all
too easily. The truth of the matter is that Athlon XPs rated at say
2400 are not 2.4 x faster than TB at 1GHz in avg cases, maybe on vector
codecs. When I compare WIndows apps for different cpus, I usually only
see the faster cpu performing closer to sqr of its claimed speedup.

A while back, Toms Hardware did a comparison of 3GHz P4s v the P100 1st
pentium and all the in betweens and the plot was basically linear and
thats on stupid benchmarks that don't reflect real world code. One has
to bear in mind the P4 not only used 30x the clock to get 30x the
benchmark performance, it also used perhaps 100x the transistor count
as well and that is all due to the Memory Wall and the necessiity to
avoid at all costs accessing DRAM. Now if we did that on an FPGA
benchmark we would be damned to hell, one should count the clock ratio
and the gate or LUT ratio but PCs have gotten away with using infinite
transistor budgets to make claims.

This makes sense to me since the instruction rate is still bound by
real memory accesses to DRAM some percent of the time for cache misses,
I figure around 2% typical or even more. DRAM has improved miserably
over 20yrs in true random access about 2x from 120ns to 60ns  Ras to
Dout time. If you use cache misses close to 0.1% then you get the hyped
nos, but code doesn't work like that atleast mine doesn't.

Try running a random number generator say R250 which can generate a new
rand number every 3ns on a XP2400 (9 ops IIRC). Now use that no to
address a table >> 4MB. All of a sudden my 12Gops Athlon is running at
3MHz ie every memory access takes 300ns or so since every part of the
memory system is wreaked (deliberately in this case). Ironically if
thats all you wanted to do, an FPOA cpu without complex MMU, TLBs could
generate random numbers in 1 cycle and drive an SDRAM controller just
as fast if not faster since SDRAMs can cyle fully random closer to
60ns. Now in packet switching and processing where large tables are
looked up with random looking fields, they use RLDRAM to get SRAM like
performance.

So what does real code look like, any old mixture of the 2 extremes, ie
sometimes its memory crippled, sometimes if everything is in L1 cache,
it really does seem to do 2 ops/clock if array accesses are spread out,
even with small forward branches. So all the complexity of these OoO
machines is there to push up the avg rate and keep it just above 1 for
typical integer codes, more for specially tuned codes. Each FP code
used though is equivalent to a large no of ops on an integer only cpu,
but then I rarely use FP except for reporting averages.

So on an FPGA cpu, without OoO, no Branch prediction, and with tiny
caches, I would expect to see only abouit .6 to .8 ops/cycle and
without caches, a fraction of that. So that leaves the real speed
difference much closer, maybe 10-20 to 1 for integer codes, but orders
more for FP codes. For an integer only problem where some of the code
can be turned into specialized instructions as in your applications
list, the FPGA cpu is more transparent and possibly a more even match
if replicated enough, but still it is dificult even to get parity and
writing HDL is much harder than plain C.

I have no experience with the Opterons yet, I have heard they might be
10x faster than my old 1GHx TB but I remain skeptical based on past
experience.

On the Harry Potter theme, I have suggested that an FPGA Transputer cpu
that solves the Memory Wall by trading it for a Thread Wall using
latency hiding MTA cpu AND esp latency hiding MTA RLDRAM can be a more
serious competitor to conventional OoO BP, SS designs that continue to
flog regular SDRAMs. In that sort of design a 10 PE + 1 MMU Transputer
node setup with RLDRAM can match 1000 Mips since each PE is only
100Mips but you have to deal with 40 threads with almost no Memory Wall
effect, ie a Thread Wall. Since the PEs are quite cheap, the limit on
FPGAs is really how many MMUs can be placed on a FPGA for max Memory
throughput and that seems to be a pin & special clocks limit rather
than core limit. Perhaps using spare BlockRams as an L1 RLDRAM
intermediate, one could get many more busy cpus inside the FPGA
sharing the RLDRAM bandwidth on L1 misses.


> > More interested in prototyping some RISC centric soft-IP designs.
>
> You can do this using existing development boards.
>
>     Best regards
>     Piotr Wyderski

regards

John Jakson 
transputer guy

(paper at wotug.org)


Article: 101831
Subject: Re: Xilinx 3s8000?
From: Ron <News5@spamex.com>
Date: Sun, 07 May 2006 12:54:19 -0700
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> If I remember right, 704 is 11 times 64, so the multiplication would
> take 121 of those 64-bit multipliers, not "roughly sixty"...

My comment was to Thomas Womack, not to you dimwit. If you had half a 
brain you would realize that it's not necessary to do 121 multiplies 
because the upper and lower halves of the multiplication matrix above 
and beneath the diagonal are symmetric. Please do not respond to 
comments (it wasn't a question, BTW) that you don't understand.

> 
> I am glad we got away from the obscenities, and now deal with basic
> math...
> Peter Alfke

And you obviously need to take some remedial math courses Peter. I have 
plenty more of what you call "obscenities" for you Xilinx scumbags who 
use this forum to spread FUD and peddle your overpriced goods. 
Admittedly I made the mistake of asking for a hobbyist discount on your 
obscenely priced software design tools when I started this thread, but 
now that I know what despicable cretins you are, I would appreciate it 
if in the future you and the other Xilinx creeps would KEEP OUT of the 
Usenet discussion threads I initiate.

Thank you,

Ron

Article: 101832
Subject: Re: Xilinx 3s8000?
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 7 May 2006 13:03:25 -0700
Links: << >>  << T >>  << A >>
Thanks for the education. I am always eager to learn.
Peter Alfke


Article: 101833
Subject: Re: Xilinx 3s8000?
From: "johnp" <johnp3+nospam@probo.com>
Date: 7 May 2006 13:05:57 -0700
Links: << >>  << T >>  << A >>
Ron -

I've seen a lot more valuable input on this newsgroup from Peter
and Austin then from you.  If you don't want to read comments
from the Xilinx folks, then don't.  Let the rest of us decide what
we want to read and whose opinions we value.   As much as I
dislike some of the thing Xilinx does, or as much as I gripe
about their software, their contributions to this newsgroup are
a lot more useful than your rants.  Name calling adds nothing
to any discussion in this forum.

John Providenza


Article: 101834
Subject: Re: flashing a led
From: "Jep" <Laurent.George@gmail.com>
Date: 7 May 2006 13:19:35 -0700
Links: << >>  << T >>  << A >>
Thanks for all your support.

I do it now  with counters, and it works :-)


Article: 101835
Subject: Re: Xilinx 3s8000?
From: fpga_toys@yahoo.com
Date: 7 May 2006 14:14:58 -0700
Links: << >>  << T >>  << A >>

johnp wrote:
> Name calling adds nothing to any discussion in this forum.

The Xilinx employees have gone out of their way not to play nice in
other discussions reciently, one really has to expect that they set the
tone in how they want to be addressed and treated, by how they treat
others. Addmittedly Ron is a bit over the top and direct, but so are
Austin, Peter, and a few other Xilinx folks that bash others in this
forum regularly.

Austin's FUD regarding Grey Market parts hurts Xilinx customers that
end up with excess inventory, and the companies that resell or build
product using it.  Certainly there is conterfeiting fraud of Xilinx
parts, just as there is in every industry, including jeans. But the
reality is that the main stream Xilinx distributors will not give small
businesses the time of day, much less hobbiests. The couple that do,
will not stock a full line, and ask for minimum qty purchases on the
rest with long lead times that exceed their requirements.  Reputable
Gray Market sources are a critical resource for hobbiests and small
companies, and the FUD just isn't necessary or warranted.  Xilinx's
"choice" to not support this secondary market is about as helpful as a
car dealership unwilling to accept factory warranty service on cars
they did not directly sell or lease.

Peter continually goes off half cocked where hobbiests are involved,
expecting that they should do their projects like any respectable
Fortune 100 company.  He's exceptionally proud of their High Margins,
which translate to high end customer costs.  When Xilinx refuses to
open up enough to allow third parties to provide competitive design
software tools, including open source alternatives, then being bashed
for the high costs of their software is fair game.  Especially when
they don't play nice with other folks in this forum. And openly
disrespect any project that doesn't have a billion dollar ROI.

The size limit of the free web software, also greatly limits what end
user boards can be built in volume for this market. Since the high cost
of Xilinx tools cuts the market size for boards with larger parts
dramatically, so does it drive up the cost of boards ith larger parts
because of reduced volume.  As I've noted before, this also kills the
reconfigurable computing market, with a Xilinx "tax" to use that board
each year by paying the high annual subscription costs just to write
new software requiring the place, route and bit stream tools. When
Xilinx either releases the bit stream generation specifications for
their parts, or includes full product line support for place, route and
bitstream generation in the free tools, the reasons for bashing them
for their software costs will mostly go away.

Till then Xilinx can continue it's FUD regarding second and third teir
companies that feed off the Gray Market, crow about the High Margins as
a measure of success .... and eat crow from hobbiests and smaller
businesses about the high costs and lack of support.

>From my perspective, it would be better if Xilinx dealt with the fraud
issues independently of cutting off support to compaies that need the
Gray Market. It would be a lot better if the tools cost issues where
removed and open up the market for boards with larger parts, and third
party software. If would be much better, if Xilinx employees didn't
bash others here either.

John


Article: 101836
Subject: Funky experiment on a Spartan II FPGA
From: "mammo" <ankur101@gmail.com>
Date: 7 May 2006 14:21:03 -0700
Links: << >>  << T >>  << A >>
Hi all,

I am trying to do a novel kind of experiment using a spartan II FPGA. I
want to measure the impedence profile (spectrum) of the Vdd and ground
planes on the FPGA. To do that, I am planning to do the following
(a) fill up the FPGA with a lot of synchronous logic
(b) clock it at different frequencies
(c) measure the voltage and current consumed at every frequency.

To make the measurements independent of the program running on the
FPGA, I am planning to hold all the logic on the FPGA in the reset
state.

Right now, I am planning to implement a few Picoblaze cores on my 50k
gate spartan II . (each picoblaze roughly takes up 9% of the slices),
tie them up and implement some test logic on the FPGA.

I am basically using the forum as a sounding board for my idea. Any
suggestions on what cores I should implement for maximum sensitivity ?
Is picoblaze a good idea ?

Thanks
Mammo


Article: 101837
Subject: Re: Funky experiment on a Spartan II FPGA
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 7 May 2006 14:37:46 -0700
Links: << >>  << T >>  << A >>
For a worst-case look, I would implementa maximum-lemgth shift register
and toggle its front end. Driven by a global clock,this generates the
maximum amplitude of synchronous spikes on the Vcc distribution.
Anything more realistic would spread out the spikes, thus lowering the
amplitude.
I suppose you know how to access the internal Vcc and Vdd levels, and
bring them to the outside.
My question is: What do you want to prove or disprove?
Peter Alfke, from home.


Article: 101838
Subject: Re: Funky experiment on a Spartan II FPGA
From: Jim Granville <no.spam@designtools.co.nz>
Date: Mon, 08 May 2006 09:54:25 +1200
Links: << >>  << T >>  << A >>
mammo wrote:
> Hi all,
> 
> I am trying to do a novel kind of experiment using a spartan II FPGA. I
> want to measure the impedence profile (spectrum) of the Vdd and ground
> planes on the FPGA. To do that, I am planning to do the following
> (a) fill up the FPGA with a lot of synchronous logic
> (b) clock it at different frequencies
> (c) measure the voltage and current consumed at every frequency.
> 
> To make the measurements independent of the program running on the
> FPGA, I am planning to hold all the logic on the FPGA in the reset
> state.

this bit has me lost, how can you use a picoblaze in the reset state ?

> Right now, I am planning to implement a few Picoblaze cores on my 50k
> gate spartan II . (each picoblaze roughly takes up 9% of the slices),
> tie them up and implement some test logic on the FPGA.
> 
> I am basically using the forum as a sounding board for my idea. Any
> suggestions on what cores I should implement for maximum sensitivity ?
> Is picoblaze a good idea ?

yes, it is widely known, and is a more typical usage of PFGA,

You could also implement a 'sea of 32 bit CE counters', which can be 
usefull to calibrate and verify your system - that is a pattern that
should not overheat the FPGA, but will give a stable spectrum.
Enable/disable of the ClockEnable, would also give results for the
clock tree and (plus) the logic fabric.

-jg


Article: 101839
Subject: Re: Funky experiment on a Spartan II FPGA
From: "mammo" <ankur101@gmail.com>
Date: 7 May 2006 15:07:30 -0700
Links: << >>  << T >>  << A >>
Peter,
>My question is: What do you want to prove or disprove?

Thanks for your suggestion. This is essentially a curiosity driven
experiment. We saw a paper in the Intel Technology journal , where they
had such impledence measurements for the P4 processor. We were
wondering if we could reproduce those measurements in our lab, and
decided to start with FPGAs rather than processors as a first baby
step.
The paper is located at:
http://www.intel.com/technology/itj/2005/volume09issue04/art02_powerdelivery/p01_abstract.htm

Also, just checking if I understand you right : are you suggesting that
I implement one huge shift register, and then just push a 10101...
pattern through it ? it seems like a good idea.

Jim,
>> To make the measurements independent of the program running on the
>> FPGA, I am planning to hold all the logic on the FPGA in the reset
>> state.
>
>this bit has me lost, how can you use a picoblaze in the reset state ?

Since I donot really want to do any real computations using the
Picoblaze, i think its okay to hold it in the reset state. I just want
to clock it at different frequencies and see what happens on the power
delivery network

Thanks for your suggestion about the clock enable. It makes a lot of
sense.

Regards,
mammo


Article: 101840
Subject: Re: Xilinx 3s8000?
From: Jim Granville <no.spam@designtools.co.nz>
Date: Mon, 08 May 2006 10:18:59 +1200
Links: << >>  << T >>  << A >>
Ron wrote:
<rant filter on>
> Peter Alfke wrote:
> 
>> If I remember right, 704 is 11 times 64, so the multiplication would
>> take 121 of those 64-bit multipliers, not "roughly sixty"...
> 
> 
> My comment was to Thomas Womack. It's not necessary to do 121 multiplies
> because the upper and lower halves of the multiplication matrix above 
> and beneath the diagonal are symmetric.
> 
>>
>> I am glad we got away from the obscenities, and now deal with basic
>> math...
>> Peter Alfke
<rant filter off>

Feeling better now Ron ?

First you started asking for help :

"...to work out a deal with the FPGA vendor or someone to lend me the 
necessary development board and s/w tools in exchange for the potential 
fame and glory, since I am but a humble retired engineer/hobbyist."

then you later add this:

"..also a $30,000 reward for factoring RSA-704.."

as you are clearly 100% honest, can we take it that the share in the 
fame and glory you offer, also extends to a share in the (now mentioned) 
prize ?

or will you donate that to a local school ?

Tip: If you want to succeed in any task, it is better to stay focused, 
avoiding wasting energies, and also not to alienate any (potential) 
sources of assistance. Lots of clever people lurk in this news group.

-jg



Article: 101841
Subject: Re: Xilinx 3s8000?
From: fpga_toys@yahoo.com
Date: 7 May 2006 15:28:20 -0700
Links: << >>  << T >>  << A >>

Jim Granville wrote:
> Tip: If you want to succeed in any task, it is better to stay focused,
> avoiding wasting energies, and also not to alienate any (potential)
> sources of assistance. Lots of clever people lurk in this news group.

And a lot of potential, or possibly soon to be EX, customers.


Article: 101842
Subject: Re: Funky experiment on a Spartan II FPGA
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 7 May 2006 16:02:32 -0700
Links: << >>  << T >>  << A >>
Correction, before anybody points out my error:
The long checkerboard shift register is a popular way to measure power
consumption, but it is actually very benign with respect to Vcc spikes,
since half the loads go Low and half go High, nicely compensting each
other.
The tougher test is to switch every bit in synchronism, from Low to
High on one clock, and from High to Low on the next, etc.
Needs a line to drive all D inputs together, and this line being
toggled.
This is of course not a realistic test, and it may show real ugly
results.
But I think that's what you were after...
Sorry for the misleading previous posting.
Peter Alfke, Xilinx (from home)


Article: 101843
Subject: Re: Funky experiment on a Spartan II FPGA
From: Jim Granville <no.spam@designtools.co.nz>
Date: Mon, 08 May 2006 11:02:55 +1200
Links: << >>  << T >>  << A >>
mammo wrote:
> Jim,
> 
>>>To make the measurements independent of the program running on the
>>>FPGA, I am planning to hold all the logic on the FPGA in the reset
>>>state.
>>
>>this bit has me lost, how can you use a picoblaze in the reset state ?
> 
> 
> Since I donot really want to do any real computations using the
> Picoblaze, i think its okay to hold it in the reset state. I just want
> to clock it at different frequencies and see what happens on the power
> delivery network
> 
> Thanks for your suggestion about the clock enable. It makes a lot of
> sense.

There are two portions of clock consumption, one is the clock network
itself, and the other is the Nodes/Fabric that toggle.
Not all data makes that distinction.

So Peter's more agressive test of a 101010 shift register will have
two power levels, depending on the ClockEnable.
Wide counters have a more typical logic % usage.

If you Pinmap, and add an OE term, you can also get the IO fabric power 
values.

The separate supplies on FPGA makes probe of the internal power rails
more difficult.

-jg


Article: 101844
Subject: Re: Funky experiment on a Spartan II FPGA
From: fpga_toys@yahoo.com
Date: 7 May 2006 16:17:29 -0700
Links: << >>  << T >>  << A >>
Hi Mammo,

I think this would be a great project, and a useful paper to present
for others too.

I'm not sure why Peter is talking about worst case, as Xilinx has
already said the larger parts lack margin to operate at the highest
frequencies with worst case design loads due to power and thermal
issues.  Besides the lack of cooling for worst case loads, most boards
also lack the power supply margins too ... and will go unstable at
worst case loading at high clock rates due to dynamic power.

It would be nice (and I've asked for this before with very negative
responses) that Xilinx openly document the dynamic power and thermal
limits. As a side note, this problem is partially mitigated by clock
skew as the parts get larger, but that doesn't help realize designing
for worst case loading, or even having a clue to predict why one
placement works and another fails, when the skew stacks up worst case
in your design.

Have fun!! ... and I look forward to your results :)

John


mammo wrote:
> Hi all,
>
> I am trying to do a novel kind of experiment using a spartan II FPGA. I
> want to measure the impedence profile (spectrum) of the Vdd and ground
> planes on the FPGA. To do that, I am planning to do the following
> (a) fill up the FPGA with a lot of synchronous logic
> (b) clock it at different frequencies
> (c) measure the voltage and current consumed at every frequency.
>
> To make the measurements independent of the program running on the
> FPGA, I am planning to hold all the logic on the FPGA in the reset
> state.
>
> Right now, I am planning to implement a few Picoblaze cores on my 50k
> gate spartan II . (each picoblaze roughly takes up 9% of the slices),
> tie them up and implement some test logic on the FPGA.
>
> I am basically using the forum as a sounding board for my idea. Any
> suggestions on what cores I should implement for maximum sensitivity ?
> Is picoblaze a good idea ?
> 
> Thanks
> Mammo


Article: 101845
Subject: Re: Funky experiment on a Spartan II FPGA
From: Jim Granville <no.spam@designtools.co.nz>
Date: Mon, 08 May 2006 11:46:56 +1200
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> Correction, before anybody points out my error:
> The long checkerboard shift register is a popular way to measure power
> consumption, but it is actually very benign with respect to Vcc spikes,
> since half the loads go Low and half go High, nicely compensting each
> other.
> The tougher test is to switch every bit in synchronism, from Low to
> High on one clock, and from High to Low on the next, etc.
> Needs a line to drive all D inputs together, and this line being
> toggled.
> This is of course not a realistic test, and it may show real ugly
> results.
> But I think that's what you were after...
> Sorry for the misleading previous posting.
> Peter Alfke, Xilinx (from home)

To implement both would be a good idea.
That way, you have two tests with similar node-toggle rates, but
different Icc profiles.
Another would be to configure (tiled) half the device as PosEdge and 
half as NegEdge, as that shifts the fabric currents. (but not the 
Clock-tree currents ).
-jg




Article: 101846
Subject: Re: Xilinx 3s8000?
From: Ron <News5@spamex.com>
Date: Sun, 07 May 2006 16:50:41 -0700
Links: << >>  << T >>  << A >>
johnp wrote:
> Name calling adds nothing
> to any discussion in this forum.

On the contrary, it will hopefully keep them OUT of any discussion 
threads I may initiate in the future.

Ron

Article: 101847
Subject: Can an FPGA be operated reliably in a car wheel?
From: "Andrew FPGA" <andrew.newsgroup@gmail.com>
Date: 7 May 2006 16:52:31 -0700
Links: << >>  << T >>  << A >>
What are the maximum g forces an FPGA could operate under?
E.g. an FPGA sitting in a car wheel, where the car is travelling at 100
km/hr experiences approx 400g due to the centripetal acceleration.
(assuming a 15" diameter wheel).
Can anyone point to products or applications where this is done
already? (I know tyre pressure sensors are coming..but these are not
FPGAs)

What would the mass of your typical FPGA package/silicon be? Say a 256
ball BGA(e.g. FT256 or similar). Force = mass x acceleration so I guess
you could work out the force on the solder balls etc etc.

I know vibration probably is an issue also - but at least that can be
mitigated to some extent with the mechanical design of our product
,e..g vibration damping etc. However, the centripetal force is another
matter - its always there whenever the wheel is rotating. (and grows
with the square of the cars velocity).


Article: 101848
Subject: Re: Xilinx 3s8000?
From: Ron <News5@spamex.com>
Date: Sun, 07 May 2006 17:10:19 -0700
Links: << >>  << T >>  << A >>
Jim Granville wrote:
> Feeling better now Ron ?

I would feel even better if people like you who have nothing to 
contribute would stop harassing me.

> as you are clearly 100% honest, can we take it that the share in the 
> fame and glory you offer, also extends to a share in the (now mentioned) 
> prize ?

You must have a reading comprehension problem Jim. I posted a link to 
the RSA challenge number in my original message that started this 
thread. Had you bothered to look it up, the $30,000 (up to $200,000 for 
RSA-2048) was clearly posted on the page I linked to.

With Austin bragging about the 1.73 billion dollars of US sales last 
year for Xilinx, I figured the $30,000 RSA prize would be 
inconsequential chicken feed to them, but yes, of course I would be 
willing to share half of the RSA prize money with *anyone* who would be 
willing to provide me with at least the design software to complete my 
project (preferably NOT Xilinx in view of their attitude towards my 
project).

For that matter, I'd be willing to send someone who already possesses 
the necessary hardware and software, a copy of the bitstream file so 
that they could run it themselves on their own hardware. Eventually I'll 
probably open a SourceForge.com project for it and open source my work, 
but I'd rather wait until my project comes to fruition first.

> Tip: If you want to succeed in any task, it is better to stay focused, 
> avoiding wasting energies, and also not to alienate any (potential) 
> sources of assistance. Lots of clever people lurk in this news group.

Haven't you realized yet that Xilinx reps are a complete waste of my 
time and energy? They have already made it abundantly clear that they 
are *NOT* a potential source of assistance to me. At least they could 
have done so politely without being condescending and rude as though I 
were some snotty nose kid who hasn't a clue. I wonder what they think I 
was doing during my 35 year career as an engineer?

I am generally very respectful to those who also show me some respect. 
For that reason, I can't believe Xilinx let those jerks out of their 
cages without a leash. "Back in the day" a salesman would never even let 
an applications engineer visit a customer unaccompanied for fear they 
would alienate the customer. Now I can see why.

Ron

Article: 101849
Subject: Re: Xilinx 3s8000?
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 7 May 2006 17:52:17 -0700
Links: << >>  << T >>  << A >>


fpga_toys@yahoo.com wrote:
>> Peter continually goes off half cocked where hobbiests are involved,
> expecting that they should do their projects like any respectable
> Fortune 100 company.  He's exceptionally proud of their High Margins,
> which translate to high end customer costs.

Why do you write such outrageous lies, just because you like the ring
of them?
I have never ever mentioned our margins. That's not my style...
I also have often bent over backwards to help students and hobbyist,
since I remember once havin been one of them myself. (I do discourage
people from wasting their time on obsolete chips, though...)
I would even have tried to help Ron, if he had presented a rational
plan for his endeavor, but he didn't. And then he sank into
obscenities...

This used to be a polite, informative and cooperative newsgroup, until
you and Ron descended on us, and turned it into an ugly shouting
contest.
Peter Alfke




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