Thoughts on IC development, EDA, and hardware design languages.

SystemVerilog Insights: always @* and always_comb are not the same !!

Posted by:Trent McClements | Posted on: February 3rd, 2015 | 7 Comments

Always_comb is one of a number of new process types added to SystemVerilog to give developers more control and improve code readability. On the surface always_comb seems like a convenient short-hand for always @*, but, surprisingly, that's not actually the case. always_comb is actually quite different than always @*, and you should be aware of how if you plan on using it! (more…)

Read More

Industry Insights: Why is engineering productivity not a top-down goal?

Posted by:Brad Quinton | Posted on: January 27th, 2015 | 2 Comments

Over the last 15 years I've been on both sides of the EDA/Semiconductor fence. I've used EDA tools to develop ICs, and I've developed and sold EDA tools. I've worked for companies big and small, even started my a few of my own, and one constant I have observed is that the demand for productivity enhancements flows from the engineers on the ground up into the "business side", not the other way around. On the surface this is surprising. High quality engineering talent is a rare commodity, you would expect that companies would be scrambling to improve productivity to get the most out of these rare (and relatively expensive) resources. (more…)

Read More

SystemVerilog Insights Series: Using the (controversial?) .* Shortcut

Posted by:Trent McClements | Posted on: January 20th, 2015 | 1 Comments

The last post in the series was about the .name SystemVerilog syntax and, a bit to my surprise, it generated a lot of great commentary, and even a bit of controversy on the value, origins and use of the .* syntax! So I figured we'd dive into .* and look at it's benefits, downsides, and perferred usage in today's post! It's easy to think of the .* syntax as a wildcard match of instance pinouts to their associated signals or ports within the instantiating module, or even as a wildcard-matching shorthand layered on top of the .name notation. But this isn't really true as there are some subtle differences between the notations that you have to be aware of! First, let's take a look at the .* usage with a quick example. (more…)

Read More

EDA Tool Developer Series: Does Your Tool’s GUI Scale?

Posted by:Mike Lee | Posted on: January 13th, 2015 | 0 Comments

If I were to look back at my EDA developments I would easily state that high up among the list of the most difficult aspects was GUI development. And not just GUI usability, that is hard enough on it's own, but in the world of EDA, GUI scalability can also be really tricky. Even something as conceptually simple and common as a design hierarchy browser can cause you conniptions as you scale up from a small testcase, through a block or subsystem level design, and up to a full chip. Lets take a look. (more…)

Read More

SystemVerilog Insights Series: Using the Port Connection Shortcuts

Posted by:Trent McClements | Posted on: January 6th, 2015 | 13 Comments

How much time have you wasted pulling interconnect through your hierarchy? I always found this very tedious, especially when the connections were obvious throughout a design hierarchy – clk goes to clk, rst to rst, etc. With SystemVerilog we now have a couple of quick shorthand methods for doing these type of I/O connectivity assignments. While they are convenient to use, we should also be aware of the shortcomings, limitations and consequences of their usage. (more…)

Read More

EDA Tool Developer Series: Always blocks don’t have sensitivity lists!

Posted by:Brad Quinton | Posted on: December 16th, 2014 | 11 Comments

Everyone knows how a SystemVerilog always block works, right? Always blocks contain sensitivity lists that describe when they should be executed. We all write our RTL that way. Common sense, right? Actually, it's not true. In fact, always blocks, and the other SystemVerilog processes (initial, always, always_comb, always_latch, and always_ff) are not, in fact, connected to the sensitivity list. The sensitivity list is actually connected to a sequential statement or a compound sequential statement that follows. A bit surprising. Let's take a look... (more…)

Read More

SystemVerilog Insights Series: Packages and Macros Together? Watch Out!

Posted by:Trent McClements | Posted on: December 9th, 2014 | 4 Comments

In Verilog, marcos were (arguably) a necessary evil for defining global constants. Luckily SystemVerilog has a better, cleaner way: Packages. But, unfortunately, to ensure backward compatibility, macros didn't go away. Now, in SystemVerilog you can use both, but if you do, watch out..! In our last post in this series we started to look at compilation units, and we promised that in this post we would push deeper into the intricacies of how packages, macros and compilation units come together. First, let's take a look at how packages and macros are related to compilation units. We'll then probe into a use case that will show the subtlety surrounding these structures. (more…)

Read More

How much is that home-grown Perl/Tcl script costing you?

Posted by:Brad Quinton | Posted on: December 2nd, 2014 | 14 Comments

It always starts out so innocently. You run into a roadblock in your design/verification process and you say to yourself: "I could write a quick script to fix that...". And so you do. It goes pretty well at first, but there are a few bugs and you need to spend a little time on StackOverflow. You then find a few special cases in your Verilog that costs you some time but you still manage to get it done by noon. (Cost: 1/2 day). Now you are feeling pretty good. "Software is easy", you say to yourself, "this is going to save me a bunch of time." At lunch you mention your exploits to your co-workers, and they are impressed. "That sounds great. Can I use that script?". "Sure", you say, feeling good that others are going to benefit from your proactive approach. (more…)

Read More

EDA Tool Developer Series: Identifying Asynchronous Resets in Verilog and SystemVerilog

Posted by:Brad Quinton | Posted on: November 25th, 2014 | 4 Comments

Welcome to Invionics' EDA Tool Developer Series. In this series we will discuss ideas, challenges and implementation details around building your own EDA tools. Today we will start with the problem of identifying asynchronous resets in Verilog and SystemVerilog RTL. The ability to correctly identify asynchronous resets is critical for a number of reasons, but one of the most important is for correct discovery of clock domains. Clock domain identification is at the core of many custom EDA tools, from partitioning to linting and re-timing. (more…)

Read More

Take charge of innovation in your IC design flow … build your own tools!

Posted by:Brad Quinton | Posted on: November 17th, 2014 | 8 Comments

IC Design is hard.  Really hard. Luckily, IC Design, Verification and CAD Engineers are an extremely talented and creative bunch.  Their job is to innovate everyday.  And they do.  But why should the innovation stop on the device design and verification side? At Invionics, we believe it is time for IC vendors to take charge of innovation in their IC design and verification flows by building the custom tools they need to get to market faster and with better products than the competition.  We also believe that a platform approach will make this quick and easy to do (but more on that later). "But wait", you say, "we have been here before! The major semiconductor players used to build their own tools, but then decided it was more cost effective to outsource the effort to the EDA industry".  True, but internal development never did go away completely.   (more…)

Read More