Re: [boost] [review] Dataflow Library

Subject: Re: [boost] [review] Dataflow Library
From: Stjepan Rajko (stipe_at_[hidden])
Date: 2008-09-08 19:22:31

On Mon, Sep 8, 2008 at 3:09 PM, Ravikiran Rajagopal
<ravi.rajagopal_at_[hidden]> wrote:
>
>> 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.
>

Thanks for giving it a try!

> 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.
>

Multiple clock domains with feedback definitely sounds like a scenario
not suitable for Dataflow.Signals.  I think in general, as soon as you
start needing a control object that needs to have some overall
knowledge of the network (unless it is a specific network for which a
custom control object can be implemented), Dataflow.Signals is
probably the wrong tool.

> 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.
>

Perhaps a Dataflow library support layer could be written for SystemC.
 I looked at SystemC a while back when someone referred me to it, but
never ended up doing anything with it...

Anyway, regarding the pin-based approach - recently I started writing
a framework for the Dataflow library called Dataflow.Managed, which is
inspired by the pin-based approach mentioned in the documentation.
You can see a test case here:
http://svn.boost.org/svn/boost/sandbox/SOC/2007/signals/libs/dataflow/test/managed/test_network.cpp
(sorry it is not well documented)

The Dataflow.Managed layer provides "intelligent" invocation of
components - it will only invoke components whose inputs have changed.
 Even though it is not specifically geared towards clock-driven
networks, you could have a clock component that changes it's output at
every edge or clock cycle, and thereby invokes each of the components
connected to it.  If you wanted to do hardware simulation, the
components would still need to simulate signal delays (a simple
solution could be that that the components read and buffer their
inputs in one half of the clock cycle, and write to their outputs in
the other), so this would still not be an ideal solution.

I think after I finalize the generic layer of the Dataflow library
(this is the underlying layer of concepts on top of which
Dataflow.Signals is built), I will try to provide small example
frameworks suitable for different kinds of scenarios.  A framework
specifically intended for clock-based networks should definitely be
one of those examples.

Thanks again for trying to implement something using the library - I'm
sorry it turned out Dataflow.Signals was the wrong tool for the job
(in the future I will know to do a better job of describing the
suitability/unsuitability of Dataflow.Signals in the documentation).

If you feel like you've gotten a good sense of where Dataflow.Signals
is useful and where it isn't (perhaps you were able to implement some
simplified version of the problem?), I would still encourage you to
write a review if you have the time.

> 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.
>

You might want to re-post this part in a new e-mail with an
appropriate subject line - it is likely to go unnoticed here.

Kind regards,

Stjepan