In case of three globals (one M1 terminal) and no south global, the generated topology was wrong. We were accessing the terminal directly with a vertical segment. It was creating a layer gap between that vertical, which is M3 and and terminal in M1. This is also too rigid a configuration.
Fix: add an horizontal, in M2, to access the terminal.
Occured on benchs/RISC-V/Minerva/sky130_c4m/.
Instead of detecting the size characteristics of a RoutingPad at a late stage when calling NetBuilder::_doRp_Access(), do it once when first loading the net in Dijkstra::load() with Configuration::selectRpcomponent().
Add a new flag attribute on RoutingPad in order to store various additionnal informations. Currently, the size characteristics.
Add an M1Offgrid flags for the terminal characteristics set.
Move getPositions() and checkRoutingPadSize() from NetBuilder to Anabatic::Configuration().
In Anabatic::Configuration, add support for the M1Offgrid options, that allows fully offgrid terminals.
The Anabatic::Configuration::checkRoutingpadSize() now store the characteristics of the terminal (HSmall, VSmall, ...) directly in the flags of the RoutingPad.
For the whole function stack, work directly on RoutingPad instead of Component* :
Add a PinRectilinearFilter to the LefImport parser in order to select on which kind of biggest rectangle extracted from the Rectilinear we want to create the Vertical or Horizontal only external component. We can choose betwen the tallest, widest or largest (area). There is also a minimum size filtering (to prune too small rectangle from the start).
Make use of the new feature in gf180mcu/mcu9t5v0.py.
To avoid re-computing informations about the RoutingPad, namely it's size characteristics (h-small, v-small, punctual, offgrid), add a flag attribute in order to store those informations. They are computed in Anabatic::Configuration::selectRpComponent().
Dragging can occurs when an AutoContactTerminal is anchored on an horizontal RoutingPad and the opposite of the connecting segment is also horizontal. In that case, the connecting segment, which is perpandicular can be dragged over the RoutingPad as to minimize the length of the opposite horizontal.
This feature was until now, only implemenred for verticals.
The _sourcePosition and _targetPosition of AutoHorizontal or AutoVertical have slighty different meanings whether the segment is in preferred routing direction or not.
The figure below is a simplificated description on how AutoSegment::getExtensionCap() compute the extension from the sourceU coordinate. sourceU being the starting or ending coordinate of segment, usually the axis of the perpandicular it is connected to.
In order to ease testing whithout constantly changing the configuration file, provide a boolean in technos.setupGF180MCU_GF() to select it.
In the dodo.py, add:
setupGF180MCU_GF( checkToolkit='../../..', pdkTop='../../../../gf180mcu-pdk', useHV=False )
This ratio is an attempt at characterizing the hardness of a design (very elusive concept). It is crudely done for now, as it is just a ratio between the initial number of events (which is equal to the number of TrackElements to place). It do not take into account the dogleg creation process that will introduce more primary events as the net topologie are slackened.
The positions of the windows and some of the settings of the controller can be saved and restored. The saving does not occurs at the closing of the application. You have to take a snapshot of the state using the File -> Save settings menu. This allow to restart the application in an initial state of your choosing and not at point you left it the last time it was run.
Widgets supporting the saving of their configuration gets two more methods:
MyWidget::saveQtSettings(); MyWidget::readQtSettings();
Currently we are saving: