Several things - test-drb@ccmp.vtda.org

14 Apr 1999

Tony wrote:

...
 > Tony said, on processor design, you can either
have one flip-flop to each
> machine state (like a P850) or microcode.  Again there are intermediate
points.
...
   I claim you
can do quite well by numbering the machine states in a suitably
 chosen binary code and having one flip-flop to each bit.  Logic for changing
 flip-flops is often _easier_ than when you have one flip-flop per state.  (I 
 Although, of course, the advantage of one f/f per state is that you can't
 get glitches when you decode the outputs of the flip-flops. 

Because you don't decode them, right?

As Tony probably remembers, my final year project at university was a GPIB
interface for a Trend papertape reader (no, it isn't finished yet - ten years
on!).  My original design used a flip-flop for each machine state in three state
machines.

I recently looked at using fewer flipflops.  I recall one of the state machines
had six states.  Using three bits, one could define the two redundant states in
such a way that this was also glitch-free.  Additionally, one of the state
variables was an input, not a flipflop...

...
 > have done both designs for the same circuit BTW). 
If you put this logic into a
...
 > ROM, this becomes in a sense a microcode ROM, but
you can do it combinatorially
...
   as well...

 A ROM _is_ combinatorial logic. I don't want to get into a silly argument
 over this, but I have great difficulty finding a conceptual difference
 between a combinatorial circuit built from a pile of AND, OR and NOT
 gates and the same circuit built (albeit using a lot more transistors) in
 a ROM. To claim that a CPU using a ROM is microcoded but one with
 _identical_ internal states using simple gates as the feedback logic
 round the sequencer flip-flops is not is a very strange way of thinking
 about things. 

Fair enough.  Just another example of different places to draw boundaries, with
grey areas in between.  I would call the ROM version microcoded, and the hard
wired version not, because the ROM version contains CODE.  (I would agree that
the two machines are equivalent, one implemented using a store of (micro-) code
and the other using gates.)  But your view is equally valid.  Perhaps this
displays your hardware background and my more software-based upbringing.

To show how grey this is, if you use a ROM to implement the combinatorial logic
for a flipflop-per-state machine, would you call the code in this ROM microcode?
It performs that function, viz. to output signals based on the machine state
which control the operation of the machine including the selection of the next
state.

For that matter, remember your example on this list a while back, using logic
gates to implement Z80 instructions.

...
  Well, I might accept it once I'd drawn out the
full schematics and
 figured out what it was going to do. The problem of what happens if it
 fails is another matter, though. As I said time and again, the time to
 try a different braking technique is _not_ when the car is skidding all
 over the place on a normal road. 

I'm not convinced the braking technique is different, though.  I would generally
try to brake thus: brake only just not hard enough to skid.  If skid occurs,
start pumping.  I claim this applies to both sorts of car, but skid is less
likely to occur with ABS.

I read once (in a sci-fi novel) about a braking system where the brake for each
wheel derived hydraulic pressure from a turbine on that axle.  ABS wasn't the
issue there, but I claim this system is passive and intrinsically anti-lock.  It
also has the advantage that a failure on one wheel doesn't affect the rest of
the vehicle (though with only a small number of wheels, as in a car, this may be
a problem).  I wonder if something of this nature could be made to work usefully
for ABS...

Philip.