ModelSim Designer

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?

Thanks, Rob

Hi Rob,

What you want is HDL Author and not the full HDL Designer which is indeed quite expensive. HDL Designer includes Design Checker (source code linter), HTML export and IBD's (which I never use). My experience is that once you start using HDL Designer you can't live without it :-) The only drawback of HDL Designer is the lack of SystemC support,

Hans

I suggest a full evaluation with a real design to validate that idea.

I did an evaluation, but settled on emacs vhdl-mode which is non-graphical, but covers much of the same ground for free.

With HDL designer I did not enjoy fussing with wires and attaching text to graphical views to get the code to come out right.

In vhdl-mode, I especially like the templates, the port copy/paste functions, and the Makefile generation for simulation.

-- Mike Treseler

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

Note that ISE and Quartus now have added serviceable block viewers. While you can't click on anything in this pdf printout,

when seen live from Quartus, clicking on a yellow box will bring up a graphical state diagram, even though all I actually wrote was a case statement in text.

HDL designer does hierarchy with a block diagram editor. To fill these boxes, it provides logic entry from state diagrams or flowcharts. This style appeals to schematically oriented designers who would rather drag boxes, wires, circles and arrows around than write code. This is a valid alternative for those who don't like writing HDL code, and Mentor has made lots of money with this product.

Code generation from graphics *appalls* designers who know an HDL and see a tidy code listing as the only viable and portable source format. A single block HDL style allows the bottom up use of variable (register) structures, functions and procedures to construct a design of arbitrary complexity from a standard template. While verbosity is possible, so is a clean, modular, single-threaded logic description with registers, wires and muxes inferred as needed by synthesis.

Yes, synthesis has improved in the last eight years, and it is no longer necessary to use write deeply nested structural designs down to the gate, mux and register level. For designers who know an HDL for synthesis and simulation, tools like HDL designer are largely irrelevant.

I use the emacs vhdl-mode compose commands to wire up my single-process instances into a top entity. If I need to view the design graphically, I use the Quartus pre-map RTL viewer.

-- Mike Treseler

Mike, Brian -

Thanks for sharing your experiences with the tools. I now have 30-day demo licenses for both ModelSim Designer and HDL Designer, so I'll try to make time to see if there's anything here I can't live without. I use Verilog almost exclusively, and I don't use the methodology of building a library of low-level logic primitives and then building up my designs from that. As Mike said, the synthesis tools are smart enough now to not require that, and with that approach you may as well be drawing schematics, which I was happy to leave behind probably 12 years ago.

I have two main motivations for looking at these tools. First, I'd like to increase my productivity. I've been doing things basically the same way for years and it's time to see what's out there that can make the job faster, easier, and even better than what I'm doing now. Second, my main customer (I'm a consultant) is an avionics company (non-defense), and the FAA requires extensive documentation to certify a product. They've been very strict with software for years, but recently they've adopted the same standards for programmable logic. I want to come up with an FPGA design methodology for my customer that will make the FAA happy without requiring a ton of extra work.

By the way, Brian, the Mentor sales guy said ModelSim Designer does not work the same as ModelSim. He used some corny analogy to describe it, but the bottom line is that they're different tools that are not interchangeable or even necessarily compatible. Still, for $2500 I'd consider buying it if it has the documentation and task automation features I'm looking for. I just wouldn't use it as my simulation engine.

I'll post back with comments from my evals if I have anything worth reporting.

Rob

Actually HDL designer creates quite clean code from the FSM editor and block diagrams. It can easily be read also manually. The problem is lack of comments in the code if it is automatically generated tough.

Just be wary with functions and procedures. Especially procedures seem to be a big problem still for design tools. I think I have seen all the major implementation tools to create garbage or crash with very simple procedures (DC, Synplify, FormalPro, Formality, few linters etc.)

Actually what I have seen very experienced VHDL coders (10+ years) also like HDL designer. They usually use only the block diagrams and text views. Block diagrams are good way of documenting the functionality. Especially when the design team is big, different coders have to read and sometimes fix other peoples code. Just browsing the code is slower than to start with block diagrams that have the dataflow clearly shown etc.

--Kim

Brian Drummond wrote: > But overall I'm with Hans that I'd definitely not want to work without

We've ended up banning the use of HDL Designer. A minor issue was it's incompatibility with our CM tools. We also had managers think that good power supply designers, good servo designers, etc. could easily design FPGAs using schematic entry. This caused some problems. But the icing on the cake was finding unconstrained clocks added to the logic without the designer being aware. Mentor's response was we needed more training. Our response was to provide more training to the engineers in using VHDL to develop FPGAs.

Sam

Yes, and once I add a comment, the graphical tool is out of the source control loop.

If you have access to any of those tools, would you mind running my reference design through and see how it does?

I agree that HDL designer is a fine browser. My point to the OP was that it is not necessary for design entry and that there are more economic ways to get this design browser function.

-- Mike Treseler