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