WP_Term Object
(
    [term_id] => 60
    [name] => Sigasi
    [slug] => sigasi
    [term_group] => 0
    [term_taxonomy_id] => 60
    [taxonomy] => category
    [description] => 
    [parent] => 14433
    [count] => 6
    [filter] => raw
    [cat_ID] => 60
    [category_count] => 6
    [category_description] => 
    [cat_name] => Sigasi
    [category_nicename] => sigasi
    [category_parent] => 14433
)

November 16, 2016June 14, 2019 by Bernard Murphy

Improving on EMACS for VHDL Creation

Improving on EMACS for VHDL Creation
by Bernard Murphy on 11-16-2016 at 7:00 am
Categories: EDA, Sigasi

OK – I admit I titled this piece as clickbait. There is a core of designers for whom belief in the supremacy of EMACS for RTL creation comes close to religion. Some will read only the title and jump immediately to penning searing comments questioning my intelligence, experience, parenthood and ability to tie my own shoes. Some, I hope, will read on if only to more precisely craft their rebuttal. A few may actually find some ideas of interest in this piece and especially in the links at the end.

I should admit upfront I am not an EMACS user, though I have worked with many fans. I rely instead for my information on the views of a group of folks at Sigasi who have been and remain very dedicated users but have come to realize that EMACS isn’t perfect for RTL (particularly VHDL) creation and that it is possible to conceive of better solutions without sacrificing your immortal soul. To give you a sense that these guys truly are among the EMACS faithful, one of their pieces is titled “Why Emacs VHDL mode is so Great. And Why We Want to Beat it”.

Let’s start with an obvious point. A major premise of VHDL (springing from its foundation in ADA) is to be correct by construction, as least as far as possible, so it is intended that you spend much more time getting to a compilable piece of code that you would in other more flexible languages. As getting to a successful compile gets harder, it is natural to want to simplify the task. VHDL-mode for EMACS was created over 20 years ago to address this need and has evolved into a truly great VHDL-aware editor. It provides great macros, a design hierarchy browser and a code formatter, which includes vertical alignment. And it has code fixing such as updating sensitivity lists to avoid latches. Plus, and this is important, it’s free. You don’t have to argue with your manager to have a part of the EDA budget carved out for an editor.

So why, the Sigasi folks themselves observe, would any EMACS fan in their right mind want to switch to a GUI-based editor for which they are going to have to pay? First, fans will respond that they see no value in a GUI. This part is as much religion as utility. EMACS (and Vi) has a GUI, it’s just less self-consciously “pretty” than modern GUIs. But the utility part is important – while you don’t want to pay for more pretty, you might pay for more utility. Utility of this type can become a requirement for ease of use; in the (production) software world, this battle was over a long time ago. No-one would work for a software company that offered only basic text editors for development.

That meaningful added utility is possible should not be surprising. Macro functions in any general-purpose text editor are necessarily limited to whatever can be accomplished with a shallow understanding of the text, since that is all they can build using regular expression matching. Within those limits they can still do some pretty useful things, but they can never be as capable as a special-purpose editor tuned to a deep understanding of a language, or if they try to do so, macros become unusably slow. For example, VHDL configurations can have significant impact on understanding chip hierarchy, but EMACS VHDL-mode does not look at configurations, presumably because this would be very slow.

Sigasi have summarized their view of differences particularly between EMACS capabilities and those in their Sigasi Pro editor. You’ll see that they give high marks to EMACS, but they note several significant areas where that approach falls short. These aren’t “pretty” GUI features. They are functional features that, if you like what VHDL-mode does for you, you might also reasonably want to have but you may never see in EMACS macro packages.

Finally, Sigasi acknowledge that EMACS diehards will not be won over easily. By raw metrics, EMACS will be faster, run in a smaller footprint, be user-customizable and easily run on a remote terminal. But are raw metrics the right metrics? Should you be measuring how quickly you can do an edit or how quickly you can get to a functioning simulation? And on remote operation – really? We should all know how to run remote X-terms these days. Preferences in an editor will always be somewhat religious, but it does seem that carrying those same preferences to their logical limit inevitably leads to editors like Sigasi Pro. You can learn more about Sigasi’s attempt to convert the EMACS faithful HERE.

Let the apoplectic comments begin…

Comments

0 Replies to “Improving on EMACS for VHDL Creation”

You must register or log in to view/post comments.

Instance

Array
(
    [node_name] => Sigasi
    [node_id] => Array
        (
            [0] => 2
        )

)

Instance

Array
(
    [node_name] => 
    [node_id] => Array
        (
            [0] => 2
        )

    [title] => Recent Forum Threads
)

Threads

Upcoming Events

Supercomputing 2024 (SC24)

2024 SIA Awards Dinner

Wafer Fab Processing

Webinar: Introduction to Power System Reliability Modeling and Design Considerations

Webinar: Virtual ISO 26262 Functional Safety Software Workshop for Automotive Value Chain

Search Semiwiki

Recent Sigasi Articles

A Picture is worth a 1,000 words

Getting More Productive Coding with SystemVerilog

Eclipsing IDEs