Array
(
    [content] => 
    [params] => Array
        (
            [0] => /forum/index.php?threads/graphical-tools-for-digital-design.471/
        )

    [addOns] => Array
        (
            [DL6/MLTP] => 13
            [Hampel/TimeZoneDebug] => 1000070
            [SV/ChangePostDate] => 2010200
            [SemiWiki/Newsletter] => 1000010
            [SemiWiki/WPMenu] => 1000010
            [SemiWiki/XPressExtend] => 1000010
            [ThemeHouse/XLink] => 1000970
            [ThemeHouse/XPress] => 1010570
            [XF] => 2021370
            [XFI] => 1050270
        )

    [wordpress] => /var/www/html
)

Graphical tools for digital design.

harpoon

Member
As an analogue designer, graphical tools are the way forward to handle large and complex designs.

So I am amazed that digital designs are still handled with a text editor. Will digital designers ever evolve to use graphical tools to describe block level connectivity ?

I did use a graphical front end tool from Expressive Systems, but they seem to have gone bust. The tool was great as it was clear how the different blocks interact with each other. This allows different designers to work on different modules very easily.

Hence my question ... will graphical tools for digital designs make a comeback ?
 
Graphical tools for digital design

Not sure what part of the digital design process you refer to.

For physical design, graphical tools are useful for initial design planning work. The process evolves from interactive to scripts. Eventually, most of the work is scripted and graphical tools are used in large part to analyze the results.
 
Tuck,
Digital designers (ASIC and COT) sometimes think of themselves as software designers so any design flow outside of using vi or emacs is seen with suspicion or contempt.

EDA companies like Mentor do offer a full-blown graphical front-end for doing design (HDL Designer).

FPGA designers on the other hand very much use graphical tools for their design flow and block level connectivity.

To me it's a personal design choice.
 
I think it is that size matters! If designs only involve connecting a modest number of things together, as most analog designs are, then graphical tools work really well. Digital designs have too many things and too many connections. Plus, of course, Verilog etc are inherently textual so if you want to be able to describe the top level in Verilog you can either enter it directly or use some graphical tool, but with thousands of connections to be made (even if the top level is just the I/Os and the core) there doesn't seem to be any advantage in using a graphical tool.
 
I've been using Mentor Graphic's HDL Designer/Author.
It really shines at FSM implementation, espcially for very large designs.

Block level / full chip integration is also pretty easy with the tool.

However, for tasks such as system verilog based verification, IDE style environments such as Visual Slick Edit seems to excel.
And to actually run verification... Modelsim/Questa seems to be the way.

For FPGAs, as mentioned above, Altera's Quartus, and Xilinx's ISE Design Suite... give you very nice gui front ends for handling floor planning, IO managment, timing constraints generation and place and route.
However, they seem a bit light on actual design entry.
 
Last edited:
Personally, I think any large designs should be broken down to smaller more manageable blocks, ... just how I was brought up as a designer. This applies (especially) to digital designs as well.

I have used a graphical tool (Expressive) in the past and found it really useful. I was able to draw on a blank sheet how different blocks interacted with each other, how different clocks are handled and i/o directions. It also prevents any typo/syntax errors. It then generated the respective .v files all connected up properly. I was then able to use my favourite text editor to do the actual design.

My thought is if this can then be extended further ?

Unfortunately, Expressive is no longer available these days ... maybe it is a sign that digital designers do not like it ?
 
Unfortunately, Expressive is no longer available these days ... maybe it is a sign that digital designers do not like it ?

It is not that they don't like it; it is that graphics are not a good way to represent algorithms. IT has been littered with so called visual programming tools where you could 'draw' the algorithms but in the end people came back to what is most productive for programming and that is pure text (nothing beats a sed or perl command for code manipulation or refactoring)
As HDL is a form of expressing parallel algorithms text is also the most productive way to represent it. When I was at university (beginning of the '90s) there was some hype around 'drawing' the function of logic blocks but that was short lived. I'm sorry but I don't remember the name of these tools. That said, graphics are used in places where it makes sense: chip floorplanning, viewing place and route results, viewing waveform output of digital sims etc.

For analog/full custom the situation is different, there the (analog) interaction of components is important together with the fine tuning of the parameters of the components. In such a situation graphics may be most productive. That said, most of my custom layouts are now pure skill text ...

greets,
Staf.
 
I think it depends on whether you have a complier with the editor.
Graphical editor will be helpful due to human visual assistant capabilities. However, if without Complier functions, it is still not that much useful for large design works.

Regards
Lance
 
I gathered as much ...

In my analogue world, we have visual test benches, block diagrams, wires, etc ...

You only see transistors at the lowest levels (mainly).

It then occured to me, why can't digital designs be done this way ? If you descend down a block low enough, you will eventually end up with a text file and you can use whatever editor you like then. However, ultimately, all the blocks are connected via a schematic-like approach. Is it less efficient ?

Wouldn't it be easier to check, understand and debug ? If done this way, would verification be a lot easier ?

In simulation, you can probe signal traces, probe nets at different points in time, test for process corners, etc ...

This can even be extended for "monte-carlo" type simulations ?

When I look at digital designs, it all looks like a big mess ... with all sorts of files doing all sorts of things, signal lines all over the place going to a million different places. It is like watching the "Operator" in the "Matrix" movies ... all I see are green symbols ... but digital designers can actually see how things are hooked up ... or claim to be able to do that.

anyway ... just my thoughts
 
I would like to hear more about people's experience with HDL Designer (seems to be the only one mentioned here) ...
 
There are some of us digital designers that prefer graphical HDL entry.

The SPW tool (Signal Processing Worksystem) has offered graphical HDL design since the early '90s. It never caught on with mainstream ASIC designers, I think, because it's very heavily oriented toward system design and specifically DSP systems: digital communications, video, audio, etc. It was quite possibly the industry's first ESL tool. After being acquired by Cadence in the '90s, the tool & its team were sold to CoWare some years ago, and last year CoWare was bought by Synopsys.

If you were a regular digital logic designer, writing state machines or whatever in vi or emacs, you would find in SPW a lot of comms-oriented library blocks that you don't need and perhaps don't understand, a "signal calculator" waveform viewer that included functions like filtering, FFT, correlation, etc. and you probably wouldn't see the value of this tool for doing HDL design entry, simulation and automatic code generation.

But it also has a graphical FSM editor, and the hardware design library includes every low and medium-level logic function you might need (counters, ALUs, multipliers, adders, barrel shifters, comparators, decoders, primitive logic gates, etc.), all parameterized as to word length and fixed point data format. Each of these blocks is represented by a C model for fastest simulation speed, a VHDL model or a Verilog model. The built-in simulator uses the C models, but can also co-simulate with the usual HDL simulators from Cadence, Mentor & Synopsys, allowing you to mix legacy HDL or other hand-coded designs with your SPW graphical designs.

I've used SPW on many ASIC designs and digital IP block developments over the years and still use it today -- mostly for signal processing designs, but on occasion I sometimes use it for "plain" logic designs -- it's usually quicker to draw the block diagram in SPW and push a button to get HDL rather than writing the HDL myself.

The code is "ugly" and obviously machine-generated, but the quality of results from synthesis is at least as good as what I've seen from most hand-coded designs. For one thing, it's consistent, no matter which member of the design team drew which block diagram.
 
I use a graphical tool, SPW, for certain digital designs -- in particular, signal-processing types of designs, which that tool was specifically designed. For complex datapaths and systems with elaborate feedback, a picture is worth a thousand words...or more appropriately, ten thousand lines of code.
Posted by Frank Eory
 
I managed a team about 10 years ago and tried to get them to use HDL Designer. My goal was to improve documentation. Unfortunately, we found that the drawings got too messy and we were spending too much time updating the schematics in an effort to make them readable. Mentor added the spreadsheet based connectivity, but the engineers still felt it was less productive than an editor and not that much better. We did document our statemachines but ended up abandoning HDL Dewsigner as part of a methodology. What we replaced it with was a flow diagram based design intent capture using MS Visio. Our intent was to capture design intent for documentation, but we found it was also useful for functional coverage. We manually extracted coverage points from the diagrams in a C behavioral model and with Vera constructs. We produced a number of first pass silicon successes with that methodology. Once again, the functional extraction process was tedious and somewhat error prone. With the advent of ABV methodologies, the availability of the OVL library and the integration of SVA and PSL into the commercial simulators, I co-founded an EDA startup a couple years ago to automate the functional coverage extraction from both flow and timing diagrams in the form of assertions in OVL, SVA or PSL. With the complexity of designs growing and the need for reuse, I've become more interested in capturing design intent rather than the hierarchical structure and I believe graphical tools are the best way to do that.
 
Flow management

For digital design there are a number of solutions that may or may not save you time when designing your SoC. As networks-on-chip become more popular and systems become more complex we will need graphical tools to handle the system overview, interconnect and off-chip communication. At the level of FSMs etc I am not sure how much time is saved using graphical tools. For experienced engineers it is quicker just to write the code using good working practices.

Where we are lacking in solutions is the areas of test bench generation and physical implementation (P&R etc). There are some graphical floor planning tools out there, but for a decent set up most companies resort to complex scripted flows. Ellexus is a startup in the UK that has recently released a tool for developing and managing scripted flows. It is designed to automatically document what you are doing by tracing the relationships between files and programs. This means you can understand a flow and check its function without having to read all the code. This makes it much easier to share and maintain a good scripted infrastructure for test and implementation. The tool is called Breeze and can be downloaded from www.ellexus.com
 
While scripting and all the tools surrounding it is a good compromise, I believe that ultimately, it will benefit from a graphical representation. If Breeze can work together with HDL designer to solve @joconnor's problems ... then i think we have a winner !
 
HDL Designer has the graphical interface. However, inside the block you have to write the code by yourself. It means you are using HDL designer interface for writing code insteade of vim or emacs. So, it is not actually a graphical interface as cadence that has been used for a long time for analog, mixed and rf design..........:)
 
Code:
<meta http-equiv="content-type" content="text/html; charset=utf-8">[COLOR=#333333]As an analogue designer, graphical tools are the way forward to handle large and complex designs.[/COLOR][COLOR=#333333]
[/COLOR]

In my experience graphical design is only possible for small and simple designs. <meta http-equiv="content-type" content="text/html; charset=utf-8">Graphical tools are a nice way to get started with digital design because it hides a lot of complexity. But it just does not scale. Once a design gets large you need textual description.
Overview block diagrams help of course. But these can easily be extracted as a view on your design.

Hendrik

--
Sigasi | The Future of VHDL Design
 
Back
Top