On Sat, 01 Apr 2006 15:58:04 GMT, "RobJ" <rsefton@abc.net> wrote:
>"Brian Drummond" <brian_drummond@btconnect.com> wrote in message
>news:fnss22hl486nr858dj1b4bkj3d7bg550qc@4ax.com...
>> On Fri, 31 Mar 2006 16:05:11 GMT, "RobJ" <rsefton@abc.net> wrote:
>>
>>>Anyone using this tool from Mentor? If so, any comments about it would be
>>>much appreciated. And any comments on how ModelSim + ModelSim Designer
>>>compares to Aldec's Active-HDL environment would be even better. I
>>>currently
>>>own ModelSim but am looking for a more complete environment (testbench
>>>automation, graphical tools, code coverage, etc.).
>>>
>>>Thanks,
>>>Rob
>>
>> It's OK, but it won't work with designs from older versions of HDL
>> Designer or Renoir. This wasn't made clear when I bought it, so I am
>> using it as a Modelsim seat alongside my (legacy) HDL Designer.
>>
>> - Brian
>
>Hi Brian -
>
>Ends up I misunderstood what ModelSim Designer is. I thought it was a
>product that runs with ModelSim, but adds new features (automated testbench
>generation, HDL to graphics, etc.). I talked at length with a Mentor sales
>person yesterday and Designer is a stand-alone simulator and development
>environment meant to attract the "low-end" FPGA crowd (like me) away from
>Active-HDL. They just lowered the price from $5500 to $2500, so it caught my
>interest. But I already own ModelSim so I'm not looking to replace it. I
>found out that HDL Designer is really what I'm looking for, but HDL Designer
>is a $17.5K tool.
>
>Have you used HDL Designer? Any comments on it?
Can't comment on the new versions, I'm still using the transition
version from Renoir (which dates from 2001).
I agree with Mike that some of it is clunky, like adding text to
graphical blocks for the this you can't deal with in wiring.
Strong plus points :
(1) Viewing/drawing block diagrams and state machines gives me a very
clear view of the design, which helps me handle the complexity.
(2) Code generation from these blocks means I have very little contact
with the alleged verbosity of VHDL. (And when I do, it's helping me by
providing clarity, instead of making me type long words)
Neutral points:
(1) Creating and using components works well and greatly encourages
re-use.
I make this neutral because when I started (1998), I created components
at a low level of abstraction - even down to a parameterisable pipeline
register. And re-used them in higher level blocks, etc - to give quite a
deep hierarchy.
Not necessarily a bad thing, but somewhat opposed to e.g. Mike
Treseler's "one process" style. These are two approaches to the same
goal - minimising complexity, so to some extent, using one renders the
other less important.
On the other hand, this hierarchy can be allowed to persist through the
tools, and greatly aids floorplanning, and creating RPMs.
So to me it's positive overall, but I recognise that's open to debate.
Negative points. (May have been addressed in new versions)
(1) Allows creation of either "blocks" (compile to entity/arch pairs)
for direct instantiation, or "components" for component instantiation,
which is deprecated in some styles.
Aside: I don't know why component instantiation is deprecated ... is it
just verbose? If so, that's less important here... (see plus point 2
above)
The trouble is
(a) Navigating "up" from a block moves to the parent (instantiating)
block; "up" from a component, just to the component's symbol itself.
Annoying, especially if you just moved "down" into the component from a
parent. I can see why ... a component may have many parents. But this is
really just an excuse for the developers not to maintain a navigation
trail, so it's really not an acceptable excuse.
(b) Blocks cannot be copied or moved to different libraries or re-used
in other than the original instantiating block. Unless you convert them
to components. (And then, if you move the component into a different
library, you also need to convert every block instantiated within it!)
Thus in the longer term, blocks tend to be self-deprecating.
(2) There are some vaguely useful concepts like "bundles" of signals
that are implemented in a half-assed way, and tend to atrophy with newer
versions. These should map neatly onto VHDL records, but don't. They
should also allow mixe signal directions and port types, like Data,
Address, Req, Ack (InOut, Out, Out, In), but don't. And so on...
My gripes aren't actually fundamental to the concept, but specific to
the implementation. And haven't changed much in years.
But overall I'm with Hans that I'd definitely not want to work without
it.
I don't know how much use this is to you, given the version differences.
But I'd question the value of the full product, and ask if Modelsim
Designer doesn't give you most of what you need (basic non-graphical
VHDL import, block diagrams, and state machines) as well as another
Modelsim seat (full function PE as far as I can tell).
As I said, I've ended up simply using it as ModelSim, but I believe I'd
have been satisfied with it - IF - I didn't have a legacy database.
- Brian