After months of gentle persuasion I finally managed to talk my girlfriend
into getting an e-mail account so she could experience the Internet first
hand. She told me she wasn't interested but she secretly bought a techie
magazine with a floppy disk offering "FREE 10 HOURS OF INTERNET ACCESS WITH
AMERICA ON-LINE!" to surprise me with an e-mail letter. She loaded the
floppy on her computer, answered all the required questions (name, address,
credit card number) and logged on AOL. Within her first hour, she got what
she thought was a normal security check (which she filled out again) of:
AMERICA ON-LINE SECURITY: Please re-verify your account bellow.
NAME:_____________________________ ACCOUNT NAME:___________
ADDRESS:_____________________________ PASSWORD:___________
CREDIT CARD NUMBER:___________________ CARD EXP. DATE:______
The next day she tried to log on but found her AOL account was restricted
because "it was used to attempt to access other AOL customers private
information." And now *I'm* in the dog house because my join-the-Internet
advice allowed some hacker to get her credit card number and caused our
panicked rush to cancel that credit card! (Aaargh!)
- John Cooley
the ESNUG guy
( ESNUG 242 Item 1 ) ---------------------------------------------- [7/96]
Subject: (ESNUG 241 #2) Is Anyone Using The Synopsys ECL Compiler?
> Do you know anybody who uses Design Compiler for ECL? The people at the
> Munich support center told me that ECL is not supported since 3.1a.
> However by browsing the library compiler books in iview I found a lot of
> features for ECL libs in 3.4a. If ECL is not supported, why is it still
> in the latest version of the Library Compiler? Is anybody doing great ECL
> designs in a very secret lab with 3.4a & I just don't have the licenses?
From: [ Synopsys Synthesis Marketing ]
Dear John,
Synopsys has been slowly phasing out ECL Compiler over the past two years
due to a lack of customer demand. We have not been actively selling the
product and our focus has been on working with ECL Compiler customers on a
transition plan to other products. The last version of software and
documentation to still contain ECL Compiler references and code was 3.4a
which was released in January 1996. Synopsys will not be providing support
to existing ECL Compiler customers beyond the 3.4a release.
- [ Synopsys Synthesis Marketing ]
( ESNUG 242 Item 2 ) ---------------------------------------------- [7/96]
From: gmann@ford.com (Greg Mann)
Subject: The Ford Verilog Coding Style for State Machines
John, I just wanted to share an improved style for encoding state machines
that we've discovered at Ford Microelectronics.
A rather simple modification in the coding style of a state machine can both
shave off area and improve timing. For a particular test case the reported
cell area was 14% less with loose timing. When timing was over-constrained,
the area was 4% less with slightly better timing. The "compare_design"
command was used to verify that the designs were functionally equivalent.
We've seen some variation in the effect of the style change, but in each
case, there was some area improvement.
Our original style was to lump all the combinational logic of the state
machine into a single "always" block and "case" statement like:
always @(state or .....)
// set defaults
...
case (state)
0: begin
...
end
1: begin
...
end
....
endcase
Our modified code simply separates the state decode from the other logic by
putting it into its own separate "always" block. This creates a one-hot
encoding which is used in the original always block.
always @(state)
begin
state0 <= #1 1'b0; // all states default to 0's
state1 <= #1 1'b0;
...
case (state)
0: state0 <= #1 1'b1; // one-hot set to 1
1: state1 <= #1 1'b1;
....
endcase
end
always @(state0 or state1 or ...)
... set defaults here
case (1'b1) // synopsys full_case parallel_case
state0: begin
...
end
state1: begin
...
end
....
endcase
My theory is that area is improved due to better sharing of logic in the
state decode and in the resulting simplification of the logic following the
decode. Anyone else have any clever FSM encoding tricks?
- Greg Mann
Ford Microelectronics Inc.
( ESNUG 242 Item 3 ) ---------------------------------------------- [7/96]
From: charles@efficient.com (Charles Shelor)
Subject: Got Burned With Design Compiler 3.4a VHDL Package Names Restriction
John,
We have a moderately large project that will eventually have 7 or 8 people
designing and testing. We have a hierarchical file structure and library
organization to assist organization, configuration control, and project
understanding. Thus we have a VHDL package of common definitions for the
entire project, plus VHDL packages of local definitions for each of the major
VHDL components if appropriate. I am attempting to compile the local VHDL
definitions package for my block. I have successfully compiled the common
VHDL definitions block into its library called 'chip_com'. I can compile the
local VHDL definitions package into its library, 'fc' using "vhdlan".
However, when I try to "analyze" using dc_shell, I get the following error:
Error: Type SLV not found on line 107 (VHDL-2157)
where SLV is a subtype of std_logic_vector that is defined in the common
definitions package. OK, I'll not create a subtype of a subtype since that
might be too complicated for DC. I editted the local definitions file and
globally replaced 'SLV' with 'std_logic_vector'. When I ran dc_shell again,
I received a memory segmentation violation!
analyze -format vhdl -library fc vhdl/definitions.vhd
Loading db file '/usr/synopsys/libraries/syn/standard.sldb'
Loading db file '/usr/synopsys/libraries/syn/gtech.db'
Reading in the Synopsys vhdl primitives.
/home/charles/molokai/chip/design/vhdl/definitions.vhd:
Segmentation Fault
Questions: Why can't I use the subtype SLV defined in 'chip_com.definitions'
to define another subtype in 'fc.definitions' within DC when it works for
VSS? When SLV is replaced in 'fc.definitions' with the ieee type
std_logic_vector, why does DC cause a memory segmentation violation?
ANSWERS: Changing the name of the 'fc.definitions' package to 'fc.defs' fixes
both problems! Easy enough WORK-AROUND (note: this is still a BUG in DC) but
it now requires the project staff to coordinate to ensure that we do not name
any packages the same as anyone else!!! Not difficult but certainly annoying
to have to come up with 9 or 10 different names that mean definitions,
textio, utilities, ... Not to mention the time that I've spent trying to
figure out what was wrong!
- Charles F. Shelor
Efficient Networks, Inc.
( ESNUG 242 Item 4 ) ---------------------------------------------- [7/96]
Subject: ( ESNUG 241 #9 ) Will Trade My Secret Switches For Yours!
> I'd like to see more secret switches "exposed" in ESNUG. In trade, here's
> mine: I was having headaches with Synopsys putting in unnecessary buffers.
> (I figured out that there was no capacitance, fannout, or timing problem, but
> I was still getting two inverters on each output.) Here's the fix:
>
> /* clean up unnecessary inverters */
> compile_clean_inverters = true
>
> (Sure enough. My extra inverters went away. I am wondering why Synopsys
> hasn't published this switch. Could there be some sort of side effect?
> So far, I have had no problems with it.) Has anyone else found any helpful
> undocumented features that they would like to share?
From: [ Jerry's Kids ]
John, keep me anonymous, please. Although the following was found at my
previous job, my current management may not like it. I didn't ask, either.
I remember trying to find as many as possible of these 2 years ago, and I
found out that a few of them were documented in solv-it, as bug workarounds.
I did a search with "hidden variable" or somesuch and got:
ccl_disable (to disable connection_class )
compile_force_local_dont_care (used by compare_design)
force_input_tran_for_output_tran (used by translate)
seqmap_on (enables/disables sequential mapping)
tlud_use_low_timing_effort (used by translate)
use_nonlinear_delay_model (library selection)
I do not know if they are still valid, some may have disappeared, etc.
- [ Jerry's Kids ]
---- ---- ---- ---- ----
From: tims@dct.rti.org ( Tim Sawinska)
John,
My favorite semi-secret switch is "compile_use_low_timing_effort = true".
I've seen it speed up compiles 10X. (And that's with a piece-wise linear
style library.) It makes the neighborhood for timing re-calculation smaller,
and thus faster, for each of those trials you see Synopsys going through.
- Tim Sawinska
Data Communications Technologies
---- ---- ---- ---- ----
From: [ A Little Bird ]
Hi John, Best keep me "anonymous."
Here's a list of variables I extracted from the dc_shell binary source code.
None of these appear in manual pages or in the Synopsys Iview collections.
I don't know what these commands/variables do (that's where the fun is!),
but I'm sure we'd all be grateful to hear from people who figure them out!
Commands:
bc_partition_logic check_clocks
context_check_disable_cmds context_check_enable_cmds
define_function define_rtl_operation
derive_clock_parameters disable_latch_transparency
distribute_capacitance extract_clock_tree
fv_control group_clock_tree
ignore_memory_loop_precedences ignore_memory_precedences
log_to_phys ph_cluster_cell
ph_create_cluster prepare_design_for_compile
report_scc_execution_status reset_iddq_invalid_state
set_iddq_invalid_state set_jtag_bsdl
syntax_check_enable_cmds write_jtag_bsdl
Variables:
annotation_control atpg_bidirect_output_only
channel_width_denominator channel_width_numerator
check_db_checksums combine_vertical_logic_groups
compile_characterize_black_boxes compile_clean_inverters
compile_enable_master_slave_inference compile_resyn_duplicate_logic
compile_use_fast_sequential_mode fast_partitioning
filter_check_real_by_default gen_ignore_bus_bit_order
hdlin_minimize_tree_delay hdlin_reg_test_print
hdlin_report_resource_costs hdlin_resource_sharing_mode
hdlin_share_common_subexpressions hdlin_share_effort
hdlin_tdrs_script_source left_justify_logic_constants
write_new_format_db_files logic_group_height_percent
logic_group_width_percent port_edge_rate
read_flexible_db_files sc_check_file_existence
scc_execute_sh_command scc_print_usage_message
test_force_bidir_pads_inwards test_force_capture_clocks
test_no_three_state_conflicts_after_capture text_unselect_on_button_press
level_sensitive_startpoint_close_active_edge
Perhaps a Synopsys R&D person would like to correct me, but from what I hear,
Synopsys like to include new software pre-release and leave it hidden behind
a switch so that they can test it a while longer. It also gives them a
chance to field test the feature with some luckless soul who can't get by
without it and has to resort to some new feature which perhaps has some
side-effects (such as a new optimisation that can wreck or save your design).
- [ A Little Bird ]
( ESNUG 242 Item 5 ) ---------------------------------------------- [7/96]
Subject: ( ESNUG 240 #4 ) Backannotation, Visibility, & 'Characterize'
From: rray@msai.mea.com (Russell Ray)
> I'm not an expert on what is really happening but I ran into this same
> problem with only using set_load and set_resistance commands. It appears
> that the loads are only visible if the current design is set to the same
> design as whey you performed the set_load commands. When the current
> design is anything else, they are not taken into account.
From: rnair@BayNetworks.COM (Rajesh Nair)
> Design Constraints, Timing constraints and any Backannotated parameters will
> only apply in the context of the design to which it was applied. (Because
> one could potentially be using the same subdesign in other designs or in
> another context in the same design. In this case, you would not want the
> backannotated value from the previous design to be present any more.)
From: greg@cqt.com (Greg Bell)
John,
I don't think this is true... there's another case. What they're talking
about is executing the set_load commands from the top level, and their effect
not being visible when you make the current_design a lower level (moving
DOWN the hierarchy).
But we're backannotating lower blocks, then moving UP the hierarchy. Just
now I ran a test, doing a "diff" of two "report_constraints -all_violators".
One report was generated after backannotating my way, and the other by
backannotating from the top level (after editing the backannotation files to
have the correct hierarchy information). The reports were the same.
So the generalization that the set_load commands are only visible from the
design where they were run seems incorrect. Rather, the tool will propagate
their effects up the hierarchy, but not down it (use characterize for that).
- Greg Bell
CommQuest Technologies
( ESNUG 242 Item 6 ) ---------------------------------------------- [7/96]
Subject: (ESNUG 240 #7) Synchronous Reset Thru An ALU Still Gives Xes!
> I've run across another "FEATURE" of Synopsys that has landed me into a
> large heap of Sheep DIP! I have a design that has a number of registers
> that are all fed by a simple ALU. Rather than have all of the registers
> use an asynchronous reset (at a cost of 1-2 gates per D FF), I simply have
> the ALU perform the following operation:
>
> 0 "AND" X
>
> And then load the resulting 0 in all of the registers by simply enabling
> all of their clock enables. Now, 0 "AND" X normally would produce 0 on
> any output of the ALU. After all, 0 "AND" *anything* should be 0, right?
> -- well, *not* according to Synopsys! I still get Xes out of my ALU!
> Naturally when I try to run my gate-level simulation I never even get out
> of reset! From reading various SOLVIT, app notes and online docs, I see
> where I could add the attribute sync_set_reset if there were some registers
> to attach it to. But since the block in question is purely combinitorial,
> what can I do?
From: Bruce Nepple <bcn@ccm.seikotsi.com>
John,
Regarding Eric being in sheep dip, I suspect that there are an awful lot of
"unneeded" logic gates in the world just to get around simulators that can't
deal logically with unknowns (this *is* a simulator issue, not a design
compiler issue). Maybe someday a simulator manufacturer will see unknown
resolution as a competitive edge (saves gates and time). The situations
where I seem to get nailed are best represented by multi-stage synchronizers
that feed-back to reset the input FF (always zero after a couple of clocks,
but always X in Verilog-XL) and logic that effectively creates 0 or 1 with
0 = A & ~A or 1 = A | ~A (always 0 or 1 in the real world, but will propagate
X's like sheep dip through a flea farm). The latter case can be spread over
many gates, and is probably what is happening to Eric. I've always solved
these either by adding gates (async. resets or whatever) or by using the
"force" function in verilog (rah rah verilog) to force critical internal
pins to zero for the first cycle. I've actually added an unused reset
pin to an IC just for simulation and fault grading. Again, I don't blame
the design compiler.
- Bruce Nepple
Seiko Communications Systems
---- ---- ---- ---- ----
From: Michael_Armstrong@BayNetworks.COM (Michael Armstrong)
John, I don't think this issue is as simple as it seems.
A simple example that sheds some light on this question is the following:
If I have a 2-input multiplexer with zero's on both inputs and an 'X' on the
select line, should I get a zero out? The answer is probably yes, but most
models of the multiplexer would put out an 'X' if the select line is unknown
regardless of the inputs instead of handling the special case of all inputs
being zero (or one, for that matter). Just think if you had a 64-input
multiplexer - should the model look for all 64 inputs to be low and handle
that special case? It might be technically correct to do so, but I think
most models would not bother. In some cases the 'X' would be the better
answer; if the select line was metastable and was not at a legal logic level,
then the output would be unknown.
- Mike Armstrong
Bay Networks
---- ---- ---- ---- ----
From: dj@lsil.com (Darren Jones)
Hey John,
In an ALU we designed, we have a similar problem. The reason in our case was
that the ALU was implementing the AND function using XOR gates (I won't go
into the gate-level details.) It ends up that if the first operand is 0, the
logic XORs the second operand with the inverted second operand. Obviously,
this would always have a result of zero in real silicon, but in simulation,
if the second operand is X, its inverted value is also X and the function
ends up with an X as a result!
In our case, it was only a problem with the structural model -- the RTL model
works fine. One solution was to change the order of the operands -- instead
of "0 AND X", try "X AND 0". I doubt that this is something Design Compiler
would be able to figure out.
- Darren Jones
LSI Logic
( ESNUG 242 Item 7 ) ---------------------------------------------- [7/96]
From: Don_Monroe@synnet.com (Don Monroe)
Subject: What Is IBM Like To Work With As A Foundry?
John, I am curious as to whether anyone has personal experiences with IBM as
an ASIC vendor. I am looking for information and opinions about how they are
to work with as an ASIC vendor with regards to tools support and issues,
general responsiveness to problems, flexibility to work with their customers
needs and requirements, etc.
- Don Monroe
3Com
( ESNUG 242 Item 8 ) ---------------------------------------------- [7/96]
From: Dean Warren <dwarren@ccm.jf.intel.com>
Subject: Seeking Comparisons Of Actel 32xxx vs. Altera 10K For Synthesis
John, Can you help me understand the tradeoffs betwen the Actel 32xxx and
Altera 10K as it relates to synthesis and ASIC conversion? Specifically I
will be using Synopsys to sythesis VHDL to one of these parts and later
converting to an ASIC.
- Dean Warren
Intel
[ Editor's Note: As always, if you need to be Anonymous with
anything on ESNUG, just say so in your letter! - John ]
|
|
