[HandshakeToHW] Add instrumentation for measuring II#988
Conversation
Prior to this PR, measuring II was a difficult manual task: Either one had to check the number of loop iterations and check the circuit latency to guestimate the II OR one had to check the waveforms and manually measure the II there. This PR therefore adds an automatic approach that dumps the average II of every innermost loop in the simulation report. The logic simply looks for loops in the control network using LLVM's loop info library and adds an extra process that monitors the loop headers output channel. When the loop exists, the average II is printed. Note that the process is added to the top-level entity rather than the testbench despite not being synthesizeable as this does not require changes to the circuit interface. Only VHDL and verilog are currently implemented. Irregular control flow (rare case) may fail to detect a loop in which case it just wouldn't be instrumented.
|
Can this be done with a new mlir operation? Like IIMonitorOp now you need to analyze the hw dialect which seems not ideal… |
You could and I am starting to think it is cleaner but it doesn't really change the analysis that has to be performed I think. One still needs to find loop nestings, exiting edges and the loop header control merge. The control_merge you can find with I am actually also starting to think that we should report the II on the exit of the outermost loop since an outerloop effectively gets pipelined too but this would then include work performed after and before the innermost loop as well. Very very alternatively I could just print the cycle count anytime a control_merge that is part of a loop gets triggered and let users post-process it, this wouldn't require any analysis as done here. However, we would not be able to tell what outer and inner loop merges are, so I am not even sure this is useful... |
|
Even if you don't use an operation, if you analyze handshake and then store the need values in an attribute on the module op that handshake to hw propagates down? So then write-hdl can just emit the RTL based on the analysis, but we can still analyze handshake? |
|
This is really cool also, thank you! |
I'd rather use an operation in that case since the attribute approach is likely to be fragile similar to some of the issues we have seen with named memory operations (as in, easily silently invalidated). I like the op since then we can reuse all the infrastructure for different backend generation. |
|
Yeah also sounds good 😁 I don't see a huge amount of difference in fragility between an attribute and an operation (especially if handshake to hardware generates the attribute just before lowering?) Both are definable with utility functions and validation and constructors in tablegen right? just that operations have operands and results. |
In this specific case the attribute would have to encode: What are the exit edges (i.e. SSA values) of the (outer)-loop and which control_merge is the inner-most loop header. I suppose you could do this in some shape or form (using operation names + encoding the index of result for the corresponding result) but you do need to write all the verification, type checking and so on yourself. With an op you get this more or less for free. If you also consider future errors the op also is a stronger signal of something going wrong and/or composes better. Lets assume the scenario someone accidently added a pass after the II instrumentation but before the harwdware lowering pass because maybe they do similar instrumentation and it somehow changes the IR in a way that affects the II monitoring: The II monitoring attribute ideally fails to verify, but could in theory also just accidently pick up a wrong channel now (due to name changes and whatnot). In the operation case there is an op in the IR. If they were require to handle it they are more likely to find it there on a failing case than an attribute. Similarily, if they were to break something a verifier is more or less guaranteed to catch it. The most likely case really is that any SSA modifications they do in their instrumentation keeps the monitoring op working because it has proper references to all the channels that are needed. |
|
I don't think this is so much fragility as "we want to store values"? I would object to being able to call the instrumentation separately to handshake to hardware, that seems dangerous? |
|
I think my objection to an op is actually "should this be serialized in handshake" and I think the answer is no: But maybe we want to put it in a hw.module? if we want reliable edge identification? |
|
Or do you think op verification is useful to us even if the op never gets serialized? |
|
It sounds to me like the best case that would satisfy all of this is to implement it as part of the handshake to hardware lowering or keep it as is right now in export-RTL. Neither cases would have the op occur in handshake IR (which I don't think has any advantages beyond "we can do it purely on handshake level") and there is no error for misuse. In the former we could even use the Generation infrastructure if we want. |
|
Yes, full agree, I think part of lowering has mild advantages but would be supportive of either 😁 |
… accuracy by defining the measure window from outside loop activation to either next outside loop activation or outer loop exit
zero9178
changed the title
…evels and innermost loops)
…tions at the moment
3 participants
Prior to this PR, measuring II was a difficult manual task: Either one had to check the number of loop iterations and check the circuit latency to guestimate the II OR one had to check the waveforms and manually measure the II there.
This PR therefore adds an automatic approach that dumps the average II of every innermost loop in the simulation report when
--instrument-iiwas using duringcompile. The logic simply looks for loops in the control network using LLVM's loop info library and adds an extra ii_monitor instance for every loop that monitors the activation channels of the loop. Anytime the loop exits, the average II is printed.Note that the process is added to the top-level entity rather than the testbench despite not being synthesizeable as this does not require changes to the circuit interface. Only VHDL and verilog are currently implemented.
Irregular control flow (rare case) may fail to detect a loop in which case it just wouldn't be instrumented.
Assisted by Claude