Posts Tagged ‘System Verilog’

An ASIC Guy Visits An FPGA World - Part II

Monday, June 22nd, 2009

Altera FPGA

I mentioned a few weeks ago that I am wrapping up a project with one of my clients and beating the bushes for another project to take its place. As part of my search, I visited a former colleague who works at a small company in Southern California. This company designs a variety of products that utilize FPGAs exclusively (no ASICs), so I got a chance to understand a little bit more about the differences between ASIC and FPGA design. Here’s the follow-on then to my previous post An ASIC Guy Visits An FPGA World.

Recall that the first 4 observations from my previous visit to FPGA World were:

Observation #1 - FPGA people put their pants on one leg at a time, just like me.

Observation #2 - I thought that behavioral synthesis had died, but apparently it was just hibernating.

Observation #3 - Physical design of FPGAs is getting like ASICs.

Observation #4 - Verification of FPGAs is getting like ASICs.

Now for the new observations:

Observation #5 - Parts are damn cheap - According to the CTO of this company, Altera Cyclone parts can cost as little as $10-$20 each in sufficient quantities. A product that requires thousands or even tens of thousands will still cost less than a 90nm mask set. For many non-consumer products with quantities in this range, FPGAs are compelling from a cost standpoint.

True, the high-end parts can cost thousands or even tens of thousands each (e.g. for the latest Xilinx Virtex 6). But considering that a Virtex 6 part is 45nm and has the gate-count equivalent of almost 10M logic gates, what would an equivalent ASIC cost?

Observation # 6 - FPGA verification is different (at least for small to medium sized FPGAs) - Since it is so easy and fast and inexpensive (compared to ASIC) to synthesize and place and route an FPGA, much more of the functional verification is done in the lab on real hardware. Simulation is typically used to get a “warm and fuzzy” that the design is mostly functional, and then the rest is done in the lab with the actual FPGA. Tools like Xilinx ChipScope allow logic-analyzer-like access into the device, providing some, but not all, of the visibility that exists in a simulation. And once bugs are found, they can be fixed with an RTL change and reprogramming the FPGA.

One unique aspect of FPGA verification is that it can be done in phases or “spirals”. Perhaps only some of the requirements for the FPGA are complete or only part of the RTL is available. No problem. One can implement just that part of the design that is complete (for instance just the dataplane processing) and program the part. Since the same part can be used over and over, the cost to do this is basically $0. Once the rest of the RTL is available, the part can be reprogrammed again.

Observation # 7 - FPGA design tools are all free or dirt cheap - I think everybody knows this fact already, but it really hit home talking to this company. Almost all the tools they use for design are free or very inexpensive, yet the tools are more than capable to “get the job done”. In fact, the company probably could not operate in the black if they had to make the kind of investment that ASIC design tools require.

Observation # 8 - Many tools and methods common in the ASIC world are still uncommon in this FPGA world - For this company, there is no such thing as logical equivalence checking. Verification tools that perform formal verification of designs (formal proof), System-Verilog simulation, OVM, VMM…not used at all. Perhaps they’ll be used for the larger designs, but right now they are getting along fine without them.


FPGA verification is clearly the area that is the most controversial. In one camp are the “old skool” FPGA designers that want to get the part in the lab as soon as possible and eschew simulation. In the other camp are the high-level verification proponents who espouse the merits of coverage-driven and metric-driven verification and recommend achieving complete coverage in simulation. I think it would really be fun to host a panel discussion with representatives from both camps and have them debate these points. I think we’d learn a lot.


harry the ASIC guy

Setting The Record Straight

Thursday, February 19th, 2009

Since conducting the Verification Methodology Poll and publishing the raw results last week, I’ve been planning to follow up with a post that digs a little deeper into the numbers. Things have gotten rather busy in the meantime, both at work and with organizing the SaaS and Cloud Computing EDA Roundtable for next week at DVCon. So I’ve let it slip a little.

Well, I noticed today that the verification methodology poll was referenced in a Cadence blog post by Adam Sherer. The results were somewhat mis-interpreted (in my opinion), so that kicked my butt to post my own interpretations to set the record straight. Says Adam:

According to the poll conducted by Harry Gries in his Harry the ASIC Guy blog, you should go “all in” on the OVM because it is the 2:1 favorite.

In fact, the raw results had VMM with 80 users and OVM with 125 users, a ratio of just over 1.5:1 (1.5625 to be exact). So the 2:1 ratio is not accurate. However, if you add in RVM/Vera users to the VMM numbers, and then add in AVM, eRM, and e users to the OVM numbers, that ratio is more like 1.8:1. Closer, but still not 2:1.

It also indicates that my poll says that “you should go ‘all in’ on the OVM”. I never said that nor does the poll say anything about what you “should do”. The data simply captures what people are planning on using next. If you are inclined to follow the majority, then perhaps OVM is the way to go. By contrast, there is nothing in the poll comparing the technical merits of the various methodologies. So, if you are inclined to make up your own mind, then you have some work to do and my poll won’t help you on that. You’re probably better off visiting JL Gray at Cool Verification.

No poll is perfect and it will be interesting to compare to DVCon and John Cooley polls to see if they are consistent. Here are a few other interesting stats that I pulled out of the poll results:

  • 91% of respondents are using some sort of SystemVerilog methodology
  • 10% are using both OVM and VMM (although I suspect many of these are consultants)
  • 27% are still using e or Vera (more e than Vera)
  • 4% are using ONLY VHDL or Verilog (this number may be low due to the skew of respondents towards advanced methodologies)

Again, I welcome you to download the raw data, which you can find in PDF format and as an Excel workbook, and draw your own conclusions.

harry the ASIC guy

DVCon Survey Results - What Do They Mean?

Tuesday, January 27th, 2009

I came across some interesting survey results from the 2007 and 2008 DVCon. Keep in mind, like with any survey, results are skewed based on attendees, which tend to be verification engineers who tend to be using the more advanced methods than the general population. Hence, I’d put more weight on the trends than on the absolute numbers.

1) Which is your primary design language?
                2007     2008
Verilog          56%      55%
VHDL              9%      10%
C/C++            13%      12%
SystemC           9%       8%
SystemVerilog    13%      15%

2 Which primary verification language do you use?
                2007     2008
C/C+             18%      18%
e                 7%       5%
OpenVera          4%       4%
Verilog          28%      25%
VHDL              7%       7%
System C         13%      11%
SystemVerilog    23%      30%

3) Which primary verification language do you plan to
use for your next design?
                2007     2008
C/C++            16%      15%
e                 5%       4%
OpenVera          1%       2%
Verilog          16%      16%
VHDL              4%       5%
SystemC          15%      11%
SystemVerilog    43%      47%

4) Which primary property specification (assertion-based
verification) language do you use?
                2007     2008
Verilog          31%      34%
VHDL              7%       6%
PSL              12%      10%
SVA              49%      50%


harry the ASIC guy

A Tale of Two Booths - Certess and Nusym

Tuesday, June 10th, 2008

I had successfully avoided the zoo that is Monday at DAC and spent Tuesday zig-zagging the exhibit halls looking for my target list of companies to visit. (And former EDA colleagues, now another year older, greyer, and heavier). Interestingly enough, the first and last booths I visited on Tuesday seemed to offer opposite approaches to address the same issue. It was the best of times, it was the worst of times.

A well polished street magician got my attention at first at the Certess booth. After a few card tricks, finding the card I had picked out in the deck, he told me that it was as easy for him to find the card as it was for Certess to find the bugs in my design. Very clever!!! Someone must have been pretty proud they came up with that one. In any case, I’d had some exposure to Certess previously and was interested enough to invest 15 minutes.

Certess’ tool does something they call functional qualification. It’s kinda like ATPG fault grading for your verification suite. Basically, it seeds your DUT with potential bugs, then considers a bug “qualified” if the verification suite would cause the bug to be controlled and observed by a checker or assertion. If you have unqualified bugs (i.e. aspects of your design that are not tested), then there are holes in your verification suite.

This is a potentially useful tool since it helps you understand where the holes are in your verification suite. What next? Write more tests and run more vectors to get to those unqualified bugs. Ugh….more tests? I was hoping this would reduce the work, not increase it!!! This might be increasing my confidence, but life was so much simpler when I could delude myself that my test suite was actually complete.

Whereas the magician caught my attention at the Certess booth, I almost missed the Nusym booth as it was tucked away in the back corner of the Exhibit Hall. Actually, they did not really have a booth, just a few demo suites with a Nusymian guarding the entrance armed with nothing more than a RFID reader and a box of Twinkies. (I did not have my camera, so you’ll have to use your imagination). After all the attention they had gotten at DVCon and from Cooley, I was surprised that “harry the ASIC guy” could just walk up and get a demo in the suite.

(Disclaimer: There was no NDA required and I asked if this was OK to blog about and was told “Yup”, so here goes…)

The cool technology behind Nusym is the ability to do on-the-fly (during simulation) coverage analysis and reactively focused vector generation. Imagine a standard System Verilog testbench with constrained random generators and checkers and coverage groups defining your functional coverage goal. Using standard constrained random testing, the generators create patterns independent of what is inside the DUT and what is happening with the coverage monitors. If you hit actual coverage monitors or not, it doesn’t matter. The generators will do what they will do, perhaps hitting the same coverage monitors over and over and missing others altogether. Result: Lots of vectors run, insufficient functional coverage, more tests needed (random or directed).

The Nusym tool (no name yet) understands the DUT and does on-the-fly coverage analysis. It builds an internal model that includes all of the branches in your DUT and all of your coverage monitors. The constraint solver then generates patterns that try to get to the coverage monitors intentionally. In this way, it can get to deeply nested and hard to reach coverage points in a few vectors whereas constrained random may take a long time or never get there. Also, when you trigger a coverage monitor, it crosses it off the list and know it does not have to hit that monitor again. So the next vectors will try to hit something new. As compared to Certess, this is actually reducing the number of tests I need to write. In fact, they recommend just having a very simple generator that defines the basic constraints and focusing most of the energy on writing the coverage monitors. Result: Much fewer vectors run, high functional coverage. No more tests needed.

It sounds too good to be true, but it was obvious that these guys really believe in this tool and that they have something special. They are taking it slow. Nusym does not have a released product yet, but they have core technology with which they are working with a few customers/partners. They are also focusing on the core of the market, Verilog DUT, System Verilog Testbench. I would not throw out my current simulator just yet, but this seems like very unique and very powerful technology that can get coverage closure orders of magnitude faster than current solutions.

If anyone else saw their demo or has any comments, please chime in.

harry the ASIC guy