benbarsdell
commented
8 years ago Thanks Miles. I had a glance at this last night too.
I have to admit that my first impression was not altogether positive:
- Not updated in 8 years
- Uses Java (enough said :P)
- Non-standard definition language (although so close to json that it might as well be)
- Not clear/intuitive what everything means (params vs. attributes? domain? basedon?)
- Figure 1 is somewhat frightening
The language used in Section 4.2 is a bit foreign but I think they're describing the same thing as what I called the 'ghost region' that's used to emulate wrap-around access.
I don't want to dismiss this, as it may well prove useful, but I would probably treat it similarly to GRC, i.e., a pipeline/graph serialization format that we should consider supporting.
On 8 July 2016 at 14:58, Miles Cranmer notifications@github.com wrote:
See this paper http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.76.6859&rep=rep1&type=pdf for a description of the format. It was created in order to solve the "critical problem [which] arrises in transferring a DSP design across dataflow-based tools due to the lack of a vendor independent language for specifying DSP-oriented dataflow graphs." (An example is shown below).
Another paper http://www.ece.umd.edu/DSPCAD/papers/hsu2005x2.pdf describes compiling these graphs into C, using different schedulers and memory management tools to help optimize the software. In section 4.2, they describe their use of ring buffers: @benbarsdell https://github.com/benbarsdell - I am curious to hear how much the Bifrost implementation differs from their's, because they provide a good explanation which may be useful in creating documentation for Bifrost.
[keyword] graph graphID [basedon graphID] { params { param prm1, prm2, ...; domain (prm1, {1, 2, ...}); domain (prm2, [1, 5]); ... } interface { input portID portID ...; output portID portID ...; } topology { nodes { nodeID [:portID ] nodeID [:portID ] ...} edges { edgeID sourceINodeID sinkNodeID; edgeID sourceINodeID sinkNodeID; ... } } refinement { subgraphID nodeID subPortID:edgeID subPortID:PortID ...; subgraphID nodeID subPortID:portID subPortID:edgeID ...; ... } attribute attributeName { edgeID value ; nodeID value ; ... } ... [built-in attribute] {...} ... }
In addition, here is an interesting chart which shows how DIF is incorporated into programming models:
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ledatelescope/bifrost/issues/26, or mute the thread https://github.com/notifications/unsubscribe/ADy3WDVdjAr8akBjUk0deuku2OTHUJm9ks5qTsfxgaJpZM4JIbk3 .
MilesCranmer
ledatelescope
telegraphic
See this paper for a description of the format. It was created in order to solve the "critical problem [which] arrises in transferring a DSP design across dataflow-based tools due to the lack of a vendor independent language for specifying DSP-oriented dataflow graphs." (An example is shown below).
Another paper describes compiling these graphs into C, using different schedulers and memory management tools to help optimize the software. In section 4.2, they describe their use of ring buffers: @benbarsdell - I am curious to hear how much the Bifrost implementation differs from their's, because they provide a good explanation which may be useful in creating documentation for Bifrost.
In addition, here is an interesting chart which shows how DIF is incorporated into programming models: