Answers Database
Mentor Graphics/M1/A1 - Recommendations for improving Cross probing into hierarchy
Record #4159
Product Family: Software
Product Line: Mentor
Product Part: crossprobe
Problem Title:
Mentor Graphics/M1/A1 - Recommendations for improving Cross probing into hierarchy
Problem Description:
Urgency: Standard
General Description:
When doing a Timing Simulation Using Xilinx A1.x/M1.x and using Cross Probing
in the Mentor Interface I can probe and simulate all the signals on the top
level. When I push down into my design hierarchy on my original design
viewpoint I am unable to probe signals. I can probe some signals, but
not all of them. When I try and probe a signal I am getting a message in the
Quicksim II window similiar to the following:
Name "/in_3" not found. No selection performed.
The Quicksim II transcript window may show an error similiar to the
following:
// Error: $$add_mapped_traces returned error status at line 747 of file
/products/idea.B4/pkgs/simv.ss5/userware/default/simv_gadget.ample within
function $add_mapped_traces (from: Uims/Ample/Ample_eval 1D)
// Error: Unable to resolve string '/in_3' to a signal or expression (from:
Analysis/SimUI/Session 12)
// Error: Unable to connect expression: '/in_3'. (from:
Analysis/SimUI/Expression 07)
// Error: Cannot resolve name reference: '/in_3'. (from: Analysis/SimUI/Expression 08)
Solution 1:
Even though you use the following guidelines to improve Cross Probing there
will almost always be some signals that you will not be able to cross probe
due to logic optimization or trimming. Please check the MAP report (*.mrp)
to verify what logic was optimized and/or removed to see if this is the
reason Cross probing is not working.
NGDAnno looks at each CLB in the implmentation and attempts to distribute
that CLB's pin to pin delays across the logic that was mapped into it. There
are a number of reasons why this process may not work such as logic
optimization, too much complex logic mapped into a CLB, or logic trimming.
If it fails, ngdanno then finds all the logic mapped into that CLB and flattens the original design
as necessary to bring all of that logic to the
same hierarchy level. Then, it cuts out that logic and replaces it with a
machine generated view of the CLB.
1) After verifying the design is working in Functional Simulation, run the
design through M1 using the default options making sure that the
"Implementation option" Timing tab is set for "EDIF" and vendor "Mentor".
Run the design in Quicksim II with Cross Probing enabled to see if Timing
Simulation is working as expected. If the design does not seem to be
functioning in Timing simulation then you will have to start pushing down
into the design hierarchy to try and narrow down the problem. This is
where some signals may not be found when trying to cross probe back to the
original design.
2) If you are not able to cross probe signals and have verified that the
logic is not removed or optimized, then more than likely this is due to
design flattening that occurs when logical annotation fails. There are
some steps to following to help mitigate the problem:
a) Make sure you have the latest patches installed.
b) Check the ngd2edif report file to check if any hierarchial levels
have been flattened.
c) Do not optimize across hierarchy boundaries, meaning do NOT use
the following MAP options:
1) map -os (logic optimization style for speed|area|balanced)
(Default is None)
2) map -oe (logic optimization effort for normal|high)
(Default is normal)
d) Disable logic replication in MAP.
1) Use map -l (to disable logic replication) if using command line.
2) Using the GUI DESELECT the "Implement Option" in the
"Optimize & Map" tab to Replicate Logic to Allow Logic Reductions.
This may compromise Quality Of Results (QOR).
In the specific case of 4K carry logic driving flip flops presents a
complex delay model that ngdanno can not solve (an FG carry mode that
uses CIN and packs both flops into the same CLB) Thus, if you employ
such an adder driving a register, do NOT put those two elements far
apart in the hieararchy.
3) Re-run the Timing simulation to verify if the design is working or not.
The same results should occur if no design changes were made. Now you
should be able to cross probe the design and debug where the problems
are occurring. Make any necessary design changes.
4) Run the modified design through M1 with the options described in Step 2,
then again verify if Timing simulation is correct.
5) Once the design works in Timing Simulation with the options in Step 2,
rerun the design through M1 without the -l (allowing Logic Replication),
and verify if Timing Simulation is now working or not.
6) Once the design is working in Timing Simulation with Allowing Logic
Replication, this will be the best implmentation of the design.
NOTE: If Quality Of Results is not compromised when using options from
Step 2, then this implementation can be used on the device.
End of Record #4159 - Last Modified: 07/07/98 09:24 |
