Is Specialization Good For Hardware Development?

Last night I started reading “The Machine That Changed The World”. It’s a book from 1990 that I’ve been meaning to read for a couple years that documents the rise of lean production through the 1900′s at companies like Toyota. The second chapter called The Rise And Fall Of Mass Production foreshadows a point on specialization that is discussed in detail (I’m assuming) later in the book. I thought it was interesting enough to post here for opinions on how it may or may not apply to specialization in hardware development.

Continue reading

Posted in Leadership | 1 Comment

SVUnit Future Directions

Future Directions of SVUnit

This post looks at some ideas for future directions for SVUnit.  Both Neil and I put forth our views.

Continue reading

Posted in TDD | Leave a comment

Happy New Year!

All the best to you and yours for 2012.

Neil and I want to wish everyone following AgileSoC a very Happy New Year!

AgileSoC has grown tremendously over the past year, and we’ve received many appreciative and insightful comments about what Neil and I are trying to do.

We look forward to 2012 — where our conversation with you about AgileSoC will continue to grow and develop.

Bryan & Neil

Posted in Uncategorized | Leave a comment

TDD for RTL

In this (very late) post, I attempt a look at why RTL designers should use Test Driven Development (TDD) to create each of their modules.

For this topic espeically, I’d like to hear your experiences with TDD, whether you think TDD is an appropriate methodology for RTL, and if you’ve been following along with our TDD-month(-and-a-half), whether you agree with Neil’s and my position that TDD is a great addition to our ASIC/FPGA development toolbox.

Continue reading

Posted in Uncategorized | Leave a comment

TDD: Verification with SVUnit

Introduction

In my last posting, I gave a brief overivew of the SVUnit framework, and it’s usage model. This post will look at how to use this framework in your workflow: how it can be integrated into your existing verification methodology to help develop new verification components, and extend existing environments.

At this point, I’ll state that the key determinant for a successful introduction is attitude. The developers must see merit in using this approach, or at least trying the approach with an open mind. Otherwise, it will very likely not be successful.

Continue reading

Posted in Uncategorized | Leave a comment

Test Driven Development: Introducing the SVUnit Framework

Up until now, we’d been discussing the justification of using TDD in an ASIC development flow.   Hopefully, we’ve convinced you to try it.  In this post we’ll introduce a TDD framework that has been developed for SystemVerilog to help you use this design technique.

A couple of weeks ago, just after we got started with TDD month, Neil added the link to the posts on several industry forums, and got this comment from Alex Gnusin on the verification guild:

“Is it a Designer responsibility to test each line of code? In this case, there is a need to provide designers with working methodology to verify their code…”

To which Neil responded:

Alex: I’m not sure if you guessed we’d be covering the topic of a working methodology – aka: unit test framework – but if you did, I’d like to thank you for that nice bit of foreshadowing!

Alex is right, a proper framework is pretty important for anyone doing TDD; primarily because it gives you the opportunity to get up and running quickly.

In the software world, there are are number of wildly popular unit test frameworks. JUnit might be the best known (for those doing java development) but there are about a million others (as you can see with a quick trip over to Wikipedia). A unit test framework is critical for TDD, that’s why myself and Rob Saxe (both formerly of XtremeEDA) put one together a couple of years ago for people wanting to do TDD with SystemVerilog.

First presented at SNUG San Jose in 2009, SVUnit is a unit test framework that provides:

  • structures for creating and running unit tests
  • utilities for reporting test status and results
  • a test “runner” that executes a set of test suites and report on their overall success/failure
  • scripts to automate the mechanical aspects of creating new unit test code
Posted in TDD, Tools, Uncategorized | Tagged , | 3 Comments

TDD And A New Paradigm For Hardware Verification

We’ve looked at why teams should consider doing TDD; we’ve looked at how the roles and responsibilities change between design and verification experts; now let’s look at when everything happens. This is the key to seeing how everything fits together.

Most teams nowadays chose to split their verification effort up as a combination of block level and top level testing. Block level testing is usually applied to every subsystem in a design and intended to exhaustively cover all the features of each subsystem. Once the block level testing is done, the exhaustively tested pieces are integrated and tested in a top level testbench.

Continue reading

Posted in Functional Verification, TDD | Tagged | 15 Comments

TDD In Hardware Development: Who Does What?

Welcome back for TDD month round 2! In our first post, Test Your Own Code!, we laid out some of the motivation for using TDD with some general discussion of the mechanics and benefits. If you read Test Your Own Code!, hopefully you’ve put some thought into where it actually fits into hardware process because that’s the topic we’re tackling today. I don’t think it’s trivial, but we can definitely squeeze TDD in. Here are my thoughts. Continue reading

Posted in Functional Verification, TDD | Tagged | 3 Comments

Test Your Own Code! (I’ve Got Better Things To Do)

November is TDD month on AgileSoC.com. This is the first of a few installments where we look at the potential of Test Driven Development (TDD) in hardware development.

If you’re unfamiliar with TDD, the first and most obvious thing you’ll notice is that TDD breaks a boundary that many hardware teams – ASIC teams in particular – consider absolutely unbreakable.

With TDD, the person that writes the code, tests the code.

[Gasp]

Before you rattle off all the reasons why it doesn’t make sense for people to test their own code, let me give you some background and attempt to explain where we’re going, both in this post and with our wild scheme to introduce TDD to hardware engineers!

Continue reading

Posted in TDD | Tagged | 3 Comments

Does Constrained Random Verification Really Work?

Being that we’re a week away from TDD month on AgileSoC.com, I thought that an appropriate way to get people thinking in a different direction – yes… test-driven development would take us in a different direction – would be to dig up a functional verification article from a couple years ago that I co-wrote. A good part of the article focused on legacy process and it opens by taking a few shots at constrained random verification.

Constrained random verification is pretty mainstream in ASIC and FPGA verification these days, though it does mean different things to different teams. The argument for constrained random verification has always been that it’s a more productive way to cover the state space in increasingly large and complex designs. I used to believe that wholeheartedly. But after seeing and hearing about it fall short – from an efficiency point of view – many times, my current impression of constrained random verification is that it just doesn’t work as well as we all want it to.

Continue reading

Posted in Functional Verification | 5 Comments