I’m starting an engagement with an internal customer (at Microsoft) who are focused very much on performance. In order to meet their performance requirements, the tooling (ESI and/or some other dialect) needs some relatively detailed information about the physical structure of the FPGA they are targeting. Essentially, they know more-or-less where they want to place and (more importantly) route their widgets but are having trouble getting Quartus to do what they want because, frankly, Quartus isn’t very good at its job. So they end up having to tell Quartus exactly what to do. Given the size of their design (number of widgets they want to place) and the irregularity of FPGA fabrics, this approach obviously doesn’t scale so they’re looking for tooling assistance. This problem is more tractable than the usual PnR problem since their design is very regular – Quartus just can’t see the regularity since it’s just a flattened netlist by the time it gets to the placement and routing steps. Plus, this is a case where you really want to choose where to put the pipeline registers after you do placement. (As I’ve argued for several years, the basic design flow – RTL → mapped netlist → placement → routing – is fundamentally broken these days.)
So I’m starting to think seriously about this topic. @stephenneuendorffer Can you share any more details about Xilinx’s approach? I’m looking to store location data about the M20Ks, DSPs, I/O columns, and some routing information (mostly about fast vs slow wires so we can conserve the fast wires).
My initial (totally uninformed) instinct is that MLIR would be difficult and unnatural to use to store the device data, but that one could attach placement and routing information to MLIR ops via attributes. I think a placement/routing/device dialect could be useful for defining custom attributes and modeling device-specific hardware (e.g. DSPs) as ops. The logic could then be lowered to RTL in the usual way (being very careful about names) and a separate TCL script could be generated instructing Quartus where to place/route the entities in the RTL (as identified by the careful names).
Does this approach seem reasonable? Thoughts?