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

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.

[youtube_sc url=9xVfIqcY1Qw width=640 height=480]

-neil

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

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

Agile Hardware Hangout Schedule

I’ve scheduled a regular agile hardware hangout to run weekly on Wednesday nights. You can either join us from the google group where I’ll post links and updates or you can go directly to the google hangout every wednesday at 7:30pst. Anyone interested in agile hardware development can join to ask questions and/or talk about whatever they like. Hope to see you there!

-neil

Agile Hardware Hangout

Screen Shot 2014-08-13 at 9.33.30 PMUPDATE: I’ve started an agile hardware hangout google group. I figured posting hangout links there would be better for keeping people posted on when/where we get a hangout started. Please join the group if you’re interested in this.

I often have a difficult time differentiating between good ideas and completely stupid ideas. I’ll admit to having had more stupid ideas than good ideas, also that I have no idea where this particular idea will end up. But in the name of friendly collaboration and pulling together the agile hardware community, I’ve decided I’m just going to go for it and see what happens.

Continue reading

The Great Agile Hardware Myth

What’s completely clear is that agile was created by software developers for other software developers that write software. Agile was not created for hardware developers that build hardware so there can be no such thing as agile hardware, right?

Nope. Wrong. I’ve heard a few comments to that effect over the years from people that are just mildly familiar with agile. I’ve heard similar comments from others honestly trying to wrap their heads around it while tripping over preconceived notions and losing themselves in hearsay. Truth is, what it means to be agile is not cut-and-dried, even within software nevermind hardware. I figured it’s finally time to take a step back to clear a few things up so that people new to the discussion can form a healthy definition for “agile hardware”. Continue reading

Win A Limited Edition AgileSoC.com T-Shirt

This is it… and it’s real. It’s the prize your friends and colleagues can only dream of. Your team… your entire company… even your family will wish they had one.

It’s a limited edition AgileSoC.com t-shirt!

photo 2 photo 1


Here’s how you win: respond with a short comment on why you think agile development works for hardware. Maybe it’s Scrum… or TDD… maybe incremental development… pair programming… retrospectives… whatever… just scroll down to the comments and tell us why it works. To be fair, even if you don’t believe agile has any application whatsoever in hardware, tell us why. A comment either way gets you into the draw.

At precisely 10:13am, Tuesday July 1, my 3 year old daughter will draw a winning name from the list of comments… and that person’s dream comes true.

To repeat, a comment telling people why agile does or doesn’t work for hardware gets you into a draw for a limited edition AgileSoC.com t-shirt. This shirt will change your life. It’s changed mine. I haven’t taken my AgileSoC.com shirt off since the day I got it.

…and when I say a limited edition, I mean limited edition. Only 2 people on the planet have one. One lucky comment could turn you into #3.

-neil