Floor Planning Lab

IO and Block Floor Planning
Lab Exercises
I/O and Block Floor Planning Lab Exercises
April 24, 2006 Page 1
IBM EDA Education - Do Not Copy
Table Of Contents
Page 91 Compiling our own Abstract Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Page 90 Custom Compiling an Abstract Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Page 89 Loading DSL and IOSpecLIst in Native ChipBench . . . . . . . . . . . . . . . . . . . . .
Page 88 Loading DSL and IOSpeclistin Native ChipBench . . . . . . . . . . . . . . . . . . . . . . .
Page 82 Data Specification for ChipBench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Page 81 Loading without a Net Listin Native ChipBench . . . . . . . . . . . . . . . . . . . . . . . .
Page 80 ----------------- Appendix ---------------- . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Page 78 Detailing the Area Plan for Placement . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Page 74 Floorplanning with a netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Page 73 NetList Floorplanning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Page 70 Making the terminal display more informative. . . . . . . . . . . . . . . . . . . . . . . . .
Page 64 IO Constraints for IO Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Page 59 Creating an Initial Area Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Page 56 Simple Model for a Black Box Macro . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Page 54 Preparing the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Page 53 IO FloorPlan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Page 50 Flattening CHIPTOP to 1 macro level of hierarchy . . . . . . . . . . . . . . . . . . . . . .
Page 49 Selective Design Flatteningin ChipBench . . . . . . . . . . . . . . . . . . . . . . . . . . .
Page 48 Working with a Netlist based Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Page 47 Loading a Netlist Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Page 39 The Hierarchy Planner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Page 38 Hierarchy Planner Lab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Page 28 Running Early Floorplanning with DSL I/Os . . . . . . . . . . . . . . . . . . . . . . . . .
Page 27 Loading a DSL model description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Page 26 Early FloorPlanning w/DSL IOs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Page 25 Creating DSL from a block diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Page 24 Block Diagram for CHIPTOP Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Page 23 Introduction to our Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Page 10 Loading with an Empty Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Page 9 Loading with an Empty Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Page 6 Setup theGuide for the Class Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Page 5 Configure theGuide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Page 4 Manual Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Page 3 Student Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Page 1 IO and Block Floor Planning Lab Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . .
Student Notes
Manual Conventions
The following conventions are used in this document. Please be
sure to read and understand these conventions to prevent errors
during the lab exercises.
The standard UNIX text editor "vi" is specified in the lab manual.
You may use any editor you prefer. In the Common Desktop
Environment, dtpad is available. On the IBM Internet, the ve (pc
like) editor is available.
vi
Indicates that the string should be replaced by a value. Consult
your instructor if you are not sure of a value. For example, if my
userid is "student10" and the lab said:
cd /afs/eda/u/<userid>/etc
I would type in:
cd /afs/eda/u/student10/etc
<string>
Indicates a torn off drop down menu, for instance:
Selection>>Pre-Select::Ports
>>
Indicates a menu section qualifier for otherwise ambiguous
selections, for instance:
Selection//Balloon Help::Cells
::
Indicates a series of drop-down menu selections from a menu bar
or pop-up menu. An example would be:
Constraints//Fix//Self Location
//
Select an icon from the window icon bar:
pZoom In
p
Select an item from a tree view:
All Settings//PowerType//VDD2
Select an item from the window menu bar using the mouse:
File//Save//Vim...
Text following this symbol indicates the action menu item to

select using the right mouse button:
Edit//Move
Text following this symbol should be entered on the Tcl command

line on the ChipBench nutgui window.
=
Text following this symbol should be entered on an xterm window
command line on the server running ChipBench.
Used to indicate a series of selections on a ChipBench dialog.

These are considered part of a numbered step.
Identifies a procedure heading. Immediately following each

procedure heading will be a short explanation of what is to be
done. The steps to be performed are each numbered and follow
the explanation. Only numbered steps are to be performed.

Configure theGuide
Setup theGuide for the Class Example
We will use theGuide to process our part thru the floorplanning methodology.
Starting an xterm on the compute server
It is important to run the design tools in this class on the class compute server and
not the display server due to memory requirements.
1. To start an xterm on the compute server, right click on the gray background of
your Citrix window and select:
Open Window on Compute Server
Be sure to run all your commands and applications beginning from this window.
Basic Setup
We will perform the basic setup for theGuide. We will force theGuide to start without
a project file so you get a chance to build a new project from scratch.
1. From the student home directory:
./bin/theguide -gui -no_project -features cu08/* tk* &
The -features option tells the guide to load only the cu08 and toolkit
components. This prevents loading by default support for technologies that we
are not using.
1. Press OK to confirm it was okay to start without a project file.
2. From theGuide menu bar:
File//New Project
3. Press OK on the new project information dialog.
4. In the methodoloogy advisor display, expand the item:
` First Time User StartUp methodology
5. Expand the item:
` Select Technology and Version
6. Follow the listed directions by selecting from theGuide menu bar:
Setup//Technology//cu08//7.0
Note: The above technology version (7.0) may be different in later toolkits. Ask
your instructor for guidance if there is more than one selection available.
7. In the methodology advisor display, expand the item:
` (Optional) Load Design Specific Data from ChipBench parms file
8. From theGuide menu bar, select:
Setup//Load ChipBench Parms
9. Select the StartingDSL.parms file.
10. Press OPEN to confirm the selection.
11. Skip the Load Design Specific Data from ASOC Project File step.
12. On the methodology advisor dialog, expand the Enter Design Specific Data
flow option.
13. From theGuide menu bar, select:
Setup//Design
14. On the General tab in the Design Setup dialog, enter:
Project Name as chiptop
Set the Working Directory to <student home directory>/work
Set the Design Vim Type to VIME (PHYSCELL)
15. Click on the Operating Conditions tab of the Design Setup dialog.
The values for the technology have already been set to the defaults.
16. Click on the Design Specific Data tab on the Design Setup dialog.
Note that many of the values have been instantiated from the values in the
ChipBench parms file we read in earlier.
17. Enter the name of the IOSpecList file by:
Clicking the File icon to the right of the IOSpeclist File field.
In the left hand column, double click on the sub-directory usercntl
In the right hand column, select the file:
chiptop.iospec
Press OK
18. Enter the name of the DesignSpecList file by:
Clicking the File icon to the right of the DesignSpecList File field.
In the left hand column, double click on the sub-directory dsl
In the right hand column, select the file:
CHIPTOP_top_level_dsl.tcl
Press OK
19. Change the the Image Type to c4
20. Click on the Timing tab of the Design Setup dialog
21. Change the hierarchical divider character to /
22. Switch to the Assertions sub-tab of the Timing tab
You will note that the assertion files have been filled in from the ChipBench
parms file we loaded earlier.
23. Switch to the PLL sub-tab of the Timing tab
Leave the PLL count set to 0, we have an early netlist.
24. Switch to the Parasitic Files sub-tab of the Timing tab
We will let ChipBench calculate all parasitics dynamically so we will not enter
anything on this page for now. Any parasitic read in from this dialog will be
static, i.e., ChipBench will not recalculate a value for the parasitic even as the
design changes. Reading in parasitics should be used with caution.
25. Switch to the Advanced sub-tab of the Timing tab
We will leave the default values in place for our lab exercise.
26. Click on the Overrides tab on the Design Setup dialog.
We will not enter any overrides or underrides for our design.
27. Click OK on the Design Setup dialog to confirm our choices.
28. On the Create Sandbox window set the following values:
New Type = Sandbox
New Sandbox Name = chiptop_init
Transformation Template = standard
Initial Data = Create Empty Root Node
GUI Parameter Set = New Set Name = chiptop
29. Press OK to confirm your selections.
30. The Data Organizer Setup window will automatically appear.
31. Select the folder icon to the right of the VIMIN entry.
32. Select the folder icon at the bottom of the dialog.
33. On the resulting dialog, in the right hand column, select the VIM called
StartingNoData.
34. Press OK twice to back out of the file selection dialog
35. Press OK to confirm your Data Organizer setup.
36. On the Save Changes confirmation dialog, press OK.
This saves our choices to the CHIPTOP.proj project file. We are ready to begin
using some tools to floorplan under theGuide.
Loading with an Empty Netlist
Loading with an Empty Netlist
We will load our design into chipbench in two phases. In the first phase we will load the
physical parameters of the chip image and package. In the second phase we will load
our logic representation by reading in a DSL file The DSL file allows us to model
architecturally significant blocks in our design.
Invoking ChipBench
This procedure will start ChipBench bringing up the ChipBench nutgui window and a
separate console window to display messages from the applications.
1. Expand theGuide item
` Process Design
2. Expand the Guide item:
` Run Tools or functions from Methodology Advisor
3. From theGuide menu bar, select
` Methodologies//IO and Block Planning (Beta)
4. Using the right mouse button, select and execute:
` Configure Methodology//Execute//with GUI
5. On the IO and Block Planning Configuration menu, set the following values:
On the Tool Tab:
For IO Style, select the file button to the right of the field and select:
AreaArray.
For Image, select the file button to the right of the field and select:
generic.
For Design Source, select the file button to the right of the field and select:
IOSpecList.
For Design SpecList, move your mouse over the Design Spec List input field
which is prefilled with a Guide variable.
Hover your mouse over the field and in the resulting information bubble, you
should see the variable evaluates to:
<student home>/dsl/CHIPTOP_top_level_dsl.tcl
On the Design Setup Tab:
Nothing needs to be specified on this page.
6. Make sure the action is set to launch and press OK to run the step.
You should now have a yellow checkmark indicating completion of the step.
The following diagram shows the methodology fully expanded as displayed
under the guide.
7. Select and execute:
` Create IO SpecList//Execute//with GUI
This step creates a header for the IO SpecList file that we will use later in the
process. This header contains keywords based on the image and technology
which we have already selected.
8. On the dialog for Create IO Speclist Tool tab, move your cursor over the set the
IO SpecList name and pause for the bubble information to pop up. You should
see that the variable evaluates to:
<student home directory>/usercntl/chiptop.iospec
9. Press the Launch editor button.
View the IO Speclist we loaded, DO NOT MAKE ANY CHANGES.
Do not perform any steps in the following description. I have already
performed the actions for the purposes of time. The IO Speclist you are seeing
is the result of the following actions.
I have provided you with the complete IOSpeclist required for the lab. During
normal operation, you would only have gotten the portion of the file about the #
Port declarations comment created. Creation of the port declarations
themselves are a user task at this time. If you already have a vim specifying
these ports available, the following series of actions in a ChipBench session can
add the ports specified in the vim to the IOSpeclist file for you.
# read in any existing IO Speclist data
> iospec::read_io_speclist -file $env(HOME)/usercntl/chiptop.iospeclist
# add any ports specified in vim that are not present in iospeclist
> chb::update_io_speclist -merge_missing_ports
# Write out updated speclist to a file
> iospec::write_io_speclist -file \
/afs/btv/data/eda007/chip/u6200/fp2/usercntl/chiptop_out.iosp
10. Press PF3 to quit the IOSpec edit session without saving any changes
11. Press OK to complete the step
12. The Create IO SpecList step on the Methodology Advisor should now be
checked.
13. Select and execute:
` Create VIM//Execute//with GUI
14. Uncheck the option for Top Level Insertion Parm File
15. Press OK to continue.
Notice that the chipbench console window appears first.
This window will contain messages about what ChipBench is doing.
dark blue text (theGuide) green text (native ChipBench) Tcl Commands
Displayed as red text, with an (S) in the message. Severe Errors
Displayed as red text, with a (E) in the message Errors
Displayed as yellow text, with a (W) in the message Warnings
black text (theGuide) dark blue text (native ChipBench) Informational
Clicking on the Errors or Warnings icon in the ChipBench console icon bar will
now display a seperate window showing only errors or warnings. Clicking on an
error or warning in this seperate window will move the view screen of the
ChipBench console window to the location in the log where that error or warning
occured.
16. The ChipBench nutgui window and a Top Level Insertion dialog are now
displayed.
17. Press Cancel on the Top Level Insertion window to close the dialog.
We have now started a ChipBench session under theGuide IO & Block
Planning methodology flow and have initialized the design image without
actually loading a netlist. We will load a DSL file to build our design model in a
few minutes.
Note: The next lab exercise experiments with what we can see with only image
data loaded. There are no actual design actions. If you have previously done
this next exercise, you can skip ahead to the section PreNetList DSL.
What you can see w/o a netlist loaded
Although we do not have a netlist loaded, we can still inspect many aspects of our
design. Anything physically related to our chosen chip image and package should
be viewable.
1. Raise the ChipBench main window to the top of your display by clicking on its
border.
2. Open a Graphic Window from the ChipBench main window icon bar.
pGraphic Win
3. From the Graphic Window menu bar, select:
Visuals//-----------
4. Move the Visuals Tear-off menu to a convenient locations on the display.
Note: The GW1 in the motif window title indicates that this tear off is associated
with Graphics Window 1. This allows you to determine which Graphic Window will
be affected when more than one Graphic Window is open.
5. From the Visuals Tear-off menu, select:
Terminal Visibility (Image)
You should now be able to see the terminal pattern on the back of the image.
Blockage Visibility (Image)
You should now be able to see blockage at the image level.
7. From the Graphic Window icon bar, Mag in to a corner of the chip and be sure
to include at least a few terminals.
You should be able to see the blockage shapes in the chip corners. You should
also be able to see blockage associated with the terminals.
Circuit Row Visibility
You should now be able to see circuit rows on the design and now they truncate
at the corner of the chip due to the blockage.
Note: In the previous picture, you can see rows of white circles running across
the design. These indicate the legal placement locations (circuit rows) for
circuits which are constraned to be placed on the IO cell placement grid defined
in the technology PDL.
9. Turn off the circuit row visibility using the above switch again (Its a toggle)
PST Visibility (Image)
1. Now Max out to view the entire chip.
You should now see the predefined PSTs in the image.
2. Now select
Package Pin Visibility
3. From the Graphic Window icon bar, select:
pMax
You should now see the package pins on the chosen package in physical
relationship to the chip.
4. From the Graphic Window menu bar, select:
Selection//-------------
5. Reposition the Selection Tear-off Menu
6. Turn on both:
Terminals
Show Names::Terminals
7. From the Icon Bar, turn on:
pFamily Highlight
By the way, a yellow sun appears over the family in family highlight whenever
this mode is active.
8. Now select a terminal or package pin.
A fly-line will appear to show the connection between the selected item and its
counterpart as shown in the previous screen shot. The Show Names selection
also causes the bubble information for the terminal to appear.
9. Select a terminal on the chip.
10. Press Mouse Button 3 and on the terminal action menu, select:
Windows//Attribute
You will get an attribute window showing physical and electrical attributes for
the selected terminal as well as the technology restrictions on its usage.
11. Change the selected terminal
The terminal attribute window will update with the values for the newly selected
terminal.
12. Select the Selection tear off menu and press Escape to close it.
13. Press Max to restore the view of the chip in the Graphic Window
You can also view voltage regions in the Graphic Window with only the image
data loaded. To turn on a voltage region:
14. Scroll to the bottom of the hotlist on the right hand side of the Graphic Window
(Cu08 has many available and somewhat specialized voltage regions).
15. Turn on the voltage regions (supplies) for one of the available HSS locations by
clicking mouse button 3 over:
HSS6AVTR
HSS6AVTT
16. Now press the refresh key (circular arrow) at the top of the hotlist and the HSS
position 6 regions will appear.
17. Turn on the voltage regions (supplies) for one of the available PLL locations by
clicking mouse button 3 over:
PLL1AGND
PLL1AVDD
PLL1AVDD2
18. Now press the refresh key (circular arrow) at the top of the hotlist and the PLL
position 1 regions will appear.
19. Turn on one the voltage regions by pressing mouse button 3 while over each
voltage region matching volt_reg_VDD# where # is a value from 2 to 9 for our
image.
volt_reg_VDD2
20. Then click the refresh icon at the upper left corner of the hotlist to force the
display to redraw.
Feel free to turn on and off the images voltage regions so you can understand
the voltage region layout.
The chb::change_voltage_domain command allows switching second supply
power C4s to a different supply. This may only be used if the generic image
switch was set at chipinit time.
You can also look at existing power structures in the design. The following
screen shot shows the M7 power and M8 PST power structures on our design.
21. Now turn off the voltage regions by pressing mouse button 3 while over each of
the entries you have turned on. Each entries text should grey out as you turn
off the display.
22. Then click the refresh icon for the display to redraw.
23. Make sure to turn off the following visibility's on the Visuals tear off menu:
Blockage Visibility (Image)
PST Visibility (Image)
Package Pin Visibility
Circuit Row Visibility
24. Press Escape to close the Visibility Tear off menu.
Introduction to our Design
The Design Spec List (DSL) language can used to create a
model of the design based on early architectural descriptions of
the design at varying levels of complexity. In addition
ChipBench can create an abstracted model of a real netlist to
use for post netlist floorplanning. I have used this second path
to construct the example DSL for our design lab.
Block Diagram for CHIPTOP Design
BLKBOX
SM0
SM1
RU1 RU2 RU4 RU3
Two 32-bit Data In Busses
8-bit cmd bus
64-bit DATAOUT
(Bidi with DATAIN)
LOG_BLK
DO_MUX
Data Out (32)
Data Out (32)
Data In (32), CMD (8), ADDRESS (8)
BLACKBOXOUT (1)
ADDRESS (8), CMD(8)
(All 64 bit busses)
SRAM_READ(64)
FAIL (1)
Creating DSL from a block diagram
Since we want to get an early look at our part, even prior to the availability of netlists,
we could construct a model of our design using the Design Spec List language to create
a high level connection map of the design. SInce DSL commands are really Tcl
commands, the power of the Tcl languge can be used to help create repetative design
structures, etc.
If you have a machine readable netlist description in some format that you can convert
and read into ChipBench, then you can use ChipBenchs abstracted netlist mechanism
to create a simplified model of the design for floorplanning purposes.
Creating DSL (read only)
For expediancy on our class part, I have recreated the block diagram previously shown
using:
= chb::compile_abstract_netlist
This command creates an abstracted netlist from the actual netlist by abstracting away
dust logic and creating representative connections to represent paths thru the
abstracted logic. This abstracted netlist was then written out in DSL format using:
= chb::write_abstract_netlist
This creates a DSL model of our design for all the architecturally significant elements
including IOs. Some change all commands were necessary to remove suffixes to cell
names to get them to match back to the real design later. Pseudo code editor
commands to achive this are:
change _CHIPTOP_VDEF <all occurances on all lines>
change _CHIPTOP_VUSG <all occurances on all lines>
Once we have DSL ready we can then proceed to load our generic image and load the
DSL into chipbench to perform some early floorplanning of our design.
Please use the DSL I have prepared for you as specified in the following lab.
We dont want to spend precious class time debugging typographic errors.
Thank you!
Early FloorPlanning w/DSL IOs
Loading a DSL model description
Running the Top Level Insertion Step
This step will allow us to load a DSL and IOSpecList file to build our design model.
1. Enter the following command on the ChipBench main window command line:
= chb::read_design_speclist -file $env(HOME)/dsl/CHIPTOP_top_level_dsl.tcl
2. Now load the physical data and attach it to the netlist created in memory from
the DSL.
= chb::prepare_physical_data
The following two steps are not actually run in our lab since this is our
first pass of the design but are here for documentation purposes.
Now read in the previous floorplan PDEF layout file if any exists:
= chb::read_pdef -file $env(HOME)/pdef3_pass1/CHIPTOP.pdef
Note that a dsl or vim netlist must be loaded before you can read in the PDEF
physical floorplan data. Also you will need to read in a PDEF file for each
hierarchical cell (chip, rlm) in the design in order to load a complete floorplan.
The PDEF definition does not provide for any automatic hierarchical loading
capability.
Repeat the above step for each macro in the design substituting the macro DEF
name for the string CHIPTOP.
You can find the list of cells to be saved in the right hand pane of the
ChipBench main window. The names in the list are shown in the format
DefName:Instance Name. Enter only the DefName portion in the
chb::read_pdef command.
For more information on the DSL language, see the DSL Command Reference
Manual.
Running Early Floorplanning with DSL I/Os
Assigning Terminals and Placing I/O Cells
1. Reselect the root cell.
2. Open a Graphic Window if one is not already open.
pGraphic WIndow
3. On the cell action menu select:
Interface//Chip IO Assignment//Driver Type Match...
4. On the Driver Type Match dialog, switch on:
Move Driver Cell
Note: All the constraints supported by Driver Type Match could be used at this
point including voltage regions, tethers and port areas. We have not set any up
in this lab exercise. We will do so in a subsequent lab You are free to use
these features on a DSL model of a design.
5. Press OK.
Early Floorplanning
In the following procedure we will use floorplan in stand alone mode.
1. Set the macro size estimates using the following pre-encoded tcl script:
= source SetDSLSizes
Nothing magic in this script. We just encoded reasonable estimates for the
macro sizes rather than having you hand instantiate each macro.
2. Look in $HOME/tcl/SetDSLSizes.tcl to see the declarations of macro size.
The following screen shot shows what you should be seeing in the Graphic
Window at this point in the design process.
Note the IO books clusted about the center of the design, placed directly on top
of their assigned terminals (note this is not yet legalized) and you can see the
RLMs we just sized shown in the lower left corner of the design.
3. With the Graphic Window open, select:
Placement//FloorPlan...
4. To run floorplan, select the following items:
FloorPlan switch on
Optimize switch on
Turn off Legalize
Consider Large Objects switch on
Honor Fixed Leaf Cells switch on
Ignore Voltage Regions switch off
5. Select the Options... button for Optimize
6. Set the Large Object Displacement Weight slider to 0
7. Set the Wire Length Weight to 3.
8. You can also try setting the cost of moving IO books to 5 rather than 1 as
shown in the graphic below. Ive found this gives me better results.
9. Press OK to accept the Optimize Options... settings
10. Move the floorplan dialog window off the top of the Graphic Window.
11. Press Apply.
If you watch the console output window, you can see the reporting on each
phase of the floorplanner iteration
12. View the placement.
We didnt legalize so there will be overlaps. The overlaps you are getting will be
excessively large with the macros in some cases basically center to center.
When the macros are overlapped tightly like this, it means they are relatively
highly connected. However, we have so many center to center overlaps here
we see that we need to raise the value for the overlap cost for floorplan.
We also see that the IO cells are wandering during the placement due to the
effects of the connected wires (we didnt fix them in position on this pass).
We could have raised the overlap weight on the first pass to reduce the number
of iterations at the expense of reducing the information available to help visually
interpret the density of connections. However legalizing on the first pass would
completely obscure any information contained in overlaps. It is recommended
that you do not immediately legalize on your first pass of floorplanning.
13. On the floorplan dialog, press the Option button next to Optimize.
14. Change the Overlap weight to 10.
This will reduce overlaps between macros in the next pass of floorplanning.
15. Turn on Refresh Placement.
This will allow you to watch the placement change interactively.
16. Press OK on the Option dialog
17. Press Apply on the Floorplan menu.
You should see a much better result this time. However you will see that the IO
books have definitely started to wander around the design.
Snap the IO Books back to their original assigned terminals
This action will cause the IO books to be snapped back to their original assigned
terminals regardless of overlap undoing any placement movement on the IO books
by the floorplanner.
1. On the cell action menu select:
Interface//Driver Type Match...
2. On the Driver Type Match dialog, switch on:
Move Driver Cell
This essentially gives priority to IO net length during the following legalization as you
are defining the placement position directly over the IO cells as the optimum position
to floorplan legalization in the following step.
Legalize the floorplan
In legalization we will
remove overlaps between macros and I/Os
legally place the macros on circuit rows
legally place I/Os on the IO placement grid
1. On the FloorPlan dialog, turn off Optimize and turn on Legalize.
We will not turn on any of the detailed options for legalization since this is an
extremely early floorplan and we dont need that level of detail yet.
2. Press OK to run FloorPlan and close the FloorPlan menu.
Optimize the IO wire length after Legalization
Since the wire lengths may have been damaged during legalizaiton, we can run
another IO assignment tool to see if we can make improvements. In the process this
tool will also check to see if all the IO resistances are in spec.
1. To make the IO nets visible during the next action do the following from the
action menu using mouse button 3:
Select//Ports
Select//Internal Net//All
2. On the Graphic Window menu bar, select:
Highlight//Highlight with Color
3. Select the color wheel
4. On the color menu, select Dark Orange.
5. Reselect the chip.
Now you can see the IO nets show in orange even when not selected.
Heres an example situation from my floorplan.
6. On the Graphic Window action menu, select:
Interface//Optimal I/O Assignment
7. On the Optimal I/O assign dialog, you can set:
Max Resistance Factor to 1
Switch on Ignore Voltage Regions
Vertical to 6
8. Press Apply
9. Check the console for resistance failures. Resistance failures will show up as
the entry in the console Total Ports Not Assigned being a value other than 0.
Heres the example shown above after Optimal IO processing.

If you can successfully assign IO below 1.00 Max Res. Factor, the difference is
a design margin available to you. If you cannot assign at or below 1.00 Max
Resistance factor you have IO issues to resolve. However for class purposes,
do not worry about fixing them if you see them, but on this class part you
probably will not find any resistance problems.
If there are no resistance failures try lowering the value of Max Resistance
Factor, say to 0.85. Keep lowering the resistance factors until you get some
failures. With the IO net highlighting on, it will be easy to see failed nets as
the unassigned ports will cause the IO flylines for unassigned nets to form a
star on the chip.
If there are resistance factors, slowly raise the resistance factor until there
are none.
Press Cancel to close the dialog when you have a good result
Note: If we had not run the chb::prepare_physical_data step earlier, the
resistance values necessary for this analysis and calculation would not have
been available.
Capture the placement data using PDEF
We can now use pdef format to save our design floorplan.
1. On the chipbench command line, create the output directory:
= mkdir $env(HOME)/pdef_plan_01
2. On the chipbench command line, now type:
= chb::write_pdef -directory $env(HOME)/pdef_plan_01 -def CHIPTOP -syn_1998
The PDEF information is useful for taking the current floorplan layout forward to
a new drop of the netlist
3. Note: Please double check the $env(HOME)/pdef_plan_01 directory to make
sure it now has data in it, we will be referencing this data later in the design
process. From the chipbench command line:
= ls $env(HOME)/pdef_plan_01
Save the VIM
1. On the ChipBench menu bar, select:
File//Save//Design....
2. On the Save Design dialog at the Directory field at the bottom of the page, press
the Select... Button.
3. Take note of the current Guide output node.
4. Press OK to save the design.
5. Exit ChipBench.
Hierarchy Planner Lab
Exercising the Hierarchy Planner within the Chip Bench
environment
The Hierarchy Planner
In this set of exercises we will use the hierarchy planner to manipulate our design.
Loading a design netlist
First we need to load the design netlist into a new ChipBench session
1. Close your previous ChipBench session if you have not already done so.
2. On theGuide menu bar, select:
Tools//ChipBench Via Socket//With Gui
3. On theGuide Gui panel for ChipBench, make sure the switch Load Design is
off.
4. Press OK to start a ChipBench session.
5. From the ChipBench main window menu bar:
File//Load//Specify Data...
6. Select Read Parms...
7. Select StartingData.parms in the rightmost list.
8. Press OK
The Netlist search path should now have a value. This time we are loading our
design and a netlist exists for it in VIM format.
9. Make sure the Design Type is set to Chip.
10. Click on Initialize Image and select Options....
11. Make sure a PDL Package File and Vim Chip Image are specified.
12. Under Options make sure Initialize Power is selected
13. Make sure Generic Image is selected
14. Press OK on the Initialize Image panel.
15. Press OK on the Design Specification window.
16. Confirm creation of the work directory.
Our design will take a minute or so to load.
Note: The design will appear to be empty, all cells are unplaced and the
unplaced cell visibility is off. thats okay, we dont need placement data to work
with the hierarchy planer.
17. On the ChipBench icon bar, select:
pLoad Library
18. Press OK to load the library to allow the hierarchy planner to count latches.
Creating some flat data
In our case, our design data is already pretty hierarchical so in order to build an
interesting test case for the hierarchy planner, we will flatten our design.
1. If a Graphic window is not open, open one now:
pGraphic Window
2. Make sure you have CHIPTOP selected from the Graphic Window menu bar by:
Window//Select Root Cell
3. Use the following command to flatten the entire design:
= chb::flatten_hierarchy -prefix_children_names -hierarchy_name hier_plan -to_leaf
You will get error messages about rule boxes and external views not loading.
This is normal for all the RLM objects since they do not have rules yet (they will
be constructed as part of the design process later).
You will also get warnings about physical data not being flattened. This is just
telling you that since the cells are not placed, the flattener cannot maintain their
relative position on the chip which is the default behavior with placed objects so
placement data is not lost.
This command does the following:
flattens the entire hierarchy (-to_leaf)
creates a new hierarchy structure in memory called hier_plan
(-hierarchy_name hier_plan)
Note: You can switch back and forth between our flattened design and the
original hierarchy at any time by selecting Hierarchy//Set Current.... on the cell
action menu for ChipTop. The original hierarchy is called ChipTop and the new
hierarchy is called hier_plan.
prefixes the names of promoted cells with the name of the parent cell they
were contained within (-prefix_children_names)
4. If you look in the console, you will see that ChipBench used a . as the
delimiter to separate names during the prefixing.
Using the Hierarchy planner
In this exercise we will open the hierarchy planner and explore our flattened design.
1. To ensure that you are looking at the hierarchy called hier_plan:
Hierarchy//Set Current...
2. Check that hier_plan is the selected hierarchy.
3. Press Cancel.
If you press OK, you will get an error since hier_plan should normally be the
active hierarchy if you have followed the base directions.
4. Now, on the ChipBench icon bar, select:
pHier Planner
5. On the Cluster Cells dialog, set the delimiter to the character ./ as shown above
6. Switch on the Ignore ISCAN* Nets to ignore the scan chains
7. Press OK.
The Bubble Gui
When the Cluster Cells action has completed, the bubble hierarchy display window
is opened.
1. To view the Connectivity View window, on the Hierarchy View windows menu bar,
double click on the desired bubble and the Connectivity View window will open
displaying that object.
First lets enlarge the text to make things a little easier to read.
2. From the Connectivity View window menu bar, select:
Edit//Preferences
3. On the bottom half of the window,
click on the Hierarchy View tab
set the text size to Large
click on the Connectivity View tab
set the text size to Large
4. Press OK
5. To switch focus back to the Hierarchy View window, on the Connectivity View
window menu bar, select:
Hierarchy View
Now lets explore some more information about the design.
6. Toggle back to the Hierarchy View
Notice the cursor in the above screen shot is pointing to the menu bar button to
toggle to the Connectivity View. This menu bar button will raise an existing
Connectivity View window to the top of the Z-stack making it visible.
Also note the list of information about each bubble in the right hand pane.
7. Click on the headers for each column in the right hand pane one at a time.
The list will be sorted based an the data in that column. The sort is always into
descending order. In the screen shot above, note that the Area column is
highlighted in yellow. This indicates that this is the current sort.
8. Click on the bubble LB in the left hand pane.
Note: Single clicking selects the bubble item. Double clicking will raise the
bubble view window and switch its viewing context to the selected bubble.
9. Raise the action menu by pressing the right mouse button and selecting:
Expand
Note that LB expands into its sub-component bubbles.
10. Sort the data right hand pane from the menu bar by selecting:
Area
Note that the area column is not completely in descending order. All the entries
at the top level of the hierarchy are in order and all the expanded entries under
LB are in order by Area. However the hierarchical structure is maintained and
all the expanded entries under LB remain together as a group in the sorted list.
They will move as a group with their parent LB as it moves in the sort order but
will remain nested under LB and sorted into descending order as a separate
subgroup
11. From the Hierarchy View menu bar, select:
Connectivity View
12. Now double click the top level.
You should be looking at the top level of the design as bubbles. Note that the
IOs and the CLKS bubbles are quite large. This is due to our testcase design
which does not contain a lot of user logic.
Right now each bubble only contains its name. Lets make the bubble display
more informative.
13. From the Connectivity View menu bar, select:
Display//Big Instances
The bubbles update with an entries that shows the number of big instances
contained in the bubble.
14. From the Connectivity View menu bar, select:
Display//Latches
You should now see the latch counts for each block in the Connectivity View.
This latch count is cumulative, it shows the total latches below that level of
hierarchy.
15. To see this cumulative counting at work, note the number of latches indicated
for the SM1 bubble (216), then double click the SM1 entry on the Hierarchy Views
navigator.
The Connectivity View dives in one level of bubble hierarchy. We now see the
sub-component bubbles under SM1.
16. On the Connectivity View, select the following:
Display//Latches
You will see the number of latches on the sub-components are:
SRAM0 = 0 latches
SRAM1 = 0 latches
BLOCK_LABEL = 192
CMD_DECODE = 24
BIST = 0
Total equals 216 as expected
17. On the Hierarchy View, double click the topmost - entry to return to the top level
on the Connectivity View.
18. If a Graphic Window is not open, on the ChipBench main window icon bar, select:
pGraphic Window
Creating an ordered placement for viewing purposes
For our next series of exercises it will help to have an ordered placement for the
design. This is an extremely crude placement since we have not correctly dealt with
IO assignment, etc. We will cover these issues elsewhere in the labs. Note that this
placement is not necessary for the work we are doing with the bubble view but rather
to illustrate the cooperative nature of the hierarchy planner and the Graphic Window.
1. Raise the cell action menu for ChipTop (RMB) and select:
Placement//CPlace
2. On the CPlace dialog,
turn on the Perform Global phase
turn off Perform Detailed phase
turn off Perform Legalization phase
Set the XFactor to 1.4
Steiner Estimation Mode
Ignore Clock Nets
Ignore Scan Pins
3. Press OK to run CPlace
4. Now back on the Connectivity View, left click over the IOs bubble to select the
bubble.
Cross Selection and HIghlighting with the Hierarchy planner
The Hierarchy planner and ChipBench use common highlighting and selection
functions.
1. Raise the bubble action menu using a right mouse click and select:
Cells//Select
Look at the Graphics Window. The cells we selected in the Connectivity View are
now selected in the Graphics WIndow as well.
This causes our previously selected cells to deselect and only ChipTop to be
selected once more.
3. On the Connectivity View, left click over the IOs bubble again.
4. Now from the bubble action menu select:
Cells//Highlight
The cells which are members of the IOs bubble are now highlighted on the
Graphics Window in the same color as the IOs bubble on the Connectivity View.
5. On the Connectivity View, left click over another bubble and highlight its
associated cells.
6. You can have multiple highlight colors displayed in the Graphic Window via the
Connectivity View highlighting mechanism.
We can now do the same with nets.
7. On the Connectivity View window, left click a bubble connection.
8. Raise the bubble net action menu and select:
Real Nets//Highlight
The nets will be highlighted in the Graphic Window using the same color used to
display the bubble connection in the Connectivity View.
Editing the Bubble Hierarchy
We can also edit the bubble hierarchy in the Hierarchy planner in addition to viewing
the bubble hierarchy. Lets dissolve the IOs bubble.
1. Left click the IOs bubble in the Connectivity View
2. Raise the bubble cell action menu and select:
Dissolve
The IOs group has now disappeared and in its place are 15 sub groups
containing related IO cells. For instance, note that there is a group called
IOs.COMMAND() which contains 8 Big Instances. This is a 8 bit IO bus for
commands that the hierarchy planner has clustered based on their related
names (only the strand names are different).
We can also merge components back together.
3. On the Hierarchy View, select IOs.PLL_TUNE.
4. On the Hierarchy View, multi-select (Cntl-LMB) PLL_RESET
5. Raise the bubble cell action menu and select:
Add
6. Enter a name (PLL_IOs) for the new bubble on the name dialog
7. Press OK
Now look at the Hierarchy View. You will see a new bubble called PLL_IOs in the
list.
8. Select the PLL_IOs bubble in the Hierarchy View
9. Double click the PLL_IOs bubble to expand it
Note that you can see the original IOs.PLL_TUNE and IOs.PLL_RESET as
sub-bubbles within PLL_IOs.
Moving Bubbles within the Hierarchy Planner
You can also create virtual layouts within the Hierarchy Planner
1. To move a cell:
left click a bubble to select the bubble to move
left click and hold while dragging the mouse to move the bubble
release the click when the bubble is in a better relative location.
Note that the bubble connections track the new location of the bubble
automatically.
You can also create groups of cells easily in the hierarchy planner.
2. On the Connectivity View menu bar, select:
File//Create Groups
3. Now on the ChipBench main window, raise the cell action menu and select:
Grouping //Group Lists//Cell Groups
4. You will see groups in the list beginning with the string bv_. These groups
correspond to the bubble structure that was in place when the Create Groups
action was run. Rerunning the command will rebuild the groups from scratch.
5. Exit out of chipbench.
Note: You will not need to save your data. We will start with a fresh copy for
our next experiment.
Loading a Netlist Design
Working with a Netlist based Design
In this design phase, we will assume we have gotten a netlist from our customer and we
want to take the floorplan we have developed so far and use it with the new, more
detailed netlist. For this pass of design we will use the default abstract netlist (Dust
Logic Aware abstraction) generated by the floorplan_flow script
Loading a design netlist
First we need to load the design netlist into a new ChipBench session
1. Close your previous ChipBench session if you have not already done so.
2. On theGuide menu bar, select:
Tools//ChipBench_Via_Socket//With Gui
3. On theGuide Gui panel for ChipBench, make sure the switch Load Design is
off.
4. Press OK to start a ChipBench session.
5. From the ChipBench main window menu bar:
6. Select Read Parms...
7. Select StartingData.parms in the rightmost list.
8. Press OK
The Netlist search path should now have a value. This time we are loading our
design and a netlist exists for it in VIM format.
9. Make sure the Design Type is set to Chip.
10. Click on Initialize Image and select Options....
11. Make sure a PDL Package File and Vim Chip Image are specified.
12. Under Options make sure only the following options are selected:
Initialize Power (Post-Invocation)
Generic Image
13. Press OK on the Initialize Image panel.
14. Press OK on the Design Specification window.
Our design will take a minute or so to load.
15. Now load the rules by doing:
File//Load Library...
16. Confirm the fields are filled in and press okay to load srules and ndrs.
Selective Design Flattening
in ChipBench
ASIC design guidelines require that incoming designs are either
flat (no hierarchy) or that the hierarchy is limited to 1 level of
macros (no nested macros). The logic design (an early netlist)
you have received for this design example does not meet that
criteria as shown in the hierarchy window below. In this section
we will flatten the design to 1 level of macros.
Flattening CHIPTOP to 1 macro level of hierarchy
CHIPTOPs hierarchy contains hierarchical structures that need to be flattened for
various reasons. Note that we could choose for floorplanning purposes to leave the
hierarchy deeper than 1 level, however a design that you are driving to completion must
have no more than 1 level of macros.
Our Flattening Strategy
The following is a list of cells and why they should be flattened. Please be sure you
also understand the reasons why these items are being flattened.
CLKS
The CLKS macro contains the clock distribution network for the design. This
clock distribution network needs to be spatially distributed across the entire chip
while one of the characteristics of a macro is that it constrains its contents to be
in a sub-region of the design. We will have to flatten CLKS to get a proper clock
tree network spread over the design.
SM0, SM1
These two macros will remain macros on the design but currently they are
multiple levels of hierarchy deep. We will flatten the contents of SM0 and SM1
so they only have leaf cells as children. Note that SM0 and SM1 are two
instances of the same macro. We will only really have to flatten the contents of
one instance since that will flatten both instantiations.
RU1, RU2, RU3, RU4
The RU# macros are four instances of the same logic. The RU# macros each
contain the logic driven by a single SCB in the original incoming logic. We are
going to eventually flatten these four macros to allow swapping of clock tree
connections between the various children of the macro. Hierarchy would
prevent this since cells on logically equivalent nets cannot be swapped across a
hierarchical boundary. However at the beginning of the design process, we will
flatten the internals of the RUs but keep the macro itself and treat it as a clock
domain to help us with our structured clock buffer placement and skew control
by limiting the size of the clock domain. Note that this is not a methodology
requirement but a design strategy we are employing with this design.
Flattening to one level of hierarchy
CHIPTOP will be flattened to a single level hierarchy using the strategy as outlined
above using the following TCL script. Please review the script and make sure you
understand what is happening. The hierarchy editing features of ChipBench can
also be accessed interactively from the cell action menu (Mouse Button 3) and the
following actions are available:
Hierarchy//Flatten
Hierarchy//Flatten Children...
Hierarchy//Create
The copy of the class example flattening script in the student directory
$HOME/tcl/AdjustHierarchy has more comments/output statements in it for your
reference.
chb::current_cell -root
puts "Flatten clock generator macro...."
chb::flatten_hierarchy -cell CLKS -no_create_move_bounds
puts "Flatten the contents of the RU's common DEF...."
chb::flatten_hierarchy -cell RU1 -prefix_children_names -to_leaf -no_create_move_bounds
puts "Flatten the contents of the LB macro...."
chb::flatten_hierarchy -cell LB -prefix_children_names -to_leaf -no_create_move_bounds
puts "Flatten the contents of SM0...."
chb::flatten_hierarchy -cell SM0 -prefix_children_names -to_leaf -no_create_move_bounds
puts " this also flattens SM1 since it is another instance of same cell!!!!"
puts "Flatten contents of DO_MUX"
chb::flatten_hierarchy -cell DO_MUX -prefix_children_names -to_leaf
-no_create_move_bounds
1. Open the Hierarchy Viewer window if one is not already open.
Windows//Hierarchy Viewer
2. On the Hierarchy Viewer window, click each box shape preceding a macro that
has a dot within it. Keeping doing this until all the filled box shapes have been
replaced by empty boxes.
For each macro expansion you will see a pop-up asking if you want to load
the data (internal netlist) for the macro you are expanding. Affirm each one.
You will not get a popup if the object has no internal netlist.
Note that you might see some delay while ChipBench processes this. Since we
had loaded the design in incremental mode as we expand the hierarchy tree,
additional net lists and physical definitions will be loaded.
The hierarchy view of the design is now fully expanded, you are looking at the
full representation of the design structure prior to flattening. Note that you
would not need to do this to run the command, this is for visualization purposes
only.
Note: In ChipBench 11.1 you will just be able to set Full Import in Model Import
Defaults to get this to happen during design load automatically
3. From the Hierarchy Viewer select CHIPTOP.
4. On the ChipBench nutgui window command input field, type:
= source AdjustHierarchy
When the script finishes running the CLKS macro has been completely
flattened out of the design. RU1 through RU4, LB, DO_MUX,SM0 and SM1 no
longer have any macro children, i.e., they are macros, not supermacros.
When you manipulate an object's hierarchy later in the design process
(flattening or creating hierarchy), you should retrace clock and scan nets after
the hierarchy change to be sure your clock and scannet group information
recorded in the vim is correct. We will not need to do this since we have not yet
traced our design.
IO FloorPlan
Preparing the Design
We will need to setup our voltage regions for the design and bring our previous floorplan
forward into the actual netlist. We also need to trace out the clock and scan structures
on the design so they can be ignored for early phases of floorplanning and placement.
The following procedure runs a script for tracing both clock and scan on the design and
already has the required parameters set for you. For more information on clock design,
see the EDA course ChipBench Clock and Tree Design.
Setting up our voltage regions
For most designs, additional voltages will have to be supplied to portions of the chip.
This is done via voltage regions. The following step from the IO and Block Planning
flow will run this action.
1. Find theGuide window with the IO and Block Planning methodology in it.
2. Select Define Voltage levels with mouse button 1
3. Press mouse button 3 to raise the action menu and select:
Execute//With Gui
4. On theGuide Gui for Define Voltage levels press Launch.
Since we started our chipbench session with the ChipBench_Via_Socket option,
theGuide will generate the script to set the Voltage Regions based on our
IOSpecList and send the script to the ChipBench tcl executor via the socket.
You can view this script by using the location specified for the executed script in
the ChipBench console output from theGuide action.
There is also a hand written script in $(env)HOME/tcl/SetVoltageRegions.tcl
which does essentially the same thing.
Bring our floorplan data forward
Now we will bring the placement and size data forward from the DSL floorplan.
1. Now load the placement from the previous floorplan session
= chb::read_pdef -file $env(HOME)/pdef_plan_01/CHIPTOP.pdef
You will get more warnings here about the dummy IO_BUS. Again this is okay
because the netlist has real I/O in it and the remainder of the process will use
the real I/O rather than our IO_BUS models.
At this point, you can read in each of the macro pdefs to get the macro sizes or
to shorten things for class, just run the following script to reload the sizes.
= source SetDSLSizes
Tracing the design using a script
1. Make sure CHIPTOP is the currently selected cell
2. On the ChipBench main windows command line, type:
= source TraceDesign
3. Review the console output for any problems.
Note: You will see the following problems which for the purpose of our lab have
no effect. The cause of the problem is shown in bold, with a sample message
following. Some of these messages will have multiple instances.
Normal operation in a hierarchical design
[CD-463]: (W) Net CE1_C_RAM in cell LB is driven by a hierarchy port and has multiple
sinks.
Optimization may cause the net to be split into multiple nets, replicating port
CE1_C_RAM on cell LB.
Because we didnt initialize the integrated timer, not necessary for trace
[ET-477]: (W) No calculator registered, NOPATH modeling applied for
PAD_ABIST_TST_CCLK.
We havent yet placed the contents of the RLMs.
[CD-469]: (W) Placement view does not exist for instance RU1.
Simple Model for a Black Box Macro
For this design, we will assume that we have a large macro in the design for which we
have not received the internal logic description. We have a CHIPTOP netlist which calls
out a black box macro and defines its inputs and outputs. Remember that ChipBench is
a four dimensional planner. We will specify values for (x,y,z,t) for our black box. For
this design we will assume that we have estimated the size of the object to be 1800
tracks wide and 3600 tracks tall. In addition, we will need four metal wiring layers to
route the internal circuits and set our timing assertions.
Setting up a black box macro for floorplanning
1. On the nutgui window, from the tree select:
CHIPTOP
Note on the nutgui window, CHIPTOP gets a blue background and a fine red
outline around the border of the blue background. The fine red outline means
the cells was selected by clicking on it in the nutgui window tree.
2. Bring up a Hierarchy Viewer window.
Windows//Hierarchy Viewer
3. Select the macro instance "BLK_BOX" from the list of hierarchical cells on the
Hierarchy Viewer window.
Note that after the selection in the Hierarchy Viewer, that CHIPTOP now has the
blue background in the nutgui window but no red outline is present. If no red
outline is present the tree in the nutgui window is providing you NO information
on what cell is selected or current. Note that the Hierarchy Viewer window does
not have this flaw. It will correctly track the selected cell(s) no matter the
method or how many cells. We highly recommend you use the Hierarchy Viewer
window anytime you need to use the window for feedback on selection.
Remember that the current size is the standard initial guess provided by Chip
Initialization.
4. Display the Exact Resize dialog so that you can manually set the size of
BLK_BOX:
Edit//Exact Resize...
Notice that there are two other resizing options on the menu. The Resize
function allows you to interactively drag the corners/sides of a macro to resize
it, the Resize by Factor function allows you to set multiplication factor for the area
of the macro. Using either of these will require us to legalize the macro size
afterwards using (usually) the Area Planner. We will see this tool in a later lab.
We will just Exact Resize the macro to a legal size for the moment.
5. Set the "Width" field to 1800 wiring tracks.
Macro widths should be set to multiples of the gate array channel step size.
You can find keyword values for both the gate array (3) and standard cell (1)
step size in the RULEDEF record of the PHYSICAL view of the macro.
6. Set the "Height" field to 3600 wiring tracks.
7. Click OK to run the Exact ReSize action and close the dialog.
BLK_BOX will grow to the specified size. We now need to set the number of
wiring layers that ChipBench will assign to this macro for its internal wiring.
8. Display the Highest Reserved Layer dialog so that we can set the ceiling.
Planning//Reserved Areas//
Set Highest Reserved Layer...
9. Select "M4" as the ceiling (top most metal layer usable by macro).
10. Click OK.
11. Change the display theme by:
Themes//Color Cells by Attribute
If you unselect BLK_BOX, its outline color is red.
To set the states of all macro location and shape constraints for later
processing, do the following.
12. Select all the macro children of the chip.
=chb::select_cell -macro
13. Unfix the shape of the selected macros.
Constraints//Unfix Shape//Self
To prevent the next set of floorplanning actions from recalculating the
necessary size for our BLK_BOX macro based on no cells in the internal netlist
(results in a size of 0 by 0),
14. First select BLK_BOX by:
=chb::select_cell BLK_BOX
15. Now set the Shape constraint to fixed to prevent BLK_BOX from being resized.
Constraints//Fix Shape//Self
If the color by attribute feature is on, the outline of "BLK_BOX" will now be
yellow when it is not the currently selected object. This indicates that
"BLK_BOX" is fixed in shape.
Setting Up a Black Box for Timing
In addition to asserting the physical constraints on our BLK_BOX macro, we will also
want to establish timing constraints at it's input and output ports. Remember that the
timing specs for an internally defined object are subject to the Columbus effect.
Inputs on the macro are signals leaving the defined logic domain (outputs) and
outputs on the macro are signals entering the defined logic domain (inputs).
For the inputs, we will set the required time of arrival to allow signals to meet the
proposed internal macro timing requirements. This can be done with the TCL
command
= et::set_required
For the outputs of the macro we will need to specify the arrival times that signals will
arrive at the macro outputs from the internal logic as well as the slew rates of these
signals. This can be accomplished with the TCL commands
= et::set_arrival
= et::set_slew
We will also set the failure calculator mode to NOPATH.
In our design the timing assertions for BLK_BOX were provided by the logic
designer in the original timing assertions for CHIPTOP.
To see the timing assertions that were set in the assertion files:
1. Switch to the usercntl directory where we put the assertion files.
cd $HOME/usercntl
2. Search the assertion files for lines pertaining to BLK_BOX
grep BLK_BOX chiptop.*.cmd
Here is a sample of the output from this grep. We can see the assertions that
the logic designer created for the BLK_BOX macro.
chiptop.eta.cmd:et::set_required -pins {{BLK_BOX/SIMILAR1_DATA(25)}} -phase "B0+R" -time 3.50
chiptop.pis.cmd:et::set_arrival -pins {{BLK_BOX/OUT_NET}} -phase "B0+R" -time 0.50
chiptop.pis.cmd:et::set_slew -pins {{BLK_BOX/OUT_NET}} -phase "B0+R" -time 0.50
If we were going to load timing assertions from a separate file we can just
source the assertions using source <my_new_assertions> on the ChipBench
Tcl command line.
Note that these assertions would be loaded in the current session but would not
be available in subsequent ChipBench sessions unless you once again source
the file with the new assertions. Merging the new assertions into the assertions
for CHIPTOP avoids this inconvenience.
Creating an Initial Area Plan
We will now calculate the area required by each macro/partition to successfully contain
its child objects. The Area Planner will perform the following functions:
Traverse the hierarchy both top down and bottom up resolving each cell.
Estimate the placement and wiring area requirements for each macro/partition.
Assign shapes and aspect ratio limits to for reshaping macros and partitions
based on shapes of their respective child cells and the relative wiring congestion
in the X/Y directions.
The area planner will also calculate the ceiling (implicit reserved layer) for each
macro and partition (the topmost wring layer the cell will be able to use)
Initializing Blockage Estimates
In this procedure we will define wire track blockage estimation parameters for image
(power rails, etc.) and book blockage. At this point in our design, since we have no
placement data ChipBench cannot use actual values from placed books. Instead
estimates of wiring plane blockage will be calculated based on whether an area is
within the active image and/or circuit row placement area. This will allow the
designer to begin developing design information and proceed to an initial placement
at which point the designer may refine area planning numbers using the Area
Update function.
1. From the ChipBench nutgui window make sure CHIPTOP is the currently
selected object.
2. On the ChipBench command line, type the following:
= source SetDesignBlockage
This command causes the ChipBench TCL interpreter to search for and load a
file called SetDesignBlockage. This file is found in your $HOME/tcl directory
on your student account. If you had wanted to explicitly define the directory in
which to find the tcl, the following syntax would also work:
= source $env(HOME)/tcl/SetDesignBlockage
The commands in this file set the image and leaf cell blockage estimates for
each wiring plane in our design (see the contents of this file in the next figure).
The text output from the TCL script will appear in the console window. We could
also have set these values from the ChipBench graphics user interface. We
can go to the user interface now to view the values set by our TCL script.
3. Raise the cell action menu using Mouse Button 3 and select
Planning//Set Blockages for Design...
On the resulting dialog window you should see all the values set by the script
displayed. You could also create or edit these values via this window. For now,
leave the values as set by the script.
4. Press Cancel to leave the window without making any changes.
The contents of the SetDesignBlockage file is as follows:
echo " "
echo "----------------------------------------- "
echo "SA-27E TCL Design Blockage Example"
echo "EDA Customer Education Team - Do Not Copy"
echo "----------------------------------------- "
echo "Design name: [ current_cell]"
echo "Constraint file name: assert_design_blockage"
echo " "
echo "Setting PC image blockage...."
chb::set_layer_blockage_averages -layer {PC} -image_blockage 50.0
echo "Setting PC leaf blockage...."
chb::set_layer_blockage_averages -layer {PC} -average_leaf_blockage 35.0
echo "Setting M1 image blockage...."
chb:: set_layer_blockage_averages -layer {M1} -image_blockage 25.0
echo "Setting M1 leaf blockage...."
chb:: set_layer_blockage_averages -layer {M1} -average_leaf_blockage 35.0
echo "assert_design_blockage complete!"
echo " "
Note that this is not an official set of numbers. You should obtain the correct
values for your technology from your ASIC field engineer.
Running the Hierarchical Area Planner
We will now run the Hierarchical Area Planner to create estimates for the area required
for each macro/partition in our design. On this first set of estimates, we will use a
common set of assumptions for the entire design and allow the hierarchical area
planner to traverse the entire design hierarchy. These assumptions will be refined
later in our floorplanning process as we develop more information about our design.
1. Be sure CHIPTOP is selected.
2. Reset the color scheme and then apply Color by Attribute Theme.
Themes//Default Settings
Themes//Color Cells by Attribute
3. Confirm that the macro BlackBox is fixed in shape (yellow or blue)
You can also see the setting by selecting a macro and looking in the attribute
information box at the bottom of the Graphic Window
4. Confirm the other macros in the design are not fixed in shape (yellow or blue)
5. Raise the Action Menu by pressing Mouse Button 3.
6. Select from the Cell Actions cascade menu select::
Planning//Hier. Area Planning...
7. On the resulting Area Planning Panel, set the following options on the Parameters
Page ON:
Resize/Reshape Soft Blocks
This will allow area planning to alter the shapes of supermacros and
macros.
Descendants Only 9999
8. Make sure the following options are turned OFF
Create Circuit Rows
This action would copy circuit rows from the chip level image into the
macros to allow legalized placement of the macros children. Since we
have not placed the RLMs yet, we will hold off on this action.
Trim Soft Blocks to Circuit Rows
The macro boundaries would be trimmed back to an integer multiple of the
circuit row height and placement cell width. We will hold off on this action
also.
Click on the Resize/Reshape Options... button.

Set the Density(%) to 67.00
This sets the maximum density that leave cells will be assumed at in the
design cell. As the density goes down, the size of the containing cell must
grow to accomadate the child cells.
Set Hard and Soft Macro Padding Factors to 1.10
Multiplies area of child macros by the specified factor when calculating the
required area requirements for placing and wiring the child macro within
the parent macro. A soft macro is a child macro without a fixed shape
constraint. A hard macro is a child macro with a fixed shape constraint.
The Library, Hard and Soft Macro areas calculated using the padding
factors are added together and used as the minimum allowable space
required to house the macros child cells.
Set the Core to I/O Gap to zero
Specifes the distance between the core logic and the I/O ring. Set this to
zero since we are doing an RLM
Encounter I/O File
Support for reading in an Encounter I/O File. We will not be using an
Encounter IO file in class
Consider Wire Demand
The "Consider Wire Demand" button tells Area Planner to estimate how
much space is required to wire the circuits once they are placed. If the
required space is larger than the wiring capacity of the calculated
placement space, the X/Y size of the macro will be increased and the
ceiling of the macro adjusted if necessary (ceiling adjustment will occur
even if the Create Reserved Areas for Signal Wiring is off.
Consider Placement Reserved Areas
The "Consider Placement Reserved Area" button tells the Area Planner to
include the effects of placement reserved areas in the size estimation of
the macro. This was initially used only for clock books but other uses are
now practiced.
Create Reserved Areas for Signal Wiring
This option tells the area planner to do a statistical analysis of the
connections in the logic and adjust the ceiling of the macro as necessary.
9. Press OK to return to the Area Planner main dialog.
10. Press OK to run the Hierarchical Area Planner.
IO Constraints for IO Assignment
Creating Fixed IO Assignments using a Tcl script
IO locations can be manually pre-assigned prior to any automated I/O assignment
functions and fixed in location to prevent the automatic functions from modifying
them. Assigned but unfixed I/O locations can be used to provide seed information
on I/O positions in a flow.
1. On the ChipBench Graphic Window menu bar, select:
Visuals//Port Visibility
2. Notice the stack of blue port indicators at the center of the chip.
If you had family highlighting on, the ports would have already been visible. If
you had highlighted the ports with chb::highlight_port, they would have also
been visible but you can switch that off with Visuals//Always Obey Visibility
Settings.
3. On the ChipBench main window command line, type:
= source IOPreAssign
4. You will now see 10 ports turn orange and assume new positions on the design
over the terminal they have been assigned to.
5. Review the contents of the IOPreAssign script below:
# explain operations
echo "Processing system clocks by assigning ports to package_pins...."
echo "Processing test io control lines by assigning ports to terminals...."
# echo all the commands to the console
set incoming_observe_state [observe]
observe -all
chb::assign_terminal -package_pin_name E08 \
-port TST_ACLK -fix_assignment
chb::assign_terminal -package_pin_name M03 \
-port TST_BCLK -fix_assignment
chb::assign_terminal -package_pin_name N03 \
-port TST_CCLK -fix_assignment
chb::assign_terminal -terminal NEKT70 -port DI1 -fix_assignment
Note that we assigned ports using two conventions, one where we assign a logical
port to a package pin, the other where we assign a logical port to a chip terminal.
Either method is acceptable. ChipBench uses the technology rules to map the
package pin method to the correct chip terminal.
Interactively Assigning Ports to Terminals
You can also use ChipBench to interactively assign IO to terminals. This is useful
for doing a few pre-assignments or for editting the generated assignment to correct
any issues.
1. Make sure ChipTop (the chip) is the currently selected cell from the Graphic
Window by:
2. Raise the cell action menu (Mouse Button 3) and select:
Windows//Lists//Ports
3. Raise the cell action window again and select:
Windows//Lists/Terminals
4. Find and select the CHIPTOP/BS_SCAN_IN port in the port list window
5. Press Mouse Button 3 to raise the Port Action menu and select:
Edit//Assign to Terminal
6. In the Terminal list window, find the terminal which is attached to package pin
K12 and select it.
Note: You can only do selection in the terminal column although you can see
the name of the associated package pin.
7. BS_SCAN_IN will appear as the assigned port on the terminal list windows
third column.
Note: You may need to widen the Terminal List window to see all the fields full
length.
We can also work the problem starting from the terminal side.
Note that the package pins are not in alphabetical order so this can be a chore
8. To resolve this problem, on the terminal list window menu bar select:
Options//Sort
9. Select Package Pin
10. Press OK.
11. Now find and select the terminal associated with package pin E13 in the
terminal list window
12. Raise the terminal action menu and select:
Edit//Assign to Port
13. In the port window, select the port BS_SCAN_OUT.
BS_SCAN_OUT will appear as the assigned port in the terminal list window.
14. Scroll up and down the terminal list window.
You should be able to also see the assignments that we made in the previous
script, IOPreAssign.
15. To identify the two ports we just assigned on the Graphic Window menu bar,
select:
Visuals//Text Visibility
16. On the port window, select BS_SCAN_IN.
17. On the port window, hold down the Ctrl key and select BS_SCAN_OUT.
Both cells are now selected and a text label appears next to them.
18. In the terminal window, select the Terminal attached to port BS_SCAN_OUT
19. Raise the action window using mouse button 3 and select:
20. Windows//Attributes
21. A terminal attribture window appears with attribute information.
Creating Port Area Contraints for our design
Lets say that we have some groups of I/O that we want to contrain to particular
regions of the chip. We may have developed this information by looking at an earlier
floor plan, by restrictions generated by the floorplan of our system board, etc. We
will use the following set of port area restrictions for our design.
1. To view the port areas created, on the ChipBench Graphic Window menu bar,
select:
Visuals//Port Area Visibility
2. To create the port areas, run the following command:
= source CreatePortAreas
This script will both create the port areas and assign the three major IO bus on
the part to each area, DATA(64), COMMAND(8) and ADDRESS(8).
Contents of the CreatePortAreas script
echo "-------------------------------------------"
echo " Create Port Areas for CHIPTOP"
echo " EDA Customer Education Team - Do Not Copy "
echo "-------------------------------------------"
# remove any prior existing port areas
chb::select_port_area -name *
chb::remove_port_area
# create the port area by region
chb::create_port_area -region {229 357 5965 8403} \
-name "IO_COMMAND" -layer "M6"
# find all the COMMAND IO and build a list
set command_io_cells [find_cell -name *COMMAND* -io -list ]
# assign the list of cells to the port area
chb::assign_port_area -port_area "IO_COMMAND" \
-cell $command_io_cells
# repeat for ADDRESS IO
-name "IO_ADDRESS" -layer "M6"
set address_io_cells [find_cell -name *ADDRESS* -io -list ]
chb::assign_port_area -port_area "IO_ADDRESS" \
-cell $address_io_cells
# repeat for DATA IO
-name "IO_DATA" -layer "M6"
set data_io_cells [find_cell -name *DATA* -io -list ]
chb::assign_port_area -port_area "IO_DATA" \
-cell $data_io_cells
3. Review the script to be sure you understand the operation
Non-contiguous port areas can be created using lists of terminals. In addition a
single port can be assigned to multiple port areas and will be assigned to one of
them. This gives the ability to define non-retangular (but rectilinear) regions.
Creating Tethers between a port and a cell
ChipBench IO Assignment also supports the concept of a tether. A tether is an
attraction that we can specify between a port and a cell or between a port and a XY
location on the chip. For this example we will create tethers between some cells and
ports.
1. On the ChipBench command line, type the following two commands:
= chb::set_port_tether -cell PLL0 -port PLL0_TUNE*
= chb::set_port_tether -cell PLL1 -port PLL1_TUNE*
Each command should list three ports which have been tethered to their
respective cell. These ports will now have an attraction to the tethered cell that
will tend to make them cluster around the cell when port assignment is
performed and the cell already has a placement position.
Making the terminal display more informative.
Sometimes when developing or editting an IO layout, you would like to be able to
see the functional capability of terminals graphically. This is relatively easy to do
using Tcl based highlighting.
1. Turn on the terminal display for the chip.
Visuals//Terminal Visibility (Image)
Note that the terminals are a uniform orange color which gives no clue as to
their allowed usage.
2. Note: The text display is still on and the Graphic Window may be a little busy
looking at the how chip. You can either toggle off the text visibility or zoom in
3. To improve the display, run the following Tcl script:
= source ColorCodeTerminals
4. This following script will color code the terminals according to the table:
dctest = green
actest = orange
pll = red
ridi = yellow
other = purple
chb::select_terminal -name *
chb::highlight_terminal -none
chb::select_terminal -driver_type dctest
chb::highlight_terminal -color green
chb::select_terminal -driver_type actest
chb::highlight_terminal -color orange
Note that some terminals may support multiple IO types. For instance AC test
IO are usually also available as DC test IO. We highlighted AC test IO after DC
test IO so that the DC test highlighting would not override the AC test
highlighting.
Getting our initial IO assignment
Now that we have created all the constraints we are putting in place for our design,
we will get an initial IO assignment.
1. Make sure CHIPTOP is the currently selected cell.
2. Raise the action menu and select:
Interface//Driver Type Match....
3. On the Driver Type Match dialog, select:
Move Driver Cell
4. Make sure Ignore Voltage Regions is on.
5. Press OK
6. Turn on the visibility for cells_L2_unplaced cells in the hotlist using mouse
button 3.
Note that you got some driver cells placed in the lower left corner of the chip.
You may have to zoom in to see the cells.
7. Drag select the driver cells in the lower left
If you look at the selected objects list, you will see some of the cells are the
tune ports that we tethered, but the PLLs are in the middle of the right edge of
the chip. This is a result of the fact that PLLs are IO cells for the purposes of
assignment. The ports were all assigned to terminals based on their original
positions, then the cells where snapped to the terminal locations which caused
the PLLs to move away from their tethered ports.
8. Re-select the root cell, CHIPTOP.
9. Run the Driver Type Match a second time to correct the PLL tethered ports.
Interface//Driver Type Match....
Reviewing the port assignment graphically
We can review the general nature of the port assignment by using the ChipBench
Graphics window.
1. To tear off the selections menu on the Graphic Window menu bar, select:
Selections//--------
2. On the tear off menu, turn on:
Selectable::Ports
Pre-Select::Ports
Show Names::Ports
3. Now visit some of the ports hovering the mouse over each one.
A text ballon will open up giving a description of each port.
4. Check that you got the general results you where expecting.
5. On the tear off menu, turn on:
Selectable::Terminals
Pre-Select::Terminals
Show Names::Terminals
6. Now visit some of the unassigned terminals.
You will see important information about each terminal appear in a text ballon
as you hover the mouse over the terminal. You could also see the same
information for an assigned terminal. You have to be very specific with the
mouse position however to distinquish between the port and the terminal at the
same location. The terminal hot spot seems to be very slightly lower than the
port hotspot. However the terminal balloon contains all the information that is
contained in the port ballon so you could turn off the ports and just leave the
terminal pre-selection and show names options on.
7. Turn off the following on the Selection tear-ff window:
Pre-Select::Ports
Show Names::Ports
8. Now visit some assigned ports.
The pre-select is now picking up the terminals each time.
9. Select the tear off menu motif frame and press ESC to close the window.
NetList Floorplanning
Floorplanning with a netlist
Running the floorplan flow on a netlist design
1. Open a Graphics Window
2. Turn on the visibility for unplaced cells in the hotlist using mouse button 3 if it is
not still on.
3. Remember to refresh the display if necessary.
To provide additional wiring spaces around the borders of our macros, we need
to create a xfactor file for the floorplanner. I have already created this file for
you for our design example. The file can be found in
$HOME/usercntl/macro.xfactor. The contents are as follows:
format xfactor_default_directions
CHIPTOP.LB 96 96 96 96
CHIPTOP.SMO 48 48 48 48
CHIPTOP.SM1 48 48 48 48
CHIPTOP.RU1 72 72 72 72
CHIPTOP.RU2 72 72 72 72
CHIPTOP.RU3 72 72 72 72
CHIPTOP.RU4 72 72 72 72
CHIPTOP.DO_MUX 144 144 144 144
CHIPTOP.BLK_BOX 48 48 48 48
4. Now we are read to proceed with the design using the real netlist as input to
create the default abstract netlist for the chb::floorplan_flow.
= source cb_flp_procs.tcl
= chb::floorplan_flow -high_temp -legalize -expansion_factor_file
$env(HOME)/usercntl/macro.xfactor -output_directory flpout_netlist
If you watch the graphic window, you can watch the design change state as the
design progresses thru the flow. I/O cells will fix and unfix, etc.
Note: You may not want to legalize your placement until you are close to being
happy with the results. Legalization can remove information from the
placement layout regarding connectivity while it is resolving overlaps. Good
practice is to run optimization, then legalization seperately.
Using abstract netlist overlays
To get a better view of our design, lets look at the abstract netlist overlay.
1. Re-select CHIPTOP if it is not your current cell.
Overlays//Abstract Options...
3. Select the FLP_FLOW_ABS net list in the left most column.
4. Select all the Objects of Interest in the center column by clicking on the
binoculor icon which has both eye pieces high lighted.
5. Press Apply.
The Graphic Window gets very noisy and hard to read.
6. Press Refresh.
Still too much information to be able to read the display. Lets get rid of some of
the connections.
7. In the relative connections column on the right, uncheck the 0-9% category.
Note: You may have to turn off additional classes of low percentage relative
connections until the number of abstracted nets in the display is reduced
enough for the design architecture to be readily visible.
8. Press Apply.
9. Refresh the Graphic Window if necessary.
Lets clean it up a little more.
10. Turn off the 10-19% class of relative connections
Now we have a pretty good model of our connections to view on the design.
Diagnosing the DO_MUX, LB problem using abstracted netlist
You can also look at specific connections. Lets examine that DO_MUX to LB bus
problem we saw earlier.
1. On the Abstraction Menu, press the binoculars with blacked out eye pieces.
All the Objects of Interest are deselected.
2. Now select DO_MUX and LB.
3. Press Apply.
Hmmm. No connections appear.
4. Turn the 0-9% and 10-19% relative connection classes back on.
5. Press Apply.
Note the low degree of connectivity between these two macros.
Apparently, there was some confusion in the original block diagram about the
number of connections required to be made between these two cells. Merging
them is contra indicated in this case.
Looking for potential congestion issues
You can also use abstracted netlists to look for potential congestion problems in the
design.
1. On the Abstraction Menu, press the binoculars with both eye pieces lit.
2. Turn off all the Relative Connections except 100%.
3. Press Apply.
Note that the connections from DO_MUX to the RU macros are not massive as
expected. A DSL modeling assumption early in the floorplan process did not
match the true netlist. Remember to continually reasses your assumptions.
Note: Later in our design process is it our intention to flatten the RU macros,
they are only clustered at this time for floorplanning purposes.
4. Start turning on level of relative connections from highest to lowest one at a
time.
This will give you a feeling for the distribution pattern of connection density on
your design.
5. On the Abstraction Menu, press Cancel to leave the menu.
6. To turn off the abstract net display, on the Graphic Window menu bar select:
Overlays//Abstract NetList
Checking the IOs in ChipBench
A command is provided in ChipBench to provide convenient checking of the IO
placement and terminal assignments.
1. On the ChipBench command line, type:
= chb::check_io_assignment
This command has no parameters and does checking on the following items:
Terminal Check
Port Area Check
Type Check
Differential Pair Check
Voltage Region Check
2. Check the ChipBench console output for results.
Detailing the Area Plan for Placement
We will now use the area planner to copy circuit rows from the chip image into each
RLM and then trim the RLMs outline to exactly match the circuit row configuration.
Circuit Rows Creation and Macro Size Legalization
1. Be sure CHIPTOP is selected.
2. Raise the Action Menu by pressing Mouse Button 3.
3. Select from the Cell Actions cascade menu select:
Planning//Hier. Area Planning...
Page OFF:
Resize/Reshape Soft Blocks
This will prevent the Area Planner from changing the size or shape of our
pre-planned RLMs.
Page ON:
Create Circuit Rows
This action will copy circuit rows from the chip level image into the macros
to allow legalized placement of the macros children.
Trim Soft Blocks to Circuit Rows
The macro boundaries will be trimmed back to an integer multiple of the
circuit row height and placement cell width.
Descendants Only 9999
6. Select the Create Circuit Rows Options... button.
7. Make sure the Consider Placement Reserved Areas button is off.
8. Select Neither as the hole punching option.
We dont have any placement reserved areas yet. The settings on this panel
will be important when working with RLMs that require hole punching. If the
switch is on, circuit rows will not be built anywhere a placement reserved area
exists. If the switch is off, the circuit rows are built ignoring the placement
reserved areas. The PD Methodology Guide will tell you whether you need to
use or ignore placement reserved areas during portions of the design
methodology.
9. Press OK to return to the Area Planner main dialog.
10. Press OK to run the Hierarchical Area Planner.
Note that the areas of all the macro children changed size with the exception of
BlackBox on which we had placed a shape constraint. This shape constraint
prevents the Area Planner from modifying BlackBox's shape.
----------------- Appendix ----------------
The following sections are provided for the students reference.
Sections here represent either methods less used or more
advanced topics which we will not have time for in class.
Loading without a Net List
in Native ChipBench
This section is provided as a reference for custom and foundry
designers who may not be operating under theGuide.
Data Specification for ChipBench
Data Specification is the process of defining the location of design data files, PDL
assertion files, technology rule files and timing rule files to ChipBench.
Specifying the Design Data Files
To speed up the process of specifying the design data for our class, we will retrieve
a ChipBench configuration file which contains the path names required for our
design.
1. From the ChipBench nutgui window, display the Data Specification panel by
selecting File, then Load, then Specify Data... from the menu bar. The following
shows the syntax we will use to indicate chained selection from a menu bar.
The picture shows the how the chained menu appears on screen.
Note: The icon in to the left of the command line lets the user toggle the
command language they are using. The feather icon represents Tcl (tickle)
and the Camel icon represents Perl (see the Nutshell book series from OReilly
and Associates(tm).
The following is the resulting panel for specifying data.
2. On the Data Specification Panel, select Read Parms...
3. Select the file StartingDSL.parms in the right pane of the file dialog.
4. Click OK.
The configuration file will be read, and the Data Specification Panel will be filled in
with the correct directory and filename values for you. The next steps will be to
confirm and complete the data specification.
5. In the "Specify NetList" section, make sure the Netlist Format radio button is set
to "VIMe and the Wire Format radio button to DWIRE".
All of our class data is VIMe based since we are running with a Cu-11 part.
6. Observe that the NetList Search Path field is empty.
We will load our design without loading any netlist data and use DSL later to
bring in a model netlist.
7. Check that the "Net List Name" field is set to CHIPTOP, the root object name of
our example design.
Note: For empty netlist operation, you will not be able to select the name of the
root object using the browse button to the right of the NetList Name field.
Without a netlist searchpath, ChipBench cannot generate the list of DEFs
available in the netlist searchpath. You will need to type in the value for your
design. Because you are typing in the name, be sure to get the case correct.
We have seen the ability to operate with the incorrect case but this causes
problems later in the design process.
8. Turn on the Initialize Image button and select Options....
On the Initialize Image Options dialog you should see values specified for the PDL
Package File and the VIM Chip Image.
Note: We provided these values for you in the StartingDSL.parms file. For a
real design, you would have worked with your ASIC FAE to determine an
appropriate image for the design relative to cost, number of I/O and circuit
capacity.
The VIM I/O Image field should be empty as we are processing an area IO part.
9. In the Options pane, turn on
Initialize Power (Post-Invocation)
This creates an idealized power bus structure based on the power
defintions in the package pdl. No design specific adjustments to the
idealized power structure will be made for currently unplaced books since
a book location is required. The idealized power bus structure is useful for
both design visualization and is also used by the congestion analysis
functions to estimate the wiring demand of the final power bus structure.
Generic Image
This marks the image data as replacable if we decide that we are not at
the correct chip size later in the design process. We would use the
chb::switch_image command to change the image.
10. Select Chip as the design object type.
This will edit/create a TYPE- keyword in the DEF view of our root object
(CHIPTOP) and set the value to CHIP.
11. Press OK to close the Initialize Image Options dialog
12. In the "Specify Library Sources" section, make sure the Library Format radio
button is set to "VIMe".
The "Search Path:" field was set when StartingDSL.parms was loaded.
13. Press the Select.... button next to the "Master File:" field.
From the "Master File Selection" dialog, confirm "pdl.6lm.c4" is selected.
14. Click OK.
15. In the "Working Directory" field, check that the working directory is set to:
./workdir
16. Press the Import Data button on the Data Specification Panel .
Press OK on the Confirm Action dialog to confirm creating the working
directory if it did not previously exist.
If any problems were encountered, ChipBench will highlight the page selection
buttons with red backgrounds where any problems occurred. Each field that has
a problem will have a red background. If the field contains multiple entries
(paths, etc.), the entry with a problem will be highlighted with a locally white
background while the remainder of the field remains red.
The Import Data button allows you to start an import directly from the Specify Data
dialog. It also now supports the option of initializing the design at the start of your
design process.
With the "Initialize Image" switch on, the designer can:
set/reset the chip image size
select/reselect the package using the Package File
import the specified design data
An empty netlist path causes this action to be skipped.
initialize the power grid for the design
Note: Some technologies may delay initializing the power grid until a later step.
Remember to use the methodology guide for your specific technology.
Loading DSL and IOSpeclist
in Native ChipBench
This section is provided as a reference for custom and foundry
designers who may not be operating under theGuide.
Loading DSL and IOSpecLIst in Native ChipBench
Now we will load a DSL model of our design onto our generic image of the design.
This DSL step we will actually perform rather than just read.
Load the prepared early DSL into ChipBench
1. On the chipbench command line, type the following command:
= chb::read_design_speclist -file $env(HOME)/dsl/chiptop_early.dsl
This command will load the DSL logic we created into the physical model of the
chip created by the Import Data and Initialize Image function. You will get a few
error messages about no outline being able to be load for the RLM macros of
the design. These are okay at this point.
2. Open the Grapic Window to observe the results.
3. In the hotlist click on the cells_L2_unplaced display item with Mouse Button 3
to turn on visibility for unplaced objects.
4. Press the Refresh icon above the hotlist.
You should see the unplaced cells now at the lower left corner of the chip.
These are the clusters that were created by the DSL. Lets try to floor plan
them based on the DSL connections.
A new feature is the ability to load an IOSpeclist containing placement
information to create an initial I/O floorplan. Wire code information is not
currently used however. The ability to use the wirecode information will be
available in the September time frame.
DSL commands may be interspersed with other chipbench Tcl commands
DSL commands will work only in ChipBench, First Encounter wont
recognize ChipBench commands.
chb::write_abstract_netlist can be used to write out DSL.
5. To load the IOSpecList, issue the command
= iospec::read_io_speclist -file $env(HOME)/usercntl/chiptop_ioplan.iosp
6. To add any IOs in the vim missing in the IOSpeclist:
= chb::update_io_speclist -merge_missing_ports
Note: For this command to work, the original IO SpecList must have at least
one port record defined.
7. To write the updated IO SpecList back out to file:
= iospec::write_io_speclist \
= -file \ <student home directory> /usercntl/chiptop_out.iosp
Note: You may have to edit the resulting file. Additional keywords are created
for the ports originally defined in the incoming iosp file and the values are set to
- which prevents the IO SpecList file from being read properly.
Custom Compiling an Abstract Netlist
This example shows how to compile a custom specified
abstract netlist.
Compiling our own Abstract Netlist
1. Select the four RU macros.
2. Raise the action menu and select:
Hierarchy//Flatten
3. Set the Hierarchy Version Name to CHIPTOP_Place
4. Set Resize Factor to 4.0
5. Turn on the following options:
Create Move Bounds
Prefix Children Names
6. Press OK to flatten the four RU macros.
7. Turn on visibility for move bounds:
Visuals//MoveBounds Visibility
Note: The next step may take a little while to run as it is creating a fairly
complex abstract netlist. In fact, this abstraction is really too complex for good
design. Maintaining some clustering of the leaf cell logic will do a better job of
letting you see the design as well as improve results and runtime.
8. Run the abstract netlist compiler from the chipbench command line:
= chb::compile_abstract_netlist -abstract_netlist MyNetList -macro -io -latch
-large_cells -logic_levels 5 -fanout_limit 25 -make_current
Note: This is a much more complex abstract netlist with about 1600 total
objects of interest.
9. To run a floorplan_flow against this abstracted netlist:
= chb::floorplan_flow -high_temp -legalize -abstraction_mode use_active -expansion_factor_file
$env(HOME)/usercntl/macro.xfactor -output_directory flpout_netlist
Notice that the run time did not degrade much. This is a result of a limit on the
floorplanner to prevent overloading it with data. The floorplanner rejects any
object of interested in an abstract netlist that is only 1 circuit row tall. So in our
case the latches were rejected which resulted in a much smaller abstracton.

Floor Planning Lab

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Floor Planning Lab

Hochgeladen von

Copyright:

Verfügbare Formate

IO and Block Floor Planning

Text following this symbol indicates the action menu item to

Text following this symbol should be entered on the Tcl command

Used to indicate a series of selections on a ChipBench dialog.

Identifies a procedure heading. Immediately following each

I/O and Block Floor Planning Lab Exercises

Das könnte Ihnen auch gefallen