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 123275

Article: 123275
Subject: Re: Need to force all signals in a design to a known value at start of simulation
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Wed, 22 Aug 2007 18:20:36 +0100
Links: << >>  << T >>  << A >>
On Wed, 22 Aug 2007 09:19:08 -0700, 
Andy <jonesandy@comcast.net> wrote:

>I don't suppose we need to tell you that having neither reset nor
>initializers is a bad design practice, even when it "works" in FPGA
>hardware.
>
>This is one case where a two-state optimization on the simulator would
>be worth its weight in gold.

I wonder.... I just wonder.... if anyone has created a replacement
for std_logic_1164 that has all the same names and things in it,
but rewrites the operator definitions so that 'U' gets treated
as zero....  it would simulate dog-slow because the simulator's
internal accelerations for std_logic_1164 would be bypassed, but
it would be useful in ugly situations like this.  You could
even implement the operators as foreign language functions,
making it possible for them to randomize the replacement
value for 'U'...

And no, I'm not signing-up to do it.  I don't have the time,
and in any case I can't sell my soul for a second time now that
I've learnt SystemVerilog :-)
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

Article: 123276
Subject: Re: Need to force all signals in a design to a known value at start of simulation
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Wed, 22 Aug 2007 18:34:45 +0100
Links: << >>  << T >>  << A >>
On Wed, 22 Aug 2007 07:45:52 -0700, wittenjon@googlemail.com wrote:

>Hi,
>
>           I have a VHDL design which has no reset, within the design
>are statements that rely on the last know state of a signal i.e sig_a
><= not sig_a,  sig_a has not had an initial value declared in the
>signal region, hence it's value is X, there are numerous occurrences
>of this within the design. The design has been place and routed and
>works ok on the board as in the real world all signals have a default
>value. I can not change the RTL code, I therefore need to force all
>signals in the design to a known state, I understand that force only
>works on 1 signal at a time. Does anybody know how to force all nets,
>or have any better ideas than using force?

Most simulators have a way to inquire about what signals exist in
a given scope.  You could incorporate that into a Tcl script.
For example, in ModelSim try loading a simulation and then issuing
the command

  find signals -recursive *

So here's a script that forces all signals in your toplevel 
testbench to zero:

  foreach sig [find signals *] {
    force $sig -deposit 0
  }

Yuck.
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

Article: 123277
Subject: Re: Power Reduction Strategy
From: Ray Andraka <ray@andraka.com>
Date: Wed, 22 Aug 2007 13:45:01 -0400
Links: << >>  << T >>  << A >>
A lot depends on the design.  Careful floorplanning can reduce power by 
20% or more by reducing the complexity and length of routing.

If your logic has multiple levels of LUTs between flip-flops, adding 
pipeline stages to reduce the number of levels of logic can reduce power 
by a bit.  This is counter-intuitive.  It works because a good 
percentage of an FPGA's power dissipation comes from propagation of 
glitch energy through combinatorial logic.  Adding flip-flops stops the 
propagation of a glitch.  There was a paper at FPGA, probably around 
2002 that talked about this and claimed as much as 25% reduction of 
power by using deep pipelining.  The example used, as I recall was 
rather extreme, but I think the idea is still valid.  Again, most of the 
dissipation is in the routing channels, not in the lut logic, so adding 
the flip-flops is outweighed by the reduced dissipation in the routing 
channels.

You can use the BUFGMUXs to gate your clocks if needed, however most 
designs need the clocks running, and gating clocks brings its own set of 
problems.

You can time multiplex one instance of logic over multiple "channels" if 
that can be done with relatively little multiplex/de-multiplex logic to 
get a smaller gate count at the expense of running at a higher 
frequency.  This often reduces power because routing complexity is 
reduced and because you only take one hit on the static dissipation 
instead of an added hit for each channel.  There will be no savings in 
teh dynamic dissipation, as that is proportional to toggle rate.  The 
dynamic power may even be a little bit higher because of capacitive 
effects on the clock distribution.

Of these, the most effective will be careful floorplanning.

You might also be able to reduce the voltages a bit if you can still 
make timing with reduced voltage.  Power aries with the square of the 
supply voltage so even small changes in voltage will yeild large savings 
on power at the expense of some performance.

tgschwind@tiscalinet.ch wrote:
> I have a design on a Spartan 3 2000. It uses nearly all slices, two
> thirds of the FF and LUTs. Also all BlockRam and all BlockMultiplier
> are used.
> The design uses three clock. A 40 Mhz clock for configuration and
> registers, 80 Mhz for data processing, and 160 Mhz for internal
> processing in certain blocks.
> 
> The problem is that the device becomes hot, so hot, that you can burn
> your fingers. I measured up to 104 °C on the FPGA Ituses nearly 1.3 W.
> I have alredy implemeted ClockEnables everywhere possible. Also on
> RAMs. I have already sythesized with Power Reduction option.
> 
> The Device can't have a active cooling, like a fan.
> 
> Does anybody have some advice how to further reduce the power ? 25 %
> would be great.
> 


Article: 123278
Subject: Re: ML401 (Virtex 4 development board) as a USB peripheral
From: hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray)
Date: Wed, 22 Aug 2007 12:57:05 -0500
Links: << >>  << T >>  << A >>

>-  but it can only do it if the driver has been told it can operate
>for a given vendorID and productID that the peripheral is setup as (I
>was unable to find a generic USB "spy" program that would simply
>interrogate and debug any attached USB device - which made the debug
>process all the more painful.

Linux has a lsusb utility that tells you what is connected.

Sample printout:
Bus 005 Device 001: ID 0000:0000
Bus 004 Device 001: ID 0000:0000
Bus 002 Device 001: ID 0000:0000
Bus 001 Device 008: ID 091e:0003 Garmin International GPSmap (various models)
Bus 001 Device 004: ID 05e3:0608 Genesys Logic, Inc.
Bus 001 Device 001: ID 0000:0000
Bus 001 Device 003: ID 0bc2:0502 Seagate RSS LLC
Bus 001 Device 002: ID 05e3:070e Genesys Logic, Inc.
Bus 003 Device 001: ID 0000:0000


-- 
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 123279
Subject: Re: Globally Asynchronous in FPGA
From: David R Brooks <davebXXX@iinet.net.au>
Date: Thu, 23 Aug 2007 02:24:33 +0800
Links: << >>  << T >>  << A >>
RCIngham wrote:
> By choosing to implement in an FPGA, you must accept the limitations of the
> architecture of the target device, including the number of permitted
> clocks. This may restrict the design style to some extent.
> 
> In an ASIC you (generally speaking) have no such restrictions, but the
> up-front cost and turn-around times are much increased.
> 
>>> IP should have a clock port and a clock enable
>>> port. So, if you need to integrate several bits of IP, you can use one
> clock
>>> with different enables.
>> Thank you but I do not get the point.
>>
>> Problem was that
>> ---------------------------
>> If there is single global system clock, the overhead (by having only
>> one global clock) becomes bigger and bigger.
>> ---------------------------
>>
>> My question was that
>> -----------------------------
>> Can FPGA come up with "Globally Asynchronous, Locally Synchronous
>> (GALS)" design style that ASIC tends to do?
>> If yes, how?
>> -----------------------------
>>
All (afaik) FPGAs are capable of running a single global clock over the 
whole chip, so long as you use the resources provided for that purpose. 
The chip maker takes care of the distribution problems.
If you want multiple clocks so you can shut down an area & save power, 
most modern FPGAs offer several clock nets. But you are now responsible 
for synchronising them.

Article: 123280
Subject: Re: MCS -> BIT
From: Jon Elson <elson@wustl.edu>
Date: Wed, 22 Aug 2007 13:41:51 -0500
Links: << >>  << T >>  << A >>


LilacSkin wrote:
> Hello
> 
> I have just the MCS file and I want to configure directly my FPGa with
> a bitstream.
> So I had to convert the MCS in BIT.
> 
> What I have done:
> 1)MCS->HEX with promgen: promgen -r <promfile> -p hex
> 2)HEX->BIT with Hex2bits : hex2bits -k <hexfile> <bitfile>
> 
> But iMPACT doen't work with the generated bitstream.
> Do you have any idea ?
> 
> Thanks !
> 

Xilinx bit files are LSB first, IIRC.  You may need to flip the
bit sequence between bytes.  Then, you need to send some extra
config clocks to the FPGA to complete the configuration sequence.
The bit file may have something at the end that causes iMPACT to
do that, and that something may have been trimmed when converting to
PROM format in the MCS file.  Also, bit files have a header at the
beginning that specifies the FPGA part #, and the date and time of
creation of the file.  Everything up to the 0xFF is header info, and can 
be read with an ASCII editor or hex file viewer.  If the header info is
not right, it may cause iMPACT to not work right.

The MCS file has a checksum at the end of every line.  Hopefully promgen
gets rid of that.

Jon


Article: 123281
Subject: Re: ML401 (Virtex 4 development board) as a USB peripheral
From: John McGrath <tails4e@gmail.com>
Date: Wed, 22 Aug 2007 18:46:09 -0000
Links: << >>  << T >>  << A >>
On Aug 22, 10:57 am, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal
Murray) wrote:
> >-  but it can only do it if the driver has been told it can operate
> >for a given vendorID and productID that the peripheral is setup as (I
> >was unable to find a generic USB "spy" program that would simply
> >interrogate and debug any attached USB device - which made the debug
> >process all the more painful.
>
> Linux has a lsusb utility that tells you what is connected.
>
> Sample printout:
> Bus 005 Device 001: ID 0000:0000
> Bus 004 Device 001: ID 0000:0000
> Bus 002 Device 001: ID 0000:0000
> Bus 001 Device 008: ID 091e:0003 Garmin International GPSmap (various models)
> Bus 001 Device 004: ID 05e3:0608 Genesys Logic, Inc.
> Bus 001 Device 001: ID 0000:0000
> Bus 001 Device 003: ID 0bc2:0502 Seagate RSS LLC
> Bus 001 Device 002: ID 05e3:070e Genesys Logic, Inc.
> Bus 003 Device 001: ID 0000:0000
>
> --
> These are my opinions, not necessarily my employer's.  I hate spam.

Hi Hal,
Thanks for that - useful to know. Unfortunately I don't have root on
my linux machine (work machine), and it's the 2.4 kernel (don't ask!)
So I was not able to use any of those nice Linux utilities. Windows
was all I had "root" on to install stuff. But lsusb sounds like the
way to go if you can use it.

P.S. Sorry for the numerous typos in my previous post - I was rushing
a bit. Also, I assume the OP has access to the EDK - which was what I
used for talking to the EZ-Host on the FPGA side, I didn't make that
clear in the original post. You don't have to use the MicroBlaze, some
HDL could be written to implement the HPI protocol too. But it did
make it a little easier to be able to use C code to implement the
protocol.

John


Article: 123282
Subject: Re: Old issues of XCell magazine
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Wed, 22 Aug 2007 12:07:31 -0700
Links: << >>  << T >>  << A >>
On Aug 20, 1:54 pm, Peter Alfke <pe...@xilinx.com> wrote:
> Somebody asked for access to old XCell magazines.
> I was able to download all issues #17 through #39 ( 2Q1995 through
> 1Q2001) by clicking on:ftp://ftp.xilinx.com/pub/documentation/xcell/xcell17.pdf    etc.
> Peter Alfke

Hi Peter,
Do you have the newer XCell magazines to download at once?

I like XCell very much.

Thank you.

Weng


Article: 123283
Subject: Re: Power Reduction Strategy
From: hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray)
Date: Wed, 22 Aug 2007 14:42:15 -0500
Links: << >>  << T >>  << A >>

>What does your IO look like? Can you soften your drive strengths, and/
>or reduce slew rates?

How much energy/heat does that save?  You aren't changing the toggle
rate or the size of the external cap, just the rise/fall times.

-- 
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 123284
Subject: Re: ML401 (Virtex 4 development board) as a USB peripheral
From: hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray)
Date: Wed, 22 Aug 2007 14:48:34 -0500
Links: << >>  << T >>  << A >>

>Hi Hal,
>Thanks for that - useful to know. Unfortunately I don't have root on
>my linux machine (work machine), and it's the 2.4 kernel (don't ask!)
>So I was not able to use any of those nice Linux utilities. Windows
>was all I had "root" on to install stuff. But lsusb sounds like the
>way to go if you can use it.

You don't need to be root.  (at least on a vanilla Fedora 6 system)

There is more info in /proc/bus/usb/, things like this:

T:  Bus=01 Lev=01 Prnt=01 Port=05 Cnt=02 Dev#=  3 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=0bc2 ProdID=0502 Rev= 2.00
S:  Manufacturer=Seagate
S:  Product=ST94811U2-RK
S:  SerialNumber=344E463039384754
C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=  4mA
I:  If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms


-- 
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 123285
Subject: Re: Spartan-3A DSP vs. Cyclone III Power-wise
From: Manny <mloulah@hotmail.com>
Date: Wed, 22 Aug 2007 12:59:49 -0700
Links: << >>  << T >>  << A >>
Many thanks all for the input.

At some stage, once I'm done with designing the system, I'll try to
gauge things in real-world and hope for the best.

Regards,
-Manny


Article: 123286
Subject: Re: Old issues of XCell magazine
From: svenand <svenand@comhem.se>
Date: Wed, 22 Aug 2007 13:20:07 -0700
Links: << >>  << T >>  << A >>
On 22 Aug, 21:07, Weng Tianxiang <wtx...@gmail.com> wrote:
> On Aug 20, 1:54 pm, Peter Alfke <pe...@xilinx.com> wrote:
>
> > Somebody asked for access to old XCell magazines.
> > I was able to download all issues #17 through #39 ( 2Q1995 through
> > 1Q2001) by clicking on:ftp://ftp.xilinx.com/pub/documentation/xcell/xcell17.pdf   etc.
> > Peter Alfke
>
> Hi Peter,
> Do you have the newer XCell magazines to download at once?
>
> I like XCell very much.
>
> Thank you.
>
> Weng

Here is a link: http://www.xilinx.com/publications/xcellonline/index.htm

Sven


Article: 123287
Subject: Re: Power Reduction Strategy
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 22 Aug 2007 13:20:10 -0700
Links: << >>  << T >>  << A >>
On Aug 22, 9:27 am, Andreas Ehliar <ehl...@lysator.liu.se> wrote:
>  Is the static power consumption of an
> empty slice the same as the static power consumption of a configured
> slice with static inputs?
>
> /Andreas

The answer is YES (same static power) IMHO.
Peter Alfke



Article: 123288
Subject: Re: Power Reduction Strategy
From: nico@puntnl.niks (Nico Coesel)
Date: Wed, 22 Aug 2007 20:26:33 GMT
Links: << >>  << T >>  << A >>
tgschwind@tiscalinet.ch wrote:

>I have a design on a Spartan 3 2000. It uses nearly all slices, two
>thirds of the FF and LUTs. Also all BlockRam and all BlockMultiplier
>are used.
>The design uses three clock. A 40 Mhz clock for configuration and
>registers, 80 Mhz for data processing, and 160 Mhz for internal
>processing in certain blocks.
>
>The problem is that the device becomes hot, so hot, that you can burn
>your fingers. I measured up to 104 =B0C on the FPGA Ituses nearly 1.3 W.
>I have alredy implemeted ClockEnables everywhere possible. Also on
>RAMs. I have already sythesized with Power Reduction option.

Where is that power reduction option?

I'm working on a design which is heating a Spartan 3 FPGA a bit too
much (not so extreme as your design, I can still keep my finger on the
chip but it is not comfortable). I would like some power savings.
According to XPower, it saves quite some power when the drive strength
of outputs is reduced.

-- 
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

Article: 123289
Subject: Re: Power Reduction Strategy
From: Ray Andraka <ray@andraka.com>
Date: Wed, 22 Aug 2007 16:57:57 -0400
Links: << >>  << T >>  << A >>
Andreas Ehliar wrote:

> On 2007-08-22, Ray Andraka <ray@andraka.com> wrote:
> 
>>You can use the BUFGMUXs to gate your clocks if needed, however most 
>>designs need the clocks running, and gating clocks brings its own set of 
>>problems.
> 
> 
> Your post got me thinking about dynamically reconfiguring an FPGA to
> save power. I wonder how much power you can save by reconfiguring an
> FPGA so that an unused block is not there as compared to just turning
> off the clock to that block. Is the static power consumption of an
> empty slice the same as the static power consumption of a configured
> slice with static inputs?
> 
> /Andreas

I think unconfigured logic has the same static dissipation as configured 
logic that has all the inputs held static, so reconfiguring to take 
logic out isn't going to save you anything.  On top of that, 
reconfiguration takes a considerable amount of power so you'd end up 
with a greater net power.  Now if you were to reconfigure so that unused 
logic gets replaced with new logic that wouldn't have fit otherwise, 
then you'll likely get some savings as long as the reconfiguration is 
done infrequently enough for the power overhead of doing the 
reconfiguraiton doesn't overshadow the savings.  Basically, if 
reconfiguration lets you get into a smaller device, then it might be a 
win for power.  If it doesn't shrink the device size, then you aren't 
going to realize any power saving.

Article: 123290
Subject: Re: ML401 (Virtex 4 development board) as a USB peripheral
From: John McGrath <tails4e@gmail.com>
Date: Wed, 22 Aug 2007 20:59:04 -0000
Links: << >>  << T >>  << A >>
On Aug 22, 12:48 pm, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal
Murray) wrote:
> >Hi Hal,
> >Thanks for that - useful to know. Unfortunately I don't have root on
> >my linux machine (work machine), and it's the 2.4 kernel (don't ask!)
> >So I was not able to use any of those nice Linux utilities. Windows
> >was all I had "root" on to install stuff. But lsusb sounds like the
> >way to go if you can use it.
>
> You don't need to be root.  (at least on a vanilla Fedora 6 system)
>
> There is more info in /proc/bus/usb/, things like this:
>
> T:  Bus=01 Lev=01 Prnt=01 Port=05 Cnt=02 Dev#=  3 Spd=480 MxCh= 0
> D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
> P:  Vendor=0bc2 ProdID=0502 Rev= 2.00
> S:  Manufacturer=Seagate
> S:  Product=ST94811U2-RK
> S:  SerialNumber=344E463039384754
> C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=  4mA
> I:  If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
> E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
>
> --
> These are my opinions, not necessarily my employer's.  I hate spam.

I think you need to be root to enable some usb features in the 2.4
kernel and I think lsusb only works with the 2.6 kernel - so I was
caught both ways - could not change my linux version, and could not
get the usb functions to work on the 2.4 kernel without root.
I could be completely wrong - I'm far from a Linux guru - but that's
more or less what I found at the time. It would have made my life a
lot easier though - maybe I should have gotten a live linux cd for my
laptop and saved all this trouble! Thanks again for the tip!


Article: 123291
Subject: Re: ML401 (Virtex 4 development board) as a USB peripheral
From: alleynb@gmail.com
Date: Wed, 22 Aug 2007 21:29:03 -0000
Links: << >>  << T >>  << A >>
On Aug 22, 9:59 pm, John McGrath <tail...@gmail.com> wrote:
> On Aug 22, 12:48 pm, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal
>
>
>
> Murray) wrote:
> > >Hi Hal,
> > >Thanks for that - useful to know. Unfortunately I don't have root on
> > >my linux machine (work machine), and it's the 2.4 kernel (don't ask!)
> > >So I was not able to use any of those nice Linux utilities. Windows
> > >was all I had "root" on to install stuff. But lsusb sounds like the
> > >way to go if you can use it.
>
> > You don't need to be root.  (at least on a vanilla Fedora 6 system)
>
> > There is more info in /proc/bus/usb/, things like this:
>
> > T:  Bus=01 Lev=01 Prnt=01 Port=05 Cnt=02 Dev#=  3 Spd=480 MxCh= 0
> > D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
> > P:  Vendor=0bc2 ProdID=0502 Rev= 2.00
> > S:  Manufacturer=Seagate
> > S:  Product=ST94811U2-RK
> > S:  SerialNumber=344E463039384754
> > C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=  4mA
> > I:  If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
> > E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> > E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
>
> > --
> > These are my opinions, not necessarily my employer's.  I hate spam.
>
> I think you need to be root to enable some usb features in the 2.4
> kernel and I think lsusb only works with the 2.6 kernel - so I was
> caught both ways - could not change my linux version, and could not
> get the usb functions to work on the 2.4 kernel without root.
> I could be completely wrong - I'm far from a Linux guru - but that's
> more or less what I found at the time. It would have made my life a
> lot easier though - maybe I should have gotten a live linux cd for my
> laptop and saved all this trouble! Thanks again for the tip!

Thanks,

Using the microblaze processor seems a bit like overkill. All I need
to do is be able to send/receive bytes from the PC to the Cypress
micro. The FPGA can then read/write from the micro over the GPIO pins.
There is an example in the cypress docs which connects leds to the
GPIOs of the micro and allows the PC to set/clear them by sending
bytes over the USB. Supposidly the micro should appear as a standard
HID device and the standard USB HID drivers can be used on windows.
Unfortunately when I download that example code it does not work.
Looking at USBview it appears that the Cypress micro has not been
enumerated properly. All fields appear as zero, hence windows does not
know what driver to use.

I'll try using linux to dump the raw transactions of the usb bus if
this is possible, to attempt to debug it.




Article: 123292
Subject: Re: ML401 (Virtex 4 development board) as a USB peripheral
From: John McGrath <tails4e@gmail.com>
Date: Wed, 22 Aug 2007 22:08:51 -0000
Links: << >>  << T >>  << A >>
On Aug 22, 2:29 pm, alle...@gmail.com wrote:
> On Aug 22, 9:59 pm, John McGrath <tail...@gmail.com> wrote:
>
>
>
> > On Aug 22, 12:48 pm, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal
>
> > Murray) wrote:
> > > >Hi Hal,
> > > >Thanks for that - useful to know. Unfortunately I don't have root on
> > > >my linux machine (work machine), and it's the 2.4 kernel (don't ask!)
> > > >So I was not able to use any of those nice Linux utilities. Windows
> > > >was all I had "root" on to install stuff. But lsusb sounds like the
> > > >way to go if you can use it.
>
> > > You don't need to be root.  (at least on a vanilla Fedora 6 system)
>
> > > There is more info in /proc/bus/usb/, things like this:
>
> > > T:  Bus=01 Lev=01 Prnt=01 Port=05 Cnt=02 Dev#=  3 Spd=480 MxCh= 0
> > > D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
> > > P:  Vendor=0bc2 ProdID=0502 Rev= 2.00
> > > S:  Manufacturer=Seagate
> > > S:  Product=ST94811U2-RK
> > > S:  SerialNumber=344E463039384754
> > > C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=  4mA
> > > I:  If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
> > > E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> > > E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
>
> > > --
> > > These are my opinions, not necessarily my employer's.  I hate spam.
>
> > I think you need to be root to enable some usb features in the 2.4
> > kernel and I think lsusb only works with the 2.6 kernel - so I was
> > caught both ways - could not change my linux version, and could not
> > get the usb functions to work on the 2.4 kernel without root.
> > I could be completely wrong - I'm far from a Linux guru - but that's
> > more or less what I found at the time. It would have made my life a
> > lot easier though - maybe I should have gotten a live linux cd for my
> > laptop and saved all this trouble! Thanks again for the tip!
>
> Thanks,
>
> Using the microblaze processor seems a bit like overkill. All I need
> to do is be able to send/receive bytes from the PC to the Cypress
> micro. The FPGA can then read/write from the micro over the GPIO pins.
> There is an example in the cypress docs which connects leds to the
> GPIOs of the micro and allows the PC to set/clear them by sending
> bytes over the USB. Supposidly the micro should appear as a standard
> HID device and the standard USB HID drivers can be used on windows.
> Unfortunately when I download that example code it does not work.
> Looking at USBview it appears that the Cypress micro has not been
> enumerated properly. All fields appear as zero, hence windows does not
> know what driver to use.
>
> I'll try using linux to dump the raw transactions of the usb bus if
> this is possible, to attempt to debug it.

Well the Cypress device will appear like a standard HID device if you
first program it to do so! You have to compile the source code for the
microcontroller running inside the EZ-Host to make it behave like the
USB Host or Peripheral you want it to be. So the first thing to do is
to load this program into the EZ-Host (there is a default program
running when it powers on, but I don't think it's a peripheral).

I used the MicroBlaze to upload this program to the EZ-Host. You don't
need to do this, but you do need to upload something to the Cypress
chip in order to get it working. I believe the Cypress Development kit
does this uploading for you, when you use their development board,
etc. The HPI protocol was the method I used to upload the program to
the Cypress chip - but there are others too (SPI, etc). The reason I
used this was because the ml401 usb-keyboard demo uses this setup to
initialize the EZ-Host, so I built on that. The uploading of the
program has to come from the FPGA side. Once done, the FPGA re-boots
the Cypress chip and then it starts implementing the USB function that
has been programmed into it.

Hope it's a little clearer now.
John


Article: 123293
Subject: Re: Power Reduction Strategy
From: Andy <jonesandy@comcast.net>
Date: Wed, 22 Aug 2007 15:42:57 -0700
Links: << >>  << T >>  << A >>
On Aug 22, 2:42 pm, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal
Murray) wrote:
> >What does your IO look like? Can you soften your drive strengths, and/
> >or reduce slew rates?
>
> How much energy/heat does that save?  You aren't changing the toggle
> rate or the size of the external cap, just the rise/fall times.
>
> --
> These are my opinions, not necessarily my employer's.  I hate spam.

OK, you got me there. It saves peak power, but not average (thermal)
power. If you could redesign the board, you might be able to make the
power supply run cooler, and thus not heat up the FPGA, but that's
probably out of scope.

OTOH, if he's got SSO problems causing inputs (perhaps not observed at
the time) to toggle excessively, then that could cause extra power to
be consumed, which would be reduced/eliminated by slowing the outputs
down. Admittedly, a bit of a reach though :)

Andy


Article: 123294
Subject: Re: Power Reduction Strategy
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Thu, 23 Aug 2007 11:01:35 +1200
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> On Aug 22, 9:27 am, Andreas Ehliar <ehl...@lysator.liu.se> wrote:
> 
>> Is the static power consumption of an
>>empty slice the same as the static power consumption of a configured
>>slice with static inputs?
>>
>>/Andreas
> 
> 
> The answer is YES (same static power) IMHO.

Has anyone measured this, to check it is the same ?

I have seen CPLDs where the Macrocell logic state did have
a measurable effect on static Icc :)
( this was not the product term fuses, but the logic levels
in a working device )

At a first look, CMOS is Vcc.Gnd level agnostic, but when
you start adding all the complex leakages,
and maybe level shifters, then you may find some variation.
(it may not be much..)

-jg


Article: 123295
Subject: Re: Need to force all signals in a design to a known value at start of simulation
From: Andy <jonesandy@comcast.net>
Date: Wed, 22 Aug 2007 16:06:04 -0700
Links: << >>  << T >>  << A >>
On Aug 22, 12:20 pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
> On Wed, 22 Aug 2007 09:19:08 -0700,
>
> Andy <jonesa...@comcast.net> wrote:
> >I don't suppose we need to tell you that having neither reset nor
> >initializers is a bad design practice, even when it "works" in FPGA
> >hardware.
>
> >This is one case where a two-state optimization on the simulator would
> >be worth its weight in gold.
>
> I wonder.... I just wonder.... if anyone has created a replacement
> for std_logic_1164 that has all the same names and things in it,
> but rewrites the operator definitions so that 'U' gets treated
> as zero....  it would simulate dog-slow because the simulator's
> internal accelerations for std_logic_1164 would be bypassed, but
> it would be useful in ugly situations like this.  You could
> even implement the operators as foreign language functions,
> making it possible for them to randomize the replacement
> value for 'U'...
>
> And no, I'm not signing-up to do it.  I don't have the time,
> and in any case I can't sell my soul for a second time now that
> I've learnt SystemVerilog :-)
> --
> Jonathan Bromley, Consultant
>
> DOULOS - Developing Design Know-how
> VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
>
> Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
> jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com
>
> The contents of this message may contain personal views which
> are not the views of Doulos Ltd., unless specifically stated.

That's scary; I was just thinking the same thing. I use numeric_bit
conversion and logic functions in my bitwise integer functions. I
wonder if simulators have accelerated operations for type bit/
bit_vector? You could just create a package that defines std_logic as
a subtype of bit, and std_logic_vector as a subtype of bit_vector or
numeric_bit.unsigned. So long as you don't use tri-states, etc. that
might work pretty well, and likely be quicker than custom operators
that remap 'u';  Initial values would get become '0' automatically.
You'd have to re-create rising/falling_edge() if they had been used.

Once upon a time, I wrote a replacement package for an old MVL7/MVL9
package, that created named subtypes of SL & SLV to match their
original type names. I can't remember how I handled bit literals
though....

I've often thought they should go back and re-define bit as a subtype
of std_logic in the language for just this purpose, especially now
that std_logic1164 falls under the main 1076 standard.

Andy


Article: 123296
Subject: Re: Voltage translation question
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Wed, 22 Aug 2007 16:45:45 -0700
Links: << >>  << T >>  << A >>
On Mon, 20 Aug 2007 17:53:02 -0700, "Eddie H" <> wrote:

>John,
>
>The load is is VCC referenced CML type. The positive rail is connected to 0.8V and VEE is connected to -2.5V. Do you think that I can use the TTL to ECL converter?

Sounds nasty, given the +0.8 Vcc. Most of the translators assume a
common 0v ground pin as both the TTL low and the ECL high.


>
>Thanks.
>
>Eddie


how about....


fpga---------R1--------+--------cml input
0/3.3                  | 
                       |
                       R2
                       |
                       |
                       |
                       |
                     -2.5v



which looks pretty good if R2 = 0.78 * R1

Does this have to be fast? Are the traces long? Those issues would
affect the absolure values of the R's.

John




Article: 123297
Subject: Re: Spartan-3A DSP vs. Cyclone III Power-wise
From: Paul Leventis <paul.leventis@gmail.com>
Date: Thu, 23 Aug 2007 00:45:15 -0000
Links: << >>  << T >>  << A >>
Hi,

Rob hit most of the points I would make.  I would also refer you to
http://www.altera.com/products/devices/cyclone2/features/power/cy2-power-compare.html
-- this is our take on the Cyclone *II* vs. Spartan-3 power story.
Regardless of how much of that material you believe (it can be
independently verified with hardware from the two vendors), when you
extend this comparison to Cyclone III devices, Cyclone III will
clearly have lower power.  I'll focus on dynamic power, since Rob
didn't touch on it much.

Both chips have the same Vdd supply voltage (1.2V).  However, Cyclone
III devices are manufactured in a 65 nm process vs. a 90 nm process in
the case of Spartan-3 (and Cyclone II devices).  This results in (a) a
reduction in the linear dimensions of the chip and thus metal
capacitance, and (b) a reduction in the size of the transistors and
resulting capacitance.  Overall, this leads to a ~30% (off the top of
my head) dynamic power reduction compared to Cyclone II devices.

On top of this, the Cyclone device family has been highly optimized
for low area (e.g. cost).  One side-effect of this is that the dynamic
power for a given amount of logic tends to be lower than higher-
performance families.  On top of this, we found in Cyclone II device
vs. Spartan-3 comparisons (referenced above) that the Cyclone II
device's power was significantly lower (~1/2) than that of Spartan-3,
despite being in the same process and with the same supply voltage.

Bottom line: You should expect much lower power in Cyclone III vs.
Cyclone II (you can trust us on that!), and thus it should not be hard
to convince yourself that Cyclone III should have signficantly less
power consumption than Spartan-3 (which is harder to trust us on :-)).

Regards,

Paul Leventis
Altera Corp.


Article: 123298
Subject: Re: Power Reduction Strategy
From: Paul Leventis <paul.leventis@gmail.com>
Date: Thu, 23 Aug 2007 01:12:30 -0000
Links: << >>  << T >>  << A >>
Hi,

Hopefully I can be of assistance despite your use of an inferior
part ;-p

You mention 1.3W of power @ 104C, presumably at room temperature (25C)
and nominal (1.2V) voltage with still air and no heatsink, measured on
the case (?).  How are you arriving at 1.3W?  Is this just the current
draw off VccInt x 1.2V?  Remember that there is also current drawn off
VccAux (65 mA * 2.5V = 163mW according to XPE).  And assuming you have
I/Os in your chip, there will additional power drawn from your VccO
(for all I/O standards) and off-chip Vtt rails (if using terminated
standards) -- more on that later.

Assuming your 1.3W is correct, then you've got a ThetaCA (case-to-
ambient thermal resistance) of (104-25) / 1.3 = 60 degrees per W!!!
That seems unlikely, so I will assume that there is some additional
source of power dissipation in your FPGA.  With no air movement, I'd
figure a thetaJA of ~15 deg/W is more reasonable (based on Cyclone III
EPE).  Assuming this is the case, you are burning somewhere in the
neighbourhood of (104 - 25) / 15 = 5.3W in your FPGA (eek).  I think
you need to find that power source!

First, I would check to be 100% certain that your I/Os are not shorted
or nothing else bad like that is happening.  Shorted I/Os (for
example, unused I/Os driving ground but hooked up to a signal or vcc
on the board) can really burn a ton of power.  Measure your device
temperature with the clocks completely disabled so that the only
contributors are static core and static I/O power -- what's the
temperature?  Then run with the I/Os clocked correctly, but disable as
much core logic functionality as possible.

Even if your I/Os are not shorted, it would help to describe your I/O
configuration.  I/Os can burn a lot of power.  Unterminated I/O
standards (such as 3.3V LVTTL) will consume power to charge and
discharge the (a) FPGA pin (b) PCB trace and (c) far-end load; all of
this current draw is dissipated as heat inside the FPGA, and is
irrespective of drive strength and slew rate (well, almost -- these
will affect the short-circuit current, but unlikely to be more than a
10% impact).

Terminated I/O standards are a whole other beast.  There is a static
current drawn through the voltage-divider network formed by your I/O
drive transistor, the series termination resistor, and the near/far-
end parallel termination resistor to Vtt.  This is true regardless of
whether you are driving a 1 or a 0.  Only some of that current draw is
dissipated as heat within the FPGA -- the rest is dissipated in off-
chip components.  This means that your *thermal power* will depend on
the drive strength of your SSTL I/O -- the higher the drive, the
higher the *system power* consumption but the lower the *FPGA thermal
power* will be.

You can download the Cyclone II or Cyclone III Early Power Estimator
to play around with I/O standards and see how much power is dissipated
on vs. off-chip for various configurations of I/O.  All the data in
that tool is from HSPICE simulations of our I/O buffer, and we've
carefully seperated out on-chip power from system power/current draw.
While Spartan-3 will have slightly different I/Os, they should behave
similarly to first order so the trends/results should be good enough
for your purposes.  The tool is available at
http://www.altera.com/support/devices/estimator/cy3-estimator/cy3-power_estimator_download.html.

If you verify that indeed you aren't burning a ton of I/O power, next
step is the core.  This is trickier -- the best things you can do are
to set clock enables on the global clocks, set clock enables on the
FFs (which disables some local clocking), and only read/write to your
RAMs when you really need the data.  For example, don't be lazy with
your FIFOs -- if you aren't using the read port on a given cycle,
disable the read enable / clock enable on the block.  You can also try
area-driven synthesis (vs. speed or balanced mapping).  This will
result in smaller circuits which will tend to use less power (but not
always).

Hopefully you'll respond with some more information on your design and
your measurements.  If all else fails and your design really is
running at 104C, and you can't slap a heat sink on it (without fan),
then I'd suggest taking the bluer road and migrate your design to
Cyclone III :-)

Regards,

Paul Leventis
Altera Corp.


Article: 123299
Subject: Re: Power Reduction Strategy
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Wed, 22 Aug 2007 19:21:30 -0700
Links: << >>  << T >>  << A >>
On Wed, 22 Aug 2007 08:19:12 -0700, tgschwind@tiscalinet.ch wrote:

>I have a design on a Spartan 3 2000. It uses nearly all slices, two
>thirds of the FF and LUTs. Also all BlockRam and all BlockMultiplier
>are used.
>The design uses three clock. A 40 Mhz clock for configuration and
>registers, 80 Mhz for data processing, and 160 Mhz for internal
>processing in certain blocks.
>
>The problem is that the device becomes hot, so hot, that you can burn
>your fingers. I measured up to 104 °C on the FPGA Ituses nearly 1.3 W.
>I have alredy implemeted ClockEnables everywhere possible. Also on
>RAMs. I have already sythesized with Power Reduction option.
>
>The Device can't have a active cooling, like a fan.
>
>Does anybody have some advice how to further reduce the power ? 25 %
>would be great.

We epoxy pin-fin heatsinks to some of our Spartan chips. It cools them
off and reduces prop delay creep. Makes them look very imposing, too,
and hides the fact that they're just FPGAs.

If they're not bga's, you can also put a "power pad" under them, and
dump some additional heat into a ground plane. Some sort of thermal
interface gunk would help.

John




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