Re: [Discuss-gnuradio] Loops in the flow graph

[Eric Blossom]

On Wed, May 12, 2010 at 05:00:32PM +0200, Alberto Trentadue wrote:
> Hello

> I've seen on the archives, and experienced myself, that GR does not
> support having loops in the flow graph.

Correct.

> I would like to get some more insight on this limitation to
> understand 1.the reasons for it and 2. how to workaround it in those
> cases where a feedback loop is a key solution.

The reasons are that we currently dynamically schedule all of the
blocks, there is no guarantee that a block will produce the number of
samples that we asked it too, and that we like doing things in larger
chunks for performance reasons.

I believe that the best way to work around this limitation would be to
statically schedule portions of the graph.  One way to do this is to
add delay annotations to the edges (connections) between blocks, and
feed that into a modified scheduling algorithm.  We'd also need a way
for blocks to promise to deliver the number of samples we ask for.
Blocks that derive from gr_sync_block, gr_sync_interpolator and
gr_sync_decimator have the appropriate behavior.  We'd just need a way
to communicate that to the scheduling mechanism.

Will Plishker, a postdoc at the University of Maryland, was doing some
work in this area.  I haven't talked to him in a while, so I'm not
sure of the status of that work.  I've cc'd him on this message.

> Naively, I try asking if it would be acceptable to detect the
> presence of at least 1 sample delay in the loop and apply a kind of
> initial condition (or simply a 0 initial value) to boot the
> computations.  Where in the code the loop detection is implemented?

The loop detection is implemented in gr_flowgraph.cc in the
topological sort code.  The actual check occurs on line 460.

> Thanks in advance
> alberto

Eric