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 87425

Article: 87425
Subject: Re: July 20th Altera Net Seminar: Stratix II Logic Density
From: "austin" <austin@xilinx.com>
Date: 23 Jul 2005 16:39:48 -0700
Links: << >>  << T >>  << A >>
Peter,

I agree.  This is a "shell and pea game" being conducted.

"Keep you eye on the LUTs -- they will grow right before your eyes!"

Amazingly, this keeps the eye off: the domain specific solutions (ie SX
is the least cost for DSP centric designs, LX is the best for logic, FX
for embedded systems), signal integrity, power, speed, EMAC, PPC, MGT,
FIFO BRAM, DCM, as well as the other hundred innovations in Virtex 4.
For all of these, there is no defense.  Nothing to say.  So, let us
just fool everyone into arguing about something else?

I applaud their marketing department's ability to put a ring through
the customer's nose, and lead them around at will.  Xilinx has always
marveled at their ability to do this.  However, we do believe our
customers are smarter than that.

By focusing the conversation, and all the brain cells on what they want
to have you focused on, they have succeeded in making a large number of
engineers do exactly what they wanted.

Keeps them from looking at the other hundred innovations that make the
Virtex 4 an undisputed winner.

For me, I will continue to point out the other 100 reasons to choose
V4.  I'll let the LUT shaped heads battle this one out, but be aware
that you are being used.

Austin


Article: 87426
Subject: Re: Best Practices to Manage Complexity in Hardward/Software Design?
From: "xpyttl" <xpyttl_NOSPAM@earthling.net>
Date: Sat, 23 Jul 2005 20:04:52 -0400
Links: << >>  << T >>  << A >>
"Fred Marshall" <fmarshallx@remove_the_x.acm.org> wrote in message 
news:NpKdnVShBI2o9H3fRVn-uA@centurytel.net...

> One reason the requirements need to be understood is to avoid changes.
>
> You should have a process to prevent changes.

ACK!

Preventing changes, the good old "requirements freeze" is a sure way to kill 
a project.

Requirements are going to change.  To pretend otherwise is just putting your 
head in the sand.  The name of the game is to manage the requirements.  For 
some reason, many software professionals seem to believe that "requirements 
management" is the same as requirements elicitation, but there is a bunch 
more than that.

You need to understand the impact of requirements changes, and deal with 
them.  Yes, some changes should be resisted.  Requirements changes that will 
significantly affect the development effort must be identified, and then the 
effort re-sized.  That may mean renegotiation.  The renegotiation may cause 
the customer to re-think how urgent the change is, or not.  Most 
requirements changes, though, are not of that nature. Most are probably just 
refinements of our understanding of the requirements.  Usually, we try to 
pretend that these are not changes by simply not documenting them.  That way 
we'll have to re-learn them.  Other times we discover that we misunderstood 
the requirement in the first place.  Well, recognize that as soon as 
possible when it has the minimum impact, and recognize the impact.

Requirements management isn't easy, but it's not a black art either.  It's 
mostly about keeping your eyes wide open.

..



Article: 87427
Subject: Re: Best Practices to Manage Complexity in Hardward/Software Design?
From: Jerry Avins <jya@ieee.org>
Date: Sat, 23 Jul 2005 20:52:14 -0400
Links: << >>  << T >>  << A >>
Fred Marshall wrote:

   ...

> 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'm sorry, Fred, but that doesn't fly most of the time. Not only with 
electronic design, but with "simpler and more straightforward" (hah!) 
projects like bridges and buildings. As the chairman of the construction 
committee during the building of a regional sewerage installation that 
included a main plant, two satellite plants, three pumping stations, and 
over 40 miles of trunk line, I can tell you than no piece of the project 
was finished without change orders. The Mercury space capsules' audio 
amplifiers were changed twice after the design was thought to be final. 
First, to replace power transistors to increase allowable dissipation, 
then to correct the near disaster caused by the change. When you go to 
the market and discover that some ingredients are unavailable, you 
substitute other ingredients or change the recipe.

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

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


Jerry Avins skrev:
> Fred Marshall wrote:
>
>    ...
>
> > 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'm sorry, Fred, but that doesn't fly most of the time. Not only with
> electronic design, but with "simpler and more straightforward" (hah!)
> projects like bridges and buildings. As the chairman of the construction
> committee during the building of a regional sewerage installation that
> included a main plant, two satellite plants, three pumping stations, and
> over 40 miles of trunk line, I can tell you than no piece of the project
> was finished without change orders. The Mercury space capsules' audio
> amplifiers were changed twice after the design was thought to be final.
> First, to replace power transistors to increase allowable dissipation,
> then to correct the near disaster caused by the change. When you go to
> the market and discover that some ingredients are unavailable, you
> substitute other ingredients or change the recipe.

Eh, Jerry... do you and Fred talk about the same things? I interpret
Fred's post such that he talks about freezing the *design*. Freezing
the design still leaves the freedom to change the *implementation*,
which, for some reason, I believe you are discussing.

To put it in a DSP context, the major design decision is to decide
whether to use a FIR filter or an IIR filter, since this is likely to
have some implications for what DSP chips can be used. Having chosen
the IIR filter, the implementation could be based on a Butterworth or
Chebyshev analog prototype or some optimized discrete-time design.
It could be a direct-form I or II, depending on whatever suits the
application. Yes, I know, the example is perhaps a bit far-fetched
but I hope you see my point. Freezing the decision to use IIR
filters still allows implementation details like filter orders and
filter coefficients to be changed, for yet some time. 

Rune


Article: 87429
Subject: Re: Best Practices to Manage Complexity in Hardward/Software Design?
From: Jerry Avins <jya@ieee.org>
Date: Sat, 23 Jul 2005 21:34:40 -0400
Links: << >>  << T >>  << A >>
Rune Allnor wrote:
> 
> Jerry Avins skrev:
> 
>>Fred Marshall wrote:
>>
>>   ...
>>
>>
>>>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'm sorry, Fred, but that doesn't fly most of the time. Not only with
>>electronic design, but with "simpler and more straightforward" (hah!)
>>projects like bridges and buildings. As the chairman of the construction
>>committee during the building of a regional sewerage installation that
>>included a main plant, two satellite plants, three pumping stations, and
>>over 40 miles of trunk line, I can tell you than no piece of the project
>>was finished without change orders. The Mercury space capsules' audio
>>amplifiers were changed twice after the design was thought to be final.
>>First, to replace power transistors to increase allowable dissipation,
>>then to correct the near disaster caused by the change. When you go to
>>the market and discover that some ingredients are unavailable, you
>>substitute other ingredients or change the recipe.
> 
> 
> Eh, Jerry... do you and Fred talk about the same things? I interpret
> Fred's post such that he talks about freezing the *design*. Freezing
> the design still leaves the freedom to change the *implementation*,
> which, for some reason, I believe you are discussing.
> 
> To put it in a DSP context, the major design decision is to decide
> whether to use a FIR filter or an IIR filter, since this is likely to
> have some implications for what DSP chips can be used. Having chosen
> the IIR filter, the implementation could be based on a Butterworth or
> Chebyshev analog prototype or some optimized discrete-time design.
> It could be a direct-form I or II, depending on whatever suits the
> application. Yes, I know, the example is perhaps a bit far-fetched
> but I hope you see my point. Freezing the decision to use IIR
> filters still allows implementation details like filter orders and
> filter coefficients to be changed, for yet some time. 

That's well put. How would you classify adding the two satellite plants 
to the sewerage system? Originally, the system was designed with one 
plant, and pipelines to it from all participating communities. One 
administration blocked the two lines from the upstream communities, 
forcing the Sewerage Authority to build the satellite plants. The 
pipeline plans were scrapped, and we considered reducing the size of the 
main plant. Is that a change of implementation, or of plans?

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

Article: 87430
Subject: Re: Best Practices to Manage Complexity in Hardward/Software Design?
From: "Matt Timmermans" <mt0000@sympatico.nospam-remove.ca>
Date: Sat, 23 Jul 2005 21:45:58 -0400
Links: << >>  << T >>  << A >>

"Rune Allnor" <allnor@tele.ntnu.no> wrote in message 
news:1122167921.820607.126720@g47g2000cwa.googlegroups.com...
> Eh, Jerry... do you and Fred talk about the same things? I interpret
> Fred's post such that he talks about freezing the *design*. Freezing
> the design still leaves the freedom to change the *implementation*,
> which, for some reason, I believe you are discussing.

What we call "implementation" in the software business is just the easy or 
less significant part of the design process.  There is no sharp distinction. 
Design is everything between inception and mass production.

> [ for example ] Freezing the decision to use IIR
> filters still allows implementation details like filter orders and
> filter coefficients to be changed, for yet some time.

Yes, and with this example you can see how the world outside of engineering 
would have no knowledge of or respect for the distinction you make between 
"design decisions" and "implementation details".  That's because the 
distinction is artificial -- it is the process of design that determines 
what will be easy to change later and what will not.  A good designer should 
avoid tying excessive investments of time or money to decisions which are 
likely to be undone later.

--
Matt 



Article: 87431
Subject: Re: Fastest way to compute floating point log and exp
From: Philip Freidin <philip@fliptronics.com>
Date: Sun, 24 Jul 2005 01:57:08 GMT
Links: << >>  << T >>  << A >>
On Sat, 23 Jul 2005 19:39:13 +0200, "Marc Battyani" <Marc.Battyani@fractalconcept.com> 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

Some time back, a company called LogPoint was offering an
alternative to floating point arithmetic, based on logarithms,
and depended on a fairly efficient float to log conversion.
(I had discussions with them, at least 8 years ago)
I seem to remember that the LOG wizard was a guy by the name
of Lester Pickett.


   http://www.mjourney.com/news/News_from_Greece/632.Log_Point.shtml

unfortunately, this seems to be dead:   www.logpoint.com
(as in, a place holder)

Have a look at patent 5197024 at www.uspto.gov for all the details.

Philip




Philip Freidin
Fliptronics

Article: 87432
Subject: Re: Overmapped
From: Philip Freidin <philip@fliptronics.com>
Date: Sun, 24 Jul 2005 02:11:07 GMT
Links: << >>  << T >>  << A >>
On Fri, 22 Jul 2005 16:39:38 +0200, "Stefan" <holzi_stefan@hotmail.com> wrote:
>Hi all,
>
>I'm using a Spartan 3 test board with a xc3s200 fpga. Before, I used a
>larger device (Virtex II ) and had no problems with my design (microblaze
>with my own IP, connected to the OPB-bus). But now, I get errors during the
>map process due to the small amount of slices... --> it seems that the
>device is too small. But: when I don't connect my IP with the OPB,
>everything's fine. At the moment when I click in Xilinx Platform Studio on
>the white square to connect to OPB that a 'S' appears , the problem with the
>overmapped slices occurs. Without connection about 50% of slices are used,
>connected to the OPB more than 230%.
>How could that be possible??

The software may be trimming logic from your design when you don't have
the IP connected. For an unrelated example, if you had a design that was
1000 slices, and the end result is a single signal, connected to an IOB,
and all the rest of the IOBs are inputs. Assuming no other issues, this
design places and routes and uses 1000 slices. If you then make a change
that just does not connect the output to the IOB, the whole design would
be trimmed, and zero slices used.

What happens is that the SW deletes logic that cannot change the external
behavior of the chip. So what happens is the logic that generates the
final signal is trimmed. Then the logic that was feeding it is now not
driving anything, and it is trimmed, and this continues all the way back
to the inputs.

In your design, if the IP is not connected to the OPB, then all its
outputs can be trimmed, and then work back to the start of the IP. If
there are no other outputs of the IP, the whole thing could be trimmed.
Same thing is true of the OPB. Also trimming can start at the input end
of a design. If an input does not connect to an IOB, or it is a constant,
then logic trimming can start at the input end, and work forward towards
the output.

The trimming report is the place to start examining this issue.

>I'm using the latest versions of ISE and XPS.
>
>Thanks in advance,
>
>Stefan
>


Philip
Philip Freidin
Fliptronics

Article: 87433
Subject: Re: Transfert data to Memec Virtex II Pro Card from PC
From: "Correlious" <arvinf@gmail.com>
Date: 23 Jul 2005 19:22:31 -0700
Links: << >>  << T >>  << A >>
Memec makes Xilinx (and other) dev kits.

Jacuqes, I have done it for a Virtex 4. What is it that you are trying
to do?


Article: 87434
Subject: Re: July 20th Altera Net Seminar: Stratix II Logic Density
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 23 Jul 2005 20:32:15 -0700
Links: << >>  << T >>  << A >>
Austin gave an interesting analogy:

I can visualize Altera Marketing trying to put a ring in designers'
noses, and (mis)leading them so that they can see nothing else but
LUTs, oblivious to all the more exciting aspects of FPGAs.

We could then call them LUTites, in memory of the Luddites in 1812
Nottingham, who also did not appreciate the technological progress
coming at them, destined to really change their lives. Many suspected
Luddites were convicted, imprisoned, or hanged. Those were the days...

But don't get us wrong:
We love LUTs. Xilinx invented the concept of LUT-based FPGAs. LUTs are
great and flexible, whether they have 4, 5, or 6 inputs. But LUTs are
not everything anymore, and the really exciting progress in FPGA
performance and density happens outside the LUTs.

Don't let anybody put a ring in your nose...
Peter Alfke, Xilinx Applications (from home)


Article: 87435
Subject: Re: Best Practices to Manage Complexity in Hardward/Software Design?
From: "steve" <bungalow_steve@yahoo.com>
Date: 23 Jul 2005 21:39:19 -0700
Links: << >>  << T >>  << A >>
"A good designer should
avoid tying excessive investments of time or money to decisions which
are
likely to be undone later. "

In other words designers have to be fortune tellers.


Article: 87436
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 21:48:30 -0700
Links: << >>  << T >>  << A >>

"Rune Allnor" <allnor@tele.ntnu.no> wrote in message 
news:1122157921.866725.149310@g44g2000cwa.googlegroups.com...
>
>
> 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 guess you might budget a lot for unexpected expenses.  But, I didn't think 
we were talking here so much about project management as about best 
practices in development.  Frankly I'd not be too comfortable with such an 
allocation *if* cost and schedule were paramount - which they often are.

Maybe you could break things down into smaller pieces and maybe not.  The 
notion is a good one to be sure - but agreeing or disagreeing in such 
general terms is too speculative for me.  Maybe that's the essence of 
"complex" - that something hasn't been well partitioned and organized, eh?

I can imagine control systems engineering as dealing with things that are 
complex and making them simpler by virtue of the tools.  Once you know about 
the tools then most things in this context are perceived as simpler aren't 
they?  That doesn't make them easier to deal with "seat of the pants" - but 
knowing that the tools are there and what they do, etc. makes things appear 
to be simpler.  Computers are great for keeping track of a lot of things at 
once - much better than humans.

We designed a control system for a semisubmersible oil and gas production 
platform in Sweden.  The thing had over 50 ballast tanks that we would 
control with a computer program (model, etc.).  When it went to sea the crew 
tried to trim the tanks by hand and were never able to level the platform. 
Eventually they decided to try out the new-fangled computer thingy and the 
platform leveled out directly.  The task was too *complex* for humans unless 
they used the computer controls and then the task was made simple for them. 
They were incapable of dealing with all the subsystems and their 
interactions.  Too many subsystems and too many interactions.  So, breaking 
it into smaller parts wasn't the solution.

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

The point was whether it was development or "research" - not that it cost a 
bit more to accomplish.

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

I agree that the goals don't change.  The point was that some try/fix 
process was likely.

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

In this case the schedule was fixed for a wide array of technologies. 
Either things panned out in time or they didn't.  If someone was trying to 
make too great a breakthrough then they would probably fail.  That was OK 
because the next step was to take the best, proven technologies and build 
something real.  Nobody in their right mind would start a product 
development with an unproven technology while there were proven technologies 
available.

The goals were easy to measure and quantify.  Either the technology appeared 
to work well or it didn't or it never really got off the ground.  The next 
phase of system development would decide which technologies really made 
sense.

(In the end, some technologies were carried a bit too far into development - 
for reasons that seemed good at the time but were really more emotional than 
real.  "High risk, high payoff" turned out to be really "high risk, very 
modest payoff".  In the end, money determined the best approach - which was 
the right outcome).

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

I agree. It was just that the original question was about best practices for 
development and not for research.  So, the responses were about development. 
Then Jerry brought up "research" and we started a bit down that path.  I 
simply tried to say that changing the question would change at least some of 
the answers.  It's a bit harder for me to envision a product engineering 
team deciding that failed tests were actually "OK" - although I know that it 
happens.  (e.g. see Richard Feynman's treatment of the space shuttle 
disaster.  Thus, I say "harder" not impossible).

Maybe there needs to be another item on the list:
"Make sure there is good craftsmanship in every discipline"

Fred 



Article: 87437
Subject: Re: parallel optic availability
From: "Franklin" <fsun998@gmail.com>
Date: 23 Jul 2005 21:51:55 -0700
Links: << >>  << T >>  << A >>
these optic modules (12x and 4+4) are available from agilent and
zarlink.  Infineon has stopped production of paoli.  I do not know
emcore or picolight.

-Franklin


Article: 87438
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 22:07:23 -0700
Links: << >>  << T >>  << A >>

"xpyttl" <xpyttl_NOSPAM@earthling.net> wrote in message 
news:IWAEe.15990$bG4.3120@fe06.lga...
> "Fred Marshall" <fmarshallx@remove_the_x.acm.org> wrote in message 
> news:NpKdnVShBI2o9H3fRVn-uA@centurytel.net...
>
>> One reason the requirements need to be understood is to avoid changes.
>>
>> You should have a process to prevent changes.
>
> ACK!
>
> Preventing changes, the good old "requirements freeze" is a sure way to 
> kill a project.
>

I'm sure we could argue about this forever.
I think it's mostly a matter of context.
One can just as easily say: "allowing changes is a sure way to kill a 
project".
Then, all you have to do is sort out what the heck either of us is talking 
about...
Because both perspectives are fine.

I once worked on a project where the box was going to be painted blue.  And 
then it was going to be painted silver.  And then it was going to be painted 
green.  So, we kept going to meetings and never finishing.  That's a good 
example for when a requirement should have been frozen.  At least it would 
have saved a lot of precious time!  It really didn't matter all that much 
but a lot of stuff was left hanging pending the decision on the color of the 
box!

Sure requirements change with new awareness, changed conditions, etc. 
Here's an example of how "new awareness" messed up a project:
We were building a processor-based system.  It was new technology.  The 
operating system had been selected and we were on a path to getting the 
system implemented.
Then, the principal in software went to a symposium and met a real OS guru. 
Actually our software principal was a guru in his own right.  Anyway, he 
came home convinced that our OS could have a much smaller footprint in 
memory.  He trashed everything that had been done and started over because 
it appeared that "better" was indeed better and "good enough" wasn't good 
enough.

....... and the project did not complete on time to matter.  It fell off the 
edge of the table.

Ever hear: "if it ain't broke don't fix it" ?  That's a design freeze and it 
makes sense.

Fred




Article: 87439
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 22:33:23 -0700
Links: << >>  << T >>  << A >>

"Jerry Avins" <jya@ieee.org> wrote in message 
news:Nf-dnavJit7de3_fRVn-ow@rcn.net...
> Fred Marshall wrote:
>
>   ...
>
>> 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'm sorry, Fred, but that doesn't fly most of the time. Not only with 
> electronic design, but with "simpler and more straightforward" (hah!) 
> projects like bridges and buildings. As the chairman of the construction 
> committee during the building of a regional sewerage installation that 
> included a main plant, two satellite plants, three pumping stations, and 
> over 40 miles of trunk line, I can tell you than no piece of the project 
> was finished without change orders. The Mercury space capsules' audio 
> amplifiers were changed twice after the design was thought to be final. 
> First, to replace power transistors to increase allowable dissipation, 
> then to correct the near disaster caused by the change. When you go to the 
> market and discover that some ingredients are unavailable, you substitute 
> other ingredients or change the recipe.

Jerry,

You were the chairman of the construction committee.
You were in control of the "higher level process to embrace great ideas for 
change".
So, you changed things when necessary.
I don't see any problem with that or any contradiction with what I said.

In the context of what I said first: "better is the enemy of good enough". 
That's when you need to freeze.  For example:

We have a filter requirement.  We design a FIR filter that works fine.  It 
has been implemented and tested.  Then somebody figures out that a few 
memory locations can be saved and we can still meet the requirement with an 
IIR filter.  So, with no design controls in place, the designer decides to 
re-design the filter.  Hey, it's fun and the experience gained is great. 
Except now the impulse response is longer and that affects parts of the 
system that had already been tested and the difference shows up rather late 
in the development cycle and the filter designer has gone and the FIR filter 
is forgotten and people are wondering how to get back to what worked and 
...... you get the idea.

I didn't say: "don't allow any changes".  I said that freezing is good *and* 
overruling the freeze process can also be good.  I'm sure that many of us 
have had experiences where things were controlled by idiots.  That makes any 
good idea look bad.  It doesn't invalidate the good ideas. I think we're 
back to Rune's suggestion that there has to be good craftsmanship.  That 
applies in management too.

Here is a very positive story about design freeze:

I took over a group that was building a rather complex board - of a design 
that had never been done before.
Their plan was to build the board and then "spin" it - i.e. do a second pass 
at the layout because they figured there would be changes, errors, things 
that didn't work, etc.  The second pass added precious months to the 
schedule.

So, I told them that we had to get first-pass success and that's what we had 
to plan on.
They had to get it right the first time.

The idea isn't exactly the same as design freeze but pretty close.  The 
design was "going to be frozen" in their minds so they had to get it right 
the first time.

They did it.  Interesting, eh?

Fred






Article: 87440
Subject: Re: Best Practices to Manage Complexity in Hardward/Software
From: Randy Yates <yates@ieee.org>
Date: Sun, 24 Jul 2005 07:55:23 GMT
Links: << >>  << T >>  << A >>
"jjlindula@hotmail.com" <jjlindula@hotmail.com> writes:

> 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.
>
> Thanks everyone,
> joe

Joe,

What a great question! As the responses have shown, you've really hit
a nerve with many engineers.

Some may have said some of this already, but allow me respond in my
own words.

1. Define the requirements. 

In performing this task, try not to think too much about the details
of how the requirements will be implemented. On the other hand,
knowledge of implementation and/or current capabilities will almost
certainly shape the requirements. For example, it would be silly to
require (at this time in history) the capabilities of a Pentium 4
processor at a power consumption of a microwatt.

3. Face the fact that if requirements are added (or changed in certain
ways), the schedule for the design WILL slip. 

4. Design from the top down. That is, begin the design decomposition
at the top level and then iteratively break the higher level blocks
into lower level blocks. AKA hierarchical design.

Something (at least for me) very interesting happens at this stage
of the design. I find that there are two tricks when defining blocks at 
a specific level that are almost contradictions. 

On one hand, it seems that a good design decomposition comes by doing
some "back-and-forth" between one level and the next lower level, or
maybe even two levels. 

On the other hand, it is necessary to discipline your mind to view the
design at the current level and avoid the tendency to "drop down" to
the lower levels, at least for a time.

It seems that by alternately viewing the design at the current level,
and then also skitting back and forth between levels and looking for
optimal configurations, you come out with the best design
decompositions.

Another set of ABSOLUTELY CRUCIAL guidelines at this stage, especially
when performing software design, is to partition the modules or blocks
such that you MAXIMIZE COHESION and REDUCE COUPLING. You can find a lot
of material on these two concepts, e.g.,

http://www.ugolandini.net/AccoppiamentoCoesioneE.html

5. Implement from the bottom up. 

6. Be patient. 

Waiting for a system to be properly designed will almost always be
more efficient (time-wise) than "waterfall development," i.e., the
type of development for impatient managers that want to see something
almost immediately.

My $0.02.
-- 
%  Randy Yates                  % "My Shangri-la has gone away, fading like 
%% Fuquay-Varina, NC            %  the Beatles on 'Hey Jude'" 
%%% 919-577-9882                %  
%%%% <yates@ieee.org>           % 'Shangri-La', *A New World Record*, ELO
http://home.earthlink.net/~yatescr

Article: 87441
Subject: Re: July 20th Altera Net Seminar: Stratix II Logic Density
From: reeuwijk@few.vu.nl (Kees van Reeuwijk)
Date: Sun, 24 Jul 2005 11:36:50 +0200
Links: << >>  << T >>  << A >>
Peter Alfke <alfke@sbcglobal.net> wrote:

> Austin gave an interesting analogy:


> Don't let anybody put a ring in your nose...
> Peter Alfke, Xilinx Applications (from home)


Could you Xilinx people please grow up, this is not insightful, this is
not even zealous company loyalty, this is just boyclub bickering.

A reasoned discussion about advantages and disadvantages of FPGA
architectures is interesting, but do you really think that this kind of
posting is informative for /anyone/?

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


Jerry Avins skrev:
> Rune Allnor wrote:
> >
> > Jerry Avins skrev:
> >
> >>Fred Marshall wrote:
> >>
> >>   ...
> >>
> >>
> >>>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'm sorry, Fred, but that doesn't fly most of the time. Not only with
> >>electronic design, but with "simpler and more straightforward" (hah!)
> >>projects like bridges and buildings. As the chairman of the construction
> >>committee during the building of a regional sewerage installation that
> >>included a main plant, two satellite plants, three pumping stations, and
> >>over 40 miles of trunk line, I can tell you than no piece of the project
> >>was finished without change orders. The Mercury space capsules' audio
> >>amplifiers were changed twice after the design was thought to be final.
> >>First, to replace power transistors to increase allowable dissipation,
> >>then to correct the near disaster caused by the change. When you go to
> >>the market and discover that some ingredients are unavailable, you
> >>substitute other ingredients or change the recipe.
> >
> >
> > Eh, Jerry... do you and Fred talk about the same things? I interpret
> > Fred's post such that he talks about freezing the *design*. Freezing
> > the design still leaves the freedom to change the *implementation*,
> > which, for some reason, I believe you are discussing.
> >
> > To put it in a DSP context, the major design decision is to decide
> > whether to use a FIR filter or an IIR filter, since this is likely to
> > have some implications for what DSP chips can be used. Having chosen
> > the IIR filter, the implementation could be based on a Butterworth or
> > Chebyshev analog prototype or some optimized discrete-time design.
> > It could be a direct-form I or II, depending on whatever suits the
> > application. Yes, I know, the example is perhaps a bit far-fetched
> > but I hope you see my point. Freezing the decision to use IIR
> > filters still allows implementation details like filter orders and
> > filter coefficients to be changed, for yet some time.
>
> That's well put. How would you classify adding the two satellite plants
> to the sewerage system? Originally, the system was designed with one
> plant, and pipelines to it from all participating communities. One
> administration blocked the two lines from the upstream communities,
> forcing the Sewerage Authority to build the satellite plants. The
> pipeline plans were scrapped, and we considered reducing the size of the
> main plant. Is that a change of implementation, or of plans?

That's certainly a change of plans, what I am concerned.

Rune


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


Matt Timmermans skrev:
> "Rune Allnor" <allnor@tele.ntnu.no> wrote in message
> news:1122167921.820607.126720@g47g2000cwa.googlegroups.com...
> > Eh, Jerry... do you and Fred talk about the same things? I interpret
> > Fred's post such that he talks about freezing the *design*. Freezing
> > the design still leaves the freedom to change the *implementation*,
> > which, for some reason, I believe you are discussing.
>
> What we call "implementation" in the software business is just the easy or
> less significant part of the design process.  There is no sharp distinction.

I know.

> Design is everything between inception and mass production.

To me, "design" si the intellectual effort of concocting (choosing) a
way of meeting the goals. "Implementation" is about putting the design

into practice.

> > [ for example ] Freezing the decision to use IIR
> > filters still allows implementation details like filter orders and
> > filter coefficients to be changed, for yet some time.
>
> Yes, and with this example you can see how the world outside of engineering
> would have no knowledge of or respect for the distinction you make between
> "design decisions" and "implementation details".

Which is why I made the point that project managment must be recruited
amongst the engineers.

> That's because the
> distinction is artificial --

Sorry, I don't agree. Again, "design" is about choosing what
algorithms to use, how to organize the program, getting a block
diagram representation etc. It's the intellectual effort invested
in making a program or system. "Implementation" is about getting
a software function or piece of machinery to perform a pre-determined
action. Which could involve an excercise in design on its own.

I don't know if you have experience with matlab. It's a computer
system for numerical computing, that allows just about anything
in software computing: Scripts, Structured programming, Object
oriented programming, GUIs, typed programming, non-typed programming...

the one thing I have not been able to do with matlab, is to implement
GOTO statements. Students who have matlab as their computing experience
(as opposed to C/C++, pascal, Fortran...) don't have any concepts of
program design. They find a way of getting something done, usually a
severe mixture of all concepts above, and do it. Program maintenance
is impossible, even understanding the code can be a nightmare.
That's before whe start speaking of how matlab handles trivial
control statements and conditionals.

Regardless of matlab, the scientists don't have much grasp of design,
they just implement. One infamous example was an ocean acoustics
propagation model, that easily could use hours on one computation.
There was a graphical interface added on that program, to plot the
results. The guy who implemented the code did not separate the two,
so you specified the visualization along with the physics of the
simulation. If you after 2 - 10 hours found that the data selection
was a bit "off", you had to do the whole 2 - 10 hour simulation
again before seeing the new data selection. The distinction was
made in later versions of the program.

This guy knew his implementation. He was the first to get this
particular sort of simulation to work, and used all sorts of tricks,
both algorithms and data structures, to get a numerically stable
simulation code. But he knew squat about design.

Similarly, I had a young engineer help me make a driver for some
arcane tape driver. The engineer knew his implementations - he got
the thing to work - but he had no concepts of design. He was not
concious about the great speed difference between the computer and
the tape drive, he did not use I/O buffers so his program read
gigabytes of data from the tape, on a byte-by-byte basis. It took
hours to read the tapes, where minutes ought to have sufficed.

"Design" is an independent skill that needs a conscious effort to
be learned. "Implementation" is actually handling the kit, be it
the computer or the lathe.

Perhaps "design" is the "strategy" and "implementation" the "tactics".

> it is the process of design that determines
> what will be easy to change later and what will not.

As user of a software program, you don't necessarily acknowledge the
difference between a structured design of the source code, or an
Object Oriented design of the source code. OO was so new when I went
to universirty, that only the specialized computer science guys got
courses that covered it. We, the engineers, could learn it on our
own, but few did: "OO is so hard to wrap one's mind around, and we
don't need it for the small projects we program".

I did make the effort, and now I hardly do anything that isn't Object
Oriented in one way or another. In this case, the difference between
the two designs are basicaly that they are two different states of
mind.
The implementations "hardly" change at all: A little bit of voodoo with

function declarations, some added restrictions on the class
declarations, and that's it.

Deciding whether to go OO or not, is a major design desicion. In my
world of scientific computing, it will have very little impact on the
"scientifically important" stuff, which is the numerics. OO could
make all the difference with respect to communication with other
programs, extensions of functionality, etc.

> A good designer should
> avoid tying excessive investments of time or money to decisions which are
> likely to be undone later.

Rune


Article: 87444
Subject: Re: Best Practices to Manage Complexity in Hardward/Software Design?
From: Steve Underwood <steveu@dis.org>
Date: Sun, 24 Jul 2005 19:41:41 +0800
Links: << >>  << T >>  << A >>
steve wrote:
> "A good designer should
> avoid tying excessive investments of time or money to decisions which
> are
> likely to be undone later. "
> 
> In other words designers have to be fortune tellers.

They certainly do. Most successful projects are those where the decision 
maker(s) could adequately forsee where enough flexibility had to be 
incorporated to cope with the most likely changes in requirements.

Add flexibility everywhere in a project and the cost, timescale, hassle, 
risk, etc. go through the roof. Provide no flexibility are the 100% 
absolutely certain changes in need that will occur over the project's 
life will make it obsolete before completion.

Regards,
Steve

Article: 87445
Subject: Re: Best Practices to Manage Complexity in Hardward/Software Design?
From: "Rune Allnor" <allnor@tele.ntnu.no>
Date: 24 Jul 2005 05:36:21 -0700
Links: << >>  << T >>  << A >>


Rune Allnor skrev:
> Jerry Avins skrev:
> > Rune Allnor wrote:
> > >
> > > Jerry Avins skrev:
> > >
> > >>Fred Marshall wrote:
> > >>
> > >>   ...
> > >>
> > >>
> > >>>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'm sorry, Fred, but that doesn't fly most of the time. Not only with
> > >>electronic design, but with "simpler and more straightforward" (hah!)
> > >>projects like bridges and buildings. As the chairman of the construction
> > >>committee during the building of a regional sewerage installation that
> > >>included a main plant, two satellite plants, three pumping stations, and
> > >>over 40 miles of trunk line, I can tell you than no piece of the project
> > >>was finished without change orders. The Mercury space capsules' audio
> > >>amplifiers were changed twice after the design was thought to be final.
> > >>First, to replace power transistors to increase allowable dissipation,
> > >>then to correct the near disaster caused by the change. When you go to
> > >>the market and discover that some ingredients are unavailable, you
> > >>substitute other ingredients or change the recipe.
> > >
> > >
> > > Eh, Jerry... do you and Fred talk about the same things? I interpret
> > > Fred's post such that he talks about freezing the *design*. Freezing
> > > the design still leaves the freedom to change the *implementation*,
> > > which, for some reason, I believe you are discussing.
> > >
> > > To put it in a DSP context, the major design decision is to decide
> > > whether to use a FIR filter or an IIR filter, since this is likely to
> > > have some implications for what DSP chips can be used. Having chosen
> > > the IIR filter, the implementation could be based on a Butterworth or
> > > Chebyshev analog prototype or some optimized discrete-time design.
> > > It could be a direct-form I or II, depending on whatever suits the
> > > application. Yes, I know, the example is perhaps a bit far-fetched
> > > but I hope you see my point. Freezing the decision to use IIR
> > > filters still allows implementation details like filter orders and
> > > filter coefficients to be changed, for yet some time.
> >
> > That's well put. How would you classify adding the two satellite plants
> > to the sewerage system? Originally, the system was designed with one
> > plant, and pipelines to it from all participating communities. One
> > administration blocked the two lines from the upstream communities,
> > forcing the Sewerage Authority to build the satellite plants. The
> > pipeline plans were scrapped, and we considered reducing the size of the
> > main plant. Is that a change of implementation, or of plans?
>
> That's certainly a change of plans, what I am concerned.
>
> Rune

My answer still stands, but I try not to use the word "plan" in this
discussion. In my mind, a "plan" is a list of things that need be done
in order to implement some system or strategy, or otherwise achieve a
goal. If circumstances change, the plan must change. Here,
"circumstances"
include both "implementation" and "design".

Your original goal, make a sewerage facility to serve the community,
was still valid. The feasible way to achieve it changed. Hence your
change of implementation and of plans.

When I talk of "changing goals" or "changing designs", I mean "changing

the purpose" of the activity. It would be a "changed design" if you
started
out to build a sewerage facility but ended up building, say, a parking
lot
or a mall.

I like to watch BBC's "Top Gear", a weekly TV show where new cars
are reviewed, tested and commented on. The hosts are very clear in
their opinions about what is good and what is bad. Particularly
high-profile brands and models (Ferraris, Porches, BMWs,...) are
put through their paces in the show.

With these types of cars, one main reason for giving bad reviews is
often the purpose of the car: "The designers did not decide what kind
of car this would be. They wanted this to be a sports car. They wanted
this to be a muscle car. They wanted this to be a road cruiser. It is
none of the above".

Of course, when the purpose of the car is undisputed, the hosts go
on to explain, in the most English way, why the purpose was not
achieved.

Rune


Article: 87446
Subject: Re: Best Practices to Manage Complexity in Hardward/Software Design?
From: "Peter K." <p.kootsookos@iolfree.ie>
Date: 24 Jul 2005 07:28:07 -0700
Links: << >>  << T >>  << A >>
Randy Yates wrote:

> 6. Be patient.
>
> Waiting for a system to be properly designed will almost always be
> more efficient (time-wise) than "waterfall development," i.e., the
> type of development for impatient managers that want to see something
> almost immediately.

I disagree.  A better model (than either big up-front design or
waterfall), in software development, is the spiral / agile model of
development.   I've found this model to be excellent, especially when
the requirements change or are not fully elicited --- as they usually
are in the sorts of software I've developed (greenfield ones).

Big up-front design can be a killer when requirements change.  For some
reason, managers and customers seem to think that software can be
changed much more easily than mechanical systems... so they do.  The
trick is to figure out when they're really expressing a new
requirement, or just jumping on the latest Big Thing.

I wholeheartedly agree with your previous point of keeping this as
abstract as possible for as long as possible.  This really helps the
whole design and elicitation process.... without investing huge amounts
of effort in implementing something that is not critical to success.

Ciao,

Peter K.


Article: 87447
Subject: Re: Fastest way to compute floating point log and exp
From: "GMM50" <george.martin@att.net>
Date: 24 Jul 2005 08:58:29 -0700
Links: << >>  << T >>  << A >>
Also check out CORDIC algorithms.

Goerge


Article: 87448
Subject: Re: Best Practices to Manage Complexity in Hardward/Software Design?
From: Jerry Avins <jya@ieee.org>
Date: Sun, 24 Jul 2005 12:07:45 -0400
Links: << >>  << T >>  << A >>
Fred Marshall wrote:

   ...

> I agree. It was just that the original question was about best practices for 
> development and not for research.  So, the responses were about development. 
> Then Jerry brought up "research" and we started a bit down that path.  I 
> simply tried to say that changing the question would change at least some of 
> the answers.  It's a bit harder for me to envision a product engineering 
> team deciding that failed tests were actually "OK" - although I know that it 
> happens.  (e.g. see Richard Feynman's treatment of the space shuttle 
> disaster.  Thus, I say "harder" not impossible).
> 
> Maybe there needs to be another item on the list:
> "Make sure there is good craftsmanship in every discipline"

I didn't mean to sidetrack the discussion. My ought to have been more 
explicit: some exploration is inevitable for all but the most mundane 
projects. It surprises none of us that R&D has become a single concept. 
I recall choosing an ADC converter peripheral card with bipolar 
multiplexer whose specs suited the needs of a project well, only to find 
-- after the hardware was assembled and drivers written -- that 
dielectric storage in the holding capacitor made the sampler unable to 
follow the multiplexer at speeds well within the spec. Oops!

(That time, I didn't have to start over. I found and fixed the problem 
and told the manufacturer how. They issued a recall and change order.)

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

Article: 87449
Subject: Re: Best Practices to Manage Complexity in Hardward/Software Design?
From: Jerry Avins <jya@ieee.org>
Date: Sun, 24 Jul 2005 12:50:40 -0400
Links: << >>  << T >>  << A >>
Rune Allnor wrote:
> 
> Rune Allnor skrev:
> 
>>Jerry Avins skrev:


   ...

>>>That's well put. How would you classify adding the two satellite plants
>>>to the sewerage system? Originally, the system was designed with one
>>>plant, and pipelines to it from all participating communities. One
>>>administration blocked the two lines from the upstream communities,
>>>forcing the Sewerage Authority to build the satellite plants. The
>>>pipeline plans were scrapped, and we considered reducing the size of the
>>>main plant. Is that a change of implementation, or of plans?
>>
>>That's certainly a change of plans, what I am concerned.
>>
>>Rune
> 
> 
> My answer still stands, but I try not to use the word "plan" in this
> discussion. In my mind, a "plan" is a list of things that need be done
> in order to implement some system or strategy, or otherwise achieve a
> goal. If circumstances change, the plan must change. Here,
> "circumstances"
> include both "implementation" and "design".
> 
> Your original goal, make a sewerage facility to serve the community,
> was still valid. The feasible way to achieve it changed. Hence your
> change of implementation and of plans.
> 
> When I talk of "changing goals" or "changing designs", I mean "changing
> 
> the purpose" of the activity. It would be a "changed design" if you
> started
> out to build a sewerage facility but ended up building, say, a parking
> lot
> or a mall.
> 
> I like to watch BBC's "Top Gear", a weekly TV show where new cars
> are reviewed, tested and commented on. The hosts are very clear in
> their opinions about what is good and what is bad. Particularly
> high-profile brands and models (Ferraris, Porches, BMWs,...) are
> put through their paces in the show.
> 
> With these types of cars, one main reason for giving bad reviews is
> often the purpose of the car: "The designers did not decide what kind
> of car this would be. They wanted this to be a sports car. They wanted
> this to be a muscle car. They wanted this to be a road cruiser. It is
> none of the above".
> 
> Of course, when the purpose of the car is undisputed, the hosts go
> on to explain, in the most English way, why the purpose was not
> achieved.

You made my point, I think. "One plant downstream" can be either a plan 
or an implementation, depending on how long a view one takes. We had 
other design goals, not stated above. Among them, we wanted to avoid 
despoiling the countryside we live in. The main plant discharges into a 
river. When the inflow from heavy rains degrades the quality of the 
effluent, the river becomes a torrent that can accommodate heavy BOD* 
loading. Where before, one community's outfall caused periodic fish 
kills, now fish congregate just downstream of our much larger plant's 
discharge pipe. Not only is dissolved oxygen higher there, but the water 
is clearer than upstream. It's a great place to fish.

The upstream plants pose a different problem. Both discharge into the 
headwaters of streams that, without their flow, would be dry for weeks 
at a time. Before the plants were built, fish and other aquatic life 
would ride out the dry spells in pools in the stream bed, and many would 
survive. (Some of the pools are spring fed.) Since they began operation, 
each upstream plant discharges about 0.3 million gallons a day of 
treated sewage into each stream. The streams never run dry. Clearly, for 
weeks at a time, there is nothing in the stream but sewage, and sewage 
is a major component at all times. We didn't want that responsibility.

_That wasn't the original plan._ But the original goal gas been met: 
there have been no fish die-offs in the 25 years that the plants have 
been in operation. Kids swim and wade without harm; animals drink. _But 
we spend a lot more to treat upstream sewage upstream_ than it would 
have cost to send it downstream and treat it there. When the downstream 
plant operates normally, as it does an average of 363 days a year, its 
effluent tests purer than most bottled water. http://www.sbrsa.org/

Jerry
___________________________
* Biological oxygen demand
-- 
Engineering is the art of making what you want from things you can get.
ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ



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