Synopsys just announced that it gave $38.5 million worth of stock to acquire
Silicon Architects, a 45 employee Sunnyvale, Calif. company which earned $3
to $4 million in revenues. An initial reaction may be that Synopsys got
snookered into paying 10x for a small company with crafty management -- but
look closer. You'll find SilArch offers a hot place & route and synthesis
ASIC library based on really efficient SSI/MSI circuits built using their
unique patented transistor structures for gate arrays. What this amounts to
is that ASIC's created using the SilArch approach benchmark (according to
my Synopsys R & D sources) from 28% to 66% *smaller* in final place & route
die sizes compared to current gate array design methodologies. (To put this
in perspective, Synopsys R & D will do entire projects hoping to get just
7% to 10% reductions in area or speed!)
- John Cooley
the ESNUG guy
( ESNUG 215 Item 1 ) ---------------------------------------------- [4/95]
Subject: (ESNUG 214 #6) Seeking Tools To Translate VHDL To Verilog
>
> Hi, John, -- do you know of any tool that translates VHDL to Verilog?
>
From: bolling@lds.loral.com (Randy Bolling)
John, I have seen Verilog->VHDL translators. The translation is pretty much
straight forward. But the syntax of VHDL contains complex data types not
found in Verilog. (Specifically, data typing and records manipulation would
be difficult. However, std_logic typed code that was synthesizable is
easily translated. For example, VHDL data type x contains n discrete values,
all modeled as log(base 4 of n) wires in Verilog. Issues like user resolved
data types with resolution functions would make for a hairy translation.
(Possibly requiring run-time support in Verilog in the form of a separate
Verilog "resolution" module.) All-in-all, not a good fit for completely
unconstrained VHDL.)
Why not buy Leapfrog with Verilog-XL model import, or Verilog-XL with
Leapfrog model import, or Precedence and connect Chronologic's VCS with say
Vantage or ModelTech, or seek out ModelTech/Mentor's newly announced
Verilog engine? While costly, it would solve the problem...
- Randy Bolling
Loral Data Systems
---- ---- ---- ----
From: eli@interhdl.com (Eli Sternheim)
Hi John,
InterHDL currently has a Verilog to VHDL translator. This translator covers
about 95% of the language, including the synthesizable subset. It has been
used by several companies to translate full designs from Verilog to VHDL
while preserving simulation results.
We're developing a translator from VHDL to Verilog. In the first stage, the
translator will cover the structural (gate level) subset. This one will be
available for beta test in early May. In the second stage, the translator
will cover the synthesizable subset of the language. This will be available
for beta in the third quarter of 1995. In the third stage, extensions will
be made to cover non-synthesizable features of the language, but the intent
is not to provide 100% coverage.
- Eli Sternheim
interHDL, Inc.
---- ---- ---- ----
From: jake@ascinc.com (Jake Karrfalt)
We at Alternative System Concepts in New Hampshire are developing a reverse
translator using the same parsing engine as our verilog2vhdl Translator.
The new product (to run on SUN and DOS platforms) is called vhdl2verilog and
will support a subset is going into beta soon. It's scheduled to ship in
late June 95. Price is in $6-8K range.
- Jake Karrfal
Alternative System Concepts
---- ---- ---- ----
From: jcooley@world.std.com (John Cooley)
Most Synopsys users already have on hand one of the world's most expensive
Verilog-to-VHDL and VHDL-to-Verilog translators available: it's called
"Design Compiler". Yup, just use for:
Verilog-to-VHDL: read -format verilog input_file.v
write -hierarchy -format vhdl -output output_file.vhd
VHDL-to-Verilog: analyze -format vhdl input_file.vhd
elaborate input_file
write -hierarchy -format verilog -output output_file.v
It's a little more complicated than this depending on exactly what/where
your VHDL libraries/packages are, etc. -- but you get the idea. (This is
just meant to show you a quick & dirty way to get simple translations.) You
won't get any fancy stuff through this conversion; just the synthesizable
subset with all timing information thrown away.
- John Cooley
the ESNUG guy
( ESNUG 215 Item 2 ) ---------------------------------------------- [4/95]
From: ann@sioux.apple.com (Ann Nunziata)
Subject: Extremely Cheesy Windows Graphics With HDL Advisor
Hi John,
We have a demo copy of HDL Advisor, and we are very disappointed in the User
Interface. Maybe you prefer (clunky) windows apps., but I am afraid that we
are Mac and Motif snobs. HDL Advisor looks like Synopsys paid someone to
write it for them on a PC. Some things we have seen are:
- The user interface does not match the UI of all Synopsys' other tools.
- The scroll bars are slow.
- Re-drawing the window is slow. For example, our normal windows redraw
instantly when moving from behind to in front of other windows. The
browswer window toolbar fills in sloooowly.
- The menu bars, when pulled down, obscure text as they should. When the
menu snaps back, the text is redrawn, BUT when the window is scrolled,
the text formerly under the menu pulldown does not scroll. (The
workaround we found was to re-size the browser window after each menu
pulldown.)
- If another window covers the browswer window, and then the browser is
brought back to the front, sometimes the browswer toolbar and frame
is not redrawn or a whole is left in the text (but NOT ALWAYS).
(Hiding and revealing over and over, or resizing the window fixes this.)
- The concept of writing to gtech libraries slows down the reading in of
designs with or without the hdl_dvisor_enabled true.
Maybe they gave you a better copy, John. Ours was Version v3.3a-slot3b.
- Ann Nunziata & Magnus Karlsson
Apple Computer, Inc.
( ESNUG 215 Item 3 ) ---------------------------------------------- [4/95]
Subject: (ESNUG 213 #1 214 #3) "DC 3.2a vs. 3.0b - Smaller But Slower Designs?"
>> Design Compiler 3.0b Design Compiler 3.2a
>> -------------------- --------------------
>> Combinational area: 39,936.000 38,893.750
>> Noncombinational area: 27,637.250 27,714.250
> |
> got larger noncomb area here ---'
>
>I have a little problem with the above results, and that's basically the
>noncomb logic area has increased. More info is needed here to explain this
>increase: is it because Synopsys simply synthesized different cells (i.e.
>buffered FF, etc... ) -- or is it because there are unknown additional FF
>and/or latches??? I've encountered a few cases where the same HDL code and
From: prz@hprnd.rose.hp.com (Paul Zimmer)
John, I checked: there are the same number of flops/latches. I did notice
one block where 3.0b used a particular presetable flop and tied the preset
inactive while 3.2a did not do this. Also, the difference in area
(comb/non-comb/combined) is about 3/10 of one percent...
> Path Group A's slack: 8.18 8.17
> Path Group B's slack: ***? -3.96
> Path Group C's slack: -1.58 -2.05
>
> ***? - This path group came up in 3.0b but report_constraint -verbose
> wouldn't give me any "slack" information. Same script, source,
> and constraint files. Very strange.
Here's more data on this "missing constraint" in 3.0b. I have since seen
this in another context. I compiled a block (using lots of tricks like:
group paths, balance registers, etc) in 3.0b and wrote out the .db file.
When I pull this .db file back into 3.0b and report a particular path,
it says the path is "unconstrained".
When I pull this SAME .db file (generated by 3.0b) into 3.2a and report
the SAME path, it shows the proper constraint!
(Yes, you got that right -- 3.2a finds a constraint in a 3.0b database file
the 3.0b can't find!) Very strange.
Besides this oddity, I'm starting to feel more comfortable with 3.2a now.
- Paul Zimmer
Hewlett Packard, Roseville
( ESNUG 215 Item 4 ) ---------------------------------------------- [4/95]
Subject: (ESNUG 213 #4) Model Tech/Synopsys VHDL Simulator Incompatibilities
>Has anyone had experience with incompatabilities between VSS (Synopsys)
>and VSIM (Model Technology)?
>
>We developed a VHDL model in Model Tech's VSIM and completely debugged it.
>When we ran the same model in Synopsys's VSS, we found that 20 out of 96 test
>sets had some sort of miscompare. I'm not surprised that different vendors
>evaluate the VHDL language differently, but I'm surprised how difficult it is
>find references detailing these differences. Any help will be appreciated.
From: matt_hsu@mhsu.com (Matt Hsu)
Hi John,
I've had experience supporting both of these VHDL simulators as I was
responsible for building the system simulation environment at my last
company (as well as a third simulator for a while).
Basically, most of the VHDL simulators I've come in contact with (either
evaluating or using) are either generally the same or too non-compliant to
mention (and most of those have died). We used to used a regression testing
philosophy that was based on 'diff'-ing golden response files but came across
the following two problems that may address this user's particular experience:
1) When using textio and the NOW function to output time stamps I found
that different simulators would use different default units. Although the
time write function allows you to pick a unit, it doesn't specify whether
the unit should be printed in upper or lower case and guess what? We saw
both. (Yes I kow you can work around case 'diff'-ing.) Trying to convert
to an integer (so 'ns' could be a string) was even more trouble because
when I divided by 1 ns, for example, I got different answers. I'm guessing
because some of the simulators wanted to give more dynamic range by
cutting range off of the bottom half of the physical definition & putting
it on the top (using a sliding scale for where integer 0 is). I couldn't
find a formula to give me the same integer for all three simulators.
2) Even more troublesome was the fact that a list of simultaneous events
would be ordered one way in one simulator and another in the other. The
following example illustrates the problem. Suppose you have a signal that
is two bits wide. You write two processes each having one bit in the
sensitivity list. In each process, you print out the new value for the bit
when the signal changes. Now, which text comes out first: the 'left bit
text or the 'right? I saw both making the 'diff' output too long to be
convenient.
For this reason we wrote a reduction and analysis script that would tell us
the whether the test passed or failed. In my opinion, the better way we
implemented later was to have the testbench check and generate a "PASS"
message when the test passed and status output for debugging when it
failed. Using this technique we built into our designs assertion warning
process that were quiet when all was well and yelled out if they detected
problems. Synthesis of these warnings was disabled.
- Matt Hsu
Ryan & Ryan
( ESNUG 215 Item 5 ) ---------------------------------------------- [4/95]
Subject: (ESNUG 214 #5) Specific Reasons Why Synopsys Sucks!
>John, Synopsys synthesis sucks because it's too difficult to use... a novice
>has to read the Synopsys VHDL Compiler manual to learn how to write VHDL
>that Synopsys can read, read the Design Compiler manual to write the timing
>& area constraints, and read the Command Reference manual to really write
>the timing & area constraints. ... the novice then has to find a Synopsys
>expert in our company who can really teach him/her how to run Synopsys. (I
>compare this with training a novice to run the Vantage simulator. The
>novice sits down in front of a workstation with an experienced Vantage user
>and learns how to run Vantage in about an hour. Done.) -- I simply do not
>accept that synthesis is so difficult of a process to run that it takes the
>learning investment that Synopsys requires in order to accomplish the task.
From: bolling@lds.loral.com (Randy Bolling)
John,
Compiling (or interpreting) and executing a language is straight forward
because its something with which most users are familiar. Few HW engineers
have avoided writing some language in their careers or in getting their
university degree. (We've all had to write *some* Assembly, C, FORTRAN,
COBOL, C++, or ADA.) This user must separate the process of simulation from
synthesis. How would a new user have any real-world metaphor or prior
experience upon which to use synthesis without first being shown the mapping
of language to gates?
New users must first learn the correlation between specific HDL constructs
and gates followed by learning how to use a synthesis tool to formulate that
mapping. After understanding the mapping, then comes the process of
optimizing the design. Every synthesis tool has these two stages. Thus, its
unfair to compare synthesis engines to simulation engines.
How to train individuals? Well, that could fill up a book of opinions...
- Randy Bolling
Loral Data Systems
---- ---- ---- ----
From: [ A non-Synopsys EDA Vendor ]
John,
Sorry to keep bothering you with mulitiple e-mails but in reading your most
recent ESNUG, I had to respond. As always, anonymous.
Someone should hit that user over the head with a two-by-four... I can
sympathize with the man but comparing ease of use of any synthesis tool with
a simulator is like comparing a Stealth to a Tonka Truck! Someday, the
process will be simple (and probably obsolete) and we'll look back, shake our
heads, and say "Work? You don't know what work is! I can remember when it
used to take three days to synthesize 500K ASICs from HDLs!" -- but that day
isn't now.
- [ A non-Synopsys EDA Vendor ]
|
|
