>"The late John Jacob Astor, a personage little given to poetic enthusiasm,
> had no hesitation in pronouncing my first grand point to be prudence; my
> next method. I do not speak it in vanity, but simply record the fact,
> that I was not unemployed in my profession by the late John Jacob Astor;
> a name which, I admit, I love to repeat, for it hath a rounded and
> orbicular sound to it, and rings like unto bullion. I will freely add,
> that I was not insensible to the late John Jacob Astor's good opinion."
From: stai@Brocadesouth.COM (Jeff Stai)
John, Let me try and convert it to 'engineer-ese' for you:
1.1 John Jacob Astor (JJA) thought I made a good point.
1.2 I like saying JJA's name. It sounds cool.
1.3 I thought highly of JJA's opinion.
>"As during the telling of the story, Captain Delano had once or twice
> started at the occasional cymballing of the hatchet-polishers, wondering
> why such an interruption should be allowed, especially in that part of
> the ship, and in the ears of an invalid; and, moreover, as the hatchets
> had anything but an attractive look, and the handlers of them still less
> so, it was, therefore, to tell the truth, not without some lurking
> reluctance, or even shrinking, it may be, that Captain Delano, with
> apparent complaisance, aquiesced in his host's invitation."
2.1 Hatchet-polishers are too loud.
2.2 The hatchets were ugly in spite of polishing.
2.3 Hatchet-polishers are ugly, too.
2.4 Despite the noise & poor location, Cap't D. accepted the invite.
Don't blame Melville, John! Check out this snippet from a recent Fibre
Channel draft standard (FC-PH-2):
"NOTE: For example, an SB CH can use TPLS to determine CU Login state for
that CH & an SB CU can use TPLS to determine CH Login state for that CU."
Your guess is as good as mine... :^)
- Jeff Stai
Brocade Communications Systems, Inc.
---- ---- ---- ---- ---- ---- ---- ----
From: vitalcom@batnet.com (Lou Covey)
John,
I read with amusement; quiet but, nonetheless, sustained, your less then
enthusiastic, yet heartfelt, reaction to the writing of Herman Melville, a
name which, when spoken in the hushed circles of academia, bring a sly,
almost Satanic smile to the lips of literature professors who, beyond
doubt, know a small and long-held, though horrific truth: that Melville, as
successful as he may have been; a success that I, with a deep personal
longing, hope to find as well, was a hack and, in truth, the only good,
that is to say, readable work was Moby Dick.
Damn, I'm good. :^) If you want literature with a kick, read Swift.
- Lou Covey
VitalCom, an EDA PR firm
( ESNUG 252 Item 1 ) -------------------------------------------- [9/96]
[ Editor's Note: Due to the size of this detailed solution,
400+ lines, this is the only item in ESNUG 252. - John ]
Subject: (ESNUG 249 #8) Correlating Mapped Xilinx to HDL Advisor 3.4b GTECH
> As part of my Xilinx XC4000 FPGA design process, I'm using HDL Advisor to
> get a pre-mapped prediction of the results my source code would produce. I
> used info provided by the HDL Advisor to go back & refine my source code.
>
> Now that I have synthesized my design I want to take the mapped design
> back to HDL Advisor & try correlating the pre-mapped predictions with the
> mapped results. Obviously, the Xilinx FPGA architecture & designware make
> it hard to correlate back to the Advisor GTECH (Boolean Generic Tech.)
>
> I was hoping to use this approach with two objectives. The 1st to simplify
> & somewhat automate the correlation between my mapped design and my source
> code. The second, to get a feeling for the relationship between HDL
> Advisor GTECH predictions (using only two input logic functions) and the
> Xilinx FPGA mapped design.
>
> Has anyone tried this approach successfully? Is this function supported by
> HDL Advisor (It's GUI seems to indicate that it can be done.)
>
> - David Mullenex
> Network Equipment Technologies
From: [ Three Synopsys HDL Advisor Support People ]
Hi, John,
The answer to this user's question is quite involved, but, in following
your policy of keeping ESNUG a user-driven technical resource, here's the
*entire* enchalada.
Before going into detail on "Mapped -> Gtech Correlation" it makes sense to
give a brief summary of what Mapped and GTECH Analysis are.
GTECH is a Synopsys term for Generic TECHnology. The GTECH circuit is the
direct product of Verilog/VHDL analysis & elaboration. In this state the
circuit is represented using technology independent boolean gates
"equations". The circuit is then optimized & mapped to a target technology.
Analysis of the GTECH circuit is independent of the mapped circuit and can
be performed prior to synthesis.
Analyzing GTECH Circuits
------------------------
Although the GTECH circuit has is a technology independent boolean
represenataion, it does contain the initial implied hardware structure
of the RTL code. It is this seed or starting point which is the single
dominant factor in the quality of results from synthesis. The quality
of the starting point is the factor which limits or enhances the
quality of your result.
Once knowledge of the initial structure or starting point is understood
the designer can make modifications to the RTL to produce a more
desirable structure and achieve a better result.
GTECH Analysis Gotchas
----------------------
The GOOD news is -> GTECH Analysis is Technology Independent
The BAD news is -> GTECH Analysis is Technology Independent
The quality of your GTECH is the quality of your RTL code and is something
you can take with you from technology to technology and is good for design
reuse. The problem is that your design performance is measured with
respect to environmental real-world issues which are embodied as physical
constraints. These constraints are inherently technology dependent.
For example:
create_clock -name CLK -period 20 {Clk}
set_input_delay -clock CLK AddrStrobe 15
The input arrival time of AddrStrobe wrt CLK will make it a critical signal.
GTECH Analysis will indicate the number of logic levels on paths from
AddrStrobe but will not flag the path as being critical. It is the
contstraint which makes the relative determination of "critical". GTECH
analysis is an *absolute* frame of reference.
The other problem is, although it may appear like bragging, that sometimes
Design Compiler can be really good! I know we all bitch about what it
misses but it does do *some* optimization. One of the really annoying
things about GTECH analysis is that I can "fix" something which will get
fixed anyways during optimization. Although there are some general
rules-of-thumb which can be used to gauge this and set expectations it is
fundamentally difficult to know the exact result of synthesis before
actually running the compiler. The best solution to this gotcha is:
"If it ain't broke, don't fix it."
And there is only one real way to see if it is broke...
Mapped Analysis
---------------
Mapped Analysis overcomes some of the gotchas inherent to GTECH analysis.
This is done by performing analysis on the mapped circuit. One obvious
issue here is that this requires a constrained mapped circuit (my_design.db)
which has been generated by Design Compiler. This requires additional
effort to synthesize and constrain the design.
Mapped Analysis gets timing numbers by using DesignTime and reports
slack in nsec. This is a much more "real" number. The area numbers
and timing values are all ones which can be obtained by running reports
in DesignCompiler *but* HDL Advisor adds Graphical views which help
you analyze and debug the results.
Mapped Analysis Gotchas
-----------------------
Here the catch is really fundamental. What users really like to
do is click on gates in their circuits and see where they come from in
the RTL code. The catch is that after optimization there is no longer
a 1-to-1 correspondence between the RTL and the circuit. The trade-off
between correlation (traceability) and optimization is a FUNDAMENTAL
issue -- but we can bend "the rules" a bit. When most people do Mapped
Analysis, they do not care as much about the specific gate but more about
the gate in context of the critical timing path. In other words, a designer
is tracing a path from:
Start_Reg/Q -> End_Reg/D [A Q->D path]
(Yes, it really starts at the CP pin.) The "loophole" is:
THE ENDPOINTS ARE INVARIANT thru RTL synthesis.
It is this little gem that allows reasonable and productive correlation
between the Mapped circuit and RTL source.
Going From Mapped To Gtech Correlation
--------------------------------------
Correlating the mapped results back to the source is a powerful analysis
method which allows you to understand what source to change to get a better
result. Correlation between the pre-optimized GTECH cicuit and the Verilog/
VHDL source is 1-to-1. Once a circuit is optimized the 1-to-1 mapping
between the Verilog/VHDL and gate level circuit is lost. This is
fundamental to the very nature of optimization. However, not all points
in the unmapped circuit are altered during optimization. Registers
(flops & latches) as well as top-level I/O are invariant through the
synthesis process. The correlation engine in HDL Advisor can be used
to analyze paths between these invariant start and end points.
In order to perform this correlation you need the following items:
File Description
---- -----------
MyModule.db Mapped Design database
Mymodule.v|vhd Verilog/VHDL RTL Design database + subsidiary source
files (like "packages" and "include" files)
VendorLib.db Semiconductor Vendor Library
The Synopsys licences required are:
DesignTime or DesignCompiler plus HDL Advisor
Build a GTECH design database from the Verilog/VHDL Source files. This is
identical to GTECH or Source Analysis. In fact you can re-use the ".ha"
file if you were previously doing GTECH Analysis. Once all of the GTECH
files (.ha) have been created. Build the GTECH and Mapped designs.
Once both of the design databases have been loaded into HDL Advisor bring up
a Histogram and click on the slack button. This will give you a Histogram
in terms of slack with the paths with the least amount of slack (critical
paths) on the left.
Once you have selected an end-point you must bring up the Path Browser and
click on the Worst Mapped Button. This brings up the worst mapped path to
the endpoint which as selected in the Histogram. To correlate this with the
GTECH code you still need to press the Mapped->Gtech button. This finds the
longest GTECH path (measured in logic levels) between the endpoints in the
mapped path. These end-points are matched in the original GTECH design. The
longest path between the two is simply the intersection of the paths in the
transitive fan-out of the start-point and the fan-in (cone of logic) of
the end-point. A summary of the steps:
1. Build GTECH design (.ha files)
2. Load GTECH & Mapped Design
3. Find Critical Path
4. PRESS Worst Mapped in Path Browser
5. PRESS Mapped->GTECH in Path Browser.
Gotchas While Going From Mapped To Gtech Correlation
----------------------------------------------------
-- Naming Differences between GTECH and Mapped
Since HDL Advisor attempts to match names between the GTECH and Mapped
databases it is essential to keep these names the same. The following
class of gotchas are all synthesis directives which cause name
mismatches.
1. bus_naming_style
2. change_names
3. set_boundary_optimization
4. group/ungroup
-- Bus Naming Style
During Mapped Correlation HDL Advisor attempts to match fixed points such
as register and I/O boundaries with in the pre and post synthesis database.
If the bus naming convention is different in both circumstances then HDL
Advisor can not match us the ports.
For example:
A[1] -> A_1 after mapping.
The documented solution is to keep the bus_name_style value the same.
The easiest wasy to do this is to set it in the .synopsys_dc.setup and
not to change it as part of a synthesis script.
-- Change Names
The command change_names changes the names of ports, cells and nets in a
design. This interferes with correlation and must be avoided.
-- Boundary Optimization
This directive causes some ports to be re-named as per the
port_complement_naming_style variable. Again this should be avoided since
it changes port names.
-- Group & Ungroup performed during Synthesis
Since HDL Advisor attempts to match points between the pre and post
mapped design databases it is a good idea to maintain the logical
hierarchy throughout the synthesis process. Even if the final production
synthesis runs use an different hierarchy, you should use a hierarchy
that matches (and you are familiar with) during simulation AND synthesis
debug tasks.
There is improved support for group/ungroup in v3.5a.
-- Build Window complains about [module].db not being found
This occurs if a mapped verison of the module is found in the path
presented to HDL Advisor. The workaround is to change the name of the
file (move it out of the way). Do not try to get too tricky and change
the path. There are TWO places the path is specified, in the
.synopsys_ha.setup as well as the .synopsys_dc.setup. The ha_shell
uses the .synopsys_dc.setup (not .synopsys_ha.setup) but the build GUI
uses information from BOTH files. This was for some backwards
compatibility with existing dc_shell methodology and scripts.
This problem will be flagged with error HDL-83 in v3.5a but we did
not have time to fix it for this release. The fix will be part of
the release which follows v3.5a.
-- Instantiated Library Cells
If the RTL source code contains instantiations of cells from a Silicon
vendor's technology library these have to be linked in even during GTECH
Analysis. This can be done by setting the following variable in the Project
Settings Window.
ha_gtech_link_library = VendorTechnology.db
-- Mapped to GTECH brings up the wrong path.
When you press the Mapped->GTECH button in path Browser HDL Advisor find
the longest path (in logic Levels) between the two selected end-points. The
end-point are matched in the GTECH design and the longest path is the
longest path in the GTECH design. This is not always the path which is
the most critical. You may be trying to fix the 3rd longest path between
the end-points. (This is not the case most of the time but it can easily
happen.) Although this may seem frustrating this is really not a BUG but
a FEATURE.
During synthesis, the optimizer will fix the longest path but often at the
expense of the other already shorter paths. The path which is critical to
you may have actually gotten longer in order to reduce timing on the path
which you are "erroneously" looking at. Fixing this "non-critical" path
will likely improve the path you really want to fix.
(John, we used this technique to improve the timing in your "famous" Verilog
vs. VHDL design contest at SNUG'95 where the engineers had to design an
up-by-5/down-by-3 counter with parity. The paths in question were 11, 9, 9,
7, & 7 logic levels. The critical path was the 3rd path and only 9 logic
levels. The other 2 "longer" paths were already optimized. This approach
help improve timing on the 3rd path even though they had already been
"fixed" by the optimizer.)
FPGA-Specific Gotchas With Mapped To Gtech Correlation
------------------------------------------------------
First off, FPGAs are just different. The logic is not implemented as
discrete SOG (Sea Of Gates) type ASIC technology so correlation to something
like a Xilinx CLB required a different interpretation. The relevant
commands considered here are:
1. group/ungroup
2. replace_fpga
3. insert_pad
[ Editor's Note: What follows is a discussion between the HDL Advisor
Technical Marketing Manager (TMM), the Field Apps Engineer (FAE), and
the Corporate Apps Engineer (CAE) about the FPGA gotchas. - John ]
-- Group and Ungroup performed during synthesis
[TMM] Why is this mentioned again for FPGAs?? [FAE] The compile strategy
recommended for Xilinx was to compile with "ungroup -all" (which is BAD for
HDL Advisor.)
-- replace_fpga and timing values
[FAE] After compile, we save the .db file, and then perform "replace_fpga"
command. This command will translate the CLB netlist to "gates
equivalance" netlist. With this netlist, we get our start and end point
register name back. This is actually required (I think it is still) by
Xilinx for their place and route tool. The problem is that report_timing
will show different timing values than the CLB netlist has shown, since now
DesignTime is adding the delay of each "equivalance gate", even though a
CLB may have absorbed many level of logic gate into one logic function (the
advantage of CLB.)
[TMM] The important issue in this case is not that the timing matches after
the replace_fpga command but that the reported critical paths are still
critical with the new timing values. In general this should be the case but
it will be very difficult to guarantee. As long as the ordered list of
critical paths is roughly in the same order, that is all that is important.
(After all your plan is to make changes to the code.)
[FAE] Another bit of information. The original gtech analysis did not
identify the same critical path until later. For example, your worst gtech
are 21 levels, and the actual critical path (after mapped) has 13 gtech
logic level. Some of the inaccuracy may be due to FSM encoding.
[TMM] Of course, this is the reason that you want to perform a mapped
analysis. Actual timing and technology dependent constraints can make a
BIG difference to which paths are critical. GTECH analysis by itself
can only be used to identify _long_ paths. Mapped analysis is needed to
identify _critical_ paths.
-- Bidirects and the insert_pad command
[FAE & CAE] At fist this was thought to be an inconsistency between Design
Compiler and the HDL Advisor since HDL Advisor reported a combinational
feedback loop while Design Compiler didn't. After a closer examination we
were able to get both tools to report the combinational feedback path. The
discrepancy was attributed to an insert_pad command included in the
synthesis scripts. Once the pad has been inserted Design Compiler does
not flag the path as a feedback path. The combinational loop is the result
of a path which starts and ends at a internal bidirect. There is no current
workaround other than trying to eliminate the root cause of the combo
feedback path.
[TMM] This only re-enforces my long held believe that you should just stay
away from internal bidirects. They can cause all sorts of problems.
[CAE] An insert_pad caused the FPGA Compiler to look at all of the logic
surrounding the pad to pick an appropriate I/O cell. Mainly the compiler is
looking for a tristate of bi-direct driver on the port. This driver is
incorporated into the pad I/O cell. A feedback path may or may not be found
depending on how the vendor has implemented this pad I/O cell in the target
technology library.
[ TMM, FAE, & CAE ] Anyway, John, we hope this helps!
- [ Three Synopsys HDL Advisor Support People ]
|
|
