Graham Bell: Hi this is Graham Bell with EDACafť and IB Systems. I have the pleasure of speaking with Gary Stringham. Hi Gary.
Gary Stringham: Hi. How are you doing?
GB: Good Gary. What brings you to DVCon?
GS: Well thereís a bunch of like-minded engineers here that are wanting to improve their designs. Some come with problems that theyíre trying to solve. In fact, last year when I was here, an engineering manager was trying to figure out how he could get software teams involved with the hardware designs early on when there was no budget for the software teams to be involved yet. So we talked about it and I gave him a couple of suggestions like having one software member involved early on or having a list of requirements early on that the hardware team can use even though thereís no software teams involved.
GB: Great. Well what do you see the trends for the industry?
GS: I see the industry moving towards the having software more involved, thereís a lot of emphasis on that which is good because you want to know what the software is going to be running on it so you know how to design the hardware. Unfortunately, not everybody is moving to that yet, and so there are still problems. In fact last month, I heard a couple of managers talk about how software is an afterthought and software is also the safety net for the hardware products. So companies are trusting the success of their products to an afterthought? It makes me wonder about that. But on the other hand, I did get an email just this morning from a guy who said that years ago, a software engineer made a comment to, not a few years ago, a software engineer made a comment to a hardware engineer who added a minor feature to the hardware and that feature had a positive impact even to today.
GB: Excellent. Can you tell us a little bit about the challenges that designers and design teams are facing to get out new products?
GS: Well thereís the chips are getting more complex and the time, the market windows are always getting shorter. But what Iíve seen is a lot of focus on tools and downstream activities, when a focus on upstream activities and design methodologies could have a big impact on cutting out the cost in the verification and system integration later on.
GB: So what does Gary Stringham bring in terms of products and services to these kind of challenges?
GS: Iím a consultant in this space. Iím in the hardware/software domain. Iíve worked with both sides. Iíve even written the book on the subject called Hardware/Firmware Interface Design. Iíve had attendees and clients comment about how my principles and my practices concepts have helped them in their design. So I can help companies out with their challenges in trying to get software more involved with hardware.
GB: Would you like to comment on a particular customer success that youíre especially proud of?
GS: One that I really liked was at Hewlett Packard when I was an engineer there, which was where I developed this, was there was one particular block that was real nasty and it took me over twelve months to write the device driver for it and there were all sorts of other issues with it. When the next generation came out, I had the device driver running in three days.
GB: Cool, sounds like youíve got some good methodologies that can help out design teams. How can our audience find out more, Gary?
GS: They can go to my website, garystringham.com, and my phone and email address are listed there.
GB: Gary, thanks for speaking with our EDACafť audience.
Graham Bell: Hi this is Graham Bell with EDACafť and IB Systems. Today Iím speaking with Gary Stringham of Gary Stringham & Associates. Welcome.
Gary Stringham: Thank you very much. Glad to be here.
GB: Gary, I understand this is your first DAC youíve exhibited at. What brings you to DAC, what are you showing and talking about with the engineers here?
GS: Well this is my first time here at DAC but I have been working in this domain of the hardware/firmware interface. There are people who focus on hardware, people who are focused on the firmware side, but the two sides have to come together to make a final product that can be shipped to customers. That interface in between there has to be designed in such a way that the integration will happen smoothly. Sometimes there are defects in the hardware and you donít want to spend the money to respin the chips. So firmware has to do some things to work around them to get a shippable product. But something could have been done, maybe, hopefully, to have avoided those defects in the first place.
I have a lot of best practices and principles that are used in how to design the hardware to make it easier for firmware to integrate with it. These best practices are more than just with the designs but also the process and procedures. Itís a methodology. So it starts from the very beginning of the early conceptual design phase and goes clear to the end when the product is being shipped out the door. So itís more than just verification, more than just co-simulation and virtual prototypes. Itís involved from the beginning to the end.
The areas cover things like collaboration. Get the hardware and the firmware engineers in the same room and have them talk to each other before hand instead of at the end of the project when theyíre pointing fingers at each other. Documentation is a very important part of collaboration, what kinds of things are in there? The firmware engineers need to have some information in order to do their part. What kind of information is needed in that? How do you design the registers? How do you lay out the bits in a register? What kind of bits should you have in the same register? There are some things that can be done to avoid problems later on down the road.
Now nobodyís perfect; human beings arenít perfect. But later on, when youíre trying to get the hardware and firmware integrated together, thereís going to be problems and youíre in a buttoned up system. Thereís no in-circuit emulators, thereís no JTAG connected. How do you figure out whatís going on? By having some test and debug hooks in the hardware, then it gives the firmware some hooks that can help diagnose problems and work around solutions.
I cover a whole gamut of things from the beginning to the end in how to improve the whole process. Iím more of the methodology kind of guy. Iím not selling tools. I do have a book out, itís available on Amazon.com. Just look for Gary Stringham, youíll find it. But I cover a whole bunch of things like that and what Iím looking for is to help companies with that as a consultant and trainer to teach your engineers, your design engineers, on how to design the products to make your products better.
GB: Can you share with us some of the projects youíve worked on as an engineer over the years?
GS: Well I spent 20 years at Hewlett Packard, the last several years was in the LaserJet business. So I was designing, writing the device driver for some of the blocks in the ASICs. There was one particular block that had all sorts of issues, I wonít go into the details why, but that was just one block. The rest of everything else was normal. But that one particular block took me over twelve months to get the device driver written for it. The abort function was 250 lines of code. And at the end of it, when I finally got the thing to work, we didnít have to respin it, fortunately, there were times when it was real close, but we didnít have to respin it. But at the end I started writing down all the things I wanted to change in the next version and thatís when I looked at it and said, ďOh, this is just common stuff, common sense stuff for all types of blocks.Ē So thatís what led me into this direction here and trying to convey this out to the industry and help the industry as a whole.
GB: Gary, whatís your contact information, whatís your website out there on the web?
GS: GaryStringham.com. Itís fairly easy. And my infoís there and you can contact me through that.
GB: Gary, thanks for speaking with our EDACafť audience today.
Interview by John Blyler, Editorial Director of ExtensionMedia, take at DAC 2010.
Hi this is John Blyler. Iím the editor-in-chief of Chip Design magazine. Today, on the DAC floor, I have the chance to talk with Gary Stringham who has just written a new book on hardware and firmware through Elsevier press. The reason this is important, as all of us know in the EDA community, Cadence has made a big push to recognize and work with the importance of software, and by that, most folks recognized it as firmware in the chip design world. Hereís an example of something that speaks directly to that.
Hi, Iím a firmware engineer. Iíve done a lot of stuff with firmware working very closely with hardware. Iíve done a lot of things in trying to get the software and hardware to work together. I have seen problems with the hardware in trying to get these issues together and so what I have done is collected a whole bunch of best practices and principles to try to get the hardware and software world together. Itís not just verification or virtual prototypes but itís a whole system from the beginning of the design to the end when the product is being shipped out the door.
One of the things I have done is to collect a whole bunch of best practices. For example, one of them is when you design a chip with the bits in the register and you come out with a new version, donít move the bits around. It makes it difficult for firmware to work on both versions of the hardware. Another example is to keep the addresses in the right place. Add some test and debug hooks so that it makes it easier for firmware to try to figure out whatís going on when the thing isnít working correctly.
A very key part is documentation. I know thatís a not-so-nice word among engineers, they donít like to write. But it is a very key tool. One of the things that is very important though is collaboration between the hardware and firmware teams. They need to collaborate before the hardware is designed, before they start designing the registers so that the hardware has the right tools and hooks that it needs for firmware to use.
Gary Stringham & Associates is the company name. What I specialize in is the hardware/firmware interface, or in other words, how to get the hardware and the firmware to play nice in the same sandbox. Some of you have worked with trying to integrate firmware and hardware together and it can be difficult because the two sides havenít talked to each other.
I have a bunch of best practices to get things to work well. For example, how to lay out the bits and registers that makes it easy to integrate the firmware later. I do some consulting and training. Iím not doing designing services. But we do help other teams of engineers get the hardware and firmware engineers in the same room to have them work together on what their best practices should be.
Itís not just in the verification area or the co-simulation or virtual prototypes, but I cover the whole gamut from the very beginning in the conceptual phase trying to make sure that all the pieces are there thatís necessary to get the product working together. And also towards the end phase, especially with test and debug hooks so that when you have problems in the end trying to get the whole thing working together thereís enough hooks and stuff to try to diagnose and troubleshoot and work around the issues that are there.
I work closely with the clients in trying to assess their needs. With best practices, best practices are only good for a specific situation so obviously it needs to be with your specific situation, with your needs and what your situation is and we work closely with that.