Re: something I came to think about ... (logical operators in if statements)

From: David Reeve (dree4456_at_big-pond.net.au)
Date: 11/19/03 

Date: Wed, 19 Nov 2003 04:34:42 GMT

"VBDis" <vbdis@aol.com> wrote in message
news:20031118190322.05539.00002376@mb-m16.aol.com...
> Im Artikel <5gcgrvsuab3d5srbtifqfq15oh351aks97@4ax.com>, "Martin Harvey
(Demon
> Account)" <martin@pergolesi.demon.co.uk> schreibt:
>
> >Kinda cool: All the statements in your "program" execute
> >simultaneously ;-)
> >
> ><Insert manic discussion about clocked versus asynchronous logic here>
>
> With threads we can get race conditions also in software. But in contrast
to
> hardware, the "delays" between the various components (threads) of a
program
> are inpredictable.
>
> From my experience with hardware circuit design (20+ years) I'd say that
there
> exist many relationships between hardware and software design.
Understanding
> hardware operations, at the low level, and hardware design procedures and
> tools, would help every program writer to master his code. Since a
hardware
> circuit is hard to debug, the hardware designers use many tools and
procedures
> to exclude possible problems from their circuits. Most software
"designers"
> usually write their code without defining states and transition graphs,
and
> tend to wait for runtime errors to find out where their design must be
> improved. Unfortunately many software bugs do not manifest during testing,
so
> that programmers pretend that their code is free of bugs, and that no
special
> efforts are required to proof their design. But at least I like to use
some
> procedures, known from hardware design, also in designing software.
>

In days of designing with 74 series logic, you would scan the databooks
looking for a 'blackbox' with something like the right functionality, and
then wire together all these functional blocks. The real buzz was to get the
bits to fit together just so, without too many partially used chips.
Designing with Delphi, I proceed down a very similar route, except I have
the new problem of having to decide how many 'black boxes' and quite what
functionality goes in each. However they are 'black-boxes' and I represent
them as such, a rectangle with input and output stubs. Outputs are handled
by events, and inputs are properties or command post boxes. You can achieve
asynchronous logic by clocking the object from its own timer, or from a
windowed message handler. Synchronous logic is obtained from direct method
calls.... in the most abstracted 'black-box' case, the DoIt method is the
only one exposed. This approach leads to testability and reuseability not
unlike that of having a box of TTL logic to choose from.

> Even the differences between hard and soft logic can help in understanding
more
> about logic in general, like finding out where trouble can lurk in the
> background. Consider expressions like (A and not A), (A and B), (B and A),
> which can produce different effects in hard- and software, that cannot be
> recognized or explained by studies of abstract boolean logic. I often used
(A
> and not A) in my circuits, sometimes also (A xor not A) - guess for what
> purpose ;-)
>
> Another remark comes just into mind: hardware people are very polite, they
use
> handshake, enable, and other kind procedures, whereas software people
prefer to
> kill, purge, or other violent terms and actions. Perhaps the introduction
of
> "try" blocks in programming languages results from some insight, that not
> everything can or should be achieved by brute force?
>

:-)

Never thought about this, but it rings true. One learn't to be careful of
brute force with a large TTL layout when Vcc could supply 40A. I guess the
odd AV isn't nothing like as spectacular or destructive.

Dave

Relevant Pages

  • Re: ADC mux charge injection on commercial DAQ boards
    ... It's driven by some fundament real and percieved difference between software and hardware. ... In addition because of the perceived simplicity of changing the SW, the specifications for SW are often fuzzy, incompletely thought out and more grandiose than is necessary to do the required job. ... Often the rest of the specified functionality is unnecessary or completely different functionality will be more useful. ... A good design will be done with an eye to exapnding capabilities in the future, an excellent design will succed in having a sufficiently general base that future modifications fit in cleanly, an exceptional design will be so simple and clean that it doesn't require changes since additional functionality can be built out of the existing functionality. ...
    (sci.electronics.design)
  • Re: Security and EOL issues
    ... OS software resources are designed that reserved ram and disk space among other resources, to reflect what current hardware size is available. ... (There was a security patch a few years ago that could not be applied to NT4 as it required more resources then NT4 could provide. ... Installing air bags requires that the automobile manufacturer design, test, ... Computer Emergency Response Teams, and Digital Investigations. ...
    (Security-Basics)
  • Re: Coding style
    ... Search this group for "think hardware" and from these posings you will see what's the difference. ... Drawing a scetch of the circuit you are about to design will always be the first step, even if you are going to use a HDL because you need to understand the circuit and how it should work. ...
    (comp.arch.fpga)
  • Staff HW Engineer ~ Lead Us to ATCA & Beyond in Your End-to-End Board-Level HW Desig
    ... The senior level hardware engineer looking for the product realization ... and true ownership that comes with full end-to-end board-level hardware ... help us retain dominance in the design of high performance switching ...
    (comp.arch.embedded)
  • Re: 10khz DBSK decoder
    ... In an AVR, you may want to come closer to the 'hardwareish' thing: run the whole thing as a Costas loop or as a signal-square-and-PLL, and do integrate-and-dump. ... In retrospect, the ISR should have just taken ADC samples and shoved them into a queue, then set a flag. ... But I had never seen that design pattern, so it just ran with that big bloated ISR... ... You'll get more consistent timing if you can trigger your ADC from hardware and interrupt on the end of conversion pulse. ...
    (comp.dsp)