Goodbye AgileSoC.com… For A While

On Friday I decided I could use a break from the blog so I’m going to step away for a bit. Not exactly sure for how long, but it might be a while. Or maybe not. We’ll see. Meanwhile, you’ll still be able to find me at neil.johnson@agilesoc.com for questions, comment and discussion re: agile hardware. Later.

-neil

Share/Bookmark
Posted in Uncategorized | 1 Comment

The Key To Test-driven Development of RTL

For me, this is a very exciting post because I think I’ve made some pretty important headway regarding TDD for hardware designers.

My big side project as of late has been a real pilot dedicated to using TDD to write RTL. I’ve blogged about some of the things I’ve learned already but the big eye-opener that I haven’t talked about yet is how TDD helps us with design partitioning and testability. Continue reading

Posted in TDD | Tagged | 5 Comments

The Starting Point for Agile Hardware (That No One Thinks About)

It should be obvious by now that I don’t mind paddling against the current. And I don’t mind suggesting a rethink of “best practices” we use in hardware development. But then there’s the practices that even for me are touchy subjects, where I know I’d be uncomfortable. Continue reading

Posted in Agile | 6 Comments

The Goal Of An Agile Hardware Team

Considering there’s been lots of new visitors to AgileSoC.com the last few months, I figured now would be a good time to (re)welcome everyone with a reminder of why we’re all here! Continue reading

Posted in Agile | 8 Comments

Agile Is More Than Just Concurrent Development

Considering SoC development requires several disciplines and considering our history of specializing and siloing these disciplines, it’s easy to see why people fall into the trap of equating agile development with concurrent development. But they aren’t the same. Continue reading

Posted in Agile | 1 Comment

Now Is Not The Time To Be Practical

They call them comfort zones for a reason, it’s because they’re comfortable.

I don’t like being in my comfort zone because when I get comfortable I fail to recognize when a change is necessary. I start framing uncomfortable change as impractical, then concoct seemingly logical arguments to avoid it. Trouble is, some of these arguments aren’t logical at all. They’re just my way of avoiding the pain that comes with taking the chance.

Some may think that becoming an agile development team is impractical; that the approach won’t work for them, that it’s too big a risk or it’ll be all pain and no gain. Where agile becomes impractical, it’ll be watered down or avoided.

As an example, suppose someone suggests XP as a model for an agile transition. Amoung other things, XP brings with it a series of primary practices. If XP doesn’t fit into your comfort zone, there’s any number of practical reasons for why you might avoid any – or all – of these practices (listed in bold). Continue reading

Posted in Agile | 2 Comments

Agile IC Methodology From Sonics

Here’s a marketing video posted yesterday from Sonics about an Agile IC Methodology they’re promoting in the run-up to ARM TechCon. Normally I might not post stuff like this directly on AgileSoC.com but I’m making an exception because one of the people in the video is me… along with some other guys that are far more recognizable :) .

If you watch the video, I hope you’ll take a few minutes to comment. I’m interested to hear what people think about it and the fact that a few different folks within the industry are coming together to promote agile development.

-neil

Posted in Agile | 1 Comment

Now What?

You’ve started doing TDD or unit testing your systemverilog code with SVUnit, your defect rate is down and you’re producing better code. You’re at the point where your experience could benefit the rest of your team but you’re not sure how to get the point across.

What do you do? Continue reading

Posted in TDD | Tagged | 1 Comment

Stepping Through an RTL Unit Test

Pretty much every testbench I’ve ever built, used or seen has a free-running clock that’s driven within a while or forever loop. Not much can happen without the clock in a synchronous design so defining the clock logic is usually the first and most obvious thing we do as verification engineers.

Screen Shot 2014-09-22 at 1.51.14 PM

Assuming your design-under-test is synchronous to the positive edge (they almost always are), testbench components usually do their work somewhere off the posedge to avoid races. With even a simple testbench these days, there will be several components, each with their own thread, pushing or pulling data from various interfaces on the DUT. The free-running clock is that steady bass drum beat that holds everything together. Continue reading

Posted in Agile | Tagged | 3 Comments

TDD for Design Proof-of-Concept

It’s finally time to see if TDD is a viable technique for writing RTL with verilog. But first, a little backstory…

For the Agile2014 conference in Orlando this past summer, Soheil and I built an Agile hardware/software co-development demo using a Xilinx FPGA with an ARM dual core Cortex-A9 to show how TDD could be used to write embedded software, drivers and RTL (i.e. TDD of a complete system). Continue reading

Posted in Agile | Tagged | 4 Comments