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 95575

Article: 95575
Subject: Re: rocket IOs with web pack
From: "Antti Lukats" <antti@openchip.org>
Date: Tue, 24 Jan 2006 14:17:39 +0100
Links: << >>  << T >>  << A >>
"colin" <colin_toogood@yahoo.com> schrieb im Newsbeitrag 
news:1138108267.480703.95060@g14g2000cwa.googlegroups.com...
> Guys
>
> Does anyone know whether ISE simulator lite will simulate the RocketIOs
> on the virtex 4 that webpack supports?
>
> I have a simulator that doesn't support smartmodels so I could live
> with the poor performance of simulator lite just to check the rocket IO
> bit of my design.
>
> regards
>
> Colin
>
WAU what a question.
No idea, but guessing NO.

And and advice about rocketIO do not trust simulations, so better to test 
out in real silicon anyway.

-- 
Antti Lukats
http://www.xilant.com 



Article: 95576
Subject: Re: help:dual-edge flip-flop possible using Verilog?
From: "Gabor" <gabor@alacron.com>
Date: 24 Jan 2006 05:55:44 -0800
Links: << >>  << T >>  << A >>

yyqonline wrote:
> Im designing a module working as an fm0-encoder, the clk and max
> datarate of which are both 640KHz. It is not complicated when the
> datarate is lower than 320K, the half of clk. But when the datarate of
> 640K, the clk frequency, is concerned, the problem comes that I have to
> change the state at both the rising and falling edge of the clk. Now I
> am using a mothod via combinational output, which is not so good and
> expansible as registered output using an FSM. I think that an FSM using
> DET(dual-edge flip-flop) would work, but I am not sure wether it is
> recommandable to use det and I don't know how to describe a det using
> synthesizable Verilog?
> It would be appreciated very much if some of you can
> *comments about the det method,
> *the methed about how to describe a det flip-flop
>
> thans a lot for any help!

Do you really mean KHz and not MHz?  If this is not a typo I would
suggest using a much faster clock to run an FSM that samples the
640KHz clock and uses edge detection (XOR on two stages of
flip-flop) to enable data transfer.

If you're really talking MHz, modern FPGA's have ways to deal with this
at the I/O buffer (double-data-rate flip-flops).

Generally multi-edge flip-flops are not synthesizable, but if the part
has them, they can be instantiated.  i.e. you can't just write:

always @ (posedge clk or negedge clk)
 ...

and expect the synthesis tool to generate useful RTL.


Article: 95577
Subject: Re: FPGA board with High Speed LVDS
From: "Noway2" <no_spam_me2@hotmail.com>
Date: 24 Jan 2006 06:06:18 -0800
Links: << >>  << T >>  << A >>
Check out the spec sheets on the Cyclone or Cyclone2.  You will likely
need to use the PLL(s), but I believe in the smalles cyclone has more
LVDS channels than you require.


Article: 95578
Subject: Re: OT:Shooting Ourselves in the Foot
From: "Bo" <bo@cephus.com>
Date: Tue, 24 Jan 2006 08:21:25 -0600
Links: << >>  << T >>  << A >>

"Joerg" <notthisjoergsch@removethispacbell.net> wrote in message 
news:TvbBf.20580$F_3.3236@newssvr29.news.prodigy.net...
> Hello Paul,
>
>>
>> The PE 's giving you refeence/verification do NOT have to be EEs. I just 
>> was approved to take the exam this April and 2 of my references were 
>> licensed mechanical PEs, not EE.  Don't let this deter you....you can 
>> find PEs of any field and use for reference.
>>
>
> Interesting. Then I would already know two (civil engineers). Was that in 
> California?
>
> 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 (?)

Perhaps you could take the exam in a neighboring state instead? AZ/NV?

Good luck!

Bo 



Article: 95579
Subject: Re: PE licunsure: was Shooting Ourselves in the Foot
From: "Bo" <bo@cephus.com>
Date: Tue, 24 Jan 2006 08:29:22 -0600
Links: << >>  << T >>  << A >>

"Joerg" <notthisjoergsch@removethispacbell.net> wrote in message 
news:vmcBf.20595$F_3.5792@newssvr29.news.prodigy.net...
> Hello Ray,
>
>
>> When I applied for mine, they wanted 5 references, 3 of which needed to 
>> be familiar with my work, and 3 of which had to be registered engineers. 
>> As it happened, all 3 were familiar with my work through past 
>> engagements, only one was licensed as an EE, the other two were MEs, both 
>> working for medical equpment companies I had done work for.  In addition, 
>> none of the references could be past employees or supervisors (the 
>> supervisors were interviewed too).  ...
>
>
> Oops, that may put another crimp in there since I was their boss all the 
> time. The CEO was my boss and has a degree but no license either. The 
> other assigment where I wasn't boss was outside the country.
>
>
>> You could always call the licensing board and discuss your predicament 
>> with them.  They are well aware that there are few PEs in manufacturing, 
>> and again, I found them to be very helpful navigating the application 
>> process, including helping you find your references. ...
>
>
> Yes, maybe talking to them is the best course of action. They might be 
> more willing now than before (I did call them about PE several years ago) 
> because they are hurting budgetwise AFAIK and may be hungry for the $275 
> fee. They had already jacked up the fees substantially to make up. Not 
> enough applicants anymore it seems.
>
>
>> BTW, yes, you generally do need 4 years between the FE exam and your PE.
>
>
> Beats me why they do that. Doesn't make much sense.
>

It seems a fine-line to walk between not getting enough applicants and 
getting too many (thus lowering the perceived value or 'exclusivity' of the 
PE club). In large part, I think the whole thing is just a huge money making 
scam-- the states make good money (and keep a significant perpetual income 
from annual fees), the Universities make money from review courses and of 
course the publishers make a killing on the prep materials.

It's looking like my venture is going to run about $1200 for fees, books, 
travel, etc. Multiply that by say 1000 examinees per year and it's 
$1.2million. Not bad, heh?

Nevertheless, if you want to play the game, you have to play by their 
rules-- as ridiculous as they might be (for example, no longer giving 
examinees their scores--even if they fail!)

Hoping to pass the 1st time around,

Paul




Article: 95580
Subject: Re: OT:Shooting Ourselves in the Foot
From: zwsdotcom@gmail.com
Date: 24 Jan 2006 06:30:04 -0800
Links: << >>  << T >>  << A >>

Simon Peacock wrote:

> So who is unqualified?  I have no degree or formal university training.  I
> went to a polytech and studied electrical.  Now I design radios and
> interface them to a digital world.

Based on my experience in industry, I would say between 10-15% of
people titled "engineer" do not have a degree (and practically none of
them have a "license"). This has no correlation at all with quality of
output, of course.

I'm actually now back at school to get the ol' parchment, because my
workplace is only 15 minutes drive from an ABET-accredited college, and
my employer has 100% tuition+books reimbursement with no annual limits.
It's a great morale-builder, because the stress level is negligible
compared with work. In fact I would almost qualify school as a leisure
activity; I feel more relaxed at work during the school term because
school gives me some problems that I KNOW to have answers.

If you have access to programs of this sort, I heartily recommend
them... not that I place any intrinsic value on the paper, but it's
handy to have and fun to acquire. Plus it expands your networking
opportunities in several ways, useful if you're a
consultant^H^H^H^H^H^H^H^H^H^Hpolitically correct term for person doing
this work without licenses/degrees/other bureaucratic irrelevancies.


Article: 95581
Subject: Re: help:dual-edge flip-flop possible using Verilog?
From: Eli Hughes <emh203@psu.edu>
Date: Tue, 24 Jan 2006 09:44:26 -0500
Links: << >>  << T >>  << A >>
I think the only device that supports this are the Xilinx CoolRunner II.

This Should work:

always @(posedge Clk or negedge Clk)
begin
	if(Rst == 1)
		Cnt <=0;
	else
		Cnt <= Cnt +1;

end

yyqonline wrote:
> Im designing a module working as an fm0-encoder, the clk and max
> datarate of which are both 640KHz. It is not complicated when the
> datarate is lower than 320K, the half of clk. But when the datarate of
> 640K, the clk frequency, is concerned, the problem comes that I have to
> change the state at both the rising and falling edge of the clk. Now I
> am using a mothod via combinational output, which is not so good and
> expansible as registered output using an FSM. I think that an FSM using
> DET(dual-edge flip-flop) would work, but I am not sure wether it is
> recommandable to use det and I don't know how to describe a det using
> synthesizable Verilog?
> It would be appreciated very much if some of you can
> *comments about the det method,
> *the methed about how to describe a det flip-flop
> 
> thans a lot for any help!
> 

Article: 95582
Subject: Re: Xilinx padding LC numbers, how do you really feel about it?
From: Ray Andraka <ray@andraka.com>
Date: Tue, 24 Jan 2006 09:45:18 -0500
Links: << >>  << T >>  << A >>
fpga_toys@yahoo.com wrote:
> Austin Lesea wrote:
> 
>>OK, OK.  We have heard you.
>>As I said, Peter and I will do our best to influence "truth in counting."
> 
> 
> Does that mean we will see either total power or derating curves for
> LUT/FF toggles to define power and thermal limits as both a percentage
> of active logic or size of the active design?
> 
> While you may not see this as important from a perspective of past
> uses for traditional hardware design, as reconfigurable computing takes
> off there is a completely different mindset hitting your market.
> Software
> tools WILL be packing active algorithms into devices to get the best
> computational effciency per device. Good packing WILL yield close to
> 100% active logic in a device, and yeild exactly what you are mocking:
> 
> 
>>Sure, go ahead and toggle every single flip flop and IO simultaneously
>>at max frequency, and I will assure you that you will not like the result.
> 
> 
> Devices that are by design not expected to be more than 10% active will
> greatly disappoint their customers. You will increasingly see large
> applications reduced to netlists which have a very high toggle
> percentage. The user will see that his application compiles to X number
> of LUTs, and will be buying devices with just over that number of LUTs
> to run the application. If the user does not encounter a clear warning
> to derate the device, then we have a truth in advertising problem.
> 
> Something akin to purchasing a family car advertised to cruise on the
> freeway at 75mph with an economy of 35mpg. Customers will not find the
> car acceptable, if it can only be operated at those speeds for 10
> minutes, and require a 50 minute inactive period on the side of the
> road to cool down because some engineer decided to save a few
> horsepower by removing the water pump and the rest of the cooling
> system. Cars are assumed to have short term duty cycles in hours, not
> minutes.
> 
> While hardware design engineers may have grown used to the omissions in
> the data sheet about duty cycles for FPGAs, the new reconfigurable
> computing market is going to be much less tollerant of devices that can
> only be operated with a 10% duty cycle, or at 10% of rated capacity.
> 
> If the data sheet says 1M LUTs capable of 800Mhz, then that is what is
> expected by end users looking at the data sheets to purchase FPGA's for
> computing. If the device is really only capable of 10% of 1M LUTs at
> 800Mhz, then from a reconfigurable computer perspective it's really
> just that, a 100K LUT device, not a 1Mhz LUT device.
> 
> Likewise, if there is only one routing solution that will achieve 100%
> utilization of the device, and a typical reconfigurable computing
> netlist will be route limited at 65% utilizaton, then a 1M LUT device
> is NOT a 1M usable LUT device, but rather only a 650K LUT device for
> typical reconfigurable computing uses.
> 
> So, this is not the 1980's any more, or even the 1990's ... a new
> emerging primary market for FPGAs is reconfigurable computing and we
> need devices which are clearly specified for worst case loads that will
> be typical ... not the exception ... in that market.
> 

I think you are a little off track here.  As a practical matter, without 
a significant amount of handcrafting, you are not going to pack a device 
close to 100% AND achieve corner of the envelope operating speeds.  It 
just isn't going to happen with a typical synthesized RTL design.

Further, unless the design is all bit-serial, you are going to have 
average toggle rates across the die less than 15%.  Even with 100% bit 
serial designs, you'll very rarely see average toggle rates exceed even 50%.

Yes, you can drive a part hard, and in some cases you'll need a heatsink 
on it, but the synthesized RTL designs being turned out are not 
typically going to get you into that corner.

Article: 95583
Subject: Re: Irrelevant, stupid, racist, and worse.
From: Ray Andraka <ray@andraka.com>
Date: Tue, 24 Jan 2006 09:46:38 -0500
Links: << >>  << T >>  << A >>
fpga_toys@yahoo.com wrote:

> fpga_toys@yahoo.com wrote:
> 
> 
>>absoulutly true ... but not the whole thread, or even vary many of the
>>authors in the thread ... the brash branding of the entire thread, even
> 
> 
> For those that missed it, there is a long wonderful thread in the
> middle of the junk regarding EE's and PE's by people like Ray that are
> always generally respected in this forum. The brash branding of the
> entire thread is knee jerk - ignore the trolls, follow the content.
> 

Yeah, I should have changed the subject in my first reply.

Article: 95584
Subject: Re: Xilinx padding LC numbers, how do you really feel about it?
From: John_H <johnhandwork@mail.com>
Date: Tue, 24 Jan 2006 14:56:07 GMT
Links: << >>  << T >>  << A >>
fpga_toys@yahoo.com wrote:
> Austin Lesea wrote:
> 
>>OK, OK.  We have heard you.
>>As I said, Peter and I will do our best to influence "truth in counting."
> 
> 
> Does that mean we will see either total power or derating curves for
> LUT/FF toggles to define power and thermal limits as both a percentage
> of active logic or size of the active design?

<snip>

Just so that I understand you (as someone watching from the peanut 
gallery) are you suggesting that there is not enough information to 
determine whether a heavily-loaded device will work?  The maximum 
allowable junction temperature is in the data sheet, the heat transfer 
values are package-specicif so they're included in the package 
documentation.  Since each I/O can handle such large currents, I'm 
assuming (I do nt know for certain) that the Vccint and Gnd pins can 
handle any current you push into the device.  It *is* an engineering 
exercise to determine the power draw of any non-simple FPGA and provide 
an appropriate power and cooling environment or do you believe otherwise?

So...  If someone can attach a heat-pipe cooling apparatus with 0.295 
deg C/watt (recently seen for high ambient temperature CPU cooling) and 
a power supply capable of pushing in unlimited current, will the large 
devices just not work?

I love the idea of getting the information "clean" in the data sheet but 
I don't understand what information could be provided to an unsupervised 
newbie engineer biting off more of a design than he should be allowed to 
develop because he obviously doesn't have the experience to understand 
engineering tradeoff in programmable devices without clouding the 
datasheet with significant amounts of information of little interest to 
98% of engineers who actually do their work with the information already 
at hand.

The arguement in this thread was that misleading numbers suck for 
engineers.  Do you honestly believe that it's misleading not to 
hand-hold the engineer by applying 20 more pages of drivel that should 
be in app notes or analysis tools?

I'd really hate to see the attitude of communicating information to the 
data sheet's target audience effectively be hampered by the attitude 
that any engineer should be able to know everything about how to design 
FPGAs from the data sheet alone.

So, if you're not just venting because you blew up a board in the past 
because you didn't do a proper engineering job, WHAT information in a 
properly cooled, powered, analyzed FPGA design should NOT be in a decent 
application note but in every device data sheet?  "Derating" doesn't 
float with me unless you have specific ideas on how this information 
should be effectively delivered in the technical document intended to 
communicate the details of the specific FPGA device family.

- John_H

Article: 95585
Subject: Re: Very OT: Americanized family names
From: Pooh Bear <rabbitsfriendsandrelations@hotmail.com>
Date: Tue, 24 Jan 2006 15:50:27 +0000
Links: << >>  << T >>  << A >>


news@rtrussell.co.uk wrote:

> In comp.arch.fpga Rich Grise, but drunk <yahright@example.net> wrote:
> : But I'm probably biased - I apparently have mostly German Blood, which
> : is probably why the "Americanized" version of my family name is so hard
> : to pronounce.
>
> I've always wondered, does the American surname Straub originate
> from a mis-reading of Strauss with an Eszett (German double-s) ?

Sounds very plausible.

Graham


Article: 95586
Subject: Re: Very OT: Americanized family names
From: "Richard Henry" <rphenry@home.com>
Date: Tue, 24 Jan 2006 07:54:47 -0800
Links: << >>  << T >>  << A >>

<news@rtrussell.co.uk> wrote in message
news:dr597s$bif$1@nntp0.reith.bbc.co.uk...
> In comp.arch.fpga Rich Grise, but drunk <yahright@example.net> wrote:
> : But I'm probably biased - I apparently have mostly German Blood, which
> : is probably why the "Americanized" version of my family name is so hard
> : to pronounce.
>
> I've always wondered, does the American surname Straub originate
> from a mis-reading of Strauss with an Eszett (German double-s) ?

Because it looks like a B to eyes not accusomed to reading German.



Article: 95587
Subject: Re: Very OT: Americanized family names
From: Jim Thompson <To-Email-Use-The-Envelope-Icon@My-Web-Site.com>
Date: Tue, 24 Jan 2006 09:15:53 -0700
Links: << >>  << T >>  << A >>
On Tue, 24 Jan 2006 07:54:47 -0800, "Richard Henry" <rphenry@home.com>
wrote:

>
><news@rtrussell.co.uk> wrote in message
>news:dr597s$bif$1@nntp0.reith.bbc.co.uk...
>> In comp.arch.fpga Rich Grise, but drunk <yahright@example.net> wrote:
>> : But I'm probably biased - I apparently have mostly German Blood, which
>> : is probably why the "Americanized" version of my family name is so hard
>> : to pronounce.
>>
>> I've always wondered, does the American surname Straub originate
>> from a mis-reading of Strauss with an Eszett (German double-s) ?
>
>Because it looks like a B to eyes not accusomed to reading German.
>

Yep.  Strauss <=> Strauß

                                        ...Jim Thompson
-- 
|  James E.Thompson, P.E.                           |    mens     |
|  Analog Innovations, Inc.                         |     et      |
|  Analog/Mixed-Signal ASIC's and Discrete Systems  |    manus    |
|  Phoenix, Arizona            Voice:(480)460-2350  |             |
|  E-mail Address at Website     Fax:(480)460-2142  |  Brass Rat  |
|       http://www.analog-innovations.com           |    1962     |
             
     It's what you learn, after you know it all, that counts.

Article: 95588
Subject: Newbie: xilinx vs arm
From: unlogic@o2.pl
Date: 24 Jan 2006 08:41:28 -0800
Links: << >>  << T >>  << A >>
Hello,

My knowledge on fpga field is almost zero. Ive got few questions.
I would like to enter into fpga world. Ive thought about buying starter
kit to start to play.
Ive found few spartans boards and arm's.

Whats the diffrence between them (development utils, hardware) ?

Ive seen that arm has gnuarm and arm-linux, does it mean that I can
program arm processor using C / C++ ?
If yes that seems  to be quite fast method rather then writing the same
in HDL ?

HDL describes hardware circuits, C / C++ is software programming
language - does it mean that arm is rather "hardware procesor"  and
spartans are rather fpga's ?
Is it possible to write in C/C++ into spartan and vice versa in HDL
with arm ?

Are there others processors which counts on this field ?

Ive would like to start feel whats going on fpga field .. soo if anyone
would point me in some directions would be great.

Thanks
-- 
un.


Article: 95589
Subject: Re: Very OT: Americanized family names
From: "John_H" <johnhandwork@mail.com>
Date: Tue, 24 Jan 2006 16:43:27 GMT
Links: << >>  << T >>  << A >>
For all those who care to respond to this thread, PLEASE REMOVE 
comp.arch.fpga from the cross-postings.

<news@rtrussell.co.uk> wrote in message 
news:dr597s$bif$1@nntp0.reith.bbc.co.uk...
> In comp.arch.fpga Rich Grise, but drunk <yahright@example.net> wrote:
> : But I'm probably biased - I apparently have mostly German Blood, which
> : is probably why the "Americanized" version of my family name is so hard
> : to pronounce.
>
> I've always wondered, does the American surname Straub originate
> from a mis-reading of Strauss with an Eszett (German double-s) ?
>
> Richard
> http://www.rtrussell.co.uk/
> To reply by email change 'news' to my forename. 



Article: 95590
Subject: Re: Data2Mem with CRC for Virtex FPGAs
From: "John D. Davis" <johnd@stanford.edu>
Date: Tue, 24 Jan 2006 08:56:48 -0800
Links: << >>  << T >>  << A >>
Hi Antti,

The bitpatch.exe worked for the Xilinx XCV1000.  It calculated the CRC and
replaced the default CRC. I tested it this past weekend by starting with a
known good bit file and updating the BRAMs used as cache with 6 different
programs.  XCV1000 don't support DISABLE_CRC, so the output of data2mem
did not program the FPGA.  I have a wrapper script/batch file that uses
data2mem + .bmm file and does the correct replacment. I then use your
bitpatch to replace the default CRC.  This saved several hours of
recompilation and all resulting downloads to the FPGA worked. Thanks for
the help. You have streamed this process and saved several days of me
hacking something based on Xilinx specs.

THANKS!
John

On Mon, 23 Jan 2006, Antti Lukats wrote:

> "John D. Davis" <johnd@stanford.edu> schrieb im Newsbeitrag
> news:Pine.GSO.4.44.0601181400370.9227-100000@elaine15.Stanford.EDU...
> > Is your library for the CRC generation available to others.
> >
> > JOhn
>
> http://help.xilant.com/Xilinx:Configuration:CRC
>
> the code snippet that does calc the CRC is at the above link,
> bitpatch utility with the ability to inject fixed CRC is scheduled for
> release as well
>
> --
> Antti Lukats
> http://www.xilant.com
>



Article: 95591
Subject: Re: Xilinx padding LC numbers, how do you really feel about it?
From: Austin Lesea <austin@xilinx.com>
Date: Tue, 24 Jan 2006 09:02:25 -0800
Links: << >>  << T >>  << A >>
toys,

Our FPGAs do not thermally "run away."

Yes, you can melt solder, with enough power.

But, we also provide the tools (web/spreadsheet/xpower) to predict that 
the power might be excessive.  That is engineering.

There is no way to 'derate' a design, until we know the entire design 
(or at least enough of it to run the web/spreadsheet power tools)

Sorry, there is just no other way to deal with the 200,000+ seats of 
software, and the 20,000+ designs happening at any given moment.

It is not an ASIC nor an ASSP that does one thing, one way.

It is a programmable device that can do just about anything from 
applications just below 1 watt, to applications just above 25 or 30 watts.

Why don't you try using the power prediction tool, and get a feel for 
what you can, and can not do?

How would you put that in a data sheet?

The recommended use of the tools is already in the users guides.

Austin


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

Ray Andraka wrote:
> I think you are a little off track here.  As a practical matter, without
> a significant amount of handcrafting, you are not going to pack a device
> close to 100% AND achieve corner of the envelope operating speeds.  It
> just isn't going to happen with a typical synthesized RTL design.

I haven't tried hard yet, and easily got "close" with several large
pipelined demos. I am concerned about what someone really concerned
about performance may fairly easily do. And in particular what does
that translate into regarding design envelopes for those that make PCI
add in FPGA
accelerator boards, and what should the customer clearly be aware of
and have disclosed for selection guidelines in Reconfigurable Computing
(RC) platforms.  Issues like monitoring the on die temp diode is barely
optional. The programmers for these platforms are not expected to be
EE's with 10 years of designing FPGA systems under their belts. Having
good, easy to read and understand limits for dynamic power, that the
board can handle by design, is critical. Both for platform selection,
and operation. The Virtex 4 users manual is very clear about derating
I/Os for concurrent switching limits. We need similar data for the fpga
core resources in equally well documented clarity so that these
"programmers" have clear bounds.

> Further, unless the design is all bit-serial, you are going to have
> average toggle rates across the die less than 15%.  Even with 100% bit
> serial designs, you'll very rarely see average toggle rates exceed even 50%.

:) 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.

> Yes, you can drive a part hard, and in some cases you'll need a heatsink
> on it, but the synthesized RTL designs being turned out are not
> typically going to get you into that corner.

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.


Article: 95593
Subject: Re: Irrelevant, stupid, racist, and worse.
From: "Peter Alfke" <peter@xilinx.com>
Date: 24 Jan 2006 09:32:38 -0800
Links: << >>  << T >>  << A >>

Ray Andraka wrote:>
> Yeah, I should have changed the subject in my first reply.

I will do everything I can to keep this newsgroup focused on FPGAs. It
is already a wide span from naive newbie questions and homework
assignments to spicy comments about data sheet content. But that is
what we can and should handle in this newsgroup.

I issued my warning when I saw that mountain of crud descending on us:
off-topic, xenophobic, rambling like a drunken sailor, and often
downright stupid. The fact that our beloved and respected Ray Andraka
inserted some pearls of wisdom does not change the general view. The
thread started with a provocative question, and then degraded into
rambling chaos.
I have watched other newsgroups fall into a similar trap, and I suggest
we band together to avoid this here. The subject is FPGAs, and we
should not get dragged into semi-intelligent (often un-informed and
even stupid) discussions about completely different subjects. There are
thousands of other newsgroups that do ventilate all sorts of ideas.
We have avoided spam, we should also be able to avoid an invasion like
the one I objected to.
Peter Alfke


Article: 95594
Subject: Re: Xilinx padding LC numbers, how do you really feel about it?
From: acher@in.tum.de (Georg Acher)
Date: 24 Jan 2006 17:37:06 GMT
Links: << >>  << T >>  << A >>
fpga_toys@yahoo.com writes:

>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.

But you can measure the core supply current. Should be easy enough to do some
correlation between current und temperature, at least for a user warning.

-- 
         Georg Acher, acher@in.tum.de
         http://www.lrr.in.tum.de/~acher
         "Oh no, not again !" The bowl of petunias

Article: 95595
Subject: Re: OT:Shooting Ourselves in the Foot
From: Rich The Philosophizer <rtp@example.net>
Date: Tue, 24 Jan 2006 17:43:40 GMT
Links: << >>  << T >>  << A >>
On Tue, 24 Jan 2006 01:55:29 +0000, Michael A. Terrell wrote:

> Proverbs 23:9
>                             Speak not in the ears of a fool:
>                             for he will despise the wisdom
>                             of thy words.

Hm. Sounds like a good idea.

Cheers!
Rich


Article: 95596
Subject: Re: Irrelevant, stupid, racist, and worse.
From: "John_H" <johnhandwork@mail.com>
Date: Tue, 24 Jan 2006 17:50:15 GMT
Links: << >>  << T >>  << A >>
"Peter Alfke" <peter@xilinx.com> wrote in message 
news:1138123958.101066.307150@g43g2000cwa.googlegroups.com...

<snip>

> I issued my warning when I saw that mountain of crud descending on us:
> off-topic, xenophobic, rambling like a drunken sailor, and often
> downright stupid. The fact that our beloved and respected Ray Andraka
> inserted some pearls of wisdom does not change the general view. The
> thread started with a provocative question, and then degraded into
> rambling chaos.
> I have watched other newsgroups fall into a similar trap, and I suggest
> we band together to avoid this here. The subject is FPGAs, and we
> should not get dragged into semi-intelligent (often un-informed and
> even stupid) discussions about completely different subjects. There are
> thousands of other newsgroups that do ventilate all sorts of ideas.
> We have avoided spam, we should also be able to avoid an invasion like
> the one I objected to.
> Peter Alfke

I started watching sci.electronics.design since analog and RF stuff tends to 
show up there, not here.  It was sad to see just how many "OT:" posts there 
are and how miserable they get.  Politics, bigotry, and general downright 
ugliness.  The only reason we got the inappropriate thread - as far as I can 
tell - is because the original poster cross-posted to three groups.  The 
scum-factor in sci.electronics.design spilled over full-force into our 
otherwise helpful usenet forum.

I don't even bother looking for the pearls of wisdom in anything with "OT:" 
in the header unless the rest of the subject catches my attention.  There 
are better places for those rants but some people feel "obliged" to "sling 
poo" through the internet where it shouldn't be slung.

- John_H 



Article: 95597
Subject: Re: Xilinx padding LC numbers, how do you really feel about it?
From: "John_H" <johnhandwork@mail.com>
Date: Tue, 24 Jan 2006 17:59:37 GMT
Links: << >>  << T >>  << A >>
<fpga_toys@yahoo.com> wrote in message 
news:1138123483.242619.84800@g49g2000cwa.googlegroups.com...
<snip>
> I haven't tried hard yet, and easily got "close" with several large
> pipelined demos. I am concerned about what someone really concerned
> about performance may fairly easily do. And in particular what does
> that translate into regarding design envelopes for those that make PCI
> add in FPGA
> accelerator boards, and what should the customer clearly be aware of
> and have disclosed for selection guidelines in Reconfigurable Computing
> (RC) platforms.
<snip>

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.  The board manufacturer should have 
specific published design limits for the board.  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.

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: 95598
Subject: Re: working with XDL
From: ptkwt@aracnet.com (Phil Tomson)
Date: 24 Jan 2006 18:01:27 GMT
Links: << >>  << T >>  << A >>
In article <1138066953.145439.135570@f14g2000cwb.googlegroups.com>,
 <fpga_toys@yahoo.com> wrote:
>
>Brian Drummond wrote:
>> IMO there should be no conflict between the continued existence of a
>> technology in open-source form using XDL, and the same or derived
>> technology streamlined into the push-button flow using NCD.
>> Xilinx use open-source tools for PPC development already.
>
>As long as the project didn't inadvertently compile and disclose the
>routing
>database as the JHDLbits project did, things are probably ok. As Phil
>notes though, and others have suggested, one set of tools that would
>be interesting would be ones capable of fixing bad nets, and that would
>require a database of chip capabilities and architecture that is
>currently
>only visible from the floor planner and device editors. Extracting that
>data and archiving it in a format useable for third party tools is
>pretty
>much what got the JHDLbits project shut down.
>

I'm not aware of the history of JHDLbits; can you give a few details?  I'm 
assuming it was an open source project (as JHDL is) so they must've gotten 
a cease & desist letter at some point.

Is there any way of avoiding the same fate?

Phil


Article: 95599
Subject: Re: OT:Shooting Ourselves in the Foot
From: Joerg <notthisjoergsch@removethispacbell.net>
Date: Tue, 24 Jan 2006 18:27:42 GMT
Links: << >>  << T >>  << A >>
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.

Regards, Joerg

http://www.analogconsultants.com



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