Enough Already About Collaborating With The Fab!

In the last 2+ years that I’ve dedicated to applying agile methods to hardware development, a big part of my focus has been on using agile to bring design, verification and software developers closer together. In my opinion, we have room for improvement in that area. From the beginning, I’ve seen incremental development as being the key for improvement because it pulls experts together, forcing them to continuously prioritize and exercise what they plan to deliver instead of hunkering down in their cubes and hoping things come together at the end.

But with all the effort I’ve put into this, I’m starting to wonder who else is thinking the same way. Is a lack of meaningful collaboration a problem in SoC development or am I seeing a problem that doesn’t actually exist? I’m starting to question my observations – or imagination perhaps – for a few different reasons.

The big one for me lately has been all the effort dedicated to increasing collaboration between design house, EDA and fab. Now I’m sure the value there is huge, but so much emphasis on collaboration between design house and fab, to me, insinuates that this next level of collaboration is a natural extension of what is already a highly collaborative environment within the design house. Is that true? Are cohesive, collaborative teams and shared priorities the norm in SoC development? Or, for example, are design and verification sub-teams formed and insulated from each by ambiguous product specifications and bug tracking databases as well as independent priorities, scheduling, and reporting structure?

It’s also easy to notice all the attention being paid to enabling early software development as software becomes an increasingly dominant component of an SoC. That’s certainly been propelling innovation in ESL design not to mention emulation and hardware acceleration. But in focusing on those areas, is it being suggested that pulling in software start dates is the missing link to getting successful product out the door? What about the fact that hardware and software tend to be treated as completely independent deliverables? Or that hardware and software development for the same SoC may be controlled by 2 separate groups within the same organization? Do early start dates compensate for that kind of deep rooted disconnect?

Of course it’s easy to generalize. Not all teams are in the same boat with respect to how they work together. And I’m certainly not suggesting a culture of bickering and infighting. That’s not the point of this at all because that’s something I don’t see. My points relate to the organizational and operational levels and on those levels there are characteristics that SoC teams exhibit almost universally. Splitting into independent functional sub-teams is one example (modeling/architecture, design, verification, software, implementation, validation, etc). A preference for working toward a single big-bang deliverable is another tendency. Software and hardware teams that are separated organizational is yet another. The list goes on.

The details and extent obviously vary team-by-team but I don’t think I’m making this stuff up. I reckon there are significant gains to be made through a critical look at and restructuring of SoC development teams in the name of stronger collaboration. Take the time to question the barriers you put up between design, verification, software and everyone else that contributes to delivery. Imagine how regular shared goals and an agile approach to development can help break these barriers. If you’re wondering what agile SoC development could look like, you can read an article I co-authored with Bryan Morris called Agile Transformation in IC Development to find out.

And of course…

Despite what the title says, continue to pay attention to collaboration with EDA and fab. Continue to invest in ESL and emulation as a means of expediting software development. I don’t want to downplay either of those because they deserve the attention they’re getting. Just don’t forget to mix in a little time for some other things that are just as important.

neil

Q. What are your thoughts on SoC team structure and how we develop and deliver products? Are we good the way we are or are we due for a change?

Do Agile And Hardware Emulation Mix?

That’s a question I’ve asked myself several times in the last couple years but have never got around to answering it, not because I don’t think it belongs but because I don’t have much experience with it.

My opinion: I think emulation belongs in agile hardware development for a few reasons… and I’m choosing to ignore the “faster than simulation” advantage that always comes with emulation. These are better reasons to like emulation:

  • It can be used to encourage application level thought
  • An emulator is a practical environment for hardware/software co-development
  • It provides a platform for connecting real peripherals and test equipment
  • Real peripherals and test equipment provide a better “visual” during customer and stakeholder demos

I think the real value of emulation is in these bullets that focus on the application level view of a piece of hardware, the platform it provides for software developers and how a product is used in a real system (or at least real’ish). If I’m right, then I’d like to think the question becomes how do you get to an emulator as soon as possible so you can start realizing this value. I have a feeling this is where agile comes in… incremental development specifically as well as everything it takes for great x-functional teamwork.

I have my thoughts on how teams get started with agile development using agile development using simulation… I’d like to hear how others think it could work with emulation.

neil

Q. Are you an emulation expert that has seen the path of least resistance when it comes to getting product deployed to an emulation platform? What does it look like?