Matt Liberty
Matt Liberty
Your idea wouldn't be hard to implement. You could manually tie it off with a sky130_fd_sc_hd__conb of a known name in the verilog. Later you can just script an opendb...
What about a cell type that lvs usually ignores like decap? I'm not enough of an LVS expert to know how to work around that.
@rtimothyedwards any thoughts on an LVS workaround?
@osamahammad21 not urgent as Anton notes but good for a background task.
@antonblanchard what did you mean by "openroad -tech" and "openroad -library"? The openroad executable does not take those command line options? In general ORFS does load in two steps: read_lef...
@antonblanchard if you do ``` read_lef -tech -library sky130_fd_sc_hd.tlef read_lef -library sky130_fd_sc_hd_merged.lef ``` it works as does: ``` read_lef sky130_fd_sc_hd.tlef read_lef sky130_fd_sc_hd_merged.lef ``` only ``` read_lef -tech sky130_fd_sc_hd.tlef read_lef -library...
odb doesn't have any locking around modifications so you would have to be very careful to avoid the GUI accessing data while an algorithm is writing it.
I think a small white list of operations we want to support is the most tractable thing to define/implement. Do you have key operations you want to perform? @arlpetergadfort for...
I think the best you can hope for is to see the data as it was before the command was started. Trying to update as it goes will be slow...
The GUI may query sta while it is running which would not be safe even in this case (eg displaying clock nets, power heat map, etc). Even in that scenario...