-
Notifications
You must be signed in to change notification settings - Fork 436
Description
I think there are two use-cases, or concerns, that should be clearly separated: development of ORFS/OpenROAD and usage of OpenROAD/ORFS.
For the end-user use-case(where I'm not an OpenROAD developer, but a user), I think LEC should be default off for out of ORFS tree designs: minimum dependencies, fast lean, optional(for architectural exploration I don't care about correctness of throwaway results). I trust OpenROAD and only need LEC as a last crossing of t's and dotting's of i's. I don't want to bog down day to day CI wasted compute or extra dependencies.
All the user can and should do with a LEC failure is to file a github issue and go about their business, crossing fingers that the problem is solved in OpenROAD or goes away as the RTL/build settings change, by the time the project is finished.
For the OpenROAD/ORFS development use-case, I have no strong opinions, I think OpenROAD/ORFS developers are the best to judge and I think that they should be free to do so without worrying about the user-experience.
For the user's use-case, I suggest an explicit invocation like make lec-floorplan/place/cts/grt/drt/final that checks previous stage against current stage.
make lec-final should probably do a LEC against drt as well as synthesis netlist following POLA.
Originally posted by @oharboe in #3908 (comment)