Hardware is easier to program than software?

So says a Computer Science programmer whose book I am reading. This is because you cannot make certain mistakes (or potential mistakes) when programming hardware-they physics won't let you--but you can in software, leading to problems down the road (this is why software often fails in 'mysterious ways' necessitating a reboot). Having done only a bit of programming in hardware (on a breadboard) in college but lots of software programming, I found his statement counter-intuitive (it seems hardware programming is harder) but it may indeed be true. After a while, after you memorize and master the hardware building block templates used in hardware programming (for example, a oscillator circuit, a Wheatstone bridge for balancing, etc etc, add your list here) indeed hardware programming maybe 'easier'.

Paul, what you say?

RayLopez99 wrote:
So says a Computer Science programmer whose book I am reading.
This is because you cannot make certain mistakes (or potential mistakes)
when programming hardware-they physics won't let you--but you can
in software, leading to problems down the road (this is why software
often fails in 'mysterious ways' necessitating a reboot). Having done
only a bit of programming in hardware (on a breadboard) in college but
lots of software programming, I found his statement counter-intuitive
(it seems hardware programming is harder) but it may indeed be true.
After a while, after you memorize and master the hardware building block
templates used in hardware programming (for example, a oscillator circuit,
a Wheatstone bridge for balancing, etc etc, add your list here) indeed
hardware programming maybe 'easier'.

Paul, what you say?

What a load of rubbish :-)

(That's the short answer...)

I guess you'll have to wait for my new book now, where
I give my considered opinion, on the habits and
qualities of Computer Science graduates :-)

Paul

"RayLopez99" wrote in message
...
So says a Computer Science programmer whose book I am reading. This is
because you cannot make certain mistakes (or potential mistakes) when
programming hardware-they physics won't let you--but you can in software,
leading to problems down the road (this is why software often fails in
'mysterious ways' necessitating a reboot). Having done only a bit of
programming in hardware (on a breadboard) in college but lots of software
programming, I found his statement counter-intuitive (it seems hardware
programming is harder) but it may indeed be true. After a while, after
you memorize and master the hardware building block templates used in
hardware programming (for example, a oscillator circuit, a Wheatstone
bridge for balancing, etc etc, add your list here) indeed hardware
programming maybe 'easier'.

Paul, what you say?

I may be missing something, but how do you program hardware without
software? You build hardware, but if you need it to do a special function
(like say, an electric door opener/closer), then you build parts into it
that make it perform the function you need. In this example, you would
probably use some kind of limit switch to stop the motor when the door
reaches its full open or closed sequence. I don't really see that as
programming; it's just hardware.
Now if you're looking for a microcontroller to use maybe an electric eye or
two to limit the speed with which it goes at end of cycle, then you're
talking about firmware programming (still not hardware).
But simply putting resistors, capacitors, and ICs on a breadboard isn't
really programming, it's simple circuitry, even if it's designed to perform
a particular function.

Did I miss something?
--
SC Tom

Not . . . logic errors can be made in hardware as well, some being subtle
and hard to track down.

"SC Tom" wrote in message ...

I may be missing something, but how do you program hardware without
software? . . . Did I miss something?

The OP's textbook may be rather old. Its reference was to the
earliest generations of computers programmed by manual
switches (or paper tape simulating many switches). Within a
decade computer operators discovered that (1) languages
(e.g. ASM, Fortran) and (2) Disk Operating Systems (as well
as (3) much-improved larger memory = data storage) was
more efficient and more powerful.

--
Don Phillipson
Carlsbad Springs
(Ottawa, Canada)

"Don Phillipson" wrote in message
...
"SC Tom" wrote in message ...

I may be missing something, but how do you program hardware without
software? . . . Did I miss something?

The OP's textbook may be rather old. Its reference was to the
earliest generations of computers programmed by manual
switches (or paper tape simulating many switches). Within a
decade computer operators discovered that (1) languages
(e.g. ASM, Fortran) and (2) Disk Operating Systems (as well
as (3) much-improved larger memory = data storage) was
more efficient and more powerful.

It would be REALly old then :-) Are we talking about the computers like the
WWII language decryption models? If so, I don't think that was any easier
than the originators of Fortran or DOS had it.
--
SC Tom

On Wednesday, September 12, 2012 2:58:01 PM UTC-4, SC Tom wrote:

Did I miss something?

--

SC Tom

I was thinking ASICs. It is true that ASIC design is software driven but the actual stitching together of the ASIC to do something useful is hardware design.

As for firmware, etc, that's usually a small part of ASIC design, typically for bootup. That part is still hardware design in my mind, though you can quibble over definitions.

RL

On 2012-09-13 03:11:44 +1000, RayLopez99 said:

So says a Computer Science programmer whose book I am reading. This is
because you cannot make certain mistakes (or potential mistakes) when
programming hardware-they physics won't let you--but you can in
software, leading to problems down the road (this is why software often
fails in 'mysterious ways' necessitating a reboot). Having done only a
bit of programming in hardware (on a breadboard) in college but lots of
software programming, I found his statement counter-intuitive (it seems
hardware programming is harder) but it may indeed be true. After a
while, after you memorize and master the hardware building block
templates used in hardware programming (for example, a oscillator
circuit, a Wheatstone bridge for balancing, etc etc, addyour list here)
indeed hardware programming maybe 'easier'.

Paul, what you say?

Writing firmware for hardware can be easier as long as you have the
appropriate tools (logic/bus analyser oscilloscopes etc). It is easier
in the sense that you are not working with an operating system and you
are totally in control of what the hardware is doing. If it breaks, it
is your fault and it can be diagnosed. With an operating system there
are often many layers of abstraction and 3rd party systems that you
have negotiate with - all areas that are ripe for presenting problems.

Debugging race conditions in hardware can be ****iferous.

On Wednesday, September 12, 2012 11:43:10 PM UTC-4, Astropher wrote:

Debugging race conditions in hardware can be ****iferous.

Yes, race conditions are unstable and do not replicate--the same hardware can have a race condition in one moment and on reboot be fine the next moment. That's why designers have timing constraints that factor in a safety factor. I think I read somewhere that in fact it's possible to have a race condition even with certain inputs and/or operating conditions (temperature, voltage swings, etc at the limit) no matter what you do, or that was the implication. Every flip-flop, a backbone of hardware design, is unstable by definition in certain conditions btw.

RL

RayLopez99 wrote:
On Wednesday, September 12, 2012 11:43:10 PM UTC-4, Astropher wrote:
Debugging race conditions in hardware can be ****iferous.

Yes, race conditions are unstable and do not replicate--the same hardware
can have a race condition in one moment and on reboot be fine the next moment.
That's why designers have timing constraints that factor in a safety factor.
I think I read somewhere that in fact it's possible to have a race condition
even with certain inputs and/or operating conditions (temperature, voltage
swings, etc at the limit) no matter what you do, or that was the implication.
Every flip-flop, a backbone of hardware design, is unstable by definition in
certain conditions btw.

RL

If this were true (that "flip-flops were evil"), your
computer wouldn't stay running for very long. Obviously,
it does stay running, so there's got to be a measure of
stability present.

Where a flip-flop can screw up, is if the data input changes,
at the same instant that the clock input is used to take a sample.
This typically arises in digital systems where two subsystems use
a different clock. Clock relationships can be synchronous (flip-flop "likes"),
plesiochronous (if phase is wrong, fails horribly and repeatedly),
or asynchronous (fails statistically, and potentially once in a blue moon).

In this case, Wikipedia doesn't have a good article, but if you're
a hardware guy, you'll recognize the subject matter on this page.

http://www.asic-world.com/tidbits/metastablity.html

My company had its own fab and CMOS process. I shared office space
in the fab building, with some of the geniuses over there. One neat
gadget they build, was to measure metastability (parameters). It's
so they could tell their customers (people who made use of the
fab products), what the statistics of metastability were for that
particular CMOS process. So if you visited there, you could be shown
an oscilloscope trace, of the squiggles caused by metastability.

A way to reduce metastability, is to use resampling. This is fine,
except in cases where the additional delay affects performance. Or,
in the old days, adding additional resampling stages, to improve
the statistics, cost more money. And that would be an incentive not
to use eight stages of resampling (as suggested in some document
I read). Typically, we'd use the two stage resampler, if a solution
was required, just like in this example. Certain late model 74F
flip flops, could be used at a couple hundred megahertz to fix
problems like this. This was back when we were still doing
significant amounts of "board logic", rather than ASICs.

http://www.asic-world.com/images/tidbits/meta.h1.gif

Ah, this brings back memories. The good ole days...
Our home-brew metastability measurement jig, may have
been based on the concept in this paper. Documents like
this, would have been required reading, at the time.

http://www.ti.com/lit/an/sdya006/sdya006.pdf

If your design is purely synchronous, the flip-flop is as stable
as can be. It's when you purposely change the data, as the clock
causes the flip-flop to sample, that bad things happen. That's
effectively a timing violation.

Paul