|
The NetTrace server works in conjunction with the QIS server and both are expected to share the same CPU and memory pool. NetTrace and QIS communicate between each other using a TCP/IP socket for commands and acknowledgements and shared memory for holding "vector" data.
The "client" communicates with NetTrace via a TCP/IP socket and a small set of commands which are described in the API section.
Typical Net Tracing Flow
|
Start Up QIS/NetTrace
|
The NetTrace server should be started and connected to QIS before a viewing client connects to QIS. In case, when QIS is connected to multiple clients (i.e a viewer and NetTrace) QIS gives preference to the commands issued by the "primary" client. It will serve the second client only if there is no pending request from first client connected.
(Mayur, this does not seem reasonable to me. Let's talk about why you recommend this ...)
|
|
GDSII or OASIS File is opened (using QIS)
|
Since NetTrace gets its data from QIS the client must start first by opening the file and displaying it to the user.
|
|
User zooms in to the point where he can accurately select a point on a conductor.
|
From a full chip view, it is generally not possible to accurately place the cursor over a conductor (except for possibly die pads or wide power/ground traces)
|
|
Set NetTrace Preferences
|
There are quite a few potential preferences that control the way the net is traced. Not all of these are necessarily appropriate for the end user to adjust. However the client may wish to provide a dialog window that shows the current prefence values and allows the user to change them.
Preferences are "sent" to the NetTrace server using the Ntrc_Set_Preferences command.
|
|
Build and upload Technology File
|
The client part of the viewer/needs to provide the user a way to "build" the stackup of conductor and via layers. The user should be able to assign from the available GDSII layers to M1,V12,M2,V32 and so on.
Once the technology file is created it needs to be transferred to the NetTrace Server using the Ntrc_Set_Tech_Stackup command.
|
|
Select Starting Point
|
The selection of the starting point (also known as the "seed" is completely a client function. The user needs to select a point some where inside of a conductor on one of the stackup layers. The client may wish to offer feedback (i.e. highlighting the conductor selected ...)
Once the starting point for the net has been selected, the client then uses the Ntrc_Start command which tells NetTrace to start a net trace and passes it the coordinate/layer starting point.
Upon receiving a Ntrc_Start command, the NetTrace server will beging returning boundary data which are outlines of conductors that belong to the net being traced.
|
|
Display Net Data
|
Boundary data will be sent fairly continuously by NetTrace server and the client must process this data and use it in some fashion to highlight the net. Generally it is assumed that the user was viewing a portion of the IC layout when the net trace began and that certain conductors, which are part of the net, need to be highlighted. It is completely up to the client as to how to highlight the net - whether to draw over the current display, to use an alpha channel to fade out the non highlighted regions, to change colors and so on. A difficulty faced by the client developer is that the best way to highlight a net may depend on the current display view - i.e. when viewing the full chip highlighting may have to be exagerated to be visible, but when zoomed in tightly the highlighting should be more subtle so as not to obscure the underlying display.
The client should store the boundary data received from NetTrace in a local cache since any display change will require a re-rendering to properly maintain highlight of the net.
It is possible, and expected, that the user may wish to pan and zoom while a net trace is underway in order to "follow" the tracing of the net as it leaves his display window. This can be accomplished by sending the appropriate window to QIS and requesting an image (or get_vector) to update the client display.
|
|
Pausing a Trace
|
During the trace, the server can be paused using the Ntrc_Pause command.
The server does not respond immediately; it will complete the analysis of the current "window" and pause after boundaries for that window have been delivered to the client. This delay might be very short or potentially on a very large and complex chip could be quite long.
The client programmer may wish to inform the user that the pause has been sent but not yet acknowledged to avoid user frustration.
|
|
Resuming a Trace
|
A trace can be resumed after a pause using Ntrc_Resume. There is no need to resend any preferences, technology file or other data.
|
|
Stopping a Trace
|
During the trace, the server can be stopped using the Ntrc_Stop command.
The server does not respond immediately; it will complete the analysis of the current "window" and pause after boundaries for that window have been delivered to the client. This delay might be very short or potentially on a very large and complex chip could be quite long.
A stop is different than a pause: it is not possible to "resume" a stopped trace.
|
|
Exiting
|
When no more nets need be traced one can exit NetTrace Ntrc_Exit which causes the server to shut itself down.
|
|