xls
xls copied to clipboard
Refactor channel->port mapping in signature
Currently, we have protos in channels that map "logical" (e.g. VALID) ports to "physical" (e.g. chan_vld) port names. Signature generation goes through the channels and populates the signature, validates that the ports exist, etc.
There are some issues with this:
- We need to keep channels around after block conversion, which means we also keep procs/functions around, even if we aren't really using them.
- Port modifications (such as those in the ram rewrite pass) need to remember to update channel metadata. The error messages you get if this goes wrong are in signature generation, which is late in the pipeline and far away from the problem. In the multi-proc codegen context where one channel might go up or down a hierarchy of blocks, each block can reference the same channel, so you need a list of block -> port mappings and then later you need to find the right block's port mappings during signature generation. Something like block inlining requires you to modify this metadata.
- Channel metadata makes IR harder to read, plus we generally don't like to carry around bare protos in the IR.
My proposed solution is to reverse the direction of the references- instead of pointing "forward" from channel -> port, to have metadata associated with a port about the channel it comes from. The simplest approach seems to be having metadata on the port itself, but it would also work to have a block-level abstraction (e.g. a bundle of ports with some metadata?).
The ideal end state has:
- Backwards pointing references from port to channel.
- Signature should be generated directly from the block.
- Modifying ports should be validated by the block, e.g. if you remove the valid port of a channel, that should either be an API error (you can only remove these ports as a group?) or a verifier error (you can remove the port, but your pass needs to replace it or the verifier will give an error near the failing pass)
- Channels should be able to be DCE'd, procs/functions be DFE'd.
- Signature generation should only have to look at the block it is being generated for (no other IR should be relevant)
- Channels shouldn't have a metadata proto as a member.