[<<][sm][>>][..]
Fri Jan 24 07:23:24 EST 2020

Pipeliner: dataflow vs. state machine

So it seems quite obvious.  Pipelining is simple: take a data flow
graph and start adding delays.  It's probably best to formulate it as
a problem that can be solved using a SMT solver.

There is one caveat: feedback.

So for state machines it is really not all that obvious.

It might be good to implement a simple machine like that and see how
it goes.  E.g. a pipelined counter, where the adder is pipelined.



The ground rule is: a pipelined state machine will have a slower state
update.

It also seems that utilization will be low if functional units do not
share a datapath.

Conclusion: pipelined state machines need a programmable datapath.


To re-iterate: this is an important insight.  Easy to see when two
regimes are put next to each other:

- Feed-forward dataflow can be pipelined without consequences: all
  function segments are utilized at max rate, providing throughput,
  but at the expense of some I/O delay which is often not an issue.

- If such a functional network is used as the update function of a
  state machine, the delay is very significiant: for an N-stage
  pipeline, the utilization is only 1/N.  In this case it is probably
  more effective to collapse the different pipeline stages into one
  programmable datapath.  The total machine's update rate will still
  be N times slower, but silicon usage might be better due to reuse.

A CPU is the natural end stage of a pipelined state machine, where we
create a programmable datapath that is universal.




[Reply][About]
[<<][sm][>>][..]