( 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" ]
|
|
