Gather QoR and other metrics and surface to user

[meheff]

It'd be good to have one place (a proto?) where various useful metrics can be written to during the build/synthesis process. Then the user could easily access these values and tools could be written to visualize them.

Random ideas for useful metrics:

• pipeline length
• number of registers
• number of various units (like mutlipliers, adders, etc) and their widths. These could include references to where they occur in the original source code input.
• stdcell counts / histograms
• various synthesis metrics: area, slack, power estimates, etc.

[cdleary]

Just a note for context that we do currently have the --output_schedule_path flag in codegen_main for dumping out the generated pipeline metadata; however, there's a bunch more metrics we could surface programmatically to the user-level tools.

[cdleary]

I think some of this was done recently by augmenting our existing proto output. @meheff @taktoa could you give a brief update on that?

Down closer to the backend, we had some downstream work here wrangling some black-box metric output formats into something user-visible/-consumable, but now with SKY130 / open PDKs this should also be doable using the Open ASIC tools flow. Tagging this issue also with the oss backend label since it applies (at least partially).

[cdleary]

Here's a sample CL that added more metrics as described in the OP: https://github.com/google/xls/commit/6652da40ee3c419a7bd1b265bada649727e45f6b#diff-930822aa60ed73921e227ad1698f2ef94cbba6cef9d6adabd550f19d0b181a7e

We may need some documentation to follow up on how people can effectively dump this out from the tools.

[meheff]

The additional metrics you pointed to in BlockMetricsProto (https://github.com/google/xls/commit/6652da40ee3c419a7bd1b265bada649727e45f6b#diff-930822aa60ed73921e227ad1698f2ef94cbba6cef9d6adabd550f19d0b181a7eR20) are generated from XLS internal analysis and not scraped from EDA tools. We will probably want some easy way to distinguish between XLS estimates and EDA tool generated data. Documentation here would definitely be good.

@taktoa recently added some internal-only bits of code for scraping some EDA tool output for some qor metrics and correlating back to source lines. With the OSS eda tools we could push that framework into OSS and expand it.