From: gunes@jadeite.Eng.Sun.COM (Gunes Aybay)
>Dear John,
>
>Please help advance my career. Six weeks ago my company, Sun Microsystems,
>started a new advertising campaign based around a short haired St. Bernard
>named "Network" as being our new corporate mascot. (The ads have been in
>the business press to target MIS managers.) "Network" is supposed to be
>Scott McNealy's (CEO of Sun Microsystems) dog.
>
>I grew up in Turkey. To me, St. Bernards are the dogs used for search and
>rescue operations on European mountains to find buried skiers. In cartoons,
>they're sometimes seen as drunk because they're drawn carrying small barrels
>of liquor under their collars. (What this has to do with networking I don't
>understand. I asked my co-workers & none of them associate networking with
>St. Bernards or any other dogs either. They just know that the people
>upstairs like it and that's what counts!) Inside Sun, they have a bulletin
>board with critical info like how much "Network" weighs and a message of the
>day like: "Today it was hot. Network drank a lot of water." They even put
>his dog house in front of Sun's headquarters for a while -- until they moved
>it in front of the company cafeteria. (Is this a good sign about our
>cafeteria food, John? No one here will talk about this.)
>
>John, here is how you can help me. Please take all the *gourmet* dog food
>you get from your dog food drive for Joe Costello and ship it to my CEO,
>Scott McNealy, here in California. (I'll pay for shipping.) Please add the
>following *handwritten* note:
>
> "Dear Scott,
> One of your best designers, <unreadable name>, thought you'd
> love this gourmet dogfood for Network!
> - John Cooley"
>
>When Scott phones you to find out who the unreadable name is, if he seems
>happy, tell him: "Oh, that was my good friend Gunes Aybay! Gunes Aybay is
>not only a joker, Gunes Aybay is one of your best designers! You should give
>Gunes Aybay a raise and a promotion in my opinion, Scott!" BUT, IF HE SEEMS
>ANGRY, quickly tell him: "I can't remember who wanted me to send you the dog
>food. I'm really busy now. Can't talk. Gotta go!"
>
> - Gunes Aybay
> Sun Microsystems
>
>P.S. It's OK to publish this letter on Internet. Half of Sun's management
>is busy walking "Network" around the building and the other half are on
>"pooper scooper" duty. They won't have time to find this on Internet! :^)
( ESNUG 224 Item 1 ) ---------------------------------------------- [8/8/95]
Subject: (ESNUG 222 #4) BSDL File Creation
>Does anyone know of a 'good' way to generate a BSDL file to describe a design
>that's been built using Synopsys Test Compiler / Design Compiler ? Synopsys
>is talking about a product (feature) that does this automatically that will
>be introduced at some point in the future, but I'm looking for a more
>immediate solution that doesn't require us to create the BSDL files manually.
From: lombardi@ctron.com (Steven J. Lombardi)
John,
We are using a program (BSDLMaker) developed by Intellitech. We needed a tool
to create BSDL models of our ASICs for use on our JTAG tester (and also, as
Pete mentioned, did not want to create them manually). We brought in a company
called Intellitech (CJ Clark) to help us out. Intellitech developed a program
to take our gate level Verilog netlist and generate a BSDL file. I believe it
is now available for purchase (no, we don't have any affiliation with
Intellitech nor share in the sales profits of the software).
Our methodology used Synopsys Test Compiler to insert JTAG and we designed our
ASICs using LSI's 300K technology. In addition to generating the BSDL, it
performs some very helpful 1149.1 design compliance checks. The program is
easy to use and it works very well. They were open to suggestions during
development and supportive during beta and the initial release. You can reach
Intellitech at "cjclark@intellitech.com"
- Steve Lombardi
Cabletron Systems
[ Editor's Note: Intellitech is the company that gave out the Best Juvenile
DAC Freebie with its Super Soaker pistol, too! :^) - John ]
( ESNUG 224 Item 2 ) ---------------------------------------------- [8/8/95]
Subject: (ESNUG 223 #5) Handling Unconnected Ports
>John, Question for the masses: What's the accepted way of leaving a port
>unconnected? We're instantiating transceivers in our design (to communicate
>with off-chip signals), but the transceiver model has ports that we don't
>need to use. Do we tie all these ports to an "unused" signal? Wouldn't this
>tie them together then? How do I handle this?
From: Dave Chapman <dchapman@well.com>
There are (at least) two ways to make a placeholder for unused pins:
Neanderthal Method:
inout unused_0, unused_1, ..., unused_n;
Cro-Magnon Method:
inout [n..0] unused;
Perhaps some of the more evolved folks can show you other methods, but I just
upgraded to being a Cro-Magnon, and am proud of it!
-Dave Chapman
( ESNUG 224 Item 3 ) ---------------------------------------------- [8/8/95]
Subject: (ESNUG 222 #1 223 #2) Verilog Parsers, full_case, parallel_case 3.3a
>Personally, I hate the new Synopsys Verilog 3.3a parser. With the following:
>
> always@ (A0 or M)
> case (A0) // synopsys full_case
> 3'b 000 : z0 = 0;
> 3'b 001 : z0 = M[0];
> 3'b 010 : z0 = M[1];
> 3'b 100 : z0 = M[2];
> default : z0 = 1'bX;
> endcase
>
>It has a "default" statement therefore it is complete by definition -- yet I
>get the following message:
>
> Warning: You are using the \fBfull_case\fP directivewith a case
> statement in which not all cases are covered. (HDL-370)
>
>What is "\fBfull_case\fP" ?? Not all cases covered?? It has a "default"!
> (Fortunately, the resulting logic seems correct.)
From: [ No Muck Please ]
John, (anonymity, please, I just wanted to follow-up on this)
The warnings from the 3.3a Verilog reader (via the "full_case" and
"parallel_case" compiler directives) are wrong. According to Synopsys, they
can safely be ignored (assuming the case statements are indeed full/parallel).
- [ No Muck Please ]
( ESNUG 224 Item 4 ) ---------------------------------------------- [8/8/95]
From: wboeke@hzsda01.att.com (W. Boeke)
Subject: Scripting Hierarchical Compiles & Critiques Of The Scripting Language
Hi, John!
This letter serves 2 purposes. First I want to express my rejoice that I
finally managed to write a generic, robust Design Compiler script for
hierarchical designs. Second I want to criticize the semantics of the dc_shell
scripting language, and find out if my colleague ESNUG members share these
opinions.
My goal was to write a script that does a true hierarchical compile, such that
the user only has to supply the HDL entities that have been modified. The tool
then should leave the other designs in the hierarchy unmodified. The problem
is that the user does not know the names of subdesigns, because Design
Compiler gives fancy names to them during scan-chain insertion, uniquifying
and parameterizing of the subdesigns. The script exists in several varieties,
depending on how the scan-chains are specified: described in the source HDL or
inserted automatically. I give the version in which all scan-chains are
created by the tool. Here comes part of the script:
1 | Top_design = des_a
2 | Re_analyze = { des_b des_c }
3 | read db/ + Top_design + .db
4 | current_design Top_design
5 | check_design /* Needed for setting attributes */
6 | Sub_designs = find(reference "*")
| Sub_designs = filter(Sub_designs,"@is_hierarchical == true && \
@is_synlib_operator == false")
7 | foreach(Cur_design, Sub_designs) {
8 | current_design find(design,Cur_design)
9 | Name = get_attribute(find(design,Cur_design),hdl_template)
10 | foreach(Name,Name) {
11 | rename_design find(design,Cur_design) Name
12 | if (dc_shell_status == 0) { remove_design find(design,Cur_design)
| }
| }
| }
Variable Re_analyze in line 2 determines the HDL files that must be
(re)analyzed. In line 3 the hierarchical design is read from the database. In
line 6, a list of all relevant subdesigns is assigned to variable Sub_designs.
In line 7, a tric starts: all subdesigns get a name equal to the original name
as specified in the HDL source text. Designs with duplicate names are removed.
The foreach loop in line 10 has one purpose: in line 9 variable Name has value
{xxx}, whereas in line 11 a value xxx (without curly braces) is needed.
13 | foreach(Cur_design, Re_analyze) {
14 | Parameter = ""
15 | if (Cur_design == xx) { File = { xx xx-bhv }; Parameter = "width=>4"
16 | } else { File = Cur_design
| }
17 | foreach(File,File) { File = vhdl/ + File + .vhd
18 | analyze -f vhdl File
| }
19 | if (Cur_design != Top_design) {
20 | remove_design find(design Cur_design)
21 | elaborate Cur_design -par Parameter
| }
| }
Starting line 13, dedicated HDL files are re-analyzed. By the if statement in
line 15, file names and VHDL generics are specified. Before elaboration in
line 21, the old subdesign must be removed, because else it would be placed in
memory 2 times, which would yield an error later-on.
22 | remove_design find(design Top_design)
23 | elaborate Top_design
24 | check_design /* Needed for setting attributes */
In line 23 the toplevel design is elaborated. Apart from unmapped subdesigns,
this toplevel design now contains old, already compiled subdesigns, named by
their original name. This means that during compilation of the toplevel these
subdesigns can be resolved. The check_design command in line 24 is needed
because else some attributes are not properly set.
25 | Sub_designs = find(reference "*")
| Sub_designs = filter(Sub_designs,"@is_hierarchical == true && \
@is_synlib_operator == false && @is_mapped == false")
26 | foreach(Cur_design, Sub_designs + Top_design) {
27 | current_design find(design Cur_design)
| /* timing constraints ... */
28 | remove_clock -all
29 | derive_clocks
30 | Clock = find(port,all_clocks())
31 | if (Clock != {}) {
32 | create_clock -name CK -period Ckperiod Clock
| /* timing constraints ... */
33 | set_scan_style multiplexed_flip_flop
34 | } else {
35 | set_max_delay Combdelay -from all_inputs() -to all_outputs()
| }
37 | uniquify
38 | compile -incremental_mapping
| }
In the lines starting 26 the new subdesigns and the toplevel are compiled. In
lines 28 - 31 the sequential subdesigns are separated from the non-sequential,
because they need different timing constraints. In line 37 subdesigns might
get new names. In line 38 they are compiled for the first time.
39 | current_design Top_design
| /* Define test ports ... */
40 | insert_test
In line 40 remarkable things happen. The toplevel now contains a mix of
subdesigns with and without scan-chains. The tool manages to recognize the
subdesigns that it can leave unmodified, it only gives them a new name,
containing the string "_test". Finally it completes the scan-chains.
| /* More timing constraints ... */
41 | Sub_designs = filter(find(reference "*"),"@is_hierarchical == true")
42 | set_dont_touch Sub_designs
43 | foreach(Cur_design, Sub_designs) {
44 | current_design Top_design
45 | Instance = filter(find(cell,"*"), "@ref_name == Cur_design")
46 | characterize -constraints Instance
47 | current_design find(design Cur_design)
48 | compile -incremental_mapping
| }
49 | current_design Top_design
50 | compile -incremental_mapping
51 | write -hier -out db/ + Top_design + .db
52 | check_test
53 | report_test -scan_path >> Report_file
Starting line 43 all subdesigns are constrained automatically. Notice the
transition from design name towards instance name in lines 45 and 46. The rest
is straight-forward. Line 52 is needed else line 53 won't work. The whole
script works only one level deep, and a flaw occurs if identical subdesigns
exist that are parameterized differently.
If somebody has comments, or knows better solutions, please let him react. The
script emerged thanks to 2 courses, manuals reading, experimenting and sending
emails to the hotline. This last sentence is meant as a transition to my next
point: I rather disagree with the semantics of the Synopsys scripting
language.
// synopsys esnug_soapbox_mode on
Designers nowadays are accustomed to well-structured, strongly typed languages
like VHDL and Verilog. But for their dc_shell scripts, they are forced to use
a language that is not very perfect. The typing rules are complex and obscure.
The correct working of commands is sometimes a matter of try-and-error, even
for the hotline staff. The understanding of some types is difficult, e.g. can
somebody tell the exact distinction between a design, a cell and a reference?
Attributes are indispensable for making scripts do what you want, but it is
often unclear at what moment they are set by the tool. Is an attribute set
after reading the database, after elaboration or after compilation? If it is
set for a reference, is it also set for a cell? Some attributes appear to be
set only after seamingly unrelated commands (e.g. line 5). User-defined
variables often must be type cast by a find command, but if this is obligatory
again is a matter of try-and-error. Between different versions of the tool the
rules appear to change, so my scripts maybe will not work in the next release.
Some decades of programming language development has revealed rules that every
computer language should adhere to. The Synopsys scripting language serves to
control very complicated and sophisticated machinery, but has syntax and
semantics that is unclear, ill-documented and error-prone. Ladies and
gentlemen, software developers at Synopsys, may I give some suggestions?
1. Commands must do what they promise. E.g. the "find" command in line 30 only
works if preceeded by derive_clocks, and this command only works in all
circumstances if preceeded by the command in line 28 (remove_clock -all).
Also, report_test only works if preceeded by check_test. Command
report_attribute yields an incomplete list of attributes. Many more
examples of unclear behaviour exist.
2. The scope of commands is unclear. Why is the result of find(design,"*") all
designs in memory, and find(reference,"*") only the references in the
current design?
3. What is the use of a design placed in memory more then once? It is a burden
for the designer, because he is forced to clean this up explicitly.
4. Names in scripts are case sensitive, whereas VHDL is not. So VHDL code that
has been beautyfied by somebody may not work with an old script. At that,
the case of component names in libraries often is unknown. Please find a
solution for this.
5. The tool should take the consequences of found errors earlier, it is not
useful to go on after a real error. The tool should stop then, and release
its licence.
6. User-defined variables should be declared, complete with their type, before
they can be used, for the sake of safety. Also, all predefined variables
should have a type. The exact type of all command and function parameters
should be documented. If types do not match, the find command could perform
the necessary type casts. As it is now, if e.g. an addition of 2 variables
is needed (like: xx + yy), then it seems to be a question of luck how this
is interpreted by the tool (will it be: xxyy, or: { xx yy }).
7. Forget about the following types: design, reference, cell and lib_cell.
Replace them by 2 types: generic and instance. An instance should inherit
all attributes and mappings from its generic, whereas attributes and
mappings of instances can be added or modified. Thus, the uniquify command
would not be needed anymore. If a generic is (re)compiled, all its
instances get the same mapping. After this, the instances could be modified
by a command like
re_compile find(instance,"*")
// synopsys esnug_soapbox_mode off
I would like to close with a request to proceed with the good work: all tools,
from Behavioural Compiler up to Test Compiler controlled by one language, in
one environment.
- W. Boeke
AT&T
( ESNUG 224 Item 5 ) ---------------------------------------------- [8/8/95]
From: drama@india.ti.com (D Ramanath)
Subject: Miracle Healing Of EDIF "write" Problem
Hi John,
I faced a problem with the Synopsys 3.2b while I am writing out a design in
EDIF. I read a design in EDIF and selected a cell in it. I executed the
"link" command and later I tried to save the design with a different name in
EDIF (using the write command). I got an error saying the "write" failed.
After selecting the design and executing the link command, I looked at the
gate level netlist to see whether there was any problem. I did nothing.
Next, when I saved the design with some other name & it happily worked. (???)
Is it a Bug or a Feature ?
- D. Ramanath
Texas Instruments
|
|
