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 87400

Article: 87400
Subject: Re: IP-cores for digital audio
From: amyler@eircom.net
Date: 22 Jul 2005 12:43:53 -0700
Links: << >>  << T >>  << A >>
I designed an SPDIF to I2S audio disembedder about 2 years ago for a
client. It's pretty straightforward, like a couple of days max. should
see it done ok once you're up to speed on what you need. The one I did
was for an Altera Stratix but the only family specific bit was a fifo.

Alan


Article: 87401
Subject: Re: DDR SDRAM on ML401
From: "jimwu88NOOOSPAM@yahoo.com" <jimwu88NOOOSPAM@yahoo.com>
Date: 22 Jul 2005 12:49:29 -0700
Links: << >>  << T >>  << A >>
I have a UCF file for ML401. If you'd like please contact me directly
(remove all capital letters in my email address) and I will send it to
you.

Jim


Article: 87402
Subject: Re: parallel optic availability
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Fri, 22 Jul 2005 21:56:08 +0200
Links: << >>  << T >>  << A >>

"Tullio Grassi" <tgrassi@mail.cern.ch> schrieb im Newsbeitrag
news:Pine.LNX.4.58.0507222100100.9491@lxplus064.cern.ch...

> Slightly off-topic post:
>
> I am looking for parallel optic (12-way) transmitter
> and receiver at ~2.7Gbps, to use with xilinx Rocket IO.

Why do you want to use parallel optics? Why not using one single
transmitter. Fibre Channel II reaches 2.something Gbit/s, if this is a lab
setup it might be possible to overclock them. Some also offer 2.5 Gbit/s.
And finally there are 4 Gbit/S Fibre Channel Tranceiers. Or use two Gigabit
tranceivers (1.25 Gbit/s) in parallel with slightly overclocking. These
tranceivers are cheap and easily availible (~$50).

Regards
Falk




Article: 87403
Subject: Re: verilog to blif(lut)
From: "Vladislav Muravin" <muravinv@advantech.ca>
Date: Fri, 22 Jul 2005 15:56:55 -0400
Links: << >>  << T >>  << A >>
What is blif format?
You are probably talking about synthesis tool, aren't you?

Vladislav


"junaid" <k.najeeb@gmail.com> wrote in message 
news:1122026304.657790.4750@g14g2000cwa.googlegroups.com...
> Hi All,
>
> Can anyone suggest a method to convert verilog file into blif (LUT)
> format. Does altera or xilinx support this file conversion ?. Kindly
> help me in this regard
>
> Thanking  you in advance
> 



Article: 87404
Subject: Transfert data to Memec Virtex II Pro Card from PC
From: jacques77@gmail.com
Date: 22 Jul 2005 12:57:39 -0700
Links: << >>  << T >>  << A >>
Hello all,

Does anyone around here has ever transfer data from PC to Memec card
using Virtex II FPGA? If yes, could you please tell me how dis you do
that?

Thank you!
Jacques


Article: 87405
Subject: Re: July 20th Altera Net Seminar: Stratix II Logic Density
From: "Paul Leventis" <paul.leventis@utoronto.ca>
Date: 22 Jul 2005 13:30:37 -0700
Links: << >>  << T >>  << A >>
Hi Sean,

Thanks for a well thought-out posting with a lot of good questions and
comments.

> How often can you
> share 4 inputs with two seperate functions? Or share 6 inputs with two
> seperate functions? My guess is that the 5 + 3 or 5 + 4 is where it
> helps more.

We found functions could share inputs often enough to justify the small
amount of extra hardware required to allow these modes.  But yes, it is
primarily the ability to implement a 4 + 4, a 3 + 5, a 6, etc. that
helps the most on density, since this allows us to efficiently pack
most of the LUTs that come out of synthesis + tech mapping without
wasting much of the ALM.  The other modes are not as commonly used but
are used often enough to justify their existance.

> I think the biggest advantage is reduced levels of logic
> isn't it? One important point will be what is the Fmax difference
> between these designs. Aren't more packed designs slower?

Yes, the main advantage of the 6-LUT is speed.  In a classic 6-LUT
architecture, the added speed of reduced logic levels would come at a
large increase in silicon cost (due to unused logic in 6-LUTs used to
implement 5-, 4- and 3-input functions).  The ALM is designed to get
the speed benefit of reduced logic levels, without that area penalty.

Packing *can* slow things down, depending on how smart the tool is.  If
you take two unrelated 4-LUTs that want to be on opposite sides of the
chip and pack them into one ALM (or one Slice), then you have probably
hurt performance.  On the other hand, taking LUTs that have some common
fan-in and packing them together probably doesn't hurt performance
much, since they likely come from parts of the design that wanted to be
together anyway.  Also, by packing more tightly, the average distance a
routing connection must travel may be reduced, improving performance.
For example, the shared LUT mask mode of the ALM that implements 2
6-LUTs sharing 4 inputs into one ALM likely doesn't hurt performance at
all -- if anything, it probably helps since it doubles the density of
those circuits, such as bused multiplexors, that use it.

> Anyway, the truth is something that will not be talked about on here.
> [snip - discussion on area of ALM vs. alternatives]

This is a good observation and is the heart of the logic architect's
design problem.  In designing Stratix II, we experimented with numerous
Logic Element designs; each was evaluated on the "silicon area per
logic function" metric.  We are claiming that you need 1.3 Slices to
implement the same functionality as an ALM (on average).  Provided the
ALM is no more than 1.3X bigger than a Slice, then the "silicon area
per logic function" is better off for the ALM.

> Since the LX200 has 200K and the S2 has 180K, my guess is that
> the SliceM + SliceL is a bit smaller than 2 x ALM.

Remember, LX200 has 89,088 Slices, and 2S180 has 71,760 ALMs.  So
*assuming* that the two dice have the same area, and *assuming* that
all that area is ALMs/Slices (which it is not), then you get an area
ratio of ALM:Slice = 1.24:1, which is lower than the logic density
ratio of 1.3:1, indicating that the ALM has better density by a ratio
of 1.30/1.24.  Of course, there are enough assumptions here to
completely invalidate this result; we both spend considerable area on
other functions, and we have overhead for redundancy technology, but
get more yield, etc... and routing is a considerable part of the logic
+ routing area...

In the end Altera chose to move to the ALM.  This involved re-writting
much of our LE-optimized IP, new Quartus synthesis, new 3rd party
synthesis, considerable changes to our CAD flow, and a lot of other
work to do so.  The only way we would have committed the resources
needed and taken this big risk is if we believed the ALM was a big win
in silicon cost and speed.

Regards,

Paul Leventis
Altera Corp.


Article: 87406
Subject: Re: parallel optic availability
From: Tullio Grassi <tgrassi@mail.cern.ch>
Date: Fri, 22 Jul 2005 23:37:35 +0200
Links: << >>  << T >>  << A >>
On Fri, 22 Jul 2005, Falk Brunner wrote:

> > Slightly off-topic post:
> >
> > I am looking for parallel optic (12-way) transmitter
> > and receiver at ~2.7Gbps, to use with xilinx Rocket IO.
> 
> Why do you want to use parallel optics? Why not using one single
> transmitter. Fibre Channel II reaches 2.something Gbit/s, if this is a lab
> setup it might be possible to overclock them. Some also offer 2.5 Gbit/s.
> And finally there are 4 Gbit/S Fibre Channel Tranceiers. Or use two Gigabit
> tranceivers (1.25 Gbit/s) in parallel with slightly overclocking. These
> tranceivers are cheap and easily availible (~$50).
> 
> Regards
> Falk
> 

the parallel optics modules that I mentioned 
handle 12 x 2.7Gb/s = 32.4 Gb/s.
For example Agilent HFBR-779B.
I need some 6 of these modules per board.
Using individual transceivers become a pain in the neck
(that is actually what we have done so far with a 
smaller scale project).
Going above 3.125 Gb/s on a single link is complicate
because require the RocketIO X that are less available,
and I prefere to avoid extreme S.I. problems...

 Tullio

Article: 87407
Subject: Re: Transfert data to Memec Virtex II Pro Card from PC
From: praetorian <Hua.Zheng@jpl.nasa.gov>
Date: Fri, 22 Jul 2005 14:48:41 -0700
Links: << >>  << T >>  << A >>
jacques77@gmail.com wrote:
> Hello all,
> 
> Does anyone around here has ever transfer data from PC to Memec card
> using Virtex II FPGA? If yes, could you please tell me how dis you do
> that?
> 
> Thank you!
> Jacques
> 
What is a Memec card?

Article: 87408
Subject: Re: General-purpose STAPL Composer?
From: ad.rast.7@nwnotlink.NOSPAM.com (Alex Rast)
Date: Fri, 22 Jul 2005 23:12:05 -0000
Links: << >>  << T >>  << A >>
at Thu, 21 Jul 2005 19:57:02 GMT in <dboukf$id8$04$1@news.t-online.com>,
r.fridolin@gmx.de (Ralph Friedrich) wrote : 

>Hello I compiled the stapl player for our testsystem.
>One function is to calculate the checksum of the JAM file.
>Regards Ralph
>
Did you also do a STAPL composer? And do you have source for that? I have a 
STAPL player, that's not a problem - what I need is a STAPL composer.

-- 
Alex Rast
ad.rast.7@nwnotlink.NOSPAM.com
(remove d., .7, not, and .NOSPAM to reply)

Article: 87409
Subject: Re: Best Practices to Manage Complexity in Hardward/Software Design?
From: "Rune Allnor" <allnor@tele.ntnu.no>
Date: 22 Jul 2005 17:08:54 -0700
Links: << >>  << T >>  << A >>


Fred Marshall skrev:
> <jjlindula@hotmail.com> wrote in message
> news:1121970065.257771.127820@g43g2000cwa.googlegroups.com...
> > Hello, I'm interested in how individuals or design groups manage
> > complexity in their design projects. What things do you do or things
> > the group does that can take complex tasks and break them into simpler
> > or more manageable tasks? It may sound like a weird question, but there
> > must be some guidelines, best practices, or habits used to achieve
> > success in designing/developing a complex project. I'm sure there must
> > be some individuals out there that are constantly taking complex tasks
> > and just about every time have success with it. Short of speaking, I
> > want to know what's the secret to their success. All comments are
> > welcomed, even the most obvious suggestions.
> >
> > As an engineer, I'm constantly trying to improve my design processes.
> >
>
> Joe,
>
> Here is another perspective:
>
> People are the source of complexity.

I'd say some problems are complex before adding the people factor.

> Better" is the enemy of "good enough".

Hmm... I've seen this in the form "'perfect' is the enemy of 'good
enough'", which I agree with. I am not sure I agree with "'better'...".


> One reason the requirements need to be understood is to avoid changes.
>
> You should have a process to prevent changes.  Design freezes are a way to
> do this.  This avoids bringing in the latest and greatest idea and perhaps
> even doing that again and again and again.....  Then you should probably
> have a higher-level process to embrace great ideas for change.

I made the mistake some time ago to browse through a book on project
management (don't remember the title, though). As far as I remember,
there were four basic modes of project planning:

A) Goals fixed, resources fixed.
B) Goals fixed, resources relaxed[*]
C) Goals relaxed[*], resources fixed
D) Goals relaxed[*], resources relaxed[*]

[*] "relaxed" means that the goals or resources either are unknown
at project planning time, or they change significantly troughout
project lifetime.

While no one knows everything that will happen in the future, I do
agree with you that changes in goals should be avoided, as far as
possible, during project lifetime. I was not happy to discover the
emphasis on cases C) and D) above, in the book I browsed. Perhaps
I am too naive?

> It doesn't happen often that it isn't, but try to make sure that the thing
> is feasible in our lifetime - otherwise it isn't engineering it's an
> experiment.

Agreed.

> Sometimes you won't know the requirements until you've tried some things.

Would this type of project qualify as cases C)-D) above?

Rune


Article: 87410
Subject: Re: Best Practices to Manage Complexity in Hardward/Software Design?
From: Jerry Avins <jya@ieee.org>
Date: Fri, 22 Jul 2005 20:30:38 -0400
Links: << >>  << T >>  << A >>
Rune Allnor wrote:
> 
> Fred Marshall skrev:
> 
>><jjlindula@hotmail.com> wrote in message
>>news:1121970065.257771.127820@g43g2000cwa.googlegroups.com...
>>
>>>Hello, I'm interested in how individuals or design groups manage
>>>complexity in their design projects. What things do you do or things
>>>the group does that can take complex tasks and break them into simpler
>>>or more manageable tasks? It may sound like a weird question, but there
>>>must be some guidelines, best practices, or habits used to achieve
>>>success in designing/developing a complex project. I'm sure there must
>>>be some individuals out there that are constantly taking complex tasks
>>>and just about every time have success with it. Short of speaking, I
>>>want to know what's the secret to their success. All comments are
>>>welcomed, even the most obvious suggestions.
>>>
>>>As an engineer, I'm constantly trying to improve my design processes.
>>>
>>
>>Joe,
>>
>>Here is another perspective:
>>
>>People are the source of complexity.
> 
> 
> I'd say some problems are complex before adding the people factor.
> 
> 
>>Better" is the enemy of "good enough".
> 
> 
> Hmm... I've seen this in the form "'perfect' is the enemy of 'good
> enough'", which I agree with. I am not sure I agree with "'better'...".
> 
> 
> 
>>One reason the requirements need to be understood is to avoid changes.
>>
>>You should have a process to prevent changes.  Design freezes are a way to
>>do this.  This avoids bringing in the latest and greatest idea and perhaps
>>even doing that again and again and again.....  Then you should probably
>>have a higher-level process to embrace great ideas for change.
> 
> 
> I made the mistake some time ago to browse through a book on project
> management (don't remember the title, though). As far as I remember,
> there were four basic modes of project planning:
> 
> A) Goals fixed, resources fixed.
> B) Goals fixed, resources relaxed[*]
> C) Goals relaxed[*], resources fixed
> D) Goals relaxed[*], resources relaxed[*]
> 
> [*] "relaxed" means that the goals or resources either are unknown
> at project planning time, or they change significantly troughout
> project lifetime.
> 
> While no one knows everything that will happen in the future, I do
> agree with you that changes in goals should be avoided, as far as
> possible, during project lifetime. I was not happy to discover the
> emphasis on cases C) and D) above, in the book I browsed. Perhaps
> I am too naive?
> 
> 
>>It doesn't happen often that it isn't, but try to make sure that the thing
>>is feasible in our lifetime - otherwise it isn't engineering it's an
>>experiment.
> 
> 
> Agreed.
> 
> 
>>Sometimes you won't know the requirements until you've tried some things.
> 
> 
> Would this type of project qualify as cases C)-D) above?

In some fields, it's typical. If you can specify the outcome and the 
path to it, it isn't research.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ

Article: 87411
Subject: Re: Best Practices to Manage Complexity in Hardward/Software Design?
From: "Rune Allnor" <allnor@tele.ntnu.no>
Date: 22 Jul 2005 17:37:47 -0700
Links: << >>  << T >>  << A >>


Jerry Avins skrev:
> Rune Allnor wrote:
> >
> > Fred Marshall skrev:
> >>Sometimes you won't know the requirements until you've tried some things.
> >
> >
> > Would this type of project qualify as cases C)-D) above?
>
> In some fields, it's typical. If you can specify the outcome and the
> path to it, it isn't research.

Ah, sorry. I didn't mention that these cases applied to projects in
general, not necessarily R&D projects. R&D comes into case C) and D)
almost by default.

Rune


Article: 87412
Subject: Re: Best Practices to Manage Complexity in Hardward/Software Design?
From: Ben Bradley <ben_nospam_bradley@frontiernet.net>
Date: Sat, 23 Jul 2005 03:18:38 GMT
Links: << >>  << T >>  << A >>
In comp.arch.fpga,comp.software-eng and comp.dsp, On 21 Jul 2005
11:21:05 -0700, "jjlindula@hotmail.com" <jjlindula@hotmail.com> wrote:

>Hello, I'm interested in how individuals or design groups manage
>complexity in their design projects. What things do you do or things
>the group does that can take complex tasks and break them into simpler
>or more manageable tasks? It may sound like a weird question, but there
>must be some guidelines, best practices, or habits used to achieve
>success in designing/developing a complex project. I'm sure there must
>be some individuals out there that are constantly taking complex tasks
>and just about every time have success with it. Short of speaking, I
>want to know what's the secret to their success. All comments are
>welcomed, even the most obvious suggestions.
>
>As an engineer, I'm constantly trying to improve my design processes.

   The big company I worked for at the time sent me to a week-long
"Software Engineering Training Program" while in the middle of a
longish project. I recall it being a mostly "positive learning
experience" but the only thing I now (10 years later) remember from it
was "Do a post-mortem on the project." When you get done with a
project (whether it's shipping or it was trashed), you (meaning the
whole team) look it over (perhaps not so much the design itself but
rather how you did it), see what you did right and what went wrong,
what you could have done better, etc. The point of this is that you
might have better insight at the start of the next project, rather
than at the end of it.
   Of course, at the end of the project I was working on, we did NOT
do a post-mortem.

>Thanks everyone,
>joe

-----
http://www.mindspring.com/~benbradley

Article: 87413
Subject: Re: Best Practices to Manage Complexity in Hardward/Software Design?
From: Erik de Castro Lopo <nospam@mega-nerd.com>
Date: Sat, 23 Jul 2005 13:34:12 +1000
Links: << >>  << T >>  << A >>
Ben Bradley wrote:
> 
>    The big company I worked for at the time sent me to a week-long
> "Software Engineering Training Program" while in the middle of a
> longish project. I recall it being a mostly "positive learning
> experience" but the only thing I now (10 years later) remember from it
> was "Do a post-mortem on the project." When you get done with a
> project (whether it's shipping or it was trashed), you (meaning the
> whole team) look it over (perhaps not so much the design itself but
> rather how you did it), see what you did right and what went wrong,
> what you could have done better, etc. The point of this is that you
> might have better insight at the start of the next project, rather
> than at the end of it.
>    Of course, at the end of the project I was working on, we did NOT
> do a post-mortem.

Very common.

I was involved in one of those hellish development projects that 
resembles a slow moving train wreck.

The project was supposed to take 9 months but ended up taking over
2.5 years. Near the end, I offered to write a paper on what went
wrong and how to avoid similar problems in future projects. I made
it clear that I was not looking to blame anyone but I wanted the
company and the development team to learn from the mistakes made.

My offer was ignored and I left the company 4 months later to
go to a job with about 5% less pay.

Erik
-- 
+-----------------------------------------------------------+
  Erik de Castro Lopo  nospam@mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
"Linux is produced to be used, whereas the others are produced
to be sold"  -- Bobby D. Bryant

Article: 87414
Subject: Re: Best Practices to Manage Complexity in Hardward/Software Design?
From: "Matt Timmermans" <mt0000@sympatico.nospam-remove.ca>
Date: Fri, 22 Jul 2005 23:49:31 -0400
Links: << >>  << T >>  << A >>

<jjlindula@hotmail.com> wrote in message 
news:1121970065.257771.127820@g43g2000cwa.googlegroups.com...
> Hello, I'm interested in how individuals or design groups manage
> complexity in their design projects. What things do you do or things
> the group does that can take complex tasks and break them into simpler
> or more manageable tasks?

Easy:

1) Make sure the chief architect or engineer is responsible for getting the 
project delivered on time.

2) Make sure he doesn't have enough time to do too much of the work himself.

3) Make sure there are enough other resources available to make it worth his 
while to take advantage of them.

Then, the chief architect or engineer will have to divide much of the 
project into manageable components that can be assigned to others.

--
Matt



Article: 87415
Subject: Re: Best Practices to Manage Complexity in Hardward/Software Design?
From: Steve Underwood <steveu@dis.org>
Date: Sat, 23 Jul 2005 12:13:13 +0800
Links: << >>  << T >>  << A >>
Erik de Castro Lopo wrote:
> I was involved in one of those hellish development projects that 
> resembles a slow moving train wreck.

Only one? Your career must have been truly blessed. :-)

Steve

Article: 87416
Subject: Re: Best Practices to Manage Complexity in Hardward/Software Design?
From: Erik de Castro Lopo <nospam@mega-nerd.com>
Date: Sat, 23 Jul 2005 18:17:28 +1000
Links: << >>  << T >>  << A >>
Steve Underwood wrote:
> 
> Erik de Castro Lopo wrote:
> > I was involved in one of those hellish development projects that
> > resembles a slow moving train wreck.
> 
> Only one? Your career must have been truly blessed. :-)

Well after that disaster I spent three and a half years doing technical 
support in the most senior level of support at SUN Microsystem.

I'm now back doing development work and find that things haven't
changed much :-).

Erik
-- 
+-----------------------------------------------------------+
  Erik de Castro Lopo  nospam@mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
"I don't think any MS Exec will ever die of old age. Satan
doesn't need the competition."
-- Digital Wokan on LinuxToday.com

Article: 87417
Subject: Re: Best Practices to Manage Complexity in Hardward/Software Design?
From: Jacob Sparre Andersen <sparre@nbi.dk>
Date: 23 Jul 2005 10:37:24 +0200
Links: << >>  << T >>  << A >>
Rune Allnor wrote:

> While no one knows everything that will happen in the future, I do
> agree with you that changes in goals should be avoided, as far as
> possible, during project lifetime.

But there is a significant class of projects - at least in failure
visibility - where you beforehand can be practically certain that the
goals will change during the project lifetime: Projects which shold
manage public sector policies (i.e. payment of unemployment benefits,
health insurance, taxes, ...)

Greetings,

Jacob

PS: Isn't this discussion a little bit off-topic for "comp.arch.fpga"
    and "comp.dsp"?
-- 
ğWhat fun is it being "cool" if you can't wear a sombrero?Ğ

Article: 87418
Subject: Update contacts at Altera
From: Jedi <me@aol.com>
Date: Sat, 23 Jul 2005 08:42:01 GMT
Links: << >>  << T >>  << A >>
Moro

Back from a successful trip in .ch I have to change
my contact details at Altera and they provide
an email address for doing this:

	csecom@altera.com

which just leads into nirvana and bounces back
with "user unknown"...

Any other address to use? Or why is it not allowed to
change address online?


rick

Article: 87419
Subject: Re: Best Practices to Manage Complexity in Hardward/Software Design?
From: "Rune Allnor" <allnor@tele.ntnu.no>
Date: 23 Jul 2005 03:48:19 -0700
Links: << >>  << T >>  << A >>


Jacob Sparre Andersen skrev:
> Rune Allnor wrote:
>
> > While no one knows everything that will happen in the future, I do
> > agree with you that changes in goals should be avoided, as far as
> > possible, during project lifetime.
>
> But there is a significant class of projects - at least in failure
> visibility - where you beforehand can be practically certain that the
> goals will change during the project lifetime: Projects which shold
> manage public sector policies (i.e. payment of unemployment benefits,
> health insurance, taxes, ...)

Do such activities satisfy the definition of of a project?
As far as I remember, a project is defined as something like

"An activity with a priori specified goals and resources,
that takes place once, and that is of limited duration."

The activites you describe seem to be programs, to me. Somehow,
I have the impression that the words "project" and "activity"
are on their way to become synonyms.

I prefer to stick to the definition of a project, with a priori
known goals and resources, and handle the changes as "deviations
from plans". Labeling the changes like that, may put some pressure
on planners to get their estimates right the next time, or make
them choose to organize the activity as something other than a
project.

> PS: Isn't this discussion a little bit off-topic for "comp.arch.fpga"
>     and "comp.dsp"?

I don't know about comp.arch.fpga, but the last few weeks the
threads on comp.dsp have not been all that on-topic, not least
thanks to me.

Every now and then, threads of more "philosophical" nature occur.
I think project organization and company policy are very important
parts of engineering projects these days. Every now and then,
such questions, rather than technology, are the roots of the
problems. I don't necessarily see this thread as off topic, what
comp.dsp is concerned.

But then, I'm a major contributor to the noise on comp.dsp.

> =BBWhat fun is it being "cool" if you can't wear a sombrero?=AB

Indeed.

Rune


Article: 87420
Subject: Re: Best Practices to Manage Complexity in Hardward/Software Design?
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Sat, 23 Jul 2005 10:16:46 -0700
Links: << >>  << T >>  << A >>
Erik de Castro Lopo wrote:
(snip)

> I was involved in one of those hellish development projects that 
> resembles a slow moving train wreck.

> The project was supposed to take 9 months but ended up taking over
> 2.5 years. Near the end, I offered to write a paper on what went
> wrong and how to avoid similar problems in future projects. I made
> it clear that I was not looking to blame anyone but I wanted the
> company and the development team to learn from the mistakes made.

Read "Mythical man-month", which pretty much has the same description,
though on a different scale.

It is written by the head of the OS/360 project.  The examples relate
to software projects, but it should be more generally applicable.

-- glen


Article: 87421
Subject: Fastest way to compute floating point log and exp
From: "Marc Battyani" <Marc.Battyani@fractalconcept.com>
Date: Sat, 23 Jul 2005 19:39:13 +0200
Links: << >>  << T >>  << A >>
I'm looking at the fastest way to compute floating point (32bit) log and exp
on an FPGA (Stratix II or Virtex 4). It must be faster than a 3.6GHz Xeon
which can do that in 18.5 clock cycles on average on a 1000 float vector
(using SSE3)

So far I've found that with a few tables and floating point MUL and ADD
blocks I should be able to do that at 160MHz on a Stratix II (not tested
yet). It's still slower than the Xeon but at least it's close. I've looked
at cordic at a glance, but it looks slower or bigger if totally unrolled.

Any ideas or pointers on a better way to do that?

Thanks

Marc



Article: 87422
Subject: Re: Best Practices to Manage Complexity in Hardward/Software Design?
From: "Fred Marshall" <fmarshallx@remove_the_x.acm.org>
Date: Sat, 23 Jul 2005 11:08:45 -0700
Links: << >>  << T >>  << A >>

"Rune Allnor" <allnor@tele.ntnu.no> wrote in message 
news:1122079067.583190.317210@o13g2000cwo.googlegroups.com...
>
>
> Jerry Avins skrev:
>> Rune Allnor wrote:
>> >
>> > Fred Marshall skrev:
>> >>Sometimes you won't know the requirements until you've tried some 
>> >>things.
>> >
>> >
>> > Would this type of project qualify as cases C)-D) above?
>>
>> In some fields, it's typical. If you can specify the outcome and the
>> path to it, it isn't research.
>
> Ah, sorry. I didn't mention that these cases applied to projects in
> general, not necessarily R&D projects. R&D comes into case C) and D)
> almost by default.
>
> Rune
>

Yeah, I thought we were talking about projects that result in a product of 
some sort.  Now, research results would be a "product" to a researcher but I 
was thinking in terms of "harder" deliverables: a system, a box, an 
application program, etc.  So, research papers weren't in my frame of 
reference as a "product".  Engineeers do research but is research 
"engineering"?  A narrower definition for engineering is to "build" 
something (as in design, build, test).  A definition from the web:
  1.. The application of scientific and mathematical principles to practical 
ends such as the design, manufacture, and operation of efficient and 
economical structures, machines, processes, and systems.
I thought that was the context and perhaps beyond into "project management".

So, when we are engineering something, sometimes we have to do a little 
research along the way and that was the crux of "sometimes you don't know 
the requirements until you've tried something".  But, at that, I think this 
is about finding out how certain things interact or behave that require some 
experimentation but I don't think of that as "research" as such.  I can 
think of lots of examples in real life.

Here's an example:
An underwater vehicle that looks like a torpedo would be launched and would 
deploy a towed array rather immediately after launch.  The vehicle was 
controlled by a circular shroud at the tail around the propellors that would 
move up/down port/starboard.  The tow cable was wrapped around the shroud 
and held in place with some hardware claptrap.
The idea was that the claptrap would be released, the flow of water would 
pull it aft and away.  The cable would deploy and the control surface would 
be free to move.
When it failed to work that way, not only did the cable not deploy but the 
vehicle had no dynamic control.
Off to the water tunnel....
It became apparent that the flow of water over the tail cone had velocity 
not only aft but *toward* the skin of the vehicle.  It pressed the claptrap 
*toward* the tail cone - which was in direct opposition to the force needed 
for it to deploy.

... that was an experiment to support development but it wasn't research. 
The result changed the specifications for the claptrap and its release 
mechanisms.

...shake, rattle and roll testing often ends up with new requirements on the 
design unless the designers are very experienced.  That's probably a good 
example.

Once I managed a project that had the purpose of "developing technology" - 
which meant that we were trying new ideas for known end applications within 
a system context.  Now that was somewhat researchy and was certainly 
development.  Having best practices regarding how to do research yields a 
different set of suggestions doesn't it?

Here's an example:
We were trying to reduce the drag of underwater vehicles using all sorts of 
very high tech methods.  One of the groups (no doubt with a vested interest) 
reported experimental success of their technique.  But, some the of the 
tests had failed.  When asked why they threw out those results, they said: 
"something must have been wrong and invalidated those tests".  But, they had 
no idea what might have been wrong or if the tests were truly invalid.  In 
the end we decided that the technology lacked robustness and the results 
were valid: they were indicative of a technology that was "on the edge" of 
working or not working.

So, for research we add to best practices: design of experiments, how to 
handle results, repeatability, etc.

Fred 



Article: 87423
Subject: Re: Best Practices to Manage Complexity in Hardward/Software Design?
From: "Rune Allnor" <allnor@tele.ntnu.no>
Date: 23 Jul 2005 15:32:01 -0700
Links: << >>  << T >>  << A >>


Fred Marshall skrev:
> "Rune Allnor" <allnor@tele.ntnu.no> wrote in message
> news:1122079067.583190.317210@o13g2000cwo.googlegroups.com...
> >
> >
> > Jerry Avins skrev:
> >> Rune Allnor wrote:
> >> >
> >> > Fred Marshall skrev:
> >> >>Sometimes you won't know the requirements until you've tried some
> >> >>things.
> >> >
> >> >
> >> > Would this type of project qualify as cases C)-D) above?
> >>
> >> In some fields, it's typical. If you can specify the outcome and the
> >> path to it, it isn't research.
> >
> > Ah, sorry. I didn't mention that these cases applied to projects in
> > general, not necessarily R&D projects. R&D comes into case C) and D)
> > almost by default.
> >
> > Rune
> >
>
> Yeah, I thought we were talking about projects that result in a product of
> some sort.  Now, research results would be a "product" to a researcher but I
> was thinking in terms of "harder" deliverables: a system, a box, an
> application program, etc.  So, research papers weren't in my frame of
> reference as a "product".  Engineeers do research but is research
> "engineering"?  A narrower definition for engineering is to "build"
> something (as in design, build, test).  A definition from the web:
>   1.. The application of scientific and mathematical principles to practical
> ends such as the design, manufacture, and operation of efficient and
> economical structures, machines, processes, and systems.
> I thought that was the context and perhaps beyond into "project management".
>
> So, when we are engineering something, sometimes we have to do a little
> research along the way and that was the crux of "sometimes you don't know
> the requirements until you've tried something".  But, at that, I think this
> is about finding out how certain things interact or behave that require some
> experimentation but I don't think of that as "research" as such.

How would you prepare for such a project, if you were to take on
something you knew/suspected would need to break new ground? Divide it
into lots of small projects, where one could decide whether to proceed
or not, after each sub-project? Allocate large fractions (25% - 50%)
of the budget to "unexpected expenses"?

>  I can
> think of lots of examples in real life.
>
> Here's an example:
> An underwater vehicle that looks like a torpedo would be launched and would
> deploy a towed array rather immediately after launch.  The vehicle was
> controlled by a circular shroud at the tail around the propellors that would
> move up/down port/starboard.  The tow cable was wrapped around the shroud
> and held in place with some hardware claptrap.
> The idea was that the claptrap would be released, the flow of water would
> pull it aft and away.  The cable would deploy and the control surface would
> be free to move.
> When it failed to work that way, not only did the cable not deploy but the
> vehicle had no dynamic control.
> Off to the water tunnel....
> It became apparent that the flow of water over the tail cone had velocity
> not only aft but *toward* the skin of the vehicle.  It pressed the claptrap
> *toward* the tail cone - which was in direct opposition to the force needed
> for it to deploy.
>
> ... that was an experiment to support development but it wasn't research.
> The result changed the specifications for the claptrap and its release
> mechanisms.

I'd say this example involves "unexpected expenses". The goal, to make
this device work, has not changed. Getting it to work, takes a little
bit longer and involves more cost than previously anticipated.

> ...shake, rattle and roll testing often ends up with new requirements on the
> design unless the designers are very experienced.  That's probably a good
> example.

I can see how the design requirements are refined or adjusted, as
experience is gained. But do the goals change? Perhaps we are splitting

hairs here, but I don't see that they do.

> Once I managed a project that had the purpose of "developing technology" -
> which meant that we were trying new ideas for known end applications within
> a system context.  Now that was somewhat researchy and was certainly
> development.  Having best practices regarding how to do research yields a
> different set of suggestions doesn't it?

The goals for that kind of project are not easy to measure/quantify.
"You are two weeks late on the breakthrough idea!" Can't really see
that happening... ;)

> Here's an example:
> We were trying to reduce the drag of underwater vehicles using all sorts of
> very high tech methods.  One of the groups (no doubt with a vested interest)
> reported experimental success of their technique.  But, some the of the
> tests had failed.  When asked why they threw out those results, they said:
> "something must have been wrong and invalidated those tests".  But, they had
> no idea what might have been wrong or if the tests were truly invalid.  In
> the end we decided that the technology lacked robustness and the results
> were valid: they were indicative of a technology that was "on the edge" of
> working or not working.

These are questions of craftmanship, regardless of whether we define
this as an engineering or R&D project. If you do a set of tests, there
are certain standards one would like to keep in order to "sell" the
results. Explaining large amounts of "anomalies" should include a
discussions of reasons, including the possible non-robust method.

A few years ago, I met a former colleague who had got a new job in a
company dealing with marine operations, since I last met him. He
described a project he was involved in, where they had as ambition to
deploy certain types of kit at the sea floor, at given locations in the

deep sea and with very high accuracy. As he finished describing the
goals,
my reaction, expressed as a combination of body language and verbal
comments was to the effect of "You guys must be mad to attempt
something
like this!" "Oh yes, that's how it might look." he responded. "We don't

expect to actually meet the ambitions, though, but we would like
to see how close we can get, and what it takes to get there."
Most reassuring.

We went on to discuss various ways of getting close to these goals.
My friend said that somebody from some service company had approached
him to discuss methods to deploy the kit. The people from the service
company had said they could do this with standard technology. "Do you
believe they can?" I asked quietly. "No. The representatives didn't
even blink an eye when I described our ambitions."

Our unspoken mutual understanding was that anyone who understood the
complexity (well, semi-sanity) of the stated goals, would be very
sceptical to whether this was at all possible. The service company
showed, as I understood my friend's tale, no signs of understanding
what this was all about, and did thus not get the contract.

> So, for research we add to best practices: design of experiments, how to
> handle results, repeatability, etc.

Exactly. To me, these aspects are embedded in the term "craftmanship".

Rune


Article: 87424
Subject: Re: Fastest way to compute floating point log and exp
From: Ray Andraka <ray@andraka.com>
Date: Sat, 23 Jul 2005 18:55:30 -0400
Links: << >>  << T >>  << A >>
Marc Battyani wrote:

>I'm looking at the fastest way to compute floating point (32bit) log and exp
>on an FPGA (Stratix II or Virtex 4). It must be faster than a 3.6GHz Xeon
>which can do that in 18.5 clock cycles on average on a 1000 float vector
>(using SSE3)
>
>So far I've found that with a few tables and floating point MUL and ADD
>blocks I should be able to do that at 160MHz on a Stratix II (not tested
>yet). It's still slower than the Xeon but at least it's close. I've looked
>at cordic at a glance, but it looks slower or bigger if totally unrolled.
>
>Any ideas or pointers on a better way to do that?
>
>Thanks
>
>Marc
>
>
>  
>
You didn't mention how much precision you need, nor for that matter what 
the log base is to be.  Log
is actually easier to compute for a floating point argument, since the 
significand is already presumably
normalized, which reduces the complexity of computing the log since the 
range is limited.  for fixed point,
the usual approach is to normalize it first, essentially converting to 
floating point.  Log base 2 is  a little
bit easier than other bases because the floating point exponent is the 
integer portion of the log.  The fraction
portion can be computed with a small (4 input) look-up to get you to 1/2 
dB or so.  If you need more
precision, there are iterative techniques that can get you to whatever 
precision you need. Exponent is the
reverse: you use a look-up to exponentiate  the fractional portion and 
then use the integer portion to control
how much the exponentiated fraction is shifted.  This can be pipelined, 
and run at over 200 MS/sec in a single
thread in Spartan3 FPGAs, faster in premium devices.

Do you need the log in floating point too, or is it fixed point log 
notation?  Most importantly, what is the precision requirement?

-- 
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com  
http://www.andraka.com  

 "They that give up essential liberty to obtain a little 
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759





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