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 151450

Article: 151450
Subject: Re: Altium Limited closing up shop - Altium Designer discontinued
From: "PovTruffe" <PovTache@gaga.invalid>
Date: Sun, 10 Apr 2011 12:00:42 +0200
Links: << >>  << T >>  << A >>
I have found this:
http://www.electronicsnews.com.au/news/altium-relocates-from-sydney-to-shanghai

Nothing was mentioned about Altium Designer being discontinued



Article: 151451
Subject: Re: Altium Limited closing up shop - Altium Designer discontinued
From: Rikard Astrof <rikard.astrof@gmail.com>
Date: Sun, 10 Apr 2011 13:57:21 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 10, 7:17=A0pm, Frank Buss <f...@frank-buss.de> wrote:
> Rikard Astrof wrote:
> > FYI: =A0Altium limited has laid off 60% of their staff and will be
> > closing the australia offices by the end of the month.
>
> April 1 is over :-) Do you have a link? Last time I tried Altium
> Designer it was a nice program. Of course expensive and with some bugs,
> but would be bad for many people who are using it if it will be
> discontinued.
>

This is not an April fools comment, this is real. 3 out of 4 of the
main architects Marc Depret, Dejan Stankovic and Benjamin Wells will
not be making the move as such have tendered their resignation,  but
have been requested by Altium management to not make it public until
after the June EOY ASX fillings have been made.

The reality is there is no guarantee that Altium as a company will be
around this time next year, so who knows what will happen to multi-
year subscriptions and promised upgrade cycles.



Article: 151452
Subject: Re: Altium Limited closing up shop - Altium Designer discontinued
From: Rikard Astrof <rikard.astrof@gmail.com>
Date: Sun, 10 Apr 2011 14:10:54 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 10, 8:00=A0pm, "PovTruffe" <PovTa...@gaga.invalid> wrote:
> I have found this:http://www.electronicsnews.com.au/news/altium-relocates=
-from-sydney-t...
>
> Nothing was mentioned about Altium Designer being discontinued

If you read the comments at the end of the article, specially those
made by Alan Smith, he's saying last week they retrenched most of the
AU staff (http://www.google.com/search?q=3Dsite%3Alinkedin.com+altium
+limited) with the hope of setting up a team in China, well since then
inside sources have confirmed that the vast majority of the people
that were supposedly meant to head off to china to setup the new
offices/team have decided to take voluntary redundancy, which means as
of today Altium Limited and their product Altium designer is in limbo.

To furthermore, lay-offs will be made this week in the San Diego
offices, this will include transfering all support calls to the China
offices.

Article: 151453
Subject: Re: Do people do this by hand?
From: Chris Maryan <kmaryan@gmail.com>
Date: Sun, 10 Apr 2011 19:14:30 -0700 (PDT)
Links: << >>  << T >>  << A >>
See if you can develop a way to script the whole thing. A lot of tools will=
 let you write a script to build up a pinout for a schematic or PCB symbol =
from something like a spreadsheet file. You can also typically use the same=
 file as a starting point for the FPGA IO definitions.

Companies that do a lot of this generally have three things going for them:=
 they've taken the time to develop good scripted/automated workflows for te=
dious tasks; once a part is in their library it gets tons of reuse; any boa=
rd developed with a particular set of IO constraints will usually get a rea=
sonable lifespan so any changes are infrequent.

Chris

Article: 151454
Subject: Re: Do people do this by hand?
From: Kim Enkovaara <kim.enkovaara@iki.fi>
Date: Mon, 11 Apr 2011 08:40:22 +0300
Links: << >>  << T >>  << A >>
On 8.4.2011 19:47, Mr.CRC wrote:

> Any ideas on how this is done in the real world would be of interest.

In the high end Schematics/PCB packages there are specific tools to do
pin planning, pin swapping etc. For example Mentor IO-designer is one
such tool. It can for example read in the constraint files from FPGA
tools and produce the symbol from that data, and if pins are swapped it
can export the new constraints etc. (there are also many other ways to
do the symbol in the tools).

There are also tools to check all the PCB design constraints and manage
that data (length rules, differential pair rules etc.)

--Kim

Article: 151455
Subject: Virtex-5 GTP with oversampling
From: Stebanoid <stebanoid@gmail.com>
Date: Mon, 11 Apr 2011 00:05:58 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hello, All.
I want to use a GTP transceiver with oversapling mode on for receiving
a 125Mbit/s signal.
But I don't know, what frequency will be in rxrecclk, if I use 10bit
bus and builtin oversampling - 12.5MHz or 62.5MHz or something else.
Has anyone worked with builtin oversampling?

Article: 151456
Subject: Re: Reference book on Pci-express (Hardware and software point of view)
From: shyam <mail.ghanashyam.prabhu@gmail.com>
Date: Mon, 11 Apr 2011 00:30:21 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 9, 1:23=A0am, Benjamin Couillard <benjamin.couill...@gmail.com>
wrote:
> On 8 avr, 04:19, "maxascent"
>
>
>
>
>
>
>
>
>
> <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk> wrote:
> > >Hi everyone,
>
> > >I was wondering if anyone here can suggest me a good reference book on
> > >PCI express design. I've seen a few on amazon but before buying I'd
> > >like to hear your suggestions.
>
> > >Thanks
>
> > PCI Express System Architecture is a good book. Its easy to follow and
> > covers everything you would need. Google books have previews of this bo=
ok
> > and others.
>
> > Jon =A0 =A0 =A0 =A0
>
> > --------------------------------------- =A0 =A0 =A0 =A0
> > Posted throughhttp://www.FPGARelated.com
>
> Thank you! I think i'll buy this one!

Hi, If you are using Xilinx PCIE express block, then I think you can
even do with the PCIExpress System Architecture ebook which is free.
Some of the sections have been skipped in the ebook version. Basically
you will only be developing the transaction layer interface if you are
using a xilinx pcie endpoint IP. Basically the data link layer and the
physical interface are digital and analog interfaces which are
normally hard blocks. The user logic falls mostly into transaction
layer and thats the one you should be worried about!

Thanks
Shyam

Article: 151457
Subject: Re: Do people do this by hand?
From: Martin Thompson <martin.j.thompson@trw.com>
Date: Mon, 11 Apr 2011 10:36:50 +0100
Links: << >>  << T >>  << A >>
"Mr.CRC" <crobcBOGUS@REMOVETHISsbcglobal.net> writes:

> Hi:
>
> I've been developing a DSP+FPGA engine laboratory experiment controller
> for some years.  This summer I have a EE intern coming to help me with
> hardware and logic development to push toward finishing things.
>
>
> Some things we need to do:
>
> 1.  Make Xilinx Spartan 3E PCB CAD model (most likely for Eagle).

My PCB tool generates BGA footprints in seconds.  Or you can buy a wizard from
PCB Matrix (now owned by Mentor, but AFAIK they still cover lots of PCB tools):
http://www.mentor.com/products/pcb-system-design/pcbmatrix

> 2.  Make Eagle model for TI TMS320F2812 DSP.

Ditto.

> 3.  Top level Verilog module to represent all FPGA IOs used and routing
> them to sub-modules.

That can be a bit tedious, although if the signal names map 1:1 (or nearly)
Emacs does a good job of the really tedious bit. If you've already got the
schematics drawn, some tools can export a VHDL wiring file which might help. 

> 4.  Begin developing some sub modules for various functionality.
>

That's the interesting part :)

>
> Steps 1, 2, and 3 seem like extremely tedious processes to perform by
> hand, especially the PCB models, since there are 176 pins on the DSP and
> may be 200-300 pins on the FPGA depending on the packages we choose.
>
> Also, the system plan is to route nearly all DSP IO and memory interface
> pins to the FPGA, so that the FPGA may be used to reconfigure at any
> time what specialty DSP IOs appear to the user via a buffered set of BNC
> connectors.  Thus, we will actually use at least >100 FPGA IOs, all
> which therefore must be coded into the top level Verilog module.

That sounds like a fun challenge, are you really planning to buffer the EMIF
onto BNC connectors?

>
> What's further boggles my mind is that this is still a relatively simple
> system, compared to the high end FPGAs and CPUs which may involve >1000
> poins each.
>
> How is this managed efficiently?  Employ grunts?  Or should I be looking
> at the scripting language in Eagle for ex. to attempt to automate the
> SMD pad placements, at least?  Is there a scripting process which can
> assist this on the Xilinx/Verilog side?
>

Last big design I did was a 676 pin BGA to 4 memory chips, 50 or so to other on
board compoments and 150 or so to expansion boards.  I used MIG to assign the
memory interfaces, import those to PlanAhead to assign the rest of the pins.
That then exports a CSV, and I have a script which then converts that into a
format that my schematic capture tool can use, so I don't have to manually keep
that in sync.  I also export a UCF file for the Xilinx implementation tools.
the pins

> Much of this seems difficult to envision how to automate because it is
> mainly primary data entry, ie., transcribing signal names from the
> system design and datasheets to pin names in PCB schematic symbols and
> to FPGA constraint files, which can't be automated.
>

It can if you have the right tools - I can't comment on whether Eagle can do this.

> If anything, it might be possible to develop a central file of signal
> names, pad locations, etc., and have scripts generate the PCB models,
> Verilog top level module, and constraint file.  That way the data entry
> only needs to be done once.  But will the scripting development be just
> as time consuming as typing everything 3 times?
>

It depends how dynamic your pinout is.  If you're sure it's right, and won't
need to to it again, just sitting down and typing it all can be a better way.
But I found it really useful to be able to tweak the pinout of the FPGA late in
the PCB design process to ease the routing and ripple that through the deswign
from one source.

And once you've got a flow that works, your next designs can make good use of
that investment.

HTH!

Martin

-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.co.uk/capabilities/39-electronic-hardware

Article: 151458
Subject: Re: Altium Limited closing up shop - Altium Designer discontinued
From: "Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk>
Date: Mon, 11 Apr 2011 14:10:40 +0100
Links: << >>  << T >>  << A >>
I'm posting as an AD user, concerned for the long term future of the tool.


> This is not an April fools comment, this is real. 3 out of 4 of the
> main architects Marc Depret, Dejan Stankovic and Benjamin Wells will
> not be making the move as such have tendered their resignation,  but
> have been requested by Altium management to not make it public until
> after the June EOY ASX fillings have been made.

> The reality is there is no guarantee that Altium as a company will be
> around this time next year, so who knows what will happen to multi-
> year subscriptions and promised upgrade cycles.


This _could_ be interpreted as FUD by a competitor.

Rikard, who are you and what's your source for the detailed information
above?


Nial





Article: 151459
Subject: TTA-Based Co-design Environment (TCE) v1.4 released
From: Pekka Jaaskelainen <pekka.jaaskelainen@nospam.invalid>
Date: Mon, 11 Apr 2011 17:15:08 +0000 (UTC)
Links: << >>  << T >>  << A >>
TTA-Based Co-design Environment (TCE) is a toolset for designing
application-specific processors (ASP) based on the Transport Triggered
Architecture (TTA). The toolset provides a complete retargetable co-design
flow from C programs down to synthesizable VHDL and parallel program
binaries. Processor customization points include the register files,
function units, supported operations, and the interconnection network.

This release includes support for LLVM 2.9, some new VHDL
implementations (an FPU and streaming operations), a connectivity
optimizer, code generation improvements, plenty of bug fixes and
more. See the CHANGES file for a more thorough listing.

Notable new features
--------------------
- Support for LLVM 2.9.
- OpenCL Embedded compliant FPU implementations by Timo Viitanen / TUT
- Generic VHDL implementations for the basic streaming operations
  from Jani Boutellier / University of Oulu.
- ConnectionSweeper IC network exploration algorithm.
  Optimizes the IC network by sweeping the buses of the machine and
  removing the least important connections first until a cycle count
  worsening threshold is reached. Tries to remove RF connections
  first as they are usually more expensive than the bypass connections.
- Added --pareto_set switch to the explorer for printing pareto efficient
  configurations. Currently supports the connectivity and cycle count as
  the quality metrics.
- proge: IP-XACT support updated to version 1.5
- Added switch --print-resource-constraints to tcecc to assist in
  deciding which resources to add to the machine to improve the
  schedule. Dumps DDGs to dot files along with dependence and
  resource constraint analysis data.

Code generator improvements
---------------------------
- Passes the first function parameter in register instead of stack.
- Uses negative guard more aggressively, less stupid guard xoring operations.
- Emulation pattern generation improved, can use immediates directly when
  using DAG to emulate missing operations.
- Some other minor pattern improvements leading to slightly better code
  on some situations.
- Alias analysis improvements, understands that register spills to stack
  cannot alias with other memory operations
- Software Bypasser is much more aggressive.

Acknowledgements
----------------
Thanks to Timo Viitanen for your first TCE contribution (the OpenCL
embedded-compliant FPU implementations) in this release!

Links
-----

TCE home page:     http://tce.cs.tut.fi
This announcement: http://tce.cs.tut.fi/downloads/ANNOUNCEMENT
Download:          http://tce.cs.tut.fi/downloads
Change log:        http://tce.cs.tut.fi/downloads/CHANGES


Article: 151460
Subject: Controllling reset duration in EDK - plb bus
From: Benjamin Couillard <benjamin.couillard@gmail.com>
Date: Mon, 11 Apr 2011 13:10:04 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi everyone,

I'm trying to simulate my EDK design that contains a PCI-express block
connected to a PLB bus. In the PCI express block it is mentionned that
"The MPLB_Rst and SPLB_Rst must be asserted simultaneously and held
for a minimum of 300 ns". I connected the reset as suggested in the
plbv46_pcie datasheet, however myst resets only last about 85 ns. It
doesn't matter how long my reset input is since the block
"proc_sys_reset_0" seems to be edge sensitive and only triggers the
PLB_reset when my external reset goes from 0 to 1.

Is there a way to force "proc_sys_reset" to generate resets of 300 ns
or more?

Best regards

Article: 151461
Subject: Altera web 10.1sp1
From: jacko <jackokring@gmail.com>
Date: Mon, 11 Apr 2011 14:14:35 -0700 (PDT)
Links: << >>  << T >>  << A >>
How small is it when installed? Can it be made smaller at the install phase? Just need MAX II and VHDL and maybe cyclone later.

Article: 151462
Subject: Source of Dynamic Power Consumption in FPGAs
From: rickman <gnuarm@gmail.com>
Date: Mon, 11 Apr 2011 15:24:18 -0700 (PDT)
Links: << >>  << T >>  << A >>
In considering the nature of power consumption in FPGA devices it
occurred to me to ask what components in the FPGA are responsible for
most of the power.  The candidates are clock trees, routing, LUT and
misc logic and finally, FFs.

In CMOS devices the power consumed comes from charging and discharging
capacitance.  So I would expect the clock trees with their constant
toggling to be a likely candidate for the most power consumption.
Second on my list is the routing since I would expect the capacitance
to be significant.  I expect the LUTs to be next but may be fairly
close to the power consumed in the FFs.

With that in mind, I think the typical way of reducing power by the
use of clock enables on registers which are on the output of logic
block may not be optimal.  This is the part that I have not fully
analyzed, but I think it could be significant.

When a register on the output of a logic block is enabled, routing and
logic feeding the register inputs will have dissipated power but after
the clock, routing and logic fed by the output will also dissipate
power regardless whether the next register will be enabled on the next
clock or not!  In other words, the routing and logic can dissipate
power just because the inputs to the logic are changing even when that
logic is not needed.

If the registers are placed at the input to a function block the
routing and logic will only dissipate power when the registers are
enabled allowing the register outputs and the logic inputs to change.
Why is this different from output registers?  If your design is a
linear pipeline then it is not different.  But that is the exception.
With branching and looping of logic flow an output can feed multiple
other logic blocks.  If multiple inputs to logic change at different
times this will also increase dissipation.  When those other logic
blocks do not need this new data the power used in the routing and
logic is wasted.

I guess the part I'm unclear on is whether this is truly significant
in a typical design.  If the branching is not a large part of a design
or if the branching is only in the control logic and not the data
paths I would expect the difference to be small or negligible.

I don't think I am the first person to think of this.  Since this is
not a part of vendors recommendations I think it is a pretty good
indicator that it is not a large enough factor to be useful.  Has
anyone seen an analysis on this?

Rick

Article: 151463
Subject: Re: Altium Limited closing up shop - Altium Designer discontinued
From: Rob Irwin <rob.irwin@altium.com>
Date: Mon, 11 Apr 2011 16:18:16 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 11, 11:10=A0pm, "Nial Stewart"
<nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote:
> I'm posting as an AD user, concerned for the long term future of the tool=
.
>
> > This is not an April fools comment, this is real. 3 out of 4 of the
> > main architects Marc Depret, Dejan Stankovic and Benjamin Wells will
> > not be making the move as such have tendered their resignation, =A0but
> > have been requested by Altium management to not make it public until
> > after the June EOY ASX fillings have been made.
> > The reality is there is no guarantee that Altium as a company will be
> > around this time next year, so who knows what will happen to multi-
> > year subscriptions and promised upgrade cycles.
>
> This _could_ be interpreted as FUD by a competitor.
>
> Rikard, who are you and what's your source for the detailed information
> above?
>
> Nial

Hi Nial. Not sure if this is FUD by a competitor, but it certainly is
ill-informed comment. I work at Altium, currently in the Australian
office, and can assure everyone that Altium Designer is not being
discontinued in ANY way. The move of HQ to China (we will remain an
Australian company) is actually aimed at allowing us to ramp up our
development schedule, and to get Altium Designer on to the desktops of
more designers and engineers around the world.

So, yes. Perhaps Rikard needs to declare who he is and who he works
for. Otherwise his comments can be disregarded.

Article: 151464
Subject: Re: Source of Dynamic Power Consumption in FPGAs
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Tue, 12 Apr 2011 01:16:15 +0000 (UTC)
Links: << >>  << T >>  << A >>
rickman <gnuarm@gmail.com> wrote:
> In considering the nature of power consumption in FPGA devices it
> occurred to me to ask what components in the FPGA are responsible for
> most of the power.  The candidates are clock trees, routing, LUT and
> misc logic and finally, FFs.
 
> In CMOS devices the power consumed comes from charging and discharging
> capacitance.  So I would expect the clock trees with their constant
> toggling to be a likely candidate for the most power consumption.
> Second on my list is the routing since I would expect the capacitance
> to be significant.  I expect the LUTs to be next but may be fairly
> close to the power consumed in the FFs.

When I first knew about CMOS, it was the transition time when
both transistors were on that was the most significant power
drain, but then logic was slower.   As I understand it, in the
faster, smaller devices, it is not tunneling current that is a
large fraction of the power.
 
> With that in mind, I think the typical way of reducing power by the
> use of clock enables on registers which are on the output of logic
> block may not be optimal.  This is the part that I have not fully
> analyzed, but I think it could be significant.

The complication in the capacitance calculation is that the metal
widths can change a lot.  The input to a buffer can be narrow, and
drive a wider output line.  Most FPGAs now include many buffers in
the routing, where routing lines used to be passive.  (There are
no internal tristate lines, though the tools will still simulate them.)
 
> When a register on the output of a logic block is enabled, routing and
> logic feeding the register inputs will have dissipated power but after
> the clock, routing and logic fed by the output will also dissipate
> power regardless whether the next register will be enabled on the next
> clock or not!  In other words, the routing and logic can dissipate
> power just because the inputs to the logic are changing even when that
> logic is not needed.

Logic design is hard enough without trying to worry about every
last bit of power.  I suppose for designs that specifically need
to last, such as digital watches, one should worry about it.
 
> If the registers are placed at the input to a function block the
> routing and logic will only dissipate power when the registers are
> enabled allowing the register outputs and the logic inputs to change.
> Why is this different from output registers?  If your design is a
> linear pipeline then it is not different.  But that is the exception.

I happen to like linear pipelines, but, yes, that is rare.

> With branching and looping of logic flow an output can feed multiple
> other logic blocks.  If multiple inputs to logic change at different
> times this will also increase dissipation.  When those other logic
> blocks do not need this new data the power used in the routing and
> logic is wasted.

There are stories about the Cray-1, and how many lines were
carefully measured to be the same length, such that signals would
arrive at the right time.  (That was ECL, so I don't believe that
power was the reason.)
 
> I guess the part I'm unclear on is whether this is truly significant
> in a typical design.  If the branching is not a large part of a design
> or if the branching is only in the control logic and not the data
> paths I would expect the difference to be small or negligible.

Well, there isn't that much you can do about it.  
 
> I don't think I am the first person to think of this.  Since this is
> not a part of vendors recommendations I think it is a pretty good
> indicator that it is not a large enough factor to be useful.  Has
> anyone seen an analysis on this?

-- glen

Article: 151465
Subject: Re: Altium Limited closing up shop - Altium Designer discontinued
From: "David L. Jones" <altzone@gmail.com>
Date: Mon, 11 Apr 2011 20:29:02 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 11, 6:57=A0am, Rikard Astrof <rikard.ast...@gmail.com> wrote:
> On Apr 10, 7:17=A0pm, Frank Buss <f...@frank-buss.de> wrote:
>
> > Rikard Astrof wrote:
> > > FYI: =A0Altium limited has laid off 60% of their staff and will be
> > > closing the australia offices by the end of the month.
>
> > April 1 is over :-) Do you have a link? Last time I tried Altium
> > Designer it was a nice program. Of course expensive and with some bugs,
> > but would be bad for many people who are using it if it will be
> > discontinued.
>
> This is not an April fools comment, this is real. 3 out of 4 of the
> main architects Marc Depret, Dejan Stankovic and Benjamin Wells will
> not be making the move as such have tendered their resignation, =A0but
> have been requested by Altium management to not make it public until
> after the June EOY ASX fillings have been made.

And your source of this is?
One of those names has left, yes, that's fairly well known, but he
decided to move to another company way before the whole China move was
even known, it had nothing to do with China.
The other two names are incorrect, unless you know something that
myself (ex) and other employees don't.

And AD being discontinued is just plain rubbish, as is the Australian
office closing.
So not a single thing you have posted is true.

But considering that based on your profile, your ONLY contributions to
this and other Usenet groups has been to post misinformation about
Altium, I call troll, or FUD stooge.

Dave.

Article: 151466
Subject: Re: Altium Limited closing up shop - Altium Designer discontinued
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Mon, 11 Apr 2011 20:32:02 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 11, 4:18=A0pm, Rob Irwin <rob.ir...@altium.com> wrote:
> On Apr 11, 11:10=A0pm, "Nial Stewart"
>
>
>
>
>
> <nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote:
> > I'm posting as an AD user, concerned for the long term future of the to=
ol.
>
> > > This is not an April fools comment, this is real. 3 out of 4 of the
> > > main architects Marc Depret, Dejan Stankovic and Benjamin Wells will
> > > not be making the move as such have tendered their resignation, =A0bu=
t
> > > have been requested by Altium management to not make it public until
> > > after the June EOY ASX fillings have been made.
> > > The reality is there is no guarantee that Altium as a company will be
> > > around this time next year, so who knows what will happen to multi-
> > > year subscriptions and promised upgrade cycles.
>
> > This _could_ be interpreted as FUD by a competitor.
>
> > Rikard, who are you and what's your source for the detailed information
> > above?
>
> > Nial
>
> Hi Nial. Not sure if this is FUD by a competitor, but it certainly is
> ill-informed comment. I work at Altium, currently in the Australian
> office, and can assure everyone that Altium Designer is not being
> discontinued in ANY way. The move of HQ to China (we will remain an
> Australian company) is actually aimed at allowing us to ramp up our
> development schedule, and to get Altium Designer on to the desktops of
> more designers and engineers around the world.
>
> So, yes. Perhaps Rikard needs to declare who he is and who he works
> for. Otherwise his comments can be disregarded.- Hide quoted text -
>
> - Show quoted text -

The post came from a DSL line in New South Wales, Sydney.  Maybe one
of the engineers that was laid off?

It seems strange to lay off most of the staff before ramping in the
new location first.

Ed McGettigan
--
Xilinx Inc.

Article: 151467
Subject: Re: Altium Limited closing up shop - Altium Designer discontinued
From: "David L. Jones" <altzone@gmail.com>
Date: Mon, 11 Apr 2011 20:34:17 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 11, 7:10=A0am, Rikard Astrof <rikard.ast...@gmail.com> wrote:
> On Apr 10, 8:00=A0pm, "PovTruffe" <PovTa...@gaga.invalid> wrote:
>
> > I have found this:http://www.electronicsnews.com.au/news/altium-relocat=
es-from-sydney-t...
>
> > Nothing was mentioned about Altium Designer being discontinued
>
> If you read the comments at the end of the article, specially those
> made by Alan Smith, he's saying last week they retrenched most of the
> AU staff (http://www.google.com/search?q=3Dsite%3Alinkedin.com+altium
> +limited) with the hope of setting up a team in China, well since then
> inside sources have confirmed that the vast majority of the people
> that were supposedly meant to head off to china to setup the new
> offices/team have decided to take voluntary redundancy, which means as
> of today Altium Limited and their product Altium designer is in limbo.

Rubbish.
There were no voluntary redundancies, and the product and company is
not in limbo.

> To furthermore, lay-offs will be made this week in the San Diego
> offices, this will include transfering all support calls to the China
> offices.

More rubbish.

So who are you, and who do you work for?

Dave.

Article: 151468
Subject: Re: Altium Limited closing up shop - Altium Designer discontinued
From: "David L. Jones" <altzone@gmail.com>
Date: Mon, 11 Apr 2011 20:43:38 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 12, 1:32=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
> On Apr 11, 4:18=A0pm, Rob Irwin <rob.ir...@altium.com> wrote:
>
>
>
> > On Apr 11, 11:10=A0pm, "Nial Stewart"
>
> > <nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote:
> > > I'm posting as an AD user, concerned for the long term future of the =
tool.
>
> > > > This is not an April fools comment, this is real. 3 out of 4 of the
> > > > main architects Marc Depret, Dejan Stankovic and Benjamin Wells wil=
l
> > > > not be making the move as such have tendered their resignation, =A0=
but
> > > > have been requested by Altium management to not make it public unti=
l
> > > > after the June EOY ASX fillings have been made.
> > > > The reality is there is no guarantee that Altium as a company will =
be
> > > > around this time next year, so who knows what will happen to multi-
> > > > year subscriptions and promised upgrade cycles.
>
> > > This _could_ be interpreted as FUD by a competitor.
>
> > > Rikard, who are you and what's your source for the detailed informati=
on
> > > above?
>
> > > Nial
>
> > Hi Nial. Not sure if this is FUD by a competitor, but it certainly is
> > ill-informed comment. I work at Altium, currently in the Australian
> > office, and can assure everyone that Altium Designer is not being
> > discontinued in ANY way. The move of HQ to China (we will remain an
> > Australian company) is actually aimed at allowing us to ramp up our
> > development schedule, and to get Altium Designer on to the desktops of
> > more designers and engineers around the world.
>
> > So, yes. Perhaps Rikard needs to declare who he is and who he works
> > for. Otherwise his comments can be disregarded.- Hide quoted text -
>
> > - Show quoted text -
>
> The post came from a DSL line in New South Wales, Sydney.

Yes, the message traces to the Hornsby area in Sydney, via a TGP
Internet account.

Dave.

Article: 151469
Subject: Re: Source of Dynamic Power Consumption in FPGAs
From: rickman <gnuarm@gmail.com>
Date: Mon, 11 Apr 2011 21:50:40 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 11, 9:16=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> rickman <gnu...@gmail.com> wrote:
>
> > I guess the part I'm unclear on is whether this is truly significant
> > in a typical design. =A0If the branching is not a large part of a desig=
n
> > or if the branching is only in the control logic and not the data
> > paths I would expect the difference to be small or negligible.
>
> Well, there isn't that much you can do about it. =A0

I'm not sure what you mean.  The point is that is you need to reduce
power in your design and it has certain features, this may be a useful
technique for reducing the power.  I would like to work with the
Silicon Blue devices to measure some power figures for a variety of
designs I've done.  When I get to that I may try this technique and
see if it gives useful results.

Rick

Article: 151470
Subject: Re: Source of Dynamic Power Consumption in FPGAs
From: backhus <goouse99@googlemail.com>
Date: Mon, 11 Apr 2011 23:44:24 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 12 Apr., 00:24, rickman <gnu...@gmail.com> wrote:
> In considering the nature of power consumption in FPGA devices it
> occurred to me to ask what components in the FPGA are responsible for
> most of the power. =A0The candidates are clock trees, routing, LUT and
> misc logic and finally, FFs.
>
> In CMOS devices the power consumed comes from charging and discharging
> capacitance. =A0So I would expect the clock trees with their constant
> toggling to be a likely candidate for the most power consumption.
> Second on my list is the routing since I would expect the capacitance
> to be significant. =A0I expect the LUTs to be next but may be fairly
> close to the power consumed in the FFs.
>
> With that in mind, I think the typical way of reducing power by the
> use of clock enables on registers which are on the output of logic
> block may not be optimal. =A0This is the part that I have not fully
> analyzed, but I think it could be significant.
>
> When a register on the output of a logic block is enabled, routing and
> logic feeding the register inputs will have dissipated power but after
> the clock, routing and logic fed by the output will also dissipate
> power regardless whether the next register will be enabled on the next
> clock or not! =A0In other words, the routing and logic can dissipate
> power just because the inputs to the logic are changing even when that
> logic is not needed.
>
> If the registers are placed at the input to a function block the
> routing and logic will only dissipate power when the registers are
> enabled allowing the register outputs and the logic inputs to change.
> Why is this different from output registers? =A0If your design is a
> linear pipeline then it is not different. =A0But that is the exception.
> With branching and looping of logic flow an output can feed multiple
> other logic blocks. =A0If multiple inputs to logic change at different
> times this will also increase dissipation. =A0When those other logic
> blocks do not need this new data the power used in the routing and
> logic is wasted.
>
> I guess the part I'm unclear on is whether this is truly significant
> in a typical design. =A0If the branching is not a large part of a design
> or if the branching is only in the control logic and not the data
> paths I would expect the difference to be small or negligible.
>
> I don't think I am the first person to think of this. =A0Since this is
> not a part of vendors recommendations I think it is a pretty good
> indicator that it is not a large enough factor to be useful. =A0Has
> anyone seen an analysis on this?
>
> Rick

Hi Rick,
have you taken a look at Xilinx Xpower Analyzer?
For a given design it calculates the power consumption with regard to
many variables.
It's interesting to see the impact of these variables on the power
consumption.
Regardles of the brand, the tendency should be similar for other FPGAs
too.
And maybe other companies have similar tools too.

Have a nice synthesis
  Eilert

Article: 151471
Subject: Re: Source of Dynamic Power Consumption in FPGAs
From: hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray)
Date: Tue, 12 Apr 2011 02:08:40 -0500
Links: << >>  << T >>  << A >>
In article <48a5df08-d39a-4c4e-bb4c-99b37bc624b1@l18g2000yqm.googlegroups.com>,
 rickman <gnuarm@gmail.com> writes:

>In CMOS devices the power consumed comes from charging and discharging
>capacitance.

That was true in the old days.

With modern (really) thin oxide, you have to consider leakage currents.


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


Article: 151472
Subject: Re: Source of Dynamic Power Consumption in FPGAs
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Tue, 12 Apr 2011 07:31:56 +0000 (UTC)
Links: << >>  << T >>  << A >>
rickman <gnuarm@gmail.com> wrote:
> On Apr 11, 9:16 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>> rickman <gnu...@gmail.com> wrote:

>> > I guess the part I'm unclear on is whether this is truly significant
>> > in a typical design.  If the branching is not a large part of a design
>> > or if the branching is only in the control logic and not the data
>> > paths I would expect the difference to be small or negligible.

>> Well, there isn't that much you can do about it.  
 
> I'm not sure what you mean.  The point is that is you need to reduce
> power in your design and it has certain features, this may be a useful
> technique for reducing the power.  

Say you have an XOR gate where the two inputs come from different
FF's clocked on the same clock, but through different paths.
If you can make those two paths the same length, then there won't
be extra transitions.

Now, with ASIC logic you get a lot of control over the wiring,
and could work to get path lengths equal.  With FPGAs, you don't
have so much control.  Even more, the routing paths are often
buffered, even though you don't see them.  

But often the circuits are designed for high-speed, and very
rarely low power.  I do remember the 74L series TTL, slower and
lower power.   If you make the metal traces narrower (reduce
capacitance) you increase the resistance, slowing down the signal.
You can trade speed for power in many ways.

> I would like to work with the
> Silicon Blue devices to measure some power figures for a variety of
> designs I've done.  When I get to that I may try this technique and
> see if it gives useful results.

So they give you more control than the usual FPGA tools?

-- glen

Article: 151473
Subject: Re: Source of Dynamic Power Consumption in FPGAs
From: shyam <mail.ghanashyam.prabhu@gmail.com>
Date: Tue, 12 Apr 2011 00:48:14 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 12, 9:50=A0am, rickman <gnu...@gmail.com> wrote:
> On Apr 11, 9:16=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>
> > rickman <gnu...@gmail.com> wrote:
>
> > > I guess the part I'm unclear on is whether this is truly significant
> > > in a typical design. =A0If the branching is not a large part of a des=
ign
> > > or if the branching is only in the control logic and not the data
> > > paths I would expect the difference to be small or negligible.
>
> > Well, there isn't that much you can do about it. =A0
>
> I'm not sure what you mean. =A0The point is that is you need to reduce
> power in your design and it has certain features, this may be a useful
> technique for reducing the power. =A0I would like to work with the
> Silicon Blue devices to measure some power figures for a variety of
> designs I've done. =A0When I get to that I may try this technique and
> see if it gives useful results.
>
> Rick

Hi Rick, As a regular subsriber of the comp arch group and an
interested engineer in reconfigurable hardware, I started reading your
post. Incidently, I read about SiliconBlue FPGAs and gives me a great
sense of happiness for I work for the IP development on SiliconBlue.

Primarily, the clock gating is very much the prominent approach to
solve dynamic powers.
Operating on a bank wise basis is yet another.
Banks supporting multiple voltage are a feature in SiliconBlue that I
feel should be exploited. For instance once can always run a mDDR bank
at 1.8 and an SD bank at 3.3 and you get substantial reduction power.

Using Clock Enables are very tricky though I think they can do much as
far as power reduction is concerned. But this most times is
architecture specific. For instance in SiliconBlue, if you are having
a clock enable on a register, and if that register is implemented in a
logic block, then the clock enable is the same for other registers in
the logic block and if the design does not have other registers having
the same clock enable, then they are mapped to other logic blocks
which is primarily wastage of resources and additionally increases
dynamic power because there are additional switches used to route
outputs from the other logic block

I have been trying to measure the dynamic power with some design of
mine, but I couldn't get the real setup with software to keep track of
the power consumption on a real time (rendering numbers using
software)

Article: 151474
Subject: Re: Source of Dynamic Power Consumption in FPGAs
From: Marc Jet <jetmarc@hotmail.com>
Date: Tue, 12 Apr 2011 04:15:43 -0700 (PDT)
Links: << >>  << T >>  << A >>
Your thoughts about where the power goes seem mostly correct.

My experience is the following.  You can't do much about static power,
except by playing with the external voltages.  Then there is I/O
consumption, like driving your outputs to the PCB, and hopefully no
floating input pins.  Sometimes you can tune those things.  But once
this is done, you have to live with the hardware.

In software, the ONE major cause for current consumption is toggling
interconnect.

Each route in reality consists of buffers, tracks, receivers, etc.
But the most important thing you can do to reduce the consumption of
the route is:

a) make the route "shorter", and/or
b) make it toggle less often.

Little else can be done, and therefore it's usually not necessary to
go into the details about what elements physically make up the route.

Clocks have a high togglerate, and high fanout converts it into lots
of routes used.  Therefore the clock tree obviously is one of the
major consumers (if not the top one).  Unfortunately the clock tree is
also one of the most difficult things to tune or get rid off.  Slow
clocks (instead of clock enables) for the slow portions of your design
are probably the most fruitful thing to do with regards to clock.

Data routes however, can often be influenced at the HDL level (by
restructuring the design).  Look at your design in the floorplanner
and FPGA editor, and at the CLB description in the datasheet.  Figure
out a good way of mapping the functionality onto the available
hardware.  Express that in your HDL, and the tools will (to some
degree) follow you through without explicit floorplanning or vendor
specific primitives.

The only other thing worth mentioning is LUT flicker.  The different
input signals each have distinct arrival times (steming from their
individual route delay).  Each time an input arrives, the LUT output
may toggle (depending on terms).  If the LUT drives a "long" route,
this causes high consumption.  Several approaches can be used to
reduce it.  A simple one is to use few logic levels.  Registering
after LUT is usually done in the same slice, thus a very short route
with little consumption during flicker.  It has a good net result for
dense data with high togglerate, despite the bigger clock tree.
Obvously, the opposite can be true for slow data.

Best regards,
Marc



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