Re: [boost] [review] Dataflow Library

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