Getting Started Lab With Spyglass 450
Getting Started Lab With Spyglass 450
Lab Book
SpyGlass 4.5.0
Getting Started with SpyGlass - Lab Book SpyGlass 4.5.0
Table of Contents
Table of Contents ............................................................................................. 2
1 Introduction ............................................................................................. 4
2.1.4 EDITOR.................................................................................6
This document covers multiple labs and each lab is dependent on the previous lab being
completed. Additional details are provided in section 3.1 on the lab directory structure.
1.1 Nomenclature
The following environment variables should be set up for SpyGlass to function correctly:
2.1.1 SPYGLASS_HOME
This variable is not mandatory to be set to run software but is useful for supporting functions,
such as path setup, moving to the top of the install hierarchy, and so on.
(csh)
setenv SPYGLASS_HOME <install_path>/SPYGLASS_HOME
(sh, bash)
export SPYGLASS_HOME=<install_path>/SPYGLASS_HOME
2.1.2 ATRENTA_LICENSE_FILE
This variable is required to set the full path-name of the license file or by using port@host
setting.
(csh)
setenv ATRENTA_LICENSE_FILE <full-path-name-of-license-file>
(sh, bash)
export ATRENTA_LICENSE_FILE=<full-path-name-of-license-file>
If your license is served from a central location, obtain the correct setup information from your
system administrator.
2.1.3 PATH
This variable assumes that the SPYGLASS_HOME variable has already been set (as above).
(csh)
set path = ($SPYGLASS_HOME/bin $path)
(sh, bash)
export PATH=“$SPYGLASS_HOME/bin:$path”
2.1.4 EDITOR
You can invoke your favorite text editor directly from the SpyGlass environment. To set up the
correct text editor, set the EDITOR environment variable as follows:
(csh)
setenv EDITOR <full-path-name-to-editor>
(sh, bash)
export EDITOR=<full-path-name-to-editor>
WB Connmax
(Verilog)
AHB2WB
WB_Subsystem (Verilog)
The design is assembled using blocks available from open source as below
For the purposes of this lab, the design is build as follows to highlight specific features in
SpyGlass
Top level USB controller block is available as a regular RTL but all of its design files
are read as a Verilog library component.
IMA ADCPM block is pre-compiled into its own work library (ima_adpcm_lib) and then
get referenced at the top level of the design.
Rest of the components are read as normal RTL files.
4 SpyGlass Overview
The objective of this lab is to quickly get you started with SpyGlass where you can run the
analysis and look at the results
It indicates the summary of the flow. You may like to select „Do no show this dialog
again‟ and then click on „close this window‟.
5. Click on GUI option “Add File(s)”. This will open up the SpyGlass: Add File(s) window
and add the following RTL files from the „rtl‟ directory as shown below
../rtl/ahb2wb.v
../rtl/wb_subsystem.v
6. Now select tab „Set Read Options‟ and enter the top level design unit name for the
block (wb_subsystem) as shown below.
7. Now Select Tab “Run Design Read” and click on option “Run Read Design” to start the
design read. The tool will prompt you to save your session as a project file as follows:
8. Let‟s save it with wb_subsystem.prj in „spyglass‟ directory and once the spyglass run is
completed. Let‟s review the design read errors reported by spyglass as shown below
There are 3-errors reported for the design (wb_subsystem), read by spyglass. You will
notice that these all errors are of same type and are reported by spyglass rule
ErrorAnalyzeBBox, which indicates that SpyGlass did not find a definition of the block
and hence marked it as a blackbox.(Note: For complete design analysis using
spyglass, all blackboxes should be resolved first and for that reason you may
additionally like to select checkbox „Synthesize Netlist‟ while running designread)
The „Design Setup‟ step enables you to start your analysis while the blocks are still
being defined. The Module View marks the blocks as follows
Green to indicate that the block is ready for analysis but not yet internally
synthesized
Black to indicate that the block can‟t be analyzed (blackboxes)
Grey to indicate that the block only has the interface description available and
can support limited analysis.
White to indicate that the block is synthesizable and you can select that DU
and open modular schematic to see the structure (with „Synthesize Netlist‟
option enabled in designread)
Note: Synthesis help will be visible only when you highlight the synthesis goal (by making that
goal highlighted with blue bar in background and you can highlight only one at a time during
setting up goal or while going to „Analyze Results‟ for that goal whereas you can enable
multiple goals just by enabling the checkboxes towards left of the goal name and they will be
executed sequentially)
2. Click on “Run Selected Goals”. Once the run completes, the tool will automatically take you
to “Analyze Results” which will open the window below (in case of multiple goals being
selected and run- it would remain in „Goal Setup & Run‟ tab)
Expand the ERROR messages first. They contain the same blackboxes being reported from
the designread stage.
Now expand the WARNING messages in the Message Tree window.
Select and expand the InferLatch issue
Double-click the first violation message. Note how the related line of RTL code is highlighted in
the HDL viewer above the results display.
Carefully analyze this rule. You can further probe this issue as follows:
First, the message tells you that a latch has been inferred for certain signal.
The „Help‟ window to the right of the message tree gives more information on the selected
message.
As you can see there is a NAND gate symbol attached with the violation message, which
indicates that violation message also has some debug information in terms of schematic data.
You can open the associated schematic data by pressing key “i” or by clicking option
Incremental Schematic (refer to red oval in snapshot above) on left hand side of the Message
view window. The incremental schematic window will look as follows:
In this particular example situation, you can see that signal ‘hready’ is getting assigned inside
an if statement without an else part and that seems to be the valid reason for latch inference
during synthesis. If design requires hready signal to be latched w.r.t strobe signal ‘stb_o’, then
this is not an unintended structure. For the purposes of this lab we will assume that these
latches are intentional and so you may like to waive the violation. For that, you right click on the
violation message and select „Waive Selected Messages…‟. It will open the waiver editor which
looks as follows:
You can waive other two violations of InferLatch in the same way.
On the other hand, if you needed to fix the problem, you can click the relevant HDL source-
code line in the RTL View and press the <e> key on the keyboard (or select „Edit file‟ from the
right click pop-up menu). Then, SpyGlass will open the RTL source file using the default text
editor, as defined by the EDITOR environment variable, with the cursor on the line that is
selected in the RTL View window. You are now ready to edit the source file and save the
modified file and can rerun the goal.
Let‟s not apply the waivers as yet but this was just to let you know about different utilities while
analyzing results. Click „cancel‟ on the waiver editor and come back to „Analyze Results‟
window.
3. Save the project file (File->Save Project) and exit (File -> Exit). You will be prompted if
you want to save the waiver file. Select „No‟ for now.
The UI remembers the stage in which you left the session and so it will by default open in
„Analyze Results‟ tab. Go back to „Design Setup‟ tab.
2. In an external text editor, examine the source file list for the USB and wb_conmax blocks
../rtl/usb/file.list
../rtl/wb_conmax/file.list
3. Add these source file lists into SpyGlass using “Import Source(s)” option from SpyGlass
GUI.
4. Run design read again and this time select the checkbox to enable „Synthesize Netlist‟.
You will notice that adding of above source files have resolved the blackboxes errors for
USB and WB_Conmax blocks, but has still generated more blackbox errors for cells
instantiated inside the USB block.
5. As you can see from the Message Tree (by double clicking the violation messages) below:
6. They appear to be standard cells being instantiaed but somehow there definition is not
provided. It is quite likely that these cells are to be passed using –y/-v option and so let‟s
explore the directory inside „usb‟ to see if there are any missing library file. We get to see
that usb_lib directory is present inside „usb‟ directory but no –y has been specified with it as
part of filelist.
7. Let‟s specify the verilog library path and extension in the set_read_option window (next to
Add Design File Tab).
Specify the Libraries directory containing libraries: ../rtl/usb/usb_lib
Specify Library File Extension: .v
9. You can notice now that you are left with just one black-box error and which is coming for
block „IMA_ADPCM_top‟. save the project file and exit
1. If you have skipped lab1, copy „wb_subsystem.prj‟ file from „snapshot‟ directory to start
with.
You will notice that the „file.list‟ includes the -libhdlfiles option along with the logical library
mapping where the HDL files are to be compiled into. This file also defines the mapping of
logical library with physical location using option “-lib”.
2. Click on “Goal Setup and Run” tab and then subsequently click on “Central Setup” tab.
nd
3. Click on button „Next‟ in the bottom of the Central Setup window. This will move you to 2
step “Resolve Blackboxes” in Central Setup. As we have already resolved the blackboxes
during designread, you can select „Show Last Results‟ against the question (“Detect
Blackboxes in the Design?”) asked here. This will load the Message Tree view which we
have seen after design read.
Note: If spyglass detects a blackbox, then setup manager will provide other option to model
the blackboxes for lint, CDC,DFT and Power analysis.
th
4. Click on Next and the Setup Manager will take you to the 4 step i.e. Design Clocks”. It is
rd
to be noted that Setup Manager skipped 3 step “Blackbox connectivity” as there were no
blackboxes found in the design otherwise you needed to setup SGDC for those blackboxes
modeling for lint and CDC analysis.
5. The „Design Clocks‟ step allows you to enter any clock definitions that you might have from
an existing SDC/SGDC file. Otherwise, select „yes‟ to enable automatic identification of
potential clocks and click „Next‟.
Select „yes‟ to show the clock trees and this will run the spyglass again to identify all
potential clocks in the design and after the completion of the run, spyglass window will look
as follows:.
6. SpyGlass has detected 3-clocks which matches the 3-clocks defined in the design
overview section of this lab book.
Hclk which is the main Amba bus clock with a period of 50ns and a 50% duty cycle
WB_clk is the wishbone bus clock with a period of 17ns and a 50% duty cycle
Phy_clk is the USB interface clock with a period of 10ns and a 50% duty cycle
7. Please enter the clock period from those definitions here. Once you click Next, SpyGlass
will give you an option to validate these clock definitions. Click Yes to validate them. You
will see the following screen which has no errors or warnings reported
8. Clicking on “Next” will take you to the “Reset Setup” screen. Select „yes‟ to Edit and
complete reset constraints as follows:
When you edit the constraints (e.g. change active value from 0 to 1 for certain reset) and
press next - you will see the following:
Once you select „yes‟. You reach the final step of Central Setup (as there was no
blackboxes so other blackbox setups got skipped), where you can run sanity check on the
generated SpyGlass Constraints file (SGDC). Click on Yes to do the sanity checking. In this
case, there is no Error or Warning (otherwise you need to review them and correct them)
and so you click on „Finish‟ to complete the setup.
1. Select „Select Goal(s) for setup/run‟ to go to the “Select Goal” tab and select connectivity,
simulation, synthesis and structure goals and click on “Run Selected goals”. It will prompt
whether you want to run them sequentially or in group mode. Select the sequential run by
pressing „Ok‟ button. We will review the run results in the next section..
Select Goal „simulation’ in the „Goal Setup & Run‟ window and then click on „Analyze Results‟
Tab. You will see the following spyglass window:
From the message window you can see violations for rule W415. This rule identifies nets which
can be simultaneously driven by 2 or more drivers in the design.
Expand the W415 rule folder and look at the underlying violation message. The
violation message indicates that net “master_data_o[31:0]” is driven by multiple drivers
in top-level of the design „wb_subsystem‟. Let‟s debug this issue and find out the root
cause in the RTL code.
Select the violation message by double clicking on it. This will correspondingly highlight
RTL line in the File View window, but you will find that the highlighted line does not
provide sufficient reason for the structural problem reported by rule message, so we
need more design information to check the correctness of the violation and which can
be obtained/viewed from one of the very useful spyglass debugging feature
„incremental schematic‟ viewer.
You will notice that a NAND gate symbol is attached with the violation message, which
indicates that violation message also has some debug information in terms of schematic
data. You can open the associated schematic data by pressing key “i” or by clicking option
Incremental Schematic (refer to red oval in snapshot above) on left hand side of the Message
view window. The incremental schematic window will look as follows:
From schematic data, you will get to see the the two drivers that are driving the reported
signal (WB_master_data_o[0]) and it can be confirmed that the port „m0_data_i‟ is driven
simultaneously by o/p ports „dat_o‟ (of instance ahb2wb_u0 ) and „m0_data_o( of instance
conmax_u1). Hence the violation reported is structurally correct.
If we go back and look at the HDL description, it seems like a typographical error where user
might have copy/pasted the previous line and changed the formal port but missed changing
the net connected to it.
The fix for these violation require an update to RTL. The code however uses an “ifdef” construct
to enable the fixed code. Let‟s enable the definition of “Fix_W415” (by adding this macro in „Set
Read Options‟ tab of Design Setup) as follows and rerun only the goal „initial_rtl/lint/simulation‟ to
verify whether violation of W415 goes away.
Now switch to „initial_rtl/lint/synthesis‟ goal under the „Run Goal‟ list of “Analyze Results”
window as follows:
Once we expand the Goal=< No Template>, we see message reported by built-in rule
SYNTH_5159.
Rule SYNTH_5159 indentifies the constructs that may not be synthesizable by some synthesis
tools.
Let‟s double click on the message for the rule SYNTH_5159 which will highlight the error in the
text navigation. We see that the statement is enclosed within the synthesis pragmas indicating
that the statement is not meant for synthesis.
We now need to enable pragma processing for SpyGlass. This is done by going back to the
“Design Setup” tab and selecting “Set read options” and enable pragma processing for
“synthesis” (along with synopsys and pragma which are default enabled). Also enable the
option that ignore text within the prgama. Lastly, to avoid additional run of design-read you can
add additional command line option „-force_compile‟ as follows:
Once you have setup the pragma processing, you can re-run only the goal “synthesis” to
ensure violation of SYNTH_5159 has gone away.
Note: As the file “IMA_ADPCM_top.vhd” is in the logical library “ima_adpcm_lib” and SpyGlass
by default does not recompile the logical libraries if the source file(s) has not changed and for
that reason we needed to force a recompile of the library using the option “force_compile”
Go back to the „Analyze Results‟ window and select „connectivity‟ goal from the list. You will
see that SpyGlass has reported 2 violations of UndrivenInTerm-ML.
Rule UndrivenInTerm-ML identifies all floating nets having no driver but loaded.
Let‟s analyze/debug the reported violation message. Expand the rule folder and look at the first
violation message. The violation message indicates that for instance “conmax_u1“ the upper
half (31:16) range of vectored input port "m0_addr_i" of size 32bit, is found to be floating in the
design. The spyglass console will look as follows:
This will pop up a small window titled as “HDL Navigation: Property” (shown below).
From the property window you can confirm that width of the vector signal
“WB_master_addr” is also 32 bit, which is same as the width of the mapped actual port
“m0_addr_i” i.e. port is fully connected with a signal bus of same size. Now we need to
check the drivers of the vectored signal “WB_master_addr”
Expand the HDL Navigation window (if not expanded earlier), which is located adjacently
right side to the RTL viewer window. Now, look for the RTL drivers for the signal
“WB_master_addr” selected in the RTL. You will notice that there is one RTL driver
reported for this signal. By selecting the reported driver object and you will notice that this
will correspondingly highlight the same statement in the RTL viewer window. The
spyglass window will look as follows:
As you can see that only lower half bits(15:0) of the vector signal “WB_master_addr” are
driven by o/p port “adr_0” of instance „ahb2wb_u0 ‟ and there is no other driver reported
for the rest of the bits of vector signal "WB_master_addr" in the HDL Navigation window.
This confirms that upper half bits of the vector signal "WB_master_addr" have no driver
and which in turn resulting the part select(31:16) of instance input port m0_addr_i
undriven as well.
The fix for these violations require an update to RTL. The code however uses an “ifdef”
construct to enable the fixed code as part of the lab. We will enable the macro definition
of “Fix_UndirvenInTerm” in „Set Read Options‟ tab of „Design Setup‟ as we have done for
W415 earlier as follows:
We shall rerun with these additional settings later to confirm that these violations are gone
away.
Switch to goal initial_rtl/lint/synthesis under „Run Goal‟ list of already run goals in Analyze
Results tab. You will see 3 violations for rule InferLatch under Goal=initial_rtl/lint/synthesis
This rule flags all signals where a latch will be inferred during synthesis of the design. So this
rule helps in the detection of RTL code, which can result in the generation of unintended latch
structures.
Expand the rule folder and look at the first violation message, which is reporting that a latch is
inferred for signal "hready". Using RTL cross-probing, you can see that signal ‘hready’ is
getting assigned inside an if statement without an else part and that seems to be the valid
reason for latch inference during synthesis.
If design requires hready signal to be latched w.r.t strobe signal ‘stb_o’, then this is not an unintended
structure. For the purposes of this lab we will assume that these latches are intentional. So typically, user
would not like to see violation messages for intended latch structures again and again. In SpyGlass you
mask the unwanted rule messages by masking them by defining waiver constraints as we have
demonstrated in lab1 (RH click on violation message and selecting „Waive Selected Messages..‟).
Review the violation message, rule and design unit (DU) details on which the waiver is to be
applied in the lower half of the Waiver window. This makes sure that waiver is applied on correct
or desired set of objects. If they are ok, then click on “Apply” button to apply the same on design
under analysis.
If you want to re-use the currently generated waivers in future spyglass runs, then you need to
also save the waiver constraints in a waiver file (.swl). This can be done by selecting option “Save
File As.” on right click menu generated on “New Waiver File pointer under Waiver Files folder”
towards the left hand side of the waiver window. Refer to snapshot below for exact look and feel.
Repeat the same steps to waive the following violations in this as well as other goals like
simulation,structure and synthesis
Remaining InferLatch violations
Violations of rule NoAssignX-ML
Violations of rule STARC-2.10.6.1
Now when you save the project file, SpyGlass will add this waiver file as an input file to the tool.
read_file –type waiver wb_subsystem_files/wb_subsystem.swl
at the same time as you just have single waiver file, so, this one becomes the default waiver file
and is dumped in the project file with following option:
With all the changes done so far, save the project again and exit from UI.
We have additionally observed that for each goal there is an additional built-in warning reported
by rule „HdlLibDuCheck_01‟ which indicates that there are precompiled design units used but rule
checking has not been enabled for them. To get that enabled, you add the following in
wb_subsystem.prj file:
Or using wildcard as these goals are under same task „lint‟ as follows:
8 Block Hand-off
In this lab we will prepare the block we analyzed for hand-off to the SoC team for integration.
To enable the block hand-off, the following SpyGlass data should be packaged
RTL
Project File(s)
SGDC Constraints
SpyGlass Waiver
SpyGlass Dashboard report
SpyGlass Datasheet report
1. The following script will capture all the required data and save it in a new directory
“wb_subsystem_package”
%source package_block.csh
%cd ../spyglass/wb_subsystem_package/spyglass
4. We need to generate the SpyGlass datasheet and SpyGlass dashboard reports for the
block (wb_subsystem) as part of handoff too. These will be done by calling a script as
follows:
% ../tools/run_regression.csh wb_subsystem
Review the datasheet and the dashboard reports. These provide summary of the results that
you see in the design which is being handed off. These reports can be extended for advanced
products/goals which we have not run as part of this lab and so they are coming as empty but
the idea here is to let you introduced to the reports and how to generate the report. You can
also use the dashboard report to watch the progress of the block during RTL development. You
would be required to ensure that Design objectives are passed but they relates to specific
products like CDC, Constraints, DFT and Power and we have not covered them as part of this
training/lab and hence ignoring that part of the report during handoff.
Once this is complete, you may like to copy the datasheet and dashboard reports too- as part
of the package directory and then make it ready to be shipped to the SoC integrator as follows:
% cp –r wb_subsystem/dashboard*
wb_subsystem_package/spyglass/wb_subsystem_files
% cp –r wb_subsystem/datasheet*
wb_subsystem_package/spyglass/wb_subsystem_files
9 Tools
The tool directory contains a number of sample scripts which are used in the training labs.
These scripts are purposely kept simple to illustrate how a user may use those. You are
welcome to use and modify these scripts to use them in your design flows. The scripts include
block_package.csh: Used to assemble the files needed to package an IP for
shipment
run_regression.csh: Used to run multiple goals and aggregate the data