There was an article in yesterday's Wall Street Journal titled "Synopsys
Insiders Sell Hot Stock" (front page of the MONEY & INVESTING section)
which reported that CEO Harvey Jones sold 2/3 of his directly held Synopsys
stock & goes on to point out various other Synopsys board members & bigwigs
selling various percentages of their direct or option-related holdings.
I don't regularly read the Wall Street Journal -- I finally went out and
bought a copy after I got my fifth phone call from people trying to get
the inside scoop on what was going on. For the record, I usually don't pay
attention to the business workings of Synopsys, Inc. But, after a few calls
I've found out that Synopsys officers are given roughly a 30 day window each
quarter to do trading, they still own reams of options on Synopsys stock and
Synopsys encourages its officers to sell their shares over time so as to
not cause blips in the stock price. At the end of yesterday's trading day,
Synopsys stock didn't change from its $47 - $48 price range and the trading
volume of 300,000 shares was on par with their average trading days.
Although I enjoy getting the usual phone calls from engineers wanting to
discuss their projects, methodologies or a better/worst ways to design, I'd
like to say as far as the Wall Street Article's concerned, I've told you
all I know in the preceeding paragraph.
- John Cooley
the ESNUG guy
( ESNUG 146 Item 1 ) ---------------------------------------------- [8/93]
Subject: (ESNUG 145 #4) "Get Latches w/ Sync RESET Instead of Async RESET"
>I was wondering if anybody else out there is having problems with v3.0b
>generating latches with async. resets. I have the following test case:
>
> module rst (d,rst,clk,q);
> input d; // data input to latch
> input rst; // async reset to latch
> input clk; // clock for lath
> output q; // output of latch
> reg q;
> always @(d or rst or clk)
> begin
> if (rst) q = 1'b0;
> else if (clk) q = d;
> end
> endmodule
>
>I set the following variable: hdlin_latch_sync_set_reset="FALSE" I always
>seem to get a latch with an sync reset. Is there any way with v3.0b to
>force an async reset?
From: schooler@boilerbob.corp.mot.com (Tony Schooler)
John, here's the reply I got from the Synopsys hotline on this issue:
This is a follow-up to the problem with the v3.0b not synthesizing to
asynchronous-resetable latches. The problem is that it was a typo in the
release notes!! We just got word that the correct variable is:
hdlin_latch_synch_set_reset = "false"
^^^^
(Note: "synch" is now spelled with an "h" !!!)
We tried it in house, and it works.
Hope this helps anyone else who runs into this problem.
- Tony Schooler
Motorola AIEG
( ESNUG 146 Item 2 ) ---------------------------------------------- [8/93]
From: hendley@suneast.East.Sun.COM (Willis Hendley)
Subject: ( ESNUG 143 #3 ) "Characterized Submodules Inherit Big Wire Models"
In the past I have seen problems with technology libraries that contain the
default capacitances:
default_inout_pin_cap : 1.0;
default_input_pin_cap : 1.0;
This was added (incorrectly) to block hierarchy input pins and therefore
caused large errors in the output loads, especially for otherwise ligtly
loaded outputs. Many levels of hierarchy also aggrevated this.
Is anyone still seeing this with recent versions and/or libraries?
- Willis Hendley
SUN Microsystems
( ESNUG 146 Item 3 ) ---------------------------------------------- [8/93]
From: [ Please Keep Me Anonymous ]
Subject: I'll Trade You This Script For Help!
I have a problem that I'd like to ask help on but not to be just another
person who's all take and no give, I'd like to contribute this simple but
useful dc_shell script to remove a level of hierarchy based on design name.
read -f edif old.edf
#find all designs
a_design_list = find(design, "*")
#find designs with desired prefix--can be suffix or infix
p_design_list = find(design, "prefix*")
#make list of all design with out prefix
b_design_list = a_design_list - p_design_list
foreach (b_design, b_design_list)
{
current_design = b_design
p_cell_list = {}
#get a list of the cells and there designs
report_cell > tmp_r_cell
#get a list of the cells and the designs that you want to ungroup
sh "egrep prefix tmp_r_cell > tmp_rp_cell"
#get a list of the cells only
sh "awk '{printf(" %s,\n", $1)}' tmp_rp_cell > tmp_p_cell"
#make a file with a list of cells to be ungrouped
sh "sed -e '$ s//' tmp_p_cell |\
sed -e '1 s/^/p_cell_list = { /' |\
sed -e '$ s/$/' > tmp_pp_cell"
#add ungroup command to file
sh "awk '{printf(" %s", $0)} \
END {printf("\nungroup p_cell_list -flatten")}' \
tmp_pp_cell > ungroup_cells.cmd"
#run file
include ungroup_cells.cmd
}
sh "rm tmp_r_cell tmp_rp_cell tmp_p_cell tmp_pp_cell ungroup_cells.cmd"
write -hierarchy -format db -output new.db top_level
write -hierarchy -format edif -output new.edf top_level
quit
I used this to remove a level of hierarchy that was created when an old
existing design was mapped from an old technology to a new technology.
The new level of hierarchy was created, by the mapper, so as to distinguish
that a design contain just one gate.
Also note that the awk commands need to be placed in a file and envoked
with awk -f.
Quid pro quo, well, here's my question. In the same hierarchial design, I
no longer need to use some of the functionality so many outputs are no
connected. Going through the hierarchy, if all the gates that drive the
unconnected outputs were removed it would save me about 30% of the size. I
wish to keep the design in a hierarchial form and cannot figure how to get
Synopsys to remove gates that don't drive any nets across a hierarchial
boundry. Is there a way?
- Please Keep Me Anonymous
( ESNUG 146 Item 4 ) ---------------------------------------------- [8/93]
Subject: (ESNUG 145 #5) "Cadence Verilog-XL "-y" Option Doesn't Seem To Work"
>One uses the "-y" option in Verilog to point to your library directory and
>Cadence Verilog is *supposed* to be able to resolve references to each of
>these separate library models in the directory because they follow the
>expected file naming convention of "MODEL.v" ... I found that the
>workaround for this problem is during invocation to use the +libext+
>
> >verilog design.v test_fixture.v -y /usr/asic/lib +libext+.v+
>
>Mind you that this is no earth shattering bug, just an annoyance and
>its workaround.
--- --- ---
From: gwolsk@sei.com (Guntram Wolski)
We've always had to do this.... We are using 1.6a.4 and 1.6a.7.....
- Guntram Wolski
Silicon Engineering, Inc.
--- --- ---
From: nir@zoran.hellnet.org (Nir Sever)
Hi John,
Actually, this isn't a workaround. That's the way it should be. In chapter 24
of the Verilog-XL manual it's written that the -y option assumes that your
library file names are the same as the FIRST module name inside them. Unless
this is the case, and in your case the file names are different, because
they have extention, you must use the +libext+ option.
- Nir (Samburski) Sever
Zoran Microelectronics LTD
--- --- ---
From: brucel@zulu.sps.mot.com (Bruce A. Loyer)
John; I saw your use of the libext in ESNUG 145 Item 5 so I thought I would
share how to have two different extensions, not just one. In my case I had
two different libraries, one that used .V and one that used .v for the
extension. "+libext+.v+.V" seems to have done the trick.
- Bruce A. Loyer
Motorola Semiconductor Product Sector
--- --- ---
From: brad@hdls.COM (Brad Eltman)
John, about your problem with -y option, I don't know if the documentation
has changed but this is really not a bug, this option has always worked this
way and at one time the Cadence documentation was correct ( I haven't looked
lately).
The rule that Verilog(R) follows is:
"module_name_to_resolve" == "filename"
The libext is a modifier for those people who must put a ".v" on the end of
the filename to make life complete. However as almost everyone ships libraries
with a ".v" at the end this option is counter intuitive.
As a side note we have been shipping our libraries for years with no ".v" on
our filenames so we can use the -y option without the libext baggage. You can
also mix librariy directories, i.e. those that have .v filename extentions
with those that don't.
Another note. ESNUG is great. Keep up the good work.
- Brad Eltman
HDL Systems
--- --- ---
From: jcooley@world.std.com (John Cooley)
I was just testing all the Verilog users out there! Honest! Gotta keep ya'll
on your toes to remain technically sharp! Really, I knew this wasn't a bug!
(Why do I get the feeling you don't believe me.... )
On to a serious side, after that response I asked myself why I must have
thought that was a bug. I discovered in retrospect that in the last few
ASIC designs I had done using Verilog, I either had libraries that were in
one file (hence used the -v option), libraries that didn't have any extentions
or, in one case, I aliased "verilog" to contain library with the +libext+.v+
switch.
Guess I should start consulting on more VHDL designs to be safe -- there are
too many experenced Verilog users around to make me look bad... ;^)
- John Cooley
EDA & ASIC Design Consultant
(and ESNUG Moderator, too!)
|
|
