Re: relative complexity of hardware and software (was: pick 'n' place machines (was: OT 0805 resistor noise))

"John Larkin" <jjlarkin@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:2a83i1l2lgqk5tvaits5o8acob6rfo41v9@xxxxxxxxxx
> Except that huge, complex, synchronously-clocked hardware logic
> systems seldom have bugs. But most software has bugs. The design
> methodologies are distinct: in hardware logic, the current system
> state is unambiguous, and combinational logic based on the current
> state sets up the next state, which is implemented, across the entire
> chip, at the next clock. People get into trouble whan they break that
> paradigm. In software, the execution point is local, but wanders all
> over the place in often unpredictable paths, and in a multitasking
> system (ie, most systems nowadays) there is seldom any decent
> mechanism for coordinating tasks.

Interesting observation.

But are you saying that the transitions in hardware logic systems are
conceived and described as system-wide (what the software world would call
"global variables")? Surely that's not true in a large system; as you said
earlier, things are broken into functional blocks, "Multipliers, adders,
fifos, PID controllers, ..."

Seems to me that as soon as you have a system consisting of smaller
components that themselves embody some complexity, but that are described in
a simplified form, the opportunity for bugs arise. For instance, one might
thing of a block as an "adder" but in fact it can overflow and wrap, a
condition that would only be obvious in hindsight.

Similarly I would think that the same opportunities for multithreading bugs
that exist in software, also exist in hardware. (Put it this way: I'm sure
I could write a threading bug in hardware if I tried.)

Perhaps the differences have more to do with how concisely small functional
blocks can be fully described (in software, even something as basic as a
scrolling listbox is hard to fully specify concisely enough to be useful to
a programmer), and with the number of layers of functional composition (>10
for even a simple desktop app, versus I imagine many fewer for a hardware
logic system)?

I don't design hardware logic so I'm just guessing. (I do design software,
so I'm all too familiar with the processes that lead to bugs on that side.)


.

Relevant Pages

  • Re: relative complexity of hardware and software (was: pick n place machines
    ... systems seldom have bugs. ... But most software has bugs. ... I don't design hardware logic so I'm just guessing. ... programmable logic does indeed allow for ratshit programming. ...
    (sci.electronics.design)
  • Re: OO Software Project Entropy Question.
    ... > the project may tend to spend more and more time fixing bugs. ... If a team implements features in small batches, such as 5 features a week, ... There are those who decide that "refactoring" is re-work. ... Design Smells are errors in design - not bugs. ...
    (comp.object)
  • Re: Is shared memory a total mess or am I just being thick????
    ... the more opportunities for new bugs you create. ... of Ingres that need improvement, ... if there are no problems, i.e. if it ain't broke, then don't fix it. ... Now whether "the approach is sound to begin with" is a question of design ...
    (comp.databases.ingres)
  • OT: Exchange (Was Re: OpenVMS - When downtime is not an option)
    ... the bugs *only* affected Exchange Server. ... Server* design flaw, not a Windows flaw. ... whether it is doing something which requires it to have high privileges at that ...
    (comp.os.vms)
  • Re: PCB layout software (Orcad versus Pads)
    ... > I have been looking at the Orcad and Pads ... design of the pcb. ... are able to do with the cad rather than what they want to do. ... Also do not worry too much about 'bugs' in the software - in the well known ...
    (sci.electronics.cad)