Formatting improvements

Formatting continues to improve. With this release, the formatter no longer break defines by inserting a space between the name and the (.

Formatting is now stricter about spaces between operators and parenthesis sign and now knows how to format enums.

Finally, data declarations do not get aligned across blocks. Alignment is a work in progress. Currently, too many items get aligned which works well for a specific coding style but not across some examples. I'm also not a massive fan of aligning objects as I don't think it aides in reading code (though it looks pretty impressive). So for the next couple of releases alignment will be toned down and later re-enabled as an option.

I'm sure you have opinions of what should be aligned and formatting in general. Please let me know your thoughts and where the plugin falls short.

Other improvements:

Fixed “Move variable declaration to before statement” quick-fix corner case: It will now correctly move data declarations to before macro statements as needed.

Resolve of enums inside constraints now works

String concatenation used as arguments to macros now works.

Structure view [CTRL-7] no longer prints null or empty messages for objects inserted by macros. In a future update, it will correctly list these items.

Code Completion:

Work is progressing on keyword code-completion. Now keyword code completion might sound like an easy thing - present a list of keywords and be done with it. IntelliJ's intent with code-completion is to only present valid options. So if code-completion is not offering a particular choice, then this option is (probably) not correct. Enabling code-completion like this takes a more effort but also provides more value.

Today a new release of the SystemVerilog plugin was released. It solves a couple of issues reported by users. It adds support for interface classes (including formatting and resolve), adds a workaround for dealing with global defines and improves formatting by leaning on guidelines from SystemVerilog.io. More on each issue below.

I would much appreciate if you share this post or a link to the website with anyone you think would be interested. I need to reach more users to help show that there is a market for a product like this. With enough support, we can take this plugin to the next level and develop it faster!

I want to become CLion but for EDA - a front-end IDE able to work with all existing tool-chains . With you and your company’s support we can get there! Thank you!

/Robert

Interface classes

Screen Shot 2018-10-24 at 1.43.24 PM.png

Interface classes is a new(-ish) concept in SystemVerilog. I have personally not seen it used anywhere and I'm not sure how well supported it is. Still, I support the idea!

You can tell interface classes was a late addition to the SystemVerilog specification as it's floating free (not referenced by any other rule) in the formal syntax (Appendix A). In other words, going by the spec, you can't reach these rules! At least as far as I can tell.

Interface classes is an intriguing idea borrowed from Java (and Kotlin) that could help when building class libraries like UVM. It's somewhat akin to multiple-inheritance but with less power and fewer pitfalls.

With interfaces, a new DV environment could say "Your sequence object fits into my DV environment as long as you follow the IVM-sequence contract." Then as a DV engineer, I would have to make sure my object follows the IVM-sequence contract by implementing all tasks and functions required.

There are even ways of doing partial implementations that would reduce the number of functions that need implementation.

I think interface classes could improve the UVM library by reducing the over-reliance on macros that implement multiple functions needed by the UVM engine. Implementing UVM using interfaces would clarify to users how it all connects and remove the hassle of dealing with macros.

I'd love to see such an implementation! Please reach out to me if you are using interfaces. Today I fully support the syntax, formatting, and resolution but I'd love to add interface checking directly in the editor. It's quite doable but the list of urgent task is long, and I will only get around to interface class checking if there is a demand.

A workaround for global defines

The SystemVerilog plugin is currently not aware of compile-order or global defines (i.e., defines passed in on the command line). To support these features, a new build environment is needed. A build environment is high on the list of features to add, but until then we now provide a workaround.

There is now a single global define assumed by the plugin. It's called edaphic and is defines as define edaphic 1. You can use this define to wrap code inside conditional compilation directives (i.e.ifdef) that only my plugin will read. In this way, you can make edaphic studio aware of global run-time defines as needed without affecting your builds.

Below is an example of how you can use it. In this example, the file edaphic_global_defines.svh will only be read by the editor and it is used to set up global definitions. At compile time this extra code is ignored since edaphic is not defined then. I hope this helps to pass in global defines as needed. It's not ideal which is why it's called a workaround. With your support, I hope to implement a real build environment soon!

Screen Shot 2018-10-24 at 12.06.15 PM.png

Better formatting

Formatting is essential and a feature I worked hard to make work. A format includes spacing, indenting and aligning objects. The goal is to make your code as readable as possible. The initial approach was to be very permissible, but that leads to poorly formatted results. I recently found SystemVerilog.io’s Style Guide, and it gave me the courage to implement stricter formatting based on its suggestion. This release is only a start, but the end goal is to format code as per the site's recommendations by default while also providing customization options.

Formatting of SystemVerilog is hard. It's not a beautiful language, and there are many places where there are no great formatting options (I'm looking at you multi-line module header that makes indenting the module body awkward).

Formatting differs from company to company, project to project and person to person. Please let me know any places where you disagree with the plug-ins formatting, and I will do my best to fix it or provide customization options.

My goal is to tighten up formatting little by little with each release.

What's next?

The issues solved with this release got me sidetracked from implementing keyword code-completion and better highlighting colors. They are still next on the list of new features to add as they are much needed. However, there are also many new issues reported and solving critical issues takes priority so please keep reporting issues!

2018.3.BETA.1: Improved error messages, formatting and macros

Better macro view