Add --flat_place_verbosity to control annotation in flat placement files - #3787
Add --flat_place_verbosity to control annotation in flat placement files#3787amin1377 wants to merge 8 commits into
Conversation
AlexandreSinger
left a comment
There was a problem hiding this comment.
I like this addition a lot @amin1377 !
I have some comments below, let me know what you think.
|
|
||
| ``site_path`` is the hierarchical path of the primitive the atom was placed on within its | ||
| cluster (``t_pb_graph_node::hierarchical_type_name()``), including the mode selected at each | ||
| level. |
There was a problem hiding this comment.
I would update this text to make it clear that anything after the pound symbol (#) is a comment and is not parsed by VPR when read; it is only for the user to better understand and interpret the file. Your new argument allows us to select how verbose we want it.
I really like the idea of adding a verbosity 0 since printing the CLB number and the primitive was always weird to me. This was grandfathered in by the first implementation of the flat placement file, which was not made by me.
| fileNameOpts->read_flat_place_file = options->read_flat_place_file; | ||
| fileNameOpts->write_flat_place_file = options->write_flat_place_file; | ||
| fileNameOpts->write_legalized_flat_place_file = options->write_legalized_flat_place_file; | ||
| fileNameOpts->flat_place_verbose = options->flat_place_verbose; |
There was a problem hiding this comment.
fileNameOpts is a weird place for this to exist; but I understand why you put it here. Is there anywhere better for this?
It is fine to keep it here (with the flat place file options), but I just thought I would ask.
| .help( | ||
| "Appends a site_path column to written flat placement files: the hierarchical path of the primitive each atom was placed on within its cluster.") | ||
| .default_value("off") | ||
| .show_in(argparse::ShowIn::HELP_ONLY); |
There was a problem hiding this comment.
See comment above about making this an integer instead of a bool.
| fprintf(fp, "# <atom_name> <x> <y> <layer> <atom_sub_tile> #<clb_blk_id> <atom_pb_type> <site_path>\n"); | ||
| } else { | ||
| fprintf(fp, "# <atom_name> <x> <y> <layer> <atom_sub_tile> #<clb_blk_id> <atom_pb_type>\n"); | ||
| } |
There was a problem hiding this comment.
This can be written slightly cleaner (and easier) by printing the common part first, then the uncommon part in an if, and then print the \n. A bit of a nit, but will make it easier to extend in the future if we want to add more.
…rilog-to-routing into amohaghegh/flat-place-site-path
Replace the boolean --flat_place_verbose with --flat_place_verbosity, an
integer scale matching the other *_verbosity options. Everything written
past the sub-tile column is informational only, since the flat placement
reader ignores it, so one knob now controls how much of it is emitted:
0: no annotation and no header comments, i.e. only the columns the
reader parses. The output is then exactly the documented input
format and carries no build timestamp, so it is reproducible.
1: header comments, plus the cluster block id and primitive type.
2: additionally the site_path of each atom.
The default of 1 keeps the written file unchanged.
Adds
--flat_place_verbosity, an integer scale (default1) controlling how much annotation is written into flat placement files by--write_flat_place/--write_legalized_flat_place. Everything past the<atom_sub_tile>column is informational only — the flat placement reader ignores it — so one knob covers all of it:0writes no annotation and no header comments, leaving exactly the documented input format with no build timestamp (so the output round-trips through--read_flat_placeand is reproducible across runs);1is today's output, the header comments plus each atom's cluster block id and primitive type;2additionally appendssite_path, the hierarchical path of the primitive the atom was placed on within its cluster, e.g.clb[0][default]/lab[0][default]/fle[3][n1_lut6]/ble6[0][default]/lut6[0]. The default of1leaves written files unchanged. This is the first piece of a larger relative-placement-constraints feature; follow-up PRs will use the recorded site paths to constrain packing.