Allow delays connected to global inputs and outputs

[klarasm]

Allow delays to be connected to global inputs and outputs.

There are a few parts of this:

1. SDFSchedule needs to find the correct rate when the IO edge is a delay. Do that by finding the first actor along that signal chain and use that rate.
2. This also does not generate a new IRId for delay edges and just uses the input one. Note that we still need the alias for the input signal since we always do the lookup.
3. ForSyDeIRToProceduralIR needs to use the translated buffers for foldActorSignals so it can see the actual buffer id.
4. Add examples for these scenarios.
5. Also remove the old hardcoded first attempt at translating Core functions to ProceduralIR.

[Himawari722]

This improvement looks great! I think you have written nonDelayInputSignal and nonDelayInputSignal to recursively find the first non delay signal, so it should support a delay actor chain and I wrote a simple example to test it. However, there was an error Actor not found: a_delay2 when I tried running an SDF graph like this:

-- system: s_in -> a_add -> d1 -> d2 -> s_out

I think the error was caused here SDFSchedule:95, when it was converting ForSyDe IR delay edges. It assumed the src and dst of an delay edge should be a non-delay actor so it just used findActorByName to find them, but it failed if there existed an delay chain. So there should also be a recursive way to build delay edges. Should I make a new issue and work on that?

[klarasm]

Right, we would need to merge successive delays between regular actors too (and ignore delay-delay connections if the chain is on an input or outout). I think it's more a nice to have since the same model with a single (merged) delay element on the edge should have the same semantic meaning (so we could get the same result by changing the model). Creating the issue would be good though, since we want to document what parts of the compiler is incomplete, and we can work on it if we have time left over.

[SamuelMiksits]

I think this is fine for the most part. I ran all of the models we have now and did not get any errors, and I tried the test suite and it passes. From the code perspective, I looked at it and it looks fine. But someone else might have other opinions or scenarios where it doesn't work

[klarasm]

I added a few more examples to this PR.

[sthaeron]

I'm a little confused about how the implementation works. I don't quite understand why adding inputDelays and outputDelays statement lists to the translation context was necessary. The signal names of system inputs and outputs, which are delayed, seem to be propagated to the process constructor for SDF examples 20 and 21. Thus, shouldn't the foldActorSignal pass for a_add add the necessary statements as they are global inputs/outputs?

Perhaps we can talk about it tomorrow in person after the meeting @klarasm. But I can't seem to wrap my head around why the original solution didn't just work once the SDF Scheduler was updated?

Nevertheless, the implementation in its current state does work!

[klarasm]

I'm a little confused about how the implementation works. I don't quite understand why adding inputDelays and outputDelays statement lists to the translation context was necessary. The signal names of system inputs and outputs, which are delayed, seem to be propagated to the process constructor for SDF examples 20 and 21. Thus, shouldn't the foldActorSignal pass for a_add add the necessary statements as they are global inputs/outputs?

The reason the current solution doesn't work is that foldActorSignals only looks at the immediate input/output, meaning if there's a delay there, it won't produce the statements for reading or writing the buffer. But this actually gave me an idea, maybe it's better to make this function continue until it finds either an actor or global input/output (similar how I did it in the scheduler)?

Perhaps we can talk about it tomorrow in person after the meeting @klarasm. But I can't seem to wrap my head around why the original solution didn't just work once the SDF Scheduler was updated?

We can do that.

Nevertheless, the implementation in its current state does work!

[klarasm]

@sthaeron

It was a good thing you commented on that, turns out the only thing we actually needed for ForSyDeIRToProceduralIR was:

diff --git a/src/ForSyDeIRToProceduralIR.hs b/src/ForSyDeIRToProceduralIR.hs
index f88c4091b8cc..43974dc59d88 100644
--- a/src/ForSyDeIRToProceduralIR.hs
+++ b/src/ForSyDeIRToProceduralIR.hs
@@ -193,8 +193,8 @@ translateIRConstructor initialContext constructor = case constructor of
                     ++ [EVar $ show functionId]
                 )
             )
-        inputStmts = foldl' foldActorSignals [] inputSignals
-        outputStmts = foldl' foldActorSignals [] outputSignals
+        inputStmts = foldl' foldActorSignals [] translatedInputSignals
+        outputStmts = foldl' foldActorSignals [] translatedOutputSignals
         stmts = reverse inputStmts ++ [actorCallStmt] ++ reverse outputStmts
         context1 = initialContext {actors = (actorId, stmts) : actors initialContext}
      in context1

Then the IO will be handled by the actors as you said.

[klarasm]

Hmm. One issue with the approach in this PR is that even if we could produce output immediately we will still try to get input first. But this we can probably put as future work.

[klarasm]

I reverted back to just placing parentheses around everything in this PR, though I have another idea in #309.

[klarasm]

Hmm. One issue with the approach in this PR is that even if we could produce output immediately we will still try to get input first. But this we can probably put as future work.

I think I address this one in the latest commit. I'm not sure about the formatting on the initial delay tokens on global output, though.