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 87450

Article: 87450
Subject: Re: Best Practices to Manage Complexity in Hardward/Software Design?
From: Jerry Avins <jya@ieee.org>
Date: Sun, 24 Jul 2005 12:52:24 -0400
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.

Not all forecasting is prognostication.

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

Article: 87451
Subject: Re: Fastest way to compute floating point log and exp
From: Kolja Sulimma <news@sulimma.de>
Date: Sun, 24 Jul 2005 19:19:39 +0200
Links: << >>  << T >>  << A >>
Marc Battyani schrieb:
> 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)
>[...] I've looked
> at cordic at a glance, but it looks slower or bigger if totally unrolled.

Why would you want to unroll it?

Kolja Sulimma

Article: 87452
Subject: Re: Fastest way to compute floating point log and exp
From: "Marc Battyani" <Marc.Battyani@fractalconcept.com>
Date: Sun, 24 Jul 2005 19:21:12 +0200
Links: << >>  << T >>  << A >>

"Ray Andraka" <ray@andraka.com> wrote:
> 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.
> >
> 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?

I need the log as an IEEE754 32 bit floating point with full precision from
an input also in IEEE754 32 bit floating point format. (Maybe this will be
changed to extended floating point (40 bits)
So far I take the mantissa, use the first bits to select the coeffs of a
small polynomial in a LUT, apply the polynomial to the mantissa, and add the
exponent multiplied by a coeff. The kind of log is not very imporant as it
is used in a more general computation which can be modified if needed. So
using log2 is probably a good idea (no coeff for the exponent)

Marc



Article: 87453
Subject: Re: Fastest way to compute floating point log and exp
From: "Marc Battyani" <Marc.Battyani@fractalconcept.com>
Date: Sun, 24 Jul 2005 19:21:22 +0200
Links: << >>  << T >>  << A >>

"Philip Freidin" <philip@fliptronics.com> wrote:
> 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?
> >
> 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.

Thanks, that's interesting but here I need to process IEEE754 32 bits
floating points.

Marc



Article: 87454
Subject: Re: Best Practices to Manage Complexity in Hardward/Software Design?
From: Jerry Avins <jya@ieee.org>
Date: Sun, 24 Jul 2005 13:27:36 -0400
Links: << >>  << T >>  << A >>


We didn't appear to agree at first, but it seems we do. I don't 
subscribe to "If it ain't broke, don't fix it", but to a related maxim: 
"If you can see trouble coming, head it off." Another sewerage example:

The upstream plants, the ones where failure turns miles of scenic brook 
into a sewage ditch, use a then-novel treatment scheme to make 
super-clean effluent. The process uses partly submerged rotating disks 
to achieve aeration and be a substrate for active bacteria. The supports 
for these disks were to be bolted to both sides of the concrete trough 
in which the sewage flows. I saw it going in, and questioned the wisdom 
of bolting steel to concrete that way. Differential expansion might tend 
to crack the concrete. Our consulting engineers had bought the patented 
design and used it "out of the box". When I questioned its longevity, I 
was reminded that prototypes had already been operating some four years 
with no problem. I remembered something else, and asked, "Where are 
they?" They were all in southern California, where the weather is quite 
different from here, central New Jersey.

The bolts were already set into the concrete; what to do? The original 
plan was bolting each end with a half-inch pad under it. We bolted one 
end with its pad, and left a half-inch gap with no nut on the other end. 
That end is supported by the bolt, but not longitudinally constrained by 
it. Despite out harsher winters, there has been no cracking yet. But the 
California installations weren't "broke", so despite all subsequent 
installations using my floating hangers, the old ones weren't fixed. At 
least one original southern California trough is now patched.

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

Article: 87455
Subject: Re: Best Practices to Manage Complexity in Hardward/Software Design?
From: Jerry Avins <jya@ieee.org>
Date: Sun, 24 Jul 2005 13:46:58 -0400
Links: << >>  << T >>  << A >>
Peter K. wrote:
> 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.

I disagree with both of you. So there! (Disagreeing seems to be an 
activity that I do very well.) I could have written that you're both 
right. There are lots of models, and some people do better with one than 
with another. When the planning is up to you, but your boss picks the 
model, it's time to circulate your resume.

I have never found a model that works for me that I can explain. My most 
productive mode is sitting with my feet on the desk and my eyes closed 
for a long time, consult a data sheet on occasion, and after a day or so 
of seeming inactivity, write down a plan. At meetings, I can't be that 
thorough, so I would usually listen at least half way through, longer if 
politics allowed (the thought just happens), and the opine, "I would go 
about it this way ....") I used to get called to participate in planning 
meetings for projects we all knew I would have no further association 
with. My advice was often followed, and sometimes backed up to. That's 
not to brag (but I acknowledge the form!), but to illustrate that my 
amorphous approach worked for at least one person -- me.

I think it's good to know several planning paradigms, and to choose one 
that fits one's own style, and perhaps the project. As usual, the best 
way is acknowledging that there is no best way.

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

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


Jerry Avins skrev:
> There are lots of models, and some people do better with one than
> with another. When the planning is up to you, but your boss picks the
> model, it's time to circulate your resume.

Most certainly agreed.

> I have never found a model that works for me that I can explain. My most
> productive mode is sitting with my feet on the desk and my eyes closed
> for a long time, consult a data sheet on occasion, and after a day or so
> of seeming inactivity, write down a plan.

Whoa, you are fast! I used to spend weeks in that mode. I am sure I
would be the worst employer any "ambitious" boss could have, drinking
coffe, reading papers and chatting with co-workers for days on end.

No apparent activity, but if left alone (no bosses wanted to see
"progress"), I always delivered on time and according to spec.

> At meetings, I can't be that
> thorough, so I would usually listen at least half way through, longer if
> politics allowed (the thought just happens), and the opine, "I would go
> about it this way ....") I used to get called to participate in planning
> meetings for projects we all knew I would have no further association
> with. My advice was often followed, and sometimes backed up to. That's
> not to brag (but I acknowledge the form!), but to illustrate that my
> amorphous approach worked for at least one person -- me.

>From my experience, the truly amazing aspect in your story is that
you were allowed to go on in this way, and that others acted
constructively on you suggestions. This is the stage where the
"fast trackers" usually find they need to make their mark on a
project, and then do.

> I think it's good to know several planning paradigms, and to choose one
> that fits one's own style, and perhaps the project. As usual, the best
> way is acknowledging that there is no best way.

Rune


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


Rune Allnor skrev:
> Jerry Avins skrev:
> > There are lots of models, and some people do better with one than
> > with another. When the planning is up to you, but your boss picks the
> > model, it's time to circulate your resume.
>
> Most certainly agreed.
>
> > I have never found a model that works for me that I can explain. My most
> > productive mode is sitting with my feet on the desk and my eyes closed
> > for a long time, consult a data sheet on occasion, and after a day or so
> > of seeming inactivity, write down a plan.
>
> Whoa, you are fast! I used to spend weeks in that mode. I am sure I
> would be the worst employer

Make that "emplyee"

Rune

> any "ambitious" boss could have, drinking
> coffe, reading papers and chatting with co-workers for days on end.
>
> No apparent activity, but if left alone (no bosses wanted to see
> "progress"), I always delivered on time and according to spec.


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


Rune Allnor skrev:
> Rune Allnor skrev:
> > Jerry Avins skrev:
> > > There are lots of models, and some people do better with one than
> > > with another. When the planning is up to you, but your boss picks the
> > > model, it's time to circulate your resume.
> >
> > Most certainly agreed.
> >
> > > I have never found a model that works for me that I can explain. My most
> > > productive mode is sitting with my feet on the desk and my eyes closed
> > > for a long time, consult a data sheet on occasion, and after a day or so
> > > of seeming inactivity, write down a plan.
> >
> > Whoa, you are fast! I used to spend weeks in that mode. I am sure I
> > would be the worst employer
>
> Make that "emplyee"

Or better still, "employee"...

Rune

> > any "ambitious" boss could have, drinking
> > coffe, reading papers and chatting with co-workers for days on end.
> >
> > No apparent activity, but if left alone (no bosses wanted to see
> > "progress"), I always delivered on time and according to spec.


Article: 87459
Subject: Problems installing windrvr.o in Red Hat EL3...
From: SantaBarbara350Z@gmail.com
Date: 24 Jul 2005 12:12:54 -0700
Links: << >>  << T >>  << A >>
I run into a problem when I 'make;make install' the linuxdrivers.tgz
file from Xilinx.  Any solutions?  I've read about 2.6.x updates and
such, but I have a 2.4.x kernel.


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

   ...

> From my experience, the truly amazing aspect in your story is that
> you were allowed to go on in this way, and that others acted
> constructively on you suggestions. This is the stage where the
> "fast trackers" usually find they need to make their mark on a
> project, and then do.

RCA Labs was a truly amazing place to work. In the midst of a research 
lab, I was a "consultant" whose contribution was making things work. My 
reputation was better than I deserved, but it (and three Outstanding 
Achievement Awards) gave me the freedom to act rationally. One of my 
suggestions, on controlling a machine vital to a high-priority project 
was turned town to my dismay. I wanted to use existing hardware (of my 
design, based on a Z-80) programmed in Forth. The project leader "knew" 
that success required a much faster machine (12 MHz 8086) programmed in 
C. He used Intel boards.

I couldn't let personality issues sink the project, and I had the 
freedom to do it my way on my own. He had a team of three programmers 
who worked on the code for 5 weeks while the electrical interface was 
being built to the various sensors, switches, air valves, and transport 
motors. I had the drawings for that and the specs for some of what the 
controller had to do. (I had, on request, designed some of the 
algorithms. That's another funny story.) I wrote the code to do the job. 
The drivers for digital I/O were part of my design for the controller, 
completed long since. After a time, the design specs were changed (a 
flaw had been found) and I updated my code. Even after the update, I had 
only about ten days invested in programming AND TESTING.

What happened when they first married computer to room-sized machine was 
a loud BANG as every relay and air cylinder was simultaneously actuated. 
Mercifully, a motor tried to run both clockwise and counterclockwise and 
blew the breaker. Still, some pushrods bent, and a few other pieces 
needed to be replaced. You see, the system had been designed by 
programmers, who naturally assumed that high must mean ON, and low must 
mean OFF. Hardware engineers design circuits to be active low, because 
I/O pins default to inputs on reset and remain high until programmed as 
outputs and then set low. Back to the drawing board! They changed the 
code, but I didn't have to. I had written it properly from the start and 
had a tech build a bank of inverters to match their wiring. Now I could 
discard the inverter board.

After two more weeks of testing and recompiling after the repairs, it 
became clear that they wouldn't meet the deadline. I was asked to pitch 
in and assist. I unplugged their controller and plugged in mine. It 
worked right off, proving once again that a 4-MHz Z-80 is fast enough 
for almost anything that moves, and that knowing every bit of the code, 
including the compiler and the monitor ROM is a great help in avoiding 
mistakes and finding them when they happen.

Three programmers working seven weeks didn't manage what I had done on 
my own in less than two. I'm not a fast programmer; I never was. I had 
several advantages, though. First, I had no one to argue with me about 
how to do it. (It's easy to reach a consensus alone. :-)) Second, I had 
experience writing software to do I/O to control hardware. I had even 
built an effective system to do that, and I used it for the project. The 
device drivers for it were bug free long before the project began. 
Third, I wrote in Forth, which let me test each code function -- rarely 
more than two lines -- as it was written, so that only correct functions 
were incorporated into subsequent code.

Anyhow, my point is that the Labs gave me the freedom to do things like 
that, and succeeding at them earned me the freedom to do even more. Very 
few engineers ever enjoy the luck that I had. I feel especially blessed.

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

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

   ...
> Make that "emplyee"

My boss once said that I was useless most of the time, but that once a 
month or so, I earned double a month's pay. I could never figure out why 
my raises weren't bigger.

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

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


Jerry Avins skrev:
[... great story snipped ...]
> Three programmers working seven weeks didn't manage what I had done on
> my own in less than two. I'm not a fast programmer; I never was. I had
> several advantages, though. First, I had no one to argue with me about
> how to do it. (It's easy to reach a consensus alone. :-)) Second, I had
> experience writing software to do I/O to control hardware. I had even
> built an effective system to do that, and I used it for the project. The
> device drivers for it were bug free long before the project began.
> Third, I wrote in Forth, which let me test each code function -- rarely
> more than two lines -- as it was written, so that only correct functions
> were incorporated into subsequent code.

You forgot your forth, and probably decisive, advantage: You knew all
aspects of the task.

I commented on it in my first post (and I think Fred hinted along
the same lines in one of his early posts), that one person must be
able to grasp the whole problem. You saw the potential trouble spots
beforehand and avoided them. The most efficient way to recover from
a problem is to avoid the problem in the first place. You knew the
hardware/software high/low conventions and so on. The other team
had to discover all that.

Of course, you had even more advantages in that you had designed
the rest of the system, so let's say you saved a week or so of
finding, reading and understanding the system spec.  

Rune


Article: 87463
Subject: Re: Xilinx software update?
From: "Martin" <0_0_0_0_@pacbell.net>
Date: Sun, 24 Jul 2005 22:39:38 GMT
Links: << >>  << T >>  << A >>
Thanks all for your replies on this subject.

-Martin



Article: 87464
Subject: Re: July 20th Altera Net Seminar: Stratix II Logic Density
From: "Peter Alfke" <peter@xilinx.com>
Date: 24 Jul 2005 15:46:55 -0700
Links: << >>  << T >>  << A >>
Kees, you have a point, but how should we respond when our competitor
runs a public web-seminar that obfuscates the issue with irrelevant
hair-splitting ? Some people might even believe them...
Peter Alfke


Article: 87465
Subject: Re: Best Practices to Manage Complexity in Hardward/Software
From: Randy Yates <yates@ieee.org>
Date: Mon, 25 Jul 2005 00:43:37 GMT
Links: << >>  << T >>  << A >>
Jerry Avins <jya@ieee.org> writes:

> It's easy to reach a consensus alone. 

Oh, man, Jerry - you can say that again!
-- 
%  Randy Yates                  % "The dreamer, the unwoken fool - 
%% Fuquay-Varina, NC            %  in dreams, no pain will kiss the brow..."
%%% 919-577-9882                %  
%%%% <yates@ieee.org>           % 'Eldorado Overture', *Eldorado*, ELO
http://home.earthlink.net/~yatescr

Article: 87466
Subject: Re: July 20th Altera Net Seminar: Stratix II Logic Density
From: Mike Treseler <mtreseler@gmail.com>
Date: Sun, 24 Jul 2005 18:05:12 -0700
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> Kees, you have a point, but how should we respond when our competitor
> runs a public web-seminar that obfuscates the issue with irrelevant
> hair-splitting ?   Some people might even believe them...

Perhaps you should give your customers more credit for
being able to think for themselves.

          -- Mike Treseler

Article: 87467
Subject: Re: July 20th Altera Net Seminar: Stratix II Logic Density
From: "austin" <austin@xilinx.com>
Date: 24 Jul 2005 18:10:09 -0700
Links: << >>  << T >>  << A >>
Mike,

We do, we do (give our customer credit to think for themselves, but we
worry about those who are not our customers...).

We made our point.  No need to go on about it.

Thanks for listening, and taking the time to reply.

Austin


Article: 87468
Subject: Re: Best Practices to Manage Complexity in Hardward/Software Design?
From: "Fred Marshall" <fmarshallx@remove_the_x.acm.org>
Date: Sun, 24 Jul 2005 18:41:04 -0700
Links: << >>  << T >>  << A >>

"Jerry Avins" <jya@ieee.org> wrote in message 
news:2qqdnZsKM7QXUn7fRVn-tg@rcn.net...
> Fred Marshall wrote:
.....................
>
> The bolts were already set into the concrete; what to do? The original 
> plan was bolting each end with a half-inch pad under it. We bolted one end 
> with its pad, and left a half-inch gap with no nut on the other end. That 
> end is supported by the bolt, but not longitudinally constrained by it. 
> Despite out harsher winters, there has been no cracking yet. But the 
> California installations weren't "broke", so despite all subsequent 
> installations using my floating hangers, the old ones weren't fixed. At 
> least one original southern California trough is now patched.
>
> Jerry
> -- 

Jerry,

Well, you didn't have a working model in the context of your application. 
But you also didn't *prove* that cracking would occur did you?  (If you did 
then OK - bear with me; I'm not suggesting that you didn't have a valid 
concern).

What if it had been built for NJ and no failure occurred?  And subsequently 
the worry came up?
Should you change the implementation or not?  Your example re: California is 
perfect!  The worry was apparently sufficiently justified that taking the 
nuts off in California would have been the smart thing to do.

A lot depends on the change that's contemplated.
I once had a job solving problems on a system that was in production.  The 
idea was to solve the problem without introducing any additional parts.  It 
was a great challenge and fun to solve the problems with that constraint. 
Very much like removing the nuts.  Mind you, the solutions were changes - 
but ones that had been asked for.

So, if all you had to do was remove some redundant nuts in order to make the 
design "better" then by all means.  These notions are more guidelines than 
hard and fast rules.  When the notions are stated in "shorthand" then maybe 
they sound stricter.  If you *must* make a change then who could argue?  We 
have not (thank goodness?) talked about change control - which is often more 
about configuration management but can also be about making the decision to 
change or not to change in a formalized manner.  The idea about design 
freeze is to enable getting into production without  ruining all the testing 
that has already been done.  It's also about getting rid of the crazy "new 
ideas" that some folks *never* stop coming up with, and curtailing those 
participants who can never make a decision, so that there can be a 
reasonable degree of stability.  It's also about not paying for the changes 
(risk, time and money) unless it's necessary.

If you have always worked with sensible people who always made the right 
decisions and caused things to happen really well without a hitch then you 
might think others are a little crazy to suggest some structure.  But, if 
you've worked with people who are always wanting to try the latest and 
greatest stuff because having fun is more important than getting out the 
product or if you've worked with people who can't make a decision or if 
you're working with people who would make an unnecessary change (because 
they had not weighed the cost and risk vs. the benefit - or because their 
assessment is different than yours) then you would see the value in some 
structure along those lines.

Sometimes "design freeze" is used to simply get people to make up their 
minds, finish their work, etc.

Software is *so* easy to change.  How many times has someone broken the 
system with some little change?  The software books are full of examples. 
Of course, many of those examples are to make a technical point.  But the 
examples sure beg the question: "What if the change had not been made at 
all?  Would it have mattered - i.e. would the system still have performed 
just fine?"  That's more to the point.  How many times did the change come 
up because the programmer thought: "Well, I just figured it might be easier 
to read the code if ...... "

I'm pretty sure we agree on most of this....

At the core this is more about decision making.  Your folks decided to not 
make changes in California.  Were they driven to that decision because they 
didn't want to spend the money?  Or, were they driven to that decision by 
blind allegiance to a "freeze" kind of rule?  I'll bet it's the former and, 
on a comparative basis, I agree with that being the driver even if we might 
disagree in hindsight (or in foresight) with the decision they made.

Fred 



Article: 87469
Subject: DCM.
From: "im.de" <im.de@gmx.de>
Date: 24 Jul 2005 18:46:03 -0700
Links: << >>  << T >>  << A >>
Hi, there

I am creating a project with Spartan 3 board. and wanna add DCM into
the XPS 6.2 project under menu "project- add/edit cores(dialog)"

What I want is to get the clock down to clock/2.
There are 3 moduls in the DCM, I am using the digital frenquency
synthesizer (DFS).

I added 3 ports: "clkin", "rst" as input, "clkfx" as output in the
internal ports connections, didnot add anything into the external ports
connections.

connected the "clkin" to "sys_clk"=50mMHz of the external ports,
reconnected the clock input ports of other components who HAD "sys_clk"
as input to the output port "clkfx"

the parameters I have
c_clkfx_multiply = 1
c_clkfx_divide = 2
c_clkin_period = 40.000000 <-----  which i am not sure the use of this
parameters.

But it did not work out.


Anyone has some idea?
thanks


Article: 87470
Subject: Re: Best Practices to Manage Complexity in Hardward/Software Design?
From: "Matt Timmermans" <mt0000@sympatico.nospam-remove.ca>
Date: Sun, 24 Jul 2005 22:16:59 -0400
Links: << >>  << T >>  << A >>
Rune, I'd rather argue about practical matters instead of definitions, so 
let me try it this way:

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

In my shop, unless I have to pass an audit, the products of all these 
activities are mostly code.  At the level you're describing, most of this 
code is just interfaces, comments, and glue, but it is real code that 
becomes part of the project.  After all, it is code that really defines the 
algorithms that get used, and the program organization, etc.  The code will 
be documented with block diagrams, overviews, various bits of UML, etc., in 
order to communicate its gestalt more clearly, but most of the work here is 
code.

I know that a lot of process-oriented folks think that there should be a 
separate design phase that produces something other than code, but which is 
actually a lot like code.  In my experience, this is a bad idea.  Rather 
than turning much of the programming job into mere transcription, it's more 
efficient to write your original ideas directly in the target language. 
That way, your programmers can work on something more interesting, and you 
don't need to rely on their secretarial skills to transcribe your thoughts 
accurately.  (Pssst.  They don't *read* what you write.  They just skim 
through it.)

> "Implementation" is about getting
> a software function or piece of machinery to perform a pre-determined
> action.

I have a bit of trouble understanding what you mean by this.  If you really 
mean "a pre-determined action", then I know there are places where 
programmers actually have jobs like this, but I swear that my shop will 
never be one of them.  Have you seen "Metropolis?"  If you just mean 
"fulfill some defined purpose", then you can see why I think that this is 
the same task as above, but on a smaller scale.  The product of this 
activity is also code.  It's just more isolated code that isn't reflected 
throughout the system like the overall architectural components are. The 
processes used for creating all this code, and the purpose of all this code, 
is essentially the same.  In all cases, the coder is defining the structure 
and operation of software.

I know you may not agree with my way of thinking about this, so to see who 
is more practically correct, perhaps we should see if we can find some sort 
of phase transition near the middle of the software development process that 
would justify your assignment of different labels to the pre-transition and 
post-transition phases:

- Is there a point near the middle of development where schedules suddenly 
become firm?  In my experience, no, there usually isn't.  Certainty 
increases gradually and continually during development.

- Is there a point near the middle of development where feasibility suddenly 
becomes proven?  I have found that doubts about feasibility can only be 
quelled by real implementations.  It is a good idea to implement these 
questionable parts of a project early, but because these aren't usually 
isolated or architectural parts of the project, you can't just do them all 
first.

- Is there a point near the middle of development when you can validate all 
of your preceding assumptions with the customer?  Again, in my experience, 
there is not.  If customers could look at a project in progress and really 
determine whether or not it meets their needs, they wouldn't need you or me.

So, if you still think that there is a real, practical, division of 
development into design and implementation phases, then when, oh when, does 
it occur, and what are the practical consequences of reaching it?

--
Matt



Article: 87471
Subject: Re: Best Practices to Manage Complexity in Hardward/Software Design?
From: "Matt Timmermans" <mt0000@sympatico.nospam-remove.ca>
Date: Sun, 24 Jul 2005 22:19:03 -0400
Links: << >>  << T >>  << A >>

"steve" <bungalow_steve@yahoo.com> wrote in message 
news:1122179959.459049.317700@o13g2000cwo.googlegroups.com...
> "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.

Oh, yes, and they have to do it the same way real fortune tellers do -- by 
understanding their customers.

--
Matt



Article: 87472
Subject: Re: Best Practices to Manage Complexity in Hardward/Software Design?
From: Steve Underwood <steveu@dis.org>
Date: Mon, 25 Jul 2005 10:23:45 +0800
Links: << >>  << T >>  << A >>
Randy Yates wrote:

>Jerry Avins <jya@ieee.org> writes:
>
>  
>
>>It's easy to reach a consensus alone. 
>>    
>>
>
>Oh, man, Jerry - you can say that again!
>  
>
Oh what bliss. A man who's free of inner conflicts. I often vigorously 
disagree with myself - especially when my tongue is saying "eat that" 
while my brain is saying "now, just how many kilos did the bathroom 
scales show the other day?" :-)

As America's great philsopher G.W. Bush so wisely said "I have opinions 
of my own, strong opinions, but I don't always agree with them." :-)

Regards,
Steve

Article: 87473
Subject: Re: Best Practices to Manage Complexity in Hardward/Software Design?
From: Jerry Avins <jya@ieee.org>
Date: Sun, 24 Jul 2005 23:21:17 -0400
Links: << >>  << T >>  << A >>
Matt Timmermans wrote:
> "steve" <bungalow_steve@yahoo.com> wrote in message 
> news:1122179959.459049.317700@o13g2000cwo.googlegroups.com...
> 
>>"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.
> 
> 
> Oh, yes, and they have to do it the same way real fortune tellers do -- by 
> understanding their customers.

Yeah man!

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

Article: 87474
Subject: Re: Best Practices to Manage Complexity in Hardward/Software Design?
From: Jerry Avins <jya@ieee.org>
Date: Sun, 24 Jul 2005 23:54:14 -0400
Links: << >>  << T >>  << A >>
Matt Timmermans wrote:
> Rune, I'd rather argue about practical matters instead of definitions, so 
> let me try it this way:
> 
> 
>>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.
> 
> 
> In my shop, unless I have to pass an audit, the products of all these 
> activities are mostly code.  At the level you're describing, most of this 
> code is just interfaces, comments, and glue, but it is real code that 
> becomes part of the project.  After all, it is code that really defines the 
> algorithms that get used, and the program organization, etc.  The code will 
> be documented with block diagrams, overviews, various bits of UML, etc., in 
> order to communicate its gestalt more clearly, but most of the work here is 
> code.
> 
> I know that a lot of process-oriented folks think that there should be a 
> separate design phase that produces something other than code, but which is 
> actually a lot like code.  In my experience, this is a bad idea.  Rather 
> than turning much of the programming job into mere transcription, it's more 
> efficient to write your original ideas directly in the target language. 
> That way, your programmers can work on something more interesting, and you 
> don't need to rely on their secretarial skills to transcribe your thoughts 
> accurately.  (Pssst.  They don't *read* what you write.  They just skim 
> through it.)
> 
> 
>>"Implementation" is about getting
>>a software function or piece of machinery to perform a pre-determined
>>action.
> 
> 
> I have a bit of trouble understanding what you mean by this.  If you really 
> mean "a pre-determined action", then I know there are places where 
> programmers actually have jobs like this, but I swear that my shop will 
> never be one of them.  Have you seen "Metropolis?"  If you just mean 
> "fulfill some defined purpose", then you can see why I think that this is 
> the same task as above, but on a smaller scale.  The product of this 
> activity is also code.  It's just more isolated code that isn't reflected 
> throughout the system like the overall architectural components are. The 
> processes used for creating all this code, and the purpose of all this code, 
> is essentially the same.  In all cases, the coder is defining the structure 
> and operation of software.
> 
> I know you may not agree with my way of thinking about this, so to see who 
> is more practically correct, perhaps we should see if we can find some sort 
> of phase transition near the middle of the software development process that 
> would justify your assignment of different labels to the pre-transition and 
> post-transition phases:
> 
> - Is there a point near the middle of development where schedules suddenly 
> become firm?  In my experience, no, there usually isn't.  Certainty 
> increases gradually and continually during development.
> 
> - Is there a point near the middle of development where feasibility suddenly 
> becomes proven?  I have found that doubts about feasibility can only be 
> quelled by real implementations.  It is a good idea to implement these 
> questionable parts of a project early, but because these aren't usually 
> isolated or architectural parts of the project, you can't just do them all 
> first.
> 
> - Is there a point near the middle of development when you can validate all 
> of your preceding assumptions with the customer?  Again, in my experience, 
> there is not.  If customers could look at a project in progress and really 
> determine whether or not it meets their needs, they wouldn't need you or me.
> 
> So, if you still think that there is a real, practical, division of 
> development into design and implementation phases, then when, oh when, does 
> it occur, and what are the practical consequences of reaching it?

Matt,

Before I write code, I want to know what it's supposed to do. When it's 
for a client, I want to be very sure that the client knows it's supposed 
to do. I did programming for hire for a time, sometimes moonlighting, 
and for a while as part of my only professional activity. I learned from 
other's bad experiences before I started to insist on a set of 
specifications that would allow the client to prove that I didn't finish 
the job, and allow me to prove that I did. Some clients didn't like to 
be pinned down, and if I liked the job I would help to write the 
document. I excepted as a requirements specification a users manual that 
explained how to use every feature and described everything that a user 
would see. If it was loose, I reserved (in writing) the right to fill in 
the details as I thought reasonable, and to charge extra for changes. It 
was a good policy, allowing me to keep friendships that I would 
otherwise have lost. Once, it sort of backfired.

A friend of a friend asked me to code a personality profile program he 
could use in his business. He had the algorithms and a general outline, 
but no details. I asked for a spec to work to, saying that a user manual 
would do. He said he'd get back to me when he was ready, we shook hands, 
and I didn't hear from him until I got a check in the mail, about a 
day's fee, a few months later. I phoned his office about the mistake and 
asked if I should return the check or tear it up. He phoned back about 
an hour later and told me that I had more than earned it.

He confessed that he had been frightened to put specs on paper because 
they might not be reasonable to meet. So every time he wrote a coherent 
subsection of the manual he coded it in BASIC to see if it was workable. 
Most of the time it was, and when it wasn't -- GWBASIC is not a good 
language for graphics -- he changed the manual. By the time he had the 
specification, he had a working program. The check was for teaching him 
how to get it right. I cashed it happily despite knowing that I had 
talked myself out of a job.

The design part consists of deciding what the used will see and what he 
must to. Coding comes after. Design can be a chapter at a time, or the 
whole manual, but at every point along the way, you need a direction.

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