Design/display two die in "one" flow

[lustefan97]

Hello,

This question is kind of a follow up to #1235. I want to implement a flow allowing for 3D face-to-face IO bonding.

I work mostly in the gui, using TCL commands and already have something working using a .DEF file, and "splitting" the flow between the bottom and top die (where a full restart is needed in between them, but the IO pin position is obtained using the .def file).

In know now that there is a way to obtain the pin position using the DB interface, but from my understanding I can get them only if a design has already been loaded/designed previously. I tried to just (in a very dumb fashion) brute force my way into designing a top die by just running a full RTL-to-GDS flow on top of the "bottom die" design, to see what woud happen.
It caused OpenROAD to, unsurprisingly, crash when using the global placement command with that log :

Stack trace:
 0# 0x000056042E18AF7B in openroad
 1# 0x00007FDDC96B6520 in /lib/x86_64-linux-gnu/libc.so.6
 2# sta::Vertex::bfsInQueue(sta::BfsIndex) const in openroad
 3# sta::BfsIterator::enqueue(sta::Vertex*) in openroad
 4# 0x000056042E587AA8 in openroad
 5# sta::ClkNetwork::ensureClkNetwork() in openroad
 6# sta::dbSta::findClkNets() in openroad
 7# grt::GlobalRouter::initClockNets() in openroad
 8# grt::GlobalRouter::initNetlist() in openroad
 9# grt::GlobalRouter::initFastRoute(int, int) in openroad
10# grt::GlobalRouter::globalRoute(bool, bool, bool) in openroad
11# gpl::RouteBase::routability() in openroad
12# gpl::NesterovPlace::doNesterovPlace(int) in openroad
13# 0x000056042E2202E8 in openroad
14# TclNRRunCallbacks in /lib/x86_64-linux-gnu/libtcl8.6.so
15# 0x00007FDDCD54F028 in /lib/x86_64-linux-gnu/libtcl8.6.so
16# Tcl_EvalEx in /lib/x86_64-linux-gnu/libtcl8.6.so
17# Tcl_Eval in /lib/x86_64-linux-gnu/libtcl8.6.so
18# gui::TclCmdInputWidget::executeCommand(QString const&, bool, bool) in openroad
19# gui::CmdInputWidget::handleEnterKeyPress(QKeyEvent*) in openroad
20# gui::TclCmdInputWidget::keyPressEvent(QKeyEvent*) in openroad
21# QWidget::event(QEvent*) in /lib/x86_64-linux-gnu/libQt5Widgets.so.5
22# QFrame::event(QEvent*) in /lib/x86_64-linux-gnu/libQt5Widgets.so.5
23# QApplicationPrivate::notify_helper(QObject*, QEvent*) in /lib/x86_64-linux-gnu/libQt5Widgets.so.5
24# QApplication::notify(QObject*, QEvent*) in /lib/x86_64-linux-gnu/libQt5Widgets.so.5
25# QCoreApplication::notifyInternal2(QObject*, QEvent*) in /lib/x86_64-linux-gnu/libQt5Core.so.5
26# 0x00007FDDCAFB202F in /lib/x86_64-linux-gnu/libQt5Widgets.so.5
27# QApplicationPrivate::notify_helper(QObject*, QEvent*) in /lib/x86_64-linux-gnu/libQt5Widgets.so.5
28# QCoreApplication::notifyInternal2(QObject*, QEvent*) in /lib/x86_64-linux-gnu/libQt5Core.so.5
29# QGuiApplicationPrivate::processKeyEvent(QWindowSystemInterfacePrivate::KeyEvent*) in /lib/x86_64-linux-gnu/libQt5Gui.so.5
30# QWindowSystemInterface::sendWindowSystemEvents(QFlags<QEventLoop::ProcessEventsFlag>) in /lib/x86_64-linux-gnu/libQt5Gui.so.5
31# 0x00007FDDC5E6ED6E in /lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
32# g_main_context_dispatch in /lib/x86_64-linux-gnu/libglib-2.0.so.0
33# 0x00007FDDC8D516C8 in /lib/x86_64-linux-gnu/libglib-2.0.so.0
34# g_main_context_iteration in /lib/x86_64-linux-gnu/libglib-2.0.so.0
35# QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) in /lib/x86_64-linux-gnu/libQt5Core.so.5
36# QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) in /lib/x86_64-linux-gnu/libQt5Core.so.5
37# QCoreApplication::exec() in /lib/x86_64-linux-gnu/libQt5Core.so.5
38# gui::startGui(int&, char**, Tcl_Interp*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, bool) in openroad
39# ord::tclAppInit(Tcl_Interp*) in openroad
40# Tcl_MainEx in /lib/x86_64-linux-gnu/libtcl8.6.so
41# main in openroad
42# 0x00007FDDC969DD90 in /lib/x86_64-linux-gnu/libc.so.6
43# __libc_start_main in /lib/x86_64-linux-gnu/libc.so.6
44# _start in openroad
Segmentation fault 

My guess is that it is due to the fact that a previous design is already placed and OpenROAD doesn't expect to be asked to place something again on top of it since it is highly illegal.
I then started to search for a way to clear/clean/flush the bottom die design (except obviously for the IO pins), but unsuccessfully since the clean command is for the Makefile and just deletes intermediates design files and thus would not be useful for me. I also tried using ord::clear, but it again crashed the app (so I guess it is not as simple as "clear the database").

The flow that I have in mind would be :

1. Load bottom die design
2. Bottom die RTL-to-GDS flow
3. Save IO pins positions using DB interface
4. Clear bottom die design (except IO positions)
5. Load Top die design
6. Top die RTL-to-GDS flow
7. Verification

I would like for those steps to be executed without intermediate reset/intervention like I have right now, in a way that respects the "no-human-in-loop" philosophy of OpenROAD.

So my questions are :

1. Is it possible to clear a design (floorplanning, placement, routing) while keeping select data (for example in a variable) in OpenROAD, to load and implement another one immediately after ?
2. Is there a way to display two dies at the same time in the GUI ? I would like to see the bottom and top die either side to side, or on top of one another (which would also help for verification)

[rovinski]

I think your best bet is to save the pin locations to some sort of file or script and then use that file to set the pin locations in both the top and bottom dies.

Note that there is some work ongoing to make OpenROAD more 3D-capable, but no firm targets on that yet.

[maliberty]

There is no way to unload the design in the current OR. You are better off structuring this as multiple runs. Note that we recently added [-write_pin_placement file_name] to place_pins so it is easy to save their locations for replay (see https://github.com/The-OpenROAD-Project/OpenROAD/tree/master/src/ppl#place-all-pins)

As we get more 3d support in the tool this will become easier.