Timothy Miller wrote:
On 7/12/06, Dieter <[EMAIL PROTECTED]> wrote:
> I can completely document hardware and provide
> and the behavioral and interface specifications and I have really
> completely described the hardware. The implementation of those
specs is
> really just busywork.
You have just insulted thousands of engineers.
After I remove my foot from my mouth, I'll make sure to watch my choice
of words a bit more next time. :) BTW, I'm one of those engineers I
insulted. My intention was to differentiate between two cases. If I
give you the following requirements "Design me a simple and efficient 8
bit microprocessor." What if I provided you with this
http://www.6502.org/archive/datasheets/wdc_w65c02s_feb_2004.pdf and
asked you to design a chip that implemented those specifications. Life
becomes much easier. A competent chip designer could probably turn out
a working simulation pretty quickly. Or more to the current problem at
hand. "Design me a GPU to compete on par with an nVidia TNT2." Now,
what if I gave you the complete block diagram, register spec, interface
and timing docs, etc?
Depends on how you look at it. I've interviewed with organizations
that do vast amounts of design up front, divide up the design into
smaller and smaller pieces, to finally hand procedure-per-sheet
instructions to minimally-trained coders at the bottom of the
hierarchy.
I heard people state, "Anyone can be taught to program." While
obviously not true (some peoples minds just don't work that way), the
underlying perception is at least in my opinion. I've worked with
several companies who would willingly hire physicists an mathematicians
before many computer science folks. These places weren't looking for
"programmers", they wear looking for people with good critical thinking
skills who understood how to break down a problem into manageable
pieces, etc.
Engineers who write software are often thought of as "coders", but
once you've reached a certain level of familiarity with a language,
the actual coding part drops into the background. While you may start
coding immediately, all you're doing is overlapping design and coding.
When a really good hacker sits down to hack together some cool code
idea, it may take longer to type in than it took to think up, but in
order to have a good idea in the first place, he had to imagine it
clearly, and that was flash thought in his mind on the way to the
computer (yes, we leave our computers sometimes). Probably a more
common scenario is that your subconscious mind has been working on it
for weeks, and when the ideas finally surface, they're fully-formed.
When you reach this point, you aren't a programmer. You are an
engineer/architect. You don't simply write what someone told you to
anymore. You start designing and building your own.
Howard commented that, despite my relative (to him) inexperience with
chip design, I write very error-free Verilog code very quickly. But
what's really happening is that what takes me 4 hours to code actually
took me days or weeks to work out in my mind.
Now, let's be careful about what we mean by 'spec'. Some things
require a lot of thought to deal with. The PCI spec, for instance, is
no cakewalk. So implementing it requires a lot of work. But a lot of
that work is just understanding something developed by a committee (so
the prose and diagrams are not always transparent). Actual typing in
of source code is a relatively small part of the process.
If we do a good enough job of documenting OGA and make sure the model
implements that correctly and is structured in a way that makes it
easy to design hardware, then the conversion to Verilog will resemble
busy-work. All the hard stuff went into doing the spec and writing
the C-language model.
That was my point originally, before I suffered a case of foot in mouth.
And while certain aspects of the implementation may be "busy work",
the debugging never is. :)
> I suppose the same could be said for a
> software system, but I have never ever seen it done
Some software projects have requirements documents, followed by design
documents, and test documents. The implementation (coding) of those
documents (specs) is seperate. I wouldn't call it busywork, it is
essential, and it needs to be done correctly, just as with hardware.
You're right that the coding process has to be done right. I suppose
for some people, it's busy work and for some, it's not. That depends
on experience. Take, for instance, some C program I wrote when I was
16 and compare how long it would take for me to do the same thing now.
There would be a vast difference in time and difficulty to achieve
the same result.
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
