Boost logo

Boost :

Subject: Re: [boost] [review] Dataflow Library
From: Ravi (lists_ravi_at_[hidden])
Date: 2008-09-08 18:37:16


On Sunday 07 September 2008 14:57:21 Stjepan Rajko wrote:
> > This one is akin to much hardware I've designed where one may have clock
> > domains and manage data events separate from processing events. In some
> > places one can do processing every clock cycle, other places things are
> > more complex.
>
> One could make a Dataflow.Signals network where each component is
> connected to a clock, so that each component does get control at every
> clock cycle and does what it wants.  But, the user would have to make
> sure that the order of invocation is correct - and that's why I'd say
> Dataflow.Signals is not the right tool for a network like this.

This is my fundamental problem with my use cases for the dataflow library. In
order to write a review, I tried to implement a simple OFDM demodulator.
Samples come in at the "correct" rate and are stored in a cyclic buffer; once
in a while, an FFT is performed, and then a channel equalizer block provides
the equalized signal and soft information at each carrier.

I could not figure out how to introduce the notion of a clock which is
necessary for modeling concurrent hardware execution. Initially, it seemed
that the dataflow library provided the tools required to replace SystemC in a
cleaner and more efficient way, but I haven't yet managed to reach that goal.
In order to model a clock, the connection between two modules would need to be
managed by an object that knows about the clock. In particular, a value
written to a connection object would not visible before the next clock (next
active edge for the Verilog/VHDL people here). Such an object is easy enough
to write until one encounters multiple clock domains (pre- and post-FFT in the
simple example above) with feedback.

In the documentation, you mentioned a "pin-based" approach. Such an approach
would seem to map very well to modeling concurrent hardware, but the notion of
clock construction eludes me even for that case. A combination of a clock-
based connection, a pin-based model and a suite of fixed-point numbers based
on expression templates would be sufficient to replace SystemC for my use
cases.

As an aside, I have been waiting (a long time) for Maurizio Vitale to post his
completed fixed-point classes based on Proto. Does anyone know what has
happened to him? I haven't seen anything from him on this list for a while.

Regards,
Ravi


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk