[<<][rtl][>>][..]
Sat Nov 9 07:50:49 EST 2019

Events on FPGA

The core is always just that:

- on a CPU, events are essentially procedure calls

- on FPGA, events are much more implicit: state transitions caused by
  certain combinations of inputs

So to put both on the same footing, it is the FPGA representation
level that needs to be abstracted a bit, because the CPU cannot do the
"polling" that is essentially done by the synchronous logic at every
clock cycle.

So how do you map events into synchronous logic?

Assume the presence of an event is represented by a 1 bit somewhere.
The core is then state updates conditional on that bit being 1.

But that does not solve the case where there can be multiple events at
once.  Maybe this is not really an issue?

Suppose that the imput to the state transition function is a mutually
exclusive bit vector, where each represents an event.

I already ran into this representing data streams.  It seems quite
natural.  Let's keep this in mind and design a machine.


The core idea seems to be that synchronous logic is too lowlevel for
all but the most essential components (e.g. an edge detector, a
counter).

This points in this direction:

- Create a library of low-level components that transfer "continous
  monitoring" into event streams, i.e. data + sync bit.

- Express all processing as (state,{event}) -> (state,{event}), where
  {event} denotes a set of events.

The difficulty seems to be events that are concurrent.  Is it too much
of a restriction to impoce each "process" to have only one "message
queue"?

This brings to mind the distinction between the channel approach and
the mailbox approach.  But that is not really what it is about, since
a sequential program gets to choose from which channel it reads next,
and can impose time order that way.

The core idea for this to work is that each machine takes only a
single event stream, and can do a single event at each clock tick.
The mailbox model works best for that.

This also makes it possible to express stream processors as functions,
e.g. giving a sequential composition structure without fan-in.

Fan-in should be handled by dedicated mergers.

Alright there are a lot of corner cases, that is clear.

E.g. it might be possible to implement a machine sequentially, but
then it needs to have a limited event input rate.





[Reply][About]
[<<][rtl][>>][..]