( DAC 02 Item 4 ) ----------------------------------------------- [ 9/10/02 ]
Subject: Summit, TenisonTech, Virtio, Translogic
BACK FROM THE DEAD: Years ago there was a small company called Summit that
used to sell graphical design entry tools in the EDA market. They were
eventually bought out by Viewlogic/Innoveda, and later just sort of quietly
died out. Now, to many an EDA watcher's surprise, Summit's back from the
dead offering high speed C simulation along with their graphical tools.
"Is Summit still around? Man, I thought they went belly up a while
back. I had the worst interview with them 6 years ago up in Beaverton."
- [ An Anon Engineer ]
"I was not particulary turned on by what Summit had to say at DAC.
Still it warrants deeper look."
- Darko Gojanovic of Intel
"I was primarily interested in Summit's C based fibre channel models.
It sounds like they have lots of features and error checking
capabilities. We would be able to instantiate them from pulldown menus
using their Visual product, which we currently use in our design
process. We would use them for testing within our testbenches.
In general we have chosen not to use C based design approaches.
Although these approaches may be good, we have a very good experience
level with RTL based design.
I believe Summit will support SystemC, which is good. I also think
Summit incorporating their C based h/w design into Visual Elite is also
a good approach. Sorry, I can't help you with comparisions with other
C design approaches, I have not looked at others at this time. As a
note, I worked for Summit before I came here."
- Tom Paulson of Q Logic
"3.0 Design Entry
Summit was the original company that turned pictures into RTL and vice
versa. They have been bought, sold, merged and spun off so many times
I can't keep track. They were part of Innoveda but were spun off just
before Mentor bought them, so they are now their own company once
again. The typical knock against these graphical tools is that they
help newbies become productive faster but once the newbie is on the
road they are too restrictive - sort of like training wheels. Anyway,
in addition to their traditional VHDL and Verilog tools, they have a
lot of C-related tools. They have a System C graphical environment
designed to allow architectural level modeling (throughput, latency,
utilization). Summit allows you to hierarchically decompose your C
down to RTL level, and then can translate that to RTL level VHDL or
Verilog. They say RTL level C is 100X faster to simulate than RTL
level VHDL or Verilog.
Translogic sells a tool called EASE that also allows the user to go
from pictures to RTL.
ASC and X-Tek Corporation sell tools that translate code from VHDL to
Verilog or vice versa. Obviously this only works on a subset of each
language."
- John Weiland of Intrinsix
"I have stopped at Summit's booth. There might be some exaggerations
there, as usual. I just look at their technology.
My first impression was that Summit FastC is very similar to Cycle-C.
Cycle-C was originally created by C-Level Design and acquired by
Synopsys early this year. Actually Summit agreed about the
similarity. The Cycle-C type approach is not a bad idea, but only
applicable for the RTL-in-C language. It's not a high level
description. Yes there is a benefit on this approach of fast
simulation speed. The disadvantage is the data-type limitation.
Since I am the vice chairman of OSCI, of course, I recommended to
Summit to support to SystemC. Actually they support it with
Visual Elite. I hope they support complete SystemC 2.0x shortly.
By the way, Fujitsu is recently promoting the UML into SoC design.
Because, C is not enough."
- Takashi Hasegawa of Fujitsu
"At this time, I would not recommend using Summit tools.
In my humble opinion, Summit software is not of high enough quality.
Surprisingly, I could live with that, what can I say, SW is SW and it
will always have some issues. But again in my opinion, Summit support
is unacceptably absent. Consider Synopsys, their sales guy phones me
three times a day when I have a problem with their tools and the worst
case fix takes only a matter of days. I've had bugs outstanding with
Summit (when they were Innoveda) for months with no visibility to
seeing them fixed. Seaway still has Summit products licensed that we
no longer use.
Having said all that, I must say that the notion of using C is smart.
There's a small company called TenisonTech that makes a tool called
VTOC. VTOC converts Verilog to C. Get it? VTOC. Anyway, the tool
works well, the support is fantastic, and the cost is reasonable.
We take our converted Verilog model (note: single source model written
in Verilog and we tie it into a full "C" model of our validation board
created with a tool developed by a company called Virtio. Again,
these guys have a great technology, great support, and very good price.
We use this board level model to develop and test the silicon model and
its associated board level SW. At SeaWay Networks, we don't go to tape
out until the device is tested with all the production SW that will
interact with the device. All of it. We also use this system to
introduce real network traffic into the simulation to ensure we are
compliant with the "big standard" (i.e. what the world in general is
actually doing as opposed to what the spec says.) We pull traffic
right off of the network and feed it into the simulation.
So, we use C this way and what do we get?
1/ SW/HW co-development virtually eliminating SW/HW API bugs
(Thank you very much TenisonTech and Virtio).
2/ Real world traffic running through a fully simulated system,
right down to the flash, virtually eliminating specification
interpretation errors.
3/ Developers working with tools that are a fraction of the cost
of a single Verilog license. Must be cheap cheap cheap.
4/ A single source device model written in verilog and converted
to "C". No maintenance problems there.
5/ Rapid proto validation, the test SW is also written before the
first sample device ever arrives.
The best part is when our developers are done, the full environment
is shipped to our customers as part of our "customer support
package". They can write their application SW using the same system.
They can run their SW with our SW and our silicon. All of this is done
with a high reliability simulation platform proven during our own
development cycle.
Now that's elegant. Our team has developed five first rev successes
ASIC's in a row using tools like this."
- Jonathan Adair of Seaway Networks
"The FastC language on the Summit tool seems reasonable if their new
C-based language is really a subset of SystemC. SystemC is
conceptually slow simulation language because it can support higher
levels above RTL. The Summit approach may be low cost and faster
simulation. They say "FastC is subset of SystemC", but we have not
confirmed it's a real subset or not. Also FastC must have a big
limitations on describing higher abstracted models.
Related to the combination of C models and HDL models on the same
schematic tool, the Summit demonstration looks good. Note that this
is just my impression of the Summit demo and no evaluation has not
been done yet."
- Masamichi Kawarabayashi of NEC
"We use VHDL for FPGA design. So at this point, we didn't look at
Summit's C-based hardware design in depth. But my impression of the
solutions Summit offered is very good. We used VisualHDL/Elite for
several years now, with no big problems. Something what I found very
interesting was their FastC, which allowed you to speed up run times
very dramatically. This may be one of the reasons for us to move
towards C. I am not so sure about behavorial level C. Many attempts
were made with behavorial VHDL (Behavorial Compiler from Synopsys).
As far as I can tell, behavioral never continued to develop."
- Stephan van Beek of Oce Technologies Netherlands
"As for Summit, I'm not sure what to say. We know the Summit folks
when they were back at Innoveda. We bought in to their VCPU solution
to help with our co-verification approach. It works for us because
we helped them debug and enhance it.
As for Visual Elite or the other products, I was not looking for
C-based HW design at DAC, so I did not spend to much time looking at
them. In fact, I have yet to buy into any C-based system modeling
or C-based HW design flow. Too much expertise resides in Verilog."
- [ An Anon Engineer ]
"I think Visual Elite 3.0 is ideas are useful for SOC design. Their
features will be useful for System level HW designers:
1) Graphical Entry. Visual Elite ver 3.0 has several features for
pin connection. For example, bus connection, pin connection with
connection table and automatic pin connection are supported.
2) It supports SystemC 2.0
3) Visual Elite ver3.0 supports C simulation with FastC technology,
HDL/C mixed simulation with HDL simulator and HW simulation
accelleration with a HW accellarator.
4) Interoperability. Summit has an API to access their data base.
I'm not Summit user, but I looked at Visual Elite ver 3.0 in Summit
suite at DAC."
- Hitoshi Kurosaka of NEC
"I've been looking at high level design entry tools since I joined
Lucent nearly two years ago. (I think you should also know I did at
one time work at the old Summit Design.) I think a bit of explanation
of why we would want to do this might help.
We have a large number of system architects/designers working in the
MUTTS area in Lucent. They are writing hue amounts of C/C++ to verify
their algorithms, which means for most of our ASICs we have a
simulation model written in C (either in full or in parts). If we have
to write this stuff, the question is why can't we use it for our
VHDL RTL model? We already use the C model to verify the VHDL, but we
would like to reduce the time to design (like everyone else).
One of the options we thought about was getting the system designers to
write in VHDL. Then we realised there is not really good behavioral
compiler available for that, and the thought of making all those C
programming guys learn VHDL sent us to the pub for a beer or 3.
Right, that sets the background.
We looked closely at C-Level design, and were about to start an eval of
their tools, then they ran out of money. I also looked a Cynapps (now
part of Forte design). They have an interesting approach to this,
which may allow some sort of synthesis from a sort of behavioural C to
RTL, but not quite yet.
Then there is the Summit FastC approach -- which is to write the your
RTL as either C, VHDL, Verilog... and use Visual HDL to push it all
out together. Speaking to some of the Summit guys left me with the
impression that they think creating state machines and so on in C is
all we need to create a behavioural description.
I think Summit's approach of using a mix of graphical and textual
design entry and allowing you to mix up styles is good. The demo
looked nice. Everything looked as good as usual with Visual. The
proof of course comes when you actually try it out. It looked to me
very much like they were working at the RT level, though allowing a
mixture of C, C++ VHDL, Verilog (which is a good thing anyway).
What I really would like to see with Visual is a way to enter some more
behavioural type stuff graphically, and then get an RTL output that I
can give to DC. One interesting possibility we thought of is that this
might help putting together a verification suite for a block or set of
blocks, using C - blocks to drive the design. This has implications
for how testbenches are created - for instance connecting things at the
block level graphically."
- Michael Lee of Lucent
"We have had 2 students working on a small project with an evaluation
license of Visual Elite as preparation for a new chip design that was
partly going to be modelled in SystemC by our customer. The students
have finished their project, but now the chip project has been killed
by the customer.
As this was going to be a whole new chip it was a nice vehicle to start
with SystemC. Most of the chips we usually design heavily reuse
existing building blocks that have been modelled in VHDL and Verilog.
For these current VHDL and Verilog we also used graphical entry. VHDL
entities are generated from block schematics that have been drawn in a
schematic editor.
As we were a Compass tools user in the past at the moment we are at a
decision point in time: our analog IP has been transferred from Compass
to Cadence for a year. So this means we currently have two separate
databases for analog and digital IP and port consistency of building
blocks is not automatically guaranteed.
Either we can move our digital IP also to Cadence, in which case we
have 1 database again, or we could move the digital IP to a tool like
Visual Elite, which offers digital designers more than the Cadence
environment, but in that case we still have two separate databases and
port consistency has to be checked in a separate way.
We definitely see advantages in SystemC: our software department now
has to build their own models of (part of) our chips to be able to
develop and test the software in parallel with the hardware. With
SystemC these models could be reused by & co-developed with the
hardware designers.
In the student project only SystemC 1.0, so basically RTL modelling,
could be used due to the limitations of Visual Elite: the new version
that we saw on DAC would enable us to go to a higher level of
abstraction. Also missing so far was the path down to synthesis: with
the introduction of FastC in the new Visual Elite this could be solved.
So it was interesting what we have heard and seen from Summit at DAC.
We do already have some licenses of Synopsys' CoCentric System Studio.
What I have seen myself and heard from our designers especially the
graphical entry of Visual is much better than from CoCentric.
Meanwhile, since we have the time, we have decided to convert our
digital IP to Cadence. I have written a small Perl script that reads
the Compass ASCII-based schematics database and converts it to Cadence
Skill scripts that redraw the schematics and symbols in Cadence
Composer. (I tried conversion via EDIF first, but was not very happy
with that.)"
- Theo Deckers of National Semiconductor
|
|
