Editor's Note: As many of you know, I live on a sheep farm that's about
45 minutes west of Boston called the "Holliston Poor Farm". (Before they
had Welfare and Social Security, they used to have a poor house or a poor
farm in every town in New England where the extremely poor went to work
for food.) A few months ago, we recieved some official looking mail for
a housemate who hadn't lived with us for at least 3 years. It was from
the Massachusetts Department of Motor Vehicles and was addressed to him
at the "Holliston Pore Farm". After a few jokes about "Clearasil" (an
acne medicine) and how our landlord looks a little like Wolfman Jack (a
famous California DJ who did ads for "Clearasil"), we (my housemates
& I) thought nothing of it. Fast forward a few months and now that long
lost housemate is getting weird mail from lab supply companies, beauty
supply warehouses, and the American Dermatological Society. Huh? Seeing
that the ex-housemate was a lawyer, all this skin stuff didn't make
sense -- until we noticed it was addressed (again) to the "Holliston Pore
Farm". It now appears that because some screwy state government employee
at the DMV typed "Pore" instead of "Poor", we're on some mailing list as
a dermatological laboratory and/or beauty salon! Life is truely weird
sometimes...
- John Cooley
your ESNUG dermatologist
( ESNUG 295 Item 1 ) ----------------------------------------------- [7/8/98]
Subject: (ESNUG 293 #3) "Women In EDA" pre-DAC Conference June 14
> Thanks for sending this mail about 'Women in EDA'. It was interesting just
> to read the agenda. It's even motivated me into thinking about where I
> want to go with my own career! Which has taken a bit of a back burner
> while I had my 2 little ones (age 4 and 1).
>
> - Sue Keppie
> Senior Apps. Support Engineer
> Mitel Semiconductor Devon, UK
From: Suzy Price <suzyp@us.ibm.com>
John,
Second my thanks. It got me fired up enough to remember that there is a
group called Women In Technology International (WITI), which sounds like
it addresses similar issues, although they extend beyond it. Just wanted
to put in a pointer to their website - www.witi.com.
- Suzy Price
Printer Controller Development
IBM
( ESNUG 295 Item 2 ) ----------------------------------------------- [7/8/98]
Subject: ( ESNUG 279 #3 ) An Intel Rebuttal To The Module Compiler Debate
> We evaluated Module Compiler here for a "math-intensive" project I'm
> working on. This tool is cool. We came up with 8 different variants of
> a mammoth pipelined multiplier (*really wide*) within a week including one
> day of instruction and a day of learning curve. Something like this would
> have taken months to develop and we were able to go back to management and
> say "here's a matrix of size vs. performance w/ various implementations".
> Never saw a manager's jaw drop so fast when we were able to provide a real
> close gate count and performance eval.
>
> - [ "Intel Inside" ]
---- ---- ---- ---- ---- ---- ----
> To twist an infamous quote from a former EDA CEO -- if Synopsys put
> "DogFood Compiler" on the market, would users be sending ESNUG testimonials
> about how tasty the gravy bits are?
>
> Module Compiler used to be the SciArc Datapath internal tool. Even though
> Synopsys bought SciArc & is trying to reposition them as a Design Reuse/IP
> vendor, deep down they really truly want to be the "standard" ASIC vendor.
> This is the old EDA vs. ASIC CAD argument with a twist. Do you think that
> Synopsys really wants us independent consultants & ASIC vendors adding our
> value to silicon; when they have the opportunity to make everybody produce
> the same lousy gates in all designs using Synopsys tools, IP, & designers?
>
> The following is an evaluation of Module Compiler from Synopsys w.r.t the
> recently announced Tera Systems' TeraPath integrated into the LSI Logic
> FlexStream datapath tool suite. In it I discuss the libraries, synthesis,
> wireload models, timing budgeting, and HDLs.
>
> - [ Some "CADs" At LSI Logic ]
From: [ "Another Intel Inside" ]
John,
I know this is a bit late but here it is, please do not use my name. But
use "Another Intel Inside". Thanks.
I read ESNUG 275 #1 and 279 #3, and it stated "Screw Module Compiler; Use
TeraPath Instead." This was in response to a message from "Intel Inside"
that MC was cool. I am not the author of that post, but I have used MC on
a project at Intel so here is my response. I will try to make it brief
since reading a long article like the TeraPath post makes me think a
marketing dude wrote it, not a designer.
I only used MC and not TeraPath, so I won't do a market comparison. In my
experience, Module Compiler worked well. A summary of the results is that
we met timing, size was a little larger (10-15%) on the data path, saved us
about 2-3 heads for 6-9 months, and aided us in the back-end work using
standard automatic place & route instead of having to use expensive hand
tweaked P&R. I think the tool was successful in helping us achieving our
goals. Now for some details.
I used Module Compiler for high speed data paths (300-400Mhz) and got
great results. I could try several implementations and see which would
get the best results. In two of the cases, the implementations were not
the best, but changing the design and re-running it was simple. To change
the design took about an hour or so to re-iterate through the
Tweak In Module Compiler -> Generate RTL -> Simulation
loop. (The bottle neck for us was the simulator.) In comparison, the
process of changing the design & resimulating using traditional methods took
about the same time since the vast majority of the time is spent in
simulation. Having unsimulatable MC code is an inconvenience -- not a
drawback, in my opinion.
The lack of layout information did not seem to bother the place and
route tool that we used. I will admit, I do want this feature but in this
design it did not matter. I think there would have been a possible area
savings with links-to-layout information in MC, but the timing came in
just fine. I think that MC must have layout data in a future version, as
I might not be this lucky again!
About libraries. The libraries I used are meant for control logic, not
for data paths. I didn't have much say in this decision, as I am only a
designer. However, Module Compiler made psuedo cells that it likes and
did its job. I believe I could have had a faster and smaller design if I
had the psuedo cells as primitives. We are now researching the possiblity
of adding MC-friendly primitive cells added to our library for better
performance.
As a designer I do the design and control the time budget for my blocks in
the chip. I guess it is not much of an issue due to the fact if planned out
well at the start, another new tool isn't need a tool to do your job. We
didn't initially plan for it's use and we didn't use MC for the entire chip.
However, we have had little or no trouble of getting all the pieces working
together and at 300-400Mhz I find that amazing.
Last issue is that MC has its own code. Yes, I have had to learn the MC
langauge. However I had to learn C shell, perl, awk, sed, C, VHDL, Verilog,
and an internal Intel HDL in my careeer, so another language really did not
matter.
It took me a week to code four blocks of the main data path and about an
hour to interate each new implementation. Most of the time (as I mentioned
before) was spent in simulation. Even if I had used another data path tool,
I'd still be spending time in simulation.
I will admit that are a few inconviences with MC but a lot less than other
tools I have used to do my job. Overall, I would use Module Compiler again,
without hesitation, which I cannot say for most of the EDA tools I use.
- [ "Another Intel Inside" ]
( ESNUG 295 Item 3 ) ----------------------------------------------- [7/8/98]
Subject: ( ESNUG 292 #1 ) Synopsys Should Catch Up On In-Place Optimization
> I thought you might be interested in a new product from Avanti. Saturn
> ( formerly Solar & Solar II) is a post-layout synthesis & optimization
> tool from Avanti that eliminates the need for IPO. Avanti claims that with
> VDSM you need a very tight synthesis/layout loop (duh!) to converge & meet
> timing goals. The interesting thing is that Avanti has acquired synthesis
> technology and stealthily struck at a Synopsys weakness. I find it hard to
> believe Avanti's claims, but they claims to support re-sizing gates, pin
> swapping, buffer insertion, and boolean optimization for post-layout
> optimization. It claims to work on million gate designs in reasonable
> times. They also claim to accurately output Verilog netlists and Synopsys
> ECO Compiler scripts (whoa!). (If some or most of this is true, they are
> way ahead of Synopsys. Maybe if someone kicks Synopsys in the pants the
> way Ambit did, they will finally get their act together with links to
> layout the way they did with 1998.02 for large block top-down synthesis.
> Maybe if you publicize this, it will happen even faster.)
>
> - [ I Came, I Saw, They Conquered ]
From: [ One Of Those Evil Cadence Marketing Guys ]
Dear John,
It seems like Avant! is playing catch-up game on the In-Place Optimization
front. Cadence's PB-Opt (Placement Based Optimization) product does
post-layout in-place optimization and is well integrated into our flow.
And BTW, this product has been out there for more than 3 years now...
- [ One Of Those Evil Cadence Marketing Guys ]
( ESNUG 295 Item 4 ) ----------------------------------------------- [7/8/98]
From: Victor_Duvanenko@truevision.com
Subject: Sun Workstation Stability Problem -- It Crashes Once A Day!
John,
I've been having a Sun Sparc station stability problem for the last couple
of months, and now it seems to crash about once a day (and for no appearent
reason). I have a dual-CPU 200 MHz machine with 1GBytes of RAM and believe
to be running the latest kernel patches of Solaris OS. The latest theory
that we have is that it is some sort of multi-CPU problem, since the crashes
seem to occur unpredictably. We have plenty of swap space allocated. Has
anyone run into a problem similar to this?
- Victor J. Duvanenko
Truevision
( ESNUG 295 Item 5 ) ----------------------------------------------- [7/8/98]
Subject: How To Translate Cadence Symbols Into A Synopsys Symbol Library
> I have Cadence symbols. I hope I can translate them to Synopsys symbol
> library. Can some tools or utilities do that for me?
>
> - Yung Hsiang Lai
> ALI Taiwan
From: chenmin <chenm@163.net>
You can put all the cadence symbols in a schematic, then edifout a edif
file xx.edif. You use the following synopsys command:
read_lib -format edif xx.edif -symbol xx.slib
write_lib xx -output xx.sdb
xx.sdb is what you want.
- Chenmin
Beijing Telegraph Administration Beijing, China
---- ---- ---- ---- ---- ---- ----
From: Igor Orlovsky <oia@javad.ru>
This procedure is described in Synopsys' "EDIF Interface User's Guide":
1. Make a schematic in Cadence with all the symbols you need to translate.
2. Run edifout to make graphical EDIF with the symbols:
% edifout edifout.il
where edifout.il is:
edifOutKeys = list(nil
'searchPath ". ~ /user/cds/etc/cdslib /user/cds/etc/cdslib/sheets"
'outputFile "cadence.edif"
'library "DESIGNS"
'cell "test"
'viewName "schematic"
'externalLibList "basic"
'netlistOption "TRUE"
'hierarchyFile ""
'ILFile ""
'design ""
'techFile "/user/cds/samples/techfile/default.tf"
'ripperLibraryName "ripper"
'ripperCellName "ripper"
'ripperViewName "symbol"
'version ""
)
You can take mentioned "ripper" library from Synopsys' interface to
Cadence examples.
3. Create a Synopsys ASCII symbol library:
dc_shell> read_lib Your_EDIF_File -format edif -symbol Your_Library.slib
Your had better also use Cadence-compatible libraries from Synopsys
interface with Cadence examples directory. Put these commands in your
.synopsys_dc.setup file:
symbol_library = symbol_library +
{ basic.sdb ripper.sdb US.8ths.sdb } ;
search_path = search_path + " <path_to_cadence_libraries>" ;
/* EDIF read symbol library variables */
edifin_lib_in_port_symbol = "ipin"
edifin_lib_out_port_symbol = "opin"
edifin_lib_inout_port_symbol = "iopin"
edifin_lib_in_osc_symbol = "iosc"
edifin_lib_out_osc_symbol = "oosc"
edifin_lib_logic_1_symbol = "vdd"
edifin_lib_logic_0_symbol = "gnd"
edifin_lib_ripper_bits_property = "schPatchExpr"
edifin_lib_ripper_bus_end = "bus_end"
edifin_lib_ripper_cell_end = "ripper"
edifin_lib_ripper_view_name = "symbol"
edifin_lib_route_grid = 1024
edifin_lib_templates = {{A,landscape,Asize},{A,portrait,Asize.book}, \
{B,landscape,Bsize},{C,landscape,Csize},{D,landscape,Dsize}, \
{E,landscape,Esize},{F,landscape,Fsize}}
/* Bus Naming variables */
bus_naming_style = "%s<%d>"
bus_dimension_separator_style = "><"
bus_range_separator_style = ":"
bus_extraction_style = "%s<%d:%d>"
bus_minus_style = "-%d"
edifout_no_array = "false"
/* Read design variagles */
edifin_autoconnect_offPageConnectors = "true"
edifin_delete_empty_cells = "true"
edifin_delete_ripper_cells = "true"
/* Power and Ground variables */
edifin_ground_net_name = "gnd!"
edifin_ground_net_property_name = ""
edifin_ground_net_property_value = ""
edifout_ground_name = "gnd"
edifout_ground_net_name = "gnd!"
edifout_ground_net_property_name = ""
edifout_ground_net_property_value = ""
edifout_ground_pin_name = "gnd!"
edifin_power_net_name = "vdd!"
edifin_power_net_property_name = ""
edifin_power_net_property_value = ""
edifout_power_name = "vdd"
edifout_power_net_name = "vdd!"
edifout_power_net_property_name = ""
edifout_power_net_property_value = ""
edifout_power_pin_name = "vdd!"
edifout_power_and_ground_representation = "net"
/* Net to Port Connection variables */
edifin_autoconnect_ports = "true"
compile_fix_multiple_port_nets = "true"
gen_match_ripper_wire_widths = "true"
edifout_name_rippers_same_as_wires = "false"
link_force_case = "case_insensitive"
single_group_per_sheet = "true"
use_port_name_for_oscs = "false"
write_name_nets_same_as_ports = "true"
/* Output variables */
edifout_netlist_only = "false"
edifout_external = "true"
edifout_translate_origin = "center"
edifout_display_instance_names = "false"
edifout_display_net_name = "false"
edifout_target_system = "cadence"
edifout_instantiate_ports = "true"
edifout_pin_name_property_name = "pinName"
edifout_designs_library_name = "SYNOPSYS"
4. Change scale in the header of your SLIB file and the name of the
library:
library("DESIGNS") {
SCALE = 1.0 / 10.0;
ROUTE_GRID = 1024;
set_route_grid(ROUTE_GRID);
set_meter_scale(0.0254 / (160 * SCALE * ROUTE_GRID));
5. Re-read symbol library in dc_shell with changed scale:
dc_shell> read_lib Your_Library.slib
6. Save symbols database:
dc_shell> write_lib Your_library -o Your_Library.sdb
7. Do not forget to add this library in your symbol library list in
.synopsys_dc.setup.
You can read these steps more detaily in "EDIF Interface User's Guide"
NOTE: These steps worked in older Synopsys release, they could differ in
the latest ones.
- Igor Orlovsky
JAVAD Positioning Systems Moscow, Russia
( ESNUG 295 Item 6 ) ----------------------------------------------- [7/8/98]
From: "Chris Cope" <chrisc@ppsol.com>
Subject: 'Translate' Headaches With Buffering, dont_touch, & Incrementals
John,
We are attempting to translate a very large design from one technology to
another similar one.
Our first attempt was to load the big .db file in and let her rip. But the
major sub-blocks have dont-touches, so it didn't penetrate the hierarchy.
Our Synopsys rep told us that we would have to manually traverse the
hierarchy removing these for it to work. He said that using a:
remove_attribute find(design,"*",-hierarchy) dont_touch
would not even work (no real explanation given).
Rather than do that, we loaded the Verilog netlist of the entire design in
and ran translate on it. This worked great since all constraints and
attributes are not present. But, many of our buffer networks had been
removed. Apparently, Synopsys does some optimizing in the translate step.
Since we had no constraints, it decided that these buffers were not needed.
So we loaded each sub-block .db file and ran translate on that. This does
have constraint info. But, alas, our buffer network was still destroyed.
I am now trying an incremental compile. But this is so time-consuming, I'm
about to start over from VHDL.
I totally understand that translate must use some smarts when figuring out
how to map cells that don't exist in the new library. But a huge selection
of buffers do exist and it sees fit to just take them out. Any ideas on why
it does this? Or how to solve my original translation problem?
- Chris Cope
Pinpoint Solutions
( ESNUG 295 Item 7 ) ----------------------------------------------- [7/8/98]
Subject: (ESNUG 293 #9 292 #8) Synopsys VHDL Compiler Handling Of X"FF"
> Perhaps Anon is refering to the 1987 LRM in his message. Anon is however
> correct that the use of such a feature is not likely to be portable --
> especially in a world where the big guns can trample on standards simply
> because they feel like it.At any rate perhaps Cadence & Synopsys engineers
> should read the LRM and implement the language semantics as described.
>
> - Tim Davis
From: Murdo McKissock <mjm@sqf.hp.com>
1. Has anyone done a survey of which tools support the 1993 VHDL standard?
The Exemplar synthesis tools and Model Tech simulator claim full support
for VHDL'93 while Synopsys always used to be strictly VHDL'87. I wonder
about more recent Synopsys tools like FPGA Express?
Hex constants are handy, but direct instantiation of an entity without a
component would save much duplication in routine VHDL design entry.
2. Below is my package to implement hexadecimal literals. "hex" is shorter
than "To_StdLogicVector", is synthesizable, allows assignment to vectors
where the length is not a multiple of 4 and supports non-binary states.
Examples of use:
signal byte_val : std_logic_vector(7 downto 0);
signal odd_val : std_logic_vector(9 downto 0);
...
byte_val <= hex("5A");
odd_val <= hex("2FE",10);
byte_val <= hex("ZZ");
Package:
library ieee;
use ieee.std_logic_1164.all;
use std.textio.all;
use ieee.std_logic_arith.all;
package hex_util is
type hex_char is ('U', 'X', '0', '1', '2', '3', '4', '5', '6', '7',
'8', '9', 'A', 'B', 'C', 'D', 'E', 'F', 'Z', '-');
type hex_vector is ARRAY(natural range <>) of hex_char;
function hex(b : hex_vector; width : integer := 0)
return std_logic_vector;
end hex_util;
package body hex_util is
function hex(b : hex_vector; width : integer := 0)
return std_logic_vector is
constant b_width : integer := b'length * 4;
variable result : std_logic_vector(b_width - 1 downto 0);
variable j : natural;
begin
j:= b_width;
for i in b'range loop -- Scan b from left to right
j:= j - 4;
case b(i) is
-- If the next line gives trouble in synthesis, you may be trying
-- to use "hex" with a non-static string argument. Changing this
-- line to assign "XXXX" would make it synthesizable, but the
-- compiler would have to work overtime to reduce the resulting
-- logic to a static value. Just look at an unmapped design!
when 'U' => result(j+3 downto j) := "UUUU";
when 'X' => result(j+3 downto j) := "XXXX";
when '0' => result(j+3 downto j) := "0000";
when '1' => result(j+3 downto j) := "0001";
when '2' => result(j+3 downto j) := "0010";
when '3' => result(j+3 downto j) := "0011";
when '4' => result(j+3 downto j) := "0100";
when '5' => result(j+3 downto j) := "0101";
when '6' => result(j+3 downto j) := "0110";
when '7' => result(j+3 downto j) := "0111";
when '8' => result(j+3 downto j) := "1000";
when '9' => result(j+3 downto j) := "1001";
when 'A' => result(j+3 downto j) := "1010";
when 'B' => result(j+3 downto j) := "1011";
when 'C' => result(j+3 downto j) := "1100";
when 'D' => result(j+3 downto j) := "1101";
when 'E' => result(j+3 downto j) := "1110";
when 'F' => result(j+3 downto j) := "1111";
when 'Z' => result(j+3 downto j) := "ZZZZ";
when '-' => result(j+3 downto j) := "----";
end case;
end loop;
if width > 0 then
for i in b_width - 1 downto width loop
assert result(i) /= '1' report
"Error: function hex tried to assign '1' to a non-existent bit";
end loop;
return result(width - 1 downto 0);
else
return result;
end if;
end;
end hex_util;
Hope this helps.
- Murdo McKissock
Hewlett-Packard Ltd.
( ESNUG 295 Item 8 ) ----------------------------------------------- [7/8/98]
Subject: How To Know Exactly Which Synopsys DesignWare Parts I'm Using
> I'm looking for a way to get the architecture (rpl, cla, clf, ...) dc_shell
> selected for designware parts. I can see it in the compile log file and
> -sure- I could do a little perl to retrieve it but... I'd prefer something
> like an attribute or a dedicated function.
>
> - Diego Coste
> Hewlett-Packard Company Grenoble, France
From: Ansgar Bambynek <a.bambynek@avm.de>
If you just want to see the DesignWare components the Design Compiler uses
just do a report_resources. This command will list you all the used
DesignWare components and the appropriate architecure used.
- Ansgar Bambynek
AVM Germany
---- ---- ---- ---- ---- ---- ----
From: Juergen Stallmann <stallmann.pad@sni.de>
Just try "report_resources". This report shows you the implementations for
the used designware parts
- Juergen Stallmann
Siemens Nixdorf Information Systems Paderborn, Germany
( ESNUG 295 Item 9 ) ----------------------------------------------- [7/8/98]
From: tcoonan@mindspring.com (Thomas A. Coonan)
Subject: For Sale -- One QUICKTURN hardware emulator
We have a Quickturn hardware emulator which we no longer wish to support in
our flow. Anyone interested in this device should contact my boss, David
Burleson at: David.Burleson@Sciatl.com
- Tom Coonan
Scientific Atlanta
( ESNUG 295 Item 10 ) ---------------------------------------------- [7/8/98]
Subject: ( ESNUG 291 #5 292 #4) Boba Fett's View Of The Synopsys Hotline
> But in that same ESNUG 292, an anonymous Synopsys contractor (using the
> pseudonym "Boba Fett of the Evil Empire"), cyncically told the rest of the
> story with: "You guys can't imagine what a chore it is, fighting my way in
> to work at Synopsys every day through the ravening hoards of experienced
> design engineers who are vying for the very few prized openings in Synopsys
> Tech. Support, just desperate to get that choice job listening to whining,
> insulting and obnoxious engineers like the above calling them on the
> telephone all day, each caller taking the attitude that their project is
> the only one in the world that's late, that they are Synopsys' number one
> priority, and that Synopsys should send them a patch for their particular
> problem yesterday, even if it can't be reproduced. How many experienced
> design engineers do YOU know who would be willing to take on a helpline
> job, full-time? And how much would we have to pay you?"
From: [ Call Me (HP's) Ishmael ]
John,
Pleez anonomyze me... Boba Fett's comment got to me: "If you think Design
Compiler license is expensive NOW...."
Yes, I *do* think DC is expensive. For what we pay for our site license,
which serves less than 10 engineers, we could pay the salaries and bennies
of 5 more engineers. Do you know what we could do with 5 more engineers
on a project? A lot! So for Synopsys to survive in the next few years
they must do at least some of the following:
1) lower the price of the tools
2) increase the value of the tools
3) improve the technical support of the tools (thus increasing the
value)
They tend to put their efforts on 2) in the areas of feature creep and
new gadgets, while ignoring 1) and 3), or making them worse. This is tough
stuff to swallow for any company, let me tell you. Synopsys, if they want
to simply survive, will work on 1) and 3).
I suspect the reason engineers call the hotline with an attitude is that
because they realize they are understaffed and overworked *because* of
the tool, not *in spite* of it.
- [ Call Me (HP's) Ishmael ]
---- ---- ---- ---- ---- ---- ----
From: landmh@taec.toshiba.com (Howard Landman)
John, you've unconsciously bought into Boba Fett's assumption that helpline
answering *should* be a full-time job. But why? That guarantees that, on
average, it falls to the less competent, and bores even *them* to tears.
When Robert Townsend was president of Avis (the "We Try Harder" campaign was
one product of his tenure there), he instituted a policy that *every*
*single* *employee* in the company had to work a reservation desk at least
2 weeks per year. Some people had trouble with this at first. The VP of
Finance fainted dead away at the approach of his first real customer.
But consider the benefits. The people who wrote the software system for
entering the rentals, had to actually spend 2 weeks *using* the system
they wrote. The people who designed the forms had to spend 2 weeks
filling them out. And so did their bosses, and their bosses' bosses.
Needless to say, a lot of small stupid annoying problems got identified *and*
*fixed* rather quickly. Because everyone up and down the management chain
knew exactly, from personal experience, how annoying they were.
Now, imagine that *every* Synopsys employee, from Aart and Harvey on down,
was required to spend 2 weeks per year in some form of customer contact;
either answering the hotline, or helping the AEs, or assisting sales calls.
Imagine the possibilities!
By the way, I heartily recommend Townsend's book "Up The Organization".
Good advice has seldom been funnier.
- Howard A. Landman
Toshiba
---- ---- ---- ---- ---- ---- ----
From: Tim Davis <timdavis@tdcon.com>
In answer to the questions, "How many experienced design engineers do YOU
know who would be willing to take on a helpline job, full-time? And how
much would we have to pay you?", posed by Boba Fett (of the Evil Empire)
my response is, "I would take the job full time and for only $150/hr."
- Tim Davis
Timothy Davis Consulting
---- ---- ---- ---- ---- ---- ----
From: dchapman@goldmountain.com (Dave Chapman)
Dear John,
I was on a support desk at my first job out of college: IBM mainframes.
After about 20 phone calls in a row "When will the system be back up?"
"I'm sorry, I don't know.", you develop a burning need to get another job.
I would be willing to consider a job at the help desk, but it would cost
them $200/hour, and I'd work 2 days a week MAX. Most people wouldn't do
it at any price. Go figure.
- Dave Chapman
Goldmountain
( ESNUG 295 Item 11 ) ---------------------------------------------- [7/8/98]
Subject: ( ESNUG 293 #13 ) Anyone Have dc_perl Running On An HP Machine?
> I'm still trying to find someone who is using dc_perl on an HP machine.
> I'm willing to do some of the work, but need some information to get
> started. Can anyone else help?
>
> - Paul LaBerge
> Micron
From: Edwin Huffstutler~ <ehuff@sedona.ch.intel.com>
John -
Yes, I have a one working internally here (heavily modified with other
stuff, or else I could post it someplace), but only by ditching Comm.pl.
Basically, you need to get the latest Expect.pm and IO:Tty perl packages
from CPAN and convert the Comm.pl functions over to ones from the Expect
package.
(Steve Golson, if you are listening - this would be a good thing for future
revs...)
- Edwin Huffstutler
Intel
( ESNUG 295 Item 12 ) ---------------------------------------------- [7/8/98]
From: Paul Tobin <pault@fusionmm.com>
Subject: I'd Like To See On ESNUG A User's Comparison Of VERA vs. SpecMan
Systems Science and Verisity are two companies providing integrated VLSI
verification environments that work seamlessly with most Verilog (& VHDL)
simulators and even some emulation systems. Systems Science sells their
VERA language and tools built on it, while Verisity sells a tool called
SpecMan using their "e" language.
Like me, I presume that many of you have looked at one or both (and possibly
other offerings) in some detail, and I'd like to trade notes. Any takers?
Can we do it here on ESNUG?
- Paul Tobin
Fusion MicroMedia
[ Editor's Note: To be anonymous in replying to anything on ESNUG, please
make sure to say so in your specific e-mail itself. Thanks. - John ]
|
|
