Several things

From: Philip.Belben_at_pgen.com <(Philip.Belben_at_pgen.com)>
Date: Wed Apr 14 11:35:24 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.
Received on Wed Apr 14 1999 - 11:35:24 BST

This archive was generated by hypermail 2.3.0 : Fri Oct 10 2014 - 23:31:42 BST