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 119175

Article: 119175
Subject: Re: An Open-Source suggestion for Xilinx
From: fpga_toys@yahoo.com
Date: 14 May 2007 10:42:48 -0700
Links: << >>  << T >>  << A >>
On May 8, 4:34 am, Antti <Antti.Luk...@xilant.com> wrote:
> 1) Impact TCP protocol has been reverse engineered
>  and there is open-source cable-server
> 2) I have tried to make software support for Cable IV high
>  speed mode, even made special FPGA-PCI design that emulates
>  LPT port + Cable IV. There is no final result on that yet.
> 3) I have written Coolrunner disassembler in order to reverse
>  engineer the Cable IV code
> 4) There is 3rd party replacement firmware for USB platform cable
> 5) possible more projects that we dont know about.

The biggest problem with much of this, is a mine field caused by the
Xilinx NDA in their software license, combined with US copyright laws
(slightly mitigated by EU restrictions), especially where any form of
encryption is used for protection.

Some open source projects have openly ignored the legal reverse
engineering standards, requiring independent teams to write functional
specifications and do the implementation from those clean room
specifications without knowledge of the original implementation
details and coding. Failure to do so. leaves the reverse engineered
(rewritten) product contaminated or tainted, and a derivative work.
These legal standards for reverse engineering were set by years of
litigation by major corporations, and set a very clear line in the
sand about what is, and is not, legal ... right down to hiring workers
which have detailed inside knowledge of a product and what that worker
can do at a new employers shop.

In the US, such reverse engineering failures can result in significant
legal judgements, and/or possible jail where encryption algorithms are
concerned, or risk of flight exists to avoid court proceedings. Even
if you live abroad, entry into the US after such violations, can leave
you in jail, if US laws are applied to you when you enter.

Selling products which violate Xilinx IP rights, or giving them away
as open source, will give Xilinx the power to pick and choose who they
wish to enforce their rights against. The Xilinx software NDA terms
are very broad, so if the information you use for the reverse
engineering is included in their software products, watch out ...
carefully follow both the US and EU laws.

It's this simple problem of Xilinx NDA and license terms that makes
the company very very high risk to support with open source
development. They include/use major Open Source products freely, but
then hide behind these very strict NDA and License terms to protect
everything from documentation, algorithms, to data formats from being
used openly for open source development to support their product line.
We've had this discussion several times in this forum.

John


Article: 119176
Subject: Re: Camera Control
From: Andy Peters <google@latke.net>
Date: 14 May 2007 11:25:48 -0700
Links: << >>  << T >>  << A >>
On May 14, 3:39 am, "MJ Pearson" <mjp...@york.ac.uk> wrote:
> Hello, I have a xupv2p board and I am wanting to use this board to perform image processing from 2 camera-link based cameras. I am building a connection board that will connect the cameras to the board and perform the de-serialization of the signals.

Save yourself a lot of aggravation, and use one of the National
Semiconductor Camera Link chips to do the de-serialization.  For
example, see: http://www.national.com/pf/DS/DS90CR288A.html.

-a


Article: 119177
Subject: Re: How to Ask a Question
From: Bob Perlman <bobsrefusebin@hotmail.com>
Date: Mon, 14 May 2007 11:54:04 -0700
Links: << >>  << T >>  << A >>
On Mon, 14 May 2007 15:45:51 +0100, "Symon" <symon_brewer@hotmail.com>
wrote:

>p.s. The Google toolbar has this great feature where you can add a Xilinx 
>(or anything else) search to your toolbar. If you have the thing installed, 
>go to the Xilinx website, right click on the search box in the top right, 
>click 'Generate Custom Search' in the menu box. V. useful. 
>
Excellent!  I never would have found that myself.  A tip o' the hat to
you, sir, and to our Google overlords.

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

Article: 119178
Subject: Re: An Open-Source suggestion for Xilinx
From: fpga_toys@yahoo.com
Date: 14 May 2007 12:15:36 -0700
Links: << >>  << T >>  << A >>
The legal requirements for reverese engineering date back to 1970's
and 1980's. Big name successes were clean-room reverse engineering of
the BIOS for the IBM PC by Compaq and Pheonix in the early 1980's, and
AMD's clean room versions of Intel Microcode. See

http://en.wikipedia.org/wiki/Clean_room_design
http://en.wikipedia.org/wiki/Compaq_Computer_Corporation
http://software.newsforge.com/article.pl?sid=06/02/01/1630225&tid=132&tid=25
http://en.wikipedia.org/wiki/Advanced_Micro_Devices

As a result, we frequently see license terms which completely bar
reverse-engineering, so even where it might be completely legal
otherwise, such as areas outside the US, the legal contract created by
the license and NDA extends the protections in ways that can result in
civil and criminal litigation. In places where the legal protections
are lacking, it's quite common to see licenses which specifically
prevent it's sale into those regions, holding the seller/buyer at risk
under US law.


Article: 119179
Subject: Timing constraint question
From: Dima <Dmitriy.Bekker@gmail.com>
Date: 14 May 2007 13:27:53 -0700
Links: << >>  << T >>  << A >>
Hello,

I am trying to specify a timing constraint for a latch that I have in
my design. I need to make sure that from the rising edge of the clock
to when a control signal goes high that causes the latch to switch, I
have less than one clock cycle delay.

This is my UCF file:

#######################
## System level constraints
Net CLK TNM_NET = CLK;
TIMEGRP "RISING_CLK" = RISING "CLK";
NET "add1_rdy" TPTHRU = "ADD1_RDY";
NET "accumulate<31>" TNM_NET = ACC;
NET "accumulate<30>" TNM_NET = ACC;
NET "accumulate<29>" TNM_NET = ACC;
NET "accumulate<28>" TNM_NET = ACC;
NET "accumulate<27>" TNM_NET = ACC;
NET "accumulate<26>" TNM_NET = ACC;
NET "accumulate<25>" TNM_NET = ACC;
NET "accumulate<24>" TNM_NET = ACC;
NET "accumulate<23>" TNM_NET = ACC;
NET "accumulate<22>" TNM_NET = ACC;
NET "accumulate<21>" TNM_NET = ACC;
NET "accumulate<20>" TNM_NET = ACC;
NET "accumulate<19>" TNM_NET = ACC;
NET "accumulate<18>" TNM_NET = ACC;
NET "accumulate<17>" TNM_NET = ACC;
NET "accumulate<16>" TNM_NET = ACC;
NET "accumulate<15>" TNM_NET = ACC;
NET "accumulate<14>" TNM_NET = ACC;
NET "accumulate<13>" TNM_NET = ACC;
NET "accumulate<12>" TNM_NET = ACC;
NET "accumulate<11>" TNM_NET = ACC;
NET "accumulate<10>" TNM_NET = ACC;
NET "accumulate<9>" TNM_NET = ACC;
NET "accumulate<8>" TNM_NET = ACC;
NET "accumulate<7>" TNM_NET = ACC;
NET "accumulate<6>" TNM_NET = ACC;
NET "accumulate<5>" TNM_NET = ACC;
NET "accumulate<4>" TNM_NET = ACC;
NET "accumulate<3>" TNM_NET = ACC;
NET "accumulate<2>" TNM_NET = ACC;
NET "accumulate<1>" TNM_NET = ACC;
NET "accumulate<0>" TNM_NET = ACC;

# Constrain CLK to 200 MHz
TIMESPEC TS_CLK = PERIOD CLK 5 ns;

# Constrain the accumulate latch (one CLK cycle)
TIMESPEC TS_ACC_LATCH = FROM "RISING_CLK" THRU "ADD1_RDY" TO "ACC"
TS_CLK * 0.99;
#######################

During PAR, I always get the message that the following constraint is
ignored:
WARNING:Timing:3223 - Timing constraint TS_ACC_LATCH = MAXDELAY FROM
TIMEGRP "RISING_CLK" THRU TIMEGRP "ADD1_RDY" TO TIMEGRP "ACC" TS_CLK *
0.99; ignored during timing analysis.

Why is that? What is the right way to specify what I'm trying to
constraint?

Thanks


Article: 119180
Subject: Re: Timing constraint question
From: "John_H" <newsgroup@johnhandwork.com>
Date: Mon, 14 May 2007 13:45:18 -0700
Links: << >>  << T >>  << A >>
Are you cutting and pasting directly?  I haven't seen the Xilinx tools add 
the MAXDELAY in the timing constraint before.  If there is no MAXDELAY 
keyword in your definition, is the add1_rdy net in your compiled design?  If 
it got renamed, the "THRU" could be a problem.

Suggestion:  if you only have the 32 bit bus by that name, try
  NET "accumulate<*>" TNM_NET = ACC;
to specify all 32 wires feed the latches that you want fixed.

If the accumulate bus is the latch output, that would be your problem: the 
TNM_NET tags all *downstream* synchronous elements.  Me, I'd just include 
the latches directly in the TO part as LATCHES( MyLatches<*> ) rather than 
using the TNM_NET to tag them all.

- John_H


"Dima" <Dmitriy.Bekker@gmail.com> wrote in message 
news:1179174473.784383.79900@n59g2000hsh.googlegroups.com...
> Hello,
>
> I am trying to specify a timing constraint for a latch that I have in
> my design. I need to make sure that from the rising edge of the clock
> to when a control signal goes high that causes the latch to switch, I
> have less than one clock cycle delay.
>
> This is my UCF file:
>
> #######################
> ## System level constraints
> Net CLK TNM_NET = CLK;
> TIMEGRP "RISING_CLK" = RISING "CLK";
> NET "add1_rdy" TPTHRU = "ADD1_RDY";
> NET "accumulate<31>" TNM_NET = ACC;
> NET "accumulate<30>" TNM_NET = ACC;
> NET "accumulate<29>" TNM_NET = ACC;
> NET "accumulate<28>" TNM_NET = ACC;
> NET "accumulate<27>" TNM_NET = ACC;
> NET "accumulate<26>" TNM_NET = ACC;
> NET "accumulate<25>" TNM_NET = ACC;
> NET "accumulate<24>" TNM_NET = ACC;
> NET "accumulate<23>" TNM_NET = ACC;
> NET "accumulate<22>" TNM_NET = ACC;
> NET "accumulate<21>" TNM_NET = ACC;
> NET "accumulate<20>" TNM_NET = ACC;
> NET "accumulate<19>" TNM_NET = ACC;
> NET "accumulate<18>" TNM_NET = ACC;
> NET "accumulate<17>" TNM_NET = ACC;
> NET "accumulate<16>" TNM_NET = ACC;
> NET "accumulate<15>" TNM_NET = ACC;
> NET "accumulate<14>" TNM_NET = ACC;
> NET "accumulate<13>" TNM_NET = ACC;
> NET "accumulate<12>" TNM_NET = ACC;
> NET "accumulate<11>" TNM_NET = ACC;
> NET "accumulate<10>" TNM_NET = ACC;
> NET "accumulate<9>" TNM_NET = ACC;
> NET "accumulate<8>" TNM_NET = ACC;
> NET "accumulate<7>" TNM_NET = ACC;
> NET "accumulate<6>" TNM_NET = ACC;
> NET "accumulate<5>" TNM_NET = ACC;
> NET "accumulate<4>" TNM_NET = ACC;
> NET "accumulate<3>" TNM_NET = ACC;
> NET "accumulate<2>" TNM_NET = ACC;
> NET "accumulate<1>" TNM_NET = ACC;
> NET "accumulate<0>" TNM_NET = ACC;
>
> # Constrain CLK to 200 MHz
> TIMESPEC TS_CLK = PERIOD CLK 5 ns;
>
> # Constrain the accumulate latch (one CLK cycle)
> TIMESPEC TS_ACC_LATCH = FROM "RISING_CLK" THRU "ADD1_RDY" TO "ACC"
> TS_CLK * 0.99;
> #######################
>
> During PAR, I always get the message that the following constraint is
> ignored:
> WARNING:Timing:3223 - Timing constraint TS_ACC_LATCH = MAXDELAY FROM
> TIMEGRP "RISING_CLK" THRU TIMEGRP "ADD1_RDY" TO TIMEGRP "ACC" TS_CLK *
> 0.99; ignored during timing analysis.
>
> Why is that? What is the right way to specify what I'm trying to
> constraint?
>
> Thanks
> 



Article: 119181
Subject: Re: Timing constraint question
From: Dima <Dmitriy.Bekker@gmail.com>
Date: 14 May 2007 14:20:06 -0700
Links: << >>  << T >>  << A >>
Thanks John,

I changed my UCF file to:

## System level constraints
Net CLK TNM_NET = CLK;
TIMEGRP "RISING_CLK" = RISING "CLK";

# Constrain CLK to 200 MHz
TIMESPEC TS_CLK = PERIOD CLK 5 ns;

# Constrain the accumulate latch (one CLK cycle)
TIMESPEC TS_ACC_LATCH = FROM "RISING_CLK" TO LATCHES( accumulate<*> )
TS_CLK * 0.99 DATAPATHONLY;

Now that latch constraint is picked up by ISE. I don't think I need
the THRU as the ready signal is synchronous with the clock.

And to answer your question, yes, the MAXDELAY was inserted
automatically by ISE when it gave the warning in my previous post.

Thanks


Article: 119182
Subject: Re: An Open-Source suggestion for Xilinx
From: fpga_toys@yahoo.com
Date: 14 May 2007 14:24:14 -0700
Links: << >>  << T >>  << A >>
On May 9, 6:07 pm, Jim Granville <no.s...@designtools.maps.co.nz>
wrote:
> How did the GPUs stack up in this comparison ?


Sorry, miss place my copy of the proceedings ... here are a few points
from the paper presented at FCCM 4/24/07 by Los Alamos Labs: "Matched
Filter Computation on FPGA, Cell, GPU", by Zachary Baker, Maya
Gokhale, and Justin Tripp.

Implementation           Speedup         Cost       Power
Speedup/$K    Speedup/kWatt
Cray XD1/2VP50           3.91             $10K       350W
0.39                   11.2
Nvidia GeForce 7900     3.10            $2.6K      350W
1.24                    8..7
IBM Cell  Processor       8.0              $8K         315W
1.0                    25.4

This table is normalized to a reference CPU. The authors presentation
provided a great wealth of comparitive development cost issues not
presented in the paper, where the FPGA and GPU didn't fare well ...
lack of tools and internals documention for optimization.  With the
Cell processor going commodity, it is very likely to take over
numerical applications where FPGA's previously had leadership ... such
as DSP.

I still believe the FPGA's have a good market ... if large FPGA's can
leverage commodity pricing combined with excellent low cost license
free tools. Since this is a completely different market, with very
different expectations, it's unlikely the existing vendors tools team
can/will provide the tools. They are still focused on what hardware
designers need, not large scale programmer lead teams that are
certainly NOT going to code in VHDL.

With the cost of electricity soaring with energy cost increases, we
are already seeing $0.36/KWH in some places. So Super Computer
faciities that are tens of megawatts are seeing cost of ownership
hinge on power and cooling costs.


Article: 119183
Subject: Re: Timing constraint question
From: "John_H" <newsgroup@johnhandwork.com>
Date: Mon, 14 May 2007 14:32:34 -0700
Links: << >>  << T >>  << A >>
So the problem probably was the TNM_NET corresponding to downstream elements 
rather than the latch itself.

If I wanted to group a bunch of synchronous elements by name, another way 
would be to use the INST rather than the NET to associate with a group, 
using TNM rather than TNM_NET.  I believe that's what gets you the good 
associations that aren't simply convenient wildcard groups.

Are you adding this TIMESPEC because Xilinx tools associate the WRONG edge 
with the timing analysis result?  I never have been happy with default 
timing analysis with latches.



"Dima" <Dmitriy.Bekker@gmail.com> wrote in message 
news:1179177606.917789.47830@e51g2000hsg.googlegroups.com...
> Thanks John,
>
> I changed my UCF file to:
>
> ## System level constraints
> Net CLK TNM_NET = CLK;
> TIMEGRP "RISING_CLK" = RISING "CLK";
>
> # Constrain CLK to 200 MHz
> TIMESPEC TS_CLK = PERIOD CLK 5 ns;
>
> # Constrain the accumulate latch (one CLK cycle)
> TIMESPEC TS_ACC_LATCH = FROM "RISING_CLK" TO LATCHES( accumulate<*> )
> TS_CLK * 0.99 DATAPATHONLY;
>
> Now that latch constraint is picked up by ISE. I don't think I need
> the THRU as the ready signal is synchronous with the clock.
>
> And to answer your question, yes, the MAXDELAY was inserted
> automatically by ISE when it gave the warning in my previous post.
>
> Thanks



Article: 119184
Subject: Re: Timing constraint question
From: Dima <Dmitriy.Bekker@gmail.com>
Date: 14 May 2007 15:05:34 -0700
Links: << >>  << T >>  << A >>
The only reason I am specifying this TIMESPEC is so ISE throws me a
failing constraint if the latching delay exceeds one clock cycle.
There is a control signal (synchronous with clock) that sets / resets
the accumulator (32-bit signal), but the latch itself is asynchronous.
I can't make this synchronous because the control line changes state
after a small delay from the edge of the clock and I need the latch to
switch right away and stabilize before the next rising edge. So this
TIMESPEC serves as a check to make sure if I specify a high frequency
clock, the latching delay does not exceed the one clock cycle. And it
is also indicates what the delay actually is (its a little over 2ns in
this case) so I can take note of it.


Article: 119185
Subject: Re: An Open-Source suggestion for Xilinx
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Tue, 15 May 2007 10:07:12 +1200
Links: << >>  << T >>  << A >>
fpga_toys@yahoo.com wrote:
> On May 9, 6:07 pm, Jim Granville <no.s...@designtools.maps.co.nz>
> wrote:
> 
>>How did the GPUs stack up in this comparison ?
> 
> 
> 
> Sorry, miss place my copy of the proceedings ... here are a few points
> from the paper presented at FCCM 4/24/07 by Los Alamos Labs: "Matched
> Filter Computation on FPGA, Cell, GPU", by Zachary Baker, Maya
> Gokhale, and Justin Tripp.
> 
> Implementation           Speedup         Cost       Power
> Speedup/$K    Speedup/kWatt
> Cray XD1/2VP50           3.91             $10K       350W
> 0.39                   11.2
> Nvidia GeForce 7900     3.10            $2.6K      350W
> 1.24                    8..7
> IBM Cell  Processor       8.0              $8K         315W
> 1.0                    25.4
> 
> This table is normalized to a reference CPU. The authors presentation
> provided a great wealth of comparitive development cost issues not
> presented in the paper, where the FPGA and GPU didn't fare well ...
> lack of tools and internals documention for optimization.  With the
> Cell processor going commodity, it is very likely to take over
> numerical applications where FPGA's previously had leadership ... such
> as DSP.
> 
> I still believe the FPGA's have a good market ... if large FPGA's can
> leverage commodity pricing combined with excellent low cost license
> free tools. Since this is a completely different market, with very
> different expectations, it's unlikely the existing vendors tools team
> can/will provide the tools. They are still focused on what hardware
> designers need, not large scale programmer lead teams that are
> certainly NOT going to code in VHDL.
> 
> With the cost of electricity soaring with energy cost increases, we
> are already seeing $0.36/KWH in some places. So Super Computer
> faciities that are tens of megawatts are seeing cost of ownership
> hinge on power and cooling costs.

Thanks - interesting numbers.
-jg



Article: 119186
Subject: Re: Xilinx software quality - how low can it go ?!
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Tue, 15 May 2007 10:09:13 +1200
Links: << >>  << T >>  << A >>
Antti wrote:

> I think it is.
> cable IV is nice piece of hardware when it works in high speed mode
> - but this is very seldom, on most PC's xilinx-software-drivers fall
> back into Cable III mode without explanation.
> 
> every other LPT connected software can use the LPT ports to the
> maximum, its just the crappy Xilinx drivers that can not handle it
> properly.

Imagine if they open sourced this, someone might be able to actually fix
it, and then everyone would benefit....

Xilinx ? Sounds like a good place to start ?

-jg


Article: 119187
Subject: Re: An Open-Source suggestion for Xilinx
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Tue, 15 May 2007 10:16:29 +1200
Links: << >>  << T >>  << A >>
Antti wrote:

> On 13 Mai, 12:00, pbF...@ludd.invalid wrote:
> 
>>Antti <Antti.Luk...@xilant.com> wrote:
>>
>>>Stephen Williams schrieb:
>>>
>>>>-----BEGIN PGP SIGNED MESSAGE-----
>>
>>>>Where I work, we've pretty much given up on being able to use
>>>>impact for anything other then writing ACE files, and it does
>>>>a clunky job at that. I suspect that open-sourcing impact would
>>>>make a *lot* of folks very very happy.
>>>
>>>Hi Steve
>>>I just recalled, I have reverse engineered the ACE file format
>>>even written ACE compressor and player, so the work has begun
>>>already :)
>>>ah, yes I can open-source the ACE player.. please remind in a few days
>>>should i forget..
>>
>>Isn't ACE just a compression algorithm/format..?
> 
> 
> I mean the "Xilinx ACE", file format for SystemACE
> its sort of JTAG bytecode, and the information is not public
> 
> its very simple code, and player is very simple too,
> way simpler than jam or xsvf...

Hi Antti,

A simpler bytecode/compression scheme sounds like something
that would benefit everyone ?

So, this is the requested reminder, after a few days, to open source this :)

I'd also cc Xilinx, and say this has wide industry support.

They could take a lead from Lattice - they are getting good
PR mileage from their Open Sourced SoftCPUs.

If I were in Xilinx, I'd sponser a web site for this stuff.
It's cheaper than $$$ advertising, and it really does help burnish
a tarnished image.

Xilinx ?

-jg




Article: 119188
Subject: Re: An Open-Source suggestion for Xilinx
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Tue, 15 May 2007 10:33:21 +1200
Links: << >>  << T >>  << A >>
fpga_toys@yahoo.com wrote:
> On May 9, 6:07 pm, Jim Granville <no.s...@designtools.maps.co.nz>
> wrote:
> 
>>How did the GPUs stack up in this comparison ?
> 
> 
> 
> Sorry, miss place my copy of the proceedings ... here are a few points
> from the paper presented at FCCM 4/24/07 by Los Alamos Labs: "Matched
> Filter Computation on FPGA, Cell, GPU", by Zachary Baker, Maya
> Gokhale, and Justin Tripp.
> 
> Implementation           Speedup         Cost       Power
> Speedup/$K    Speedup/kWatt
> Cray XD1/2VP50           3.91             $10K       350W
> 0.39                   11.2
> Nvidia GeForce 7900     3.10            $2.6K      350W
> 1.24                    8..7
> IBM Cell  Processor       8.0              $8K         315W
> 1.0                    25.4

I also see this in todays news:

AMD leapfrogs Nvidia with graphics chip
http://www.eetimes.com/news/latest/showArticle.jhtml;jsessionid=CGUERC2TICR3EQSNDLOSKHSCJUNN2JVN;?articleID=199501447

Of course, one's latest release _should_ come out in front of the 
opposition's  current production.
320 ALU and 512 bit memory...

"Both the AMD and Nvidia chips show graphics accelerators are undergoing 
a major shift from being specialized engines aimed at processing 
polygons and pixels to being highly-parallel general purpose processors. 
Intel Corp. has signaled it too will participate in this trend with a 
design in the works called Larabee about which it has so far not 
revealed many details."

Now, we just need the tools to catch up to the silicon :)


-jg



Article: 119189
Subject: bus macros for partial reconfiguration of virtex2pro?
From: "L. Schreiber" <l.s.rockfan@web.de>
Date: Tue, 15 May 2007 01:02:50 +0200
Links: << >>  << T >>  << A >>
Hi everybody.

I'm sitting over a partial reconfiguration project for university.

I'm absolutelly new to this topic, but as an introduction to this topic, 
of course I 've already read the concerning xilinx appsheets and several 
further sheets from 3rd persons or university papers that are going more 
into detail.

But they all have something in common. They don't say much about those 
bus macros, how they work, where to get them or how to create them. They 
mainly talk about the design flow.

In the last sheet I recently have read that fpga specific bus macros are 
available over the website of xilinx, but I had no success in finding 
them there.

Other sheets say, that you have to built them on your own via the fpga 
editor. But how, when it's absolutelly unclear to me how they work.

I'm also wondering if I have to create one bus macro in the fpga editor 
per 4 interconnecting signals between dynamic and static parts or if i 
can reuse one bus macro and instantiate from it several times in my vhdl 
code.

Maybe someone experienced to this can give me some advises and clarify 
some things.

The used device is a virtex2pro (xc2vp30-ff896) mounted on the ml310. 
used software is the ISE and EDK version 7.

Another problem with ISE I encountered is, that after I have build a new 
system via the base system builder and created a new ISE project from 
the vhdl-filed created by the EDK, the ISE cannot find those referenced 
vhdl modules from the xilinx library inside the EDK folder on the hard 
disk. Instead it marks all the components instantiated with a question 
mark. Does there exist a possibility to tell the ISE, where to look up 
for the library modules (a library path or something like that)?

thanks a lot for your help
greetings, Lars Schreiber

Article: 119190
Subject: Re: Power Consumption Estimation for PCI card, any advice?
From: Dave Greenfield <davidg@altera.com>
Date: 14 May 2007 18:42:02 -0700
Links: << >>  << T >>  << A >>
At Altera, power estimation is important. If customers rely on
accurate power estimates for making decisions on power management,
thermal management, and device selection, then accuracy also matters.
We vigorously test our power modeling across a large suite of customer
designs to ensure accuracy and continuous improvement.

2 differences comparing estimators for Stratix III and Virtex 5 . .
- clock power should not be omitted from the estimator (even the
Virtex-4 XPE includes a worksheet for clock power)
- register power should vary with toggle rate (it does for the Stratix
III EPE)

We've done the technical analysis and benchmarking on the accuracy of
the spreadsheet based tools. Details on power estimation and other
elements of Stratix III Programmable Power Technology (if you are
interested) are discussed in a recent net seminar at:
http://www.altera.com/education/net_seminars/all/ns-stratix3-design-power-voltage.html

Relying on 20% margin for estimation of Altera devices is reasonable.
Using consistent assumptions in early power estimators for device
selection benchmarking may not be reasonable.

Dave Greenfield
Altera Marketing



Article: 119191
Subject: Re: Power Consumption Estimation for PCI card, any advice?
From: austin <austin@xilinx.com>
Date: Mon, 14 May 2007 18:54:59 -0700
Links: << >>  << T >>  << A >>
And,

How predictable was that?

The fact that we beat them, hands down, for power on V4, led to Altera 
posing the estimator as the 'issue'.

Watch the shells, and keep your eye on that (power estimator) pea:  you 
know where it is, don't you?  You will win the prize.

Unfortunately, it is the oldest scam in the book.  Distract your 
attention, and cause you to focus where they want.  This all the while 
they rob you blind.

They can not have it both ways: is triple oxide bad or good?  If you 
read the Stratix 2 stuff, it is "bad" and "risky" and "unproven."

If you read Stratix 3 literature, it is "power saving" and a "breakthrough."

Imitation is the sincerest form of flattery.

Austin

Austin

Article: 119192
Subject: Re: How to Ask a Question
From: fpga_toys@yahoo.com
Date: 14 May 2007 20:47:29 -0700
Links: << >>  << T >>  << A >>
On May 14, 12:49 am, Bob Perlman <bobsrefuse...@hotmail.com> wrote:
> In light of a recent flameboree in these parts, I thought it might be
> helpful to provide a link to an article entitled, "How to Ask a
> Question the Smart Way."  Although aimed at programmers and programmer
> wannabes, the advice is equally applicable to hardware designers old
> and new.


Also be nice to have a good article on how to ANSWER it in a nice way
too :)

or not so nice ..... hehehe

http://www.flayme.com/


Article: 119193
Subject: Re: how to choose the perfect fpga support
From: JK <krishna.janumanchi@gmail.com>
Date: 14 May 2007 21:04:13 -0700
Links: << >>  << T >>  << A >>
On May 12, 4:54 am, Eric Smith <e...@brouhaha.com> wrote:
> kha_vhdl <abai...@gmail.com> writes:
> > i want know what are the basics that i should know to choose the
> > perfect fpga( for example Sparta,3 or Virtex 4 into Xlinx) and thank
> > you for your answer
>
> Add the family number, pin count, the number of CLBs, three times the
> number of multipliers, half the number of block RAMs, and the last
> four digits of the telephone number of the local vendor sales office,
> then divide by 42 for a figure of merit.  Pick the FPGA with the
> highest figure of merit, unless there is a full moon, in which case
> you should use the third-highest (or wait a few days).
>
> Eric

bingo..... :)
patent it... patent it.... patent it...

Regards,
JK


Article: 119194
Subject: Re: Power Consumption Estimation for PCI card, any advice?
From: Paul Leventis <paul.leventis@gmail.com>
Date: 14 May 2007 21:11:11 -0700
Links: << >>  << T >>  << A >>
Hello Leon,

The quality of a power estimate depends on many factors.  Let's talk
only about dynamic power, since our worst-case static power is a
specification and thus pessimistic by nature.

*Models*  The power models in Quartus II for our recent FPGAs are
extremely detailed and are correlated against silicon with many
thousands of different targeted designs.  Whatever Austin may think,
the models for Stratix II & Cyclone II predict dynamic power within a
range of +20..-10%.  We try to err on the side of slightly over-
predicting power since underpredicting has worse consequences for our
customers.  However, this assumes that we have *perfect vectors* for
the operation of your design.  And designs that have very glitchy
paths (for example, long XOR chains) could be over-predicted by the
tools even more.

*Design Information*  You've used the PowerPlay Power Analyzer on your
full design, so it knows everything - synthesis, placement, routing,
and bit settings.  However, for people who use the Early Power
Estimator spreadsheet, then it doesn't know everything -- it must make
guesses for LUT functions and length/fanout of routes, and you must
make guesses for block modes, etc.

*Vectors/Toggle Rates*  Assuming the tools & models are of high
quality, this is where the biggest source of error comes from.  Did
you provide vectors from a gate-level simulation of your full design?
Did your vectors truly reflect the worst-case mode of operation you
will encounter in the real system?  If you only had partial vectors,
Quartus will fill in the blanks (for example, for combinational logic
between registers in RTL simulations) -- and it's fairly good at this,
but this is another source of error.

Even with good models and perfect vectors, the power tools are
designed primarily for estimating power dissipation for thermal design
and/or battery life.  When it comes to adequately sizing your supply,
you begin to run into a new problem -- current transients.  Vectors
turn into average power over the period of simulation -- but you will
have periods of time where the switching exceeds this average.  But
then again, you have on-chip and off-chip decoupling capacitors that
filter/smooth out these spikes.  There is no quick-and-easy answer
here...

So at the end of the day, I can't help you with what a reasonable
guard-band is to apply to determine your power supply.  2X is a number
I know some customers use -- but that could be too low or horribly
over-engineered.  Some customers over-engineer their prototype, but
downsize their supplies after characterizing the first batch without
needing to respin the board design.

Sorry I can't give you a more concrete answer,

Paul Leventis
Altera Corp.


Article: 119195
Subject: Re: Power Consumption Estimation for PCI card, any advice?
From: Paul Leventis <paul.leventis@gmail.com>
Date: 14 May 2007 21:58:49 -0700
Links: << >>  << T >>  << A >>
Hi Austin,

I'm sure the readers of this newsgroup are shocked to hear that
companies try to draw attention to their own strengths and point out
competitor's weaknesses :-). Yes, we focus a lot on power, power
analysis, and power estimation for the reason you suggest -- we
believe we have clear advantages in this area, and we think power is
an important criteria of our customers when selecting devices.

> draw attention away from the areas where they do not
> excel, and into an area where no one can prove anything!

Open up you Virtex-5 estimator.  Type in 20000 FFs.  Set the toggle
rate to 10% and clock to 200 Mhz.  Then change the toggle rate to
20%.  No change in power despite a change in switching activity?  For
that matter, where is the clock tree power?  I guess bugs are expected
in software, but these are fairly egregious omissions.  Perhaps the
tool is accurate for designs without FFs and clocks, but somehow I
don't think that's a lot of your target market ;-)

> So, is Altera's power estimator that accurate?

Yes.  All your deflections aside, I have yet to see anything from you
to refute the accuracy of our estimators.

> I would give the estimate a 20% bump for what it might actually be in
> practice.  Any one unit will be under the estimate.  Only a fast corner
> processed part which is shipped to fill the order will come in at the
> high end of the estimate.  Since you can not only order "typical" parts,
> the additional margin is absolutely necessary.

This is a fairly confusing statement.  I'm not sure whether you are
talking about dynamic or static power or both.

If the power tool a customer is using does not provide "Maximum"
silicon characteristics, then yes, they need to bump up the *static
power* portion of the estimate.  How much depends on many factors, but
I believe Austin's own advice in the past has been 2X from typical to
maximum, and in the absence of any other information, 2X is actual not
a bad guess.  However, if the tool they are using has maximum or worst-
case specs available, then there is no need to guardband -- the
estimates already reflect the fastest they will receive.  Of course,
the junction temperature must be representative of the hottest
conditions the chip will be operating in, since temperature also has a
large impact on static power consumtion.

When it comes to dynamic power, process variation does not have a
strong impact.  When you select Maximum characteristics in the EPE/
Quartus, we do adjust dynamic power slightly to account for worst-case
dynamic power we see on corner units.  But this variation is small (a
few percent).  Metal cap can vary, but it varies independently between
metal layers (resulting in an averaging effect).  Faster transistors
have very little impact on dynamic power, since the capacitance that
needs to be charged is still the same, and the short-circuit current
becomes shorter (transistor switches faster) but more intense
(transistor pull current faster), resulting in little change in
dynamic power for most circuits.

> We also
> demonstrated how the same design in both chips led to a 15 to 20 degree
> C power savings in V4.

I am not familiar with the details of this particular design.  Is it
the same one you were showing customers that had some of our I/Os
shorted to power?  That was a nifty trick.  Very dramatic demo.

Regardless, there will always be designs that work well on one chip
vs. the other.  We also have demonstrated a number of designs to
customers and in various NetSeminars.  Short of making our HDL &
designs open to one another for critique, I doubt we will ever get
agreement (or complete buy-in from our audiences) on our dynamic power
demonstrations.

But what is more important in these demos is how good is estimator
accuracy?  At end of the day, its not only important which device
consumes lower power (I think ours do, you think yours do), but can
the customer figure out what that power will be early in the design
cycle?  Can they measure it or profile it accurately during design?
Can they optimize it with the push of a button in the CAD tools as
they can with Quartus?

Paul


Article: 119196
Subject: Re: Digital gain and offset correction
From: "Marco T." <marcotoschi@gmail.com>
Date: 14 May 2007 22:11:35 -0700
Links: << >>  << T >>  << A >>

Paul ha scritto:

> Gain = multiplication   or  even simpler, right bitshift if you only
> need scaling factors of powers of 2
> Offset = addition
>
> both operations are done very easily in an FPGA
>
> If you're really asking how to perform multiplication and addition in
> an fpga, then you should go purchase a decent VHDL or Verilog textbook
> - there are many out there.  For VHDL I like Andrew Rushton's VHDL for
> Logic Synthesis, but that's a personal preferance.  For Verilog I have
> no idea, but I'm sure many people here would be happy to recommend you
> one.
>
>
>
> On May 14, 2:31 am, "Marco T." <marcotos...@gmail.com> wrote:
> > Hallo,
> > which is the way to perform digital vgain and offset correction using
> > a fpga?
> >
> > Thanks,
> > Marco T.


I wasn't asking about how to perform addition and multiplication.

I was asking if there are other implementations or auto tuning-
techniques, in example if someone has made a loopback to perform it.

But if + and * are the only ones... so it's not useful to go on with
this conversation.

Marco T.


Article: 119197
Subject: Re: An Open-Source suggestion for Xilinx
From: Eric Smith <eric@brouhaha.com>
Date: 14 May 2007 23:46:55 -0700
Links: << >>  << T >>  << A >>
fpga_toys@yahoo.com writes:
> The biggest problem with much of this, is a mine field caused by the
> Xilinx NDA in their software license, combined with US copyright laws
> (slightly mitigated by EU restrictions), especially where any form of
> encryption is used for protection.

If your mention of US copyright laws is meant to reference the DMCA
provisions against reverse engineering for circumvention, it should
be noted that the DMCA specifically exempts reverse-engineering for
the purposes of achieving iteroperability.

Article: 119198
Subject: Re: bus macros for partial reconfiguration of virtex2pro?
From: David Kramer <kramer@ira.uka.de>
Date: Tue, 15 May 2007 09:22:39 +0200
Links: << >>  << T >>  << A >>
Hello Lars,

you can find this link in the Xilinx Application Note 290:

http://www.xilinx.com/bvdocs/appnotes/xapp290.zip

In this zip-file you 'll find a bus_macro-folder with bus_macros for
your Virtex2Pro.

Best regards,

David


L. Schreiber schrieb:
> Hi everybody.
> 
> I'm sitting over a partial reconfiguration project for university.
> 
> I'm absolutelly new to this topic, but as an introduction to this topic,
> of course I 've already read the concerning xilinx appsheets and several
> further sheets from 3rd persons or university papers that are going more
> into detail.
> 
> But they all have something in common. They don't say much about those
> bus macros, how they work, where to get them or how to create them. They
> mainly talk about the design flow.
> 
> In the last sheet I recently have read that fpga specific bus macros are
> available over the website of xilinx, but I had no success in finding
> them there.
> 
> Other sheets say, that you have to built them on your own via the fpga
> editor. But how, when it's absolutelly unclear to me how they work.
> 
> I'm also wondering if I have to create one bus macro in the fpga editor
> per 4 interconnecting signals between dynamic and static parts or if i
> can reuse one bus macro and instantiate from it several times in my vhdl
> code.
> 
> Maybe someone experienced to this can give me some advises and clarify
> some things.
> 
> The used device is a virtex2pro (xc2vp30-ff896) mounted on the ml310.
> used software is the ISE and EDK version 7.
> 
> Another problem with ISE I encountered is, that after I have build a new
> system via the base system builder and created a new ISE project from
> the vhdl-filed created by the EDK, the ISE cannot find those referenced
> vhdl modules from the xilinx library inside the EDK folder on the hard
> disk. Instead it marks all the components instantiated with a question
> mark. Does there exist a possibility to tell the ISE, where to look up
> for the library modules (a library path or something like that)?
> 
> thanks a lot for your help
> greetings, Lars Schreiber

Article: 119199
Subject: Re: Digital gain and offset correction
From: Sean Durkin <news_may07@durkin.de>
Date: Tue, 15 May 2007 09:47:33 +0200
Links: << >>  << T >>  << A >>
Marco T. wrote:
> I wasn't asking about how to perform addition and multiplication.
> 
> I was asking if there are other implementations or auto tuning-
> techniques, in example if someone has made a loopback to perform it.
That's *not* what you were asking.

You were asking:
"Which is the way to perform digital vgain and offset correction using a
fpga?"

How is anyone supposed to see that you want to now about loopback and
auto-tuning from that?

How are we supposed to give you decent answers if you don't state your
question clearly?

It's like calling your auto shop and asking "How do I fix a broken
car?". No mechanic will be able to give you a decent answer, because he
doesn't know what kind of car you are talking about, what is broken,
what kind of tools you have to repair it and if you know how to use them.
Without more information, your question is meaningless and much too
vague to answer.
That's why Antti reacted the way he did when you first asked this here.
It was his ironic way of letting you know that your question doesn't
really make sense.

So: Without knowing what it is you want to do gain/offset correction
for, noone will be able to give you a decent answer. If, for example,
you want to do gain/offset-correction for a CMOS image sensor, it's
different from doing GOC for RF receivers. In the end it all amounts to
+ and *, but how you get the values to add or multiply by differs a lot
depending on the system you are looking at.

So actually, you don't want to know about *PERFORMING*
gain/offset-correction at all (because that's trivial, just + and *)...
Instead, what you want to know is how one obtains the correction factors
(maybe through auto-tuning and/or loopbacks), which is a totally
different subject.

-- 
My email address is only valid until the end of the month.
Try figuring out what the address is going to be after that...



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