Determining InstancePin direction
Brought to you by:
andrewgschmidt,
nsteiner
Menu
▾
▴
#67 Determining InstancePin direction
It would be convenient to provide a way to determine the direction of an InstancePin from the Instance itself. A todo in Instance.hpp refers to this. There are two ways this can be done currently without additional data structures.
-
Use DDB to find get the PinDirection. However, this requires a linked DDB instance and is made more difficult if a design has not yet been placed or even mapped.
-
For an InstancePin, look up the parent Net and then compare the pin to Net::sourcesBegin(). This works well when a net has a single source, but still requires going to the Net.
A possible solution might be to separate sources and sinks in the Instance as they are in the Net. This way a user can iterate over the desired type of pin and would simplify code that traverses physical netlists.
With respect to dependence on a DDB instance, any existing XDL instances must necessarily already be mapped. And even without placement info, we can use the site type to look up the corresponding PrimitiveDef.
It seems to me that if a DDB instance exists, it ought to be consulted, because the PrimitiveDef spells out the real device directionality of each pin, whereas the XDL net merely tells us what the user claims, and that only for the subset of pins that they are using. I could implement this by creating an Instance class in torc::architecture that would include the PrimitiveDef pointer. If non-zero, the code would get directionality from it, otherwise I would use the approach below. (And I'll note that availability of the PrimitiveDef pointer could be useful in many other ways for placers or routers, perhaps especially in the case of polymorphic sites.)
If no DDB instance exists, the Instance class could just use one additional map from pin name to pin direction, and update this map anytime it updated the InstancePin map. The cost would be a single additional map. Any thoughts?
I agree that most of the time there is a correspondance between XDL instances and DDB sites, but at one point, I recall discussion of having unpacking code that would transform a physical netlist from sites into bels or perhaps some other intermediate form, but still using the physical netlist container. Such an approach would no longer have instances that represent sites in the DDB instance. Unpacked code would also probably benefit from making it easier to traverse the netlist in whatever form it takes.
I agree that using a DDB instance would work well and that having a PrimitiveDef pointer could be very useful for other tools. If tighter integration is the long term goal, it seems that such integration should include things like pips stored as architecture::Arc, eliminating the need for string representations in the physical netlist if a DDB is expected to exist.
While I like the idea of tighter integration, I think it should still be optional since the separation between physical and architecture allows a user to pick and choose what they need for a particular task. Maybe there is room for a new type of physical netlist, on that is built with as much architecture information as possible allowing for a very compact binary representation for embedded applications.
The approach of adding a map from pin name to direction would certainly provide the information, however I would argue that an approach that more closely mirrors the Net, allowing iteration over source or sink InstancePins, would make using the direction information easier for users. That would require only a single additional map as well.
The following steps slightly away from the issue at hand:
Also in the realm of making the API easier to use, I think that the InstancePin would benefit from a member function perhaps called "getNetPtr" that leverages the Progeny::getParentWeakPtr function. A new user might have difficulty figuring out how to access the Net connected to a given InstancePin whereas it is obvious how to get the Instance with getInstancePtr.
Going one step further, functions that have the same flavor as DDB::expand... functions might be useful in physical as well. These might look something like: