Liz Massingill interviews InPA’s Joe Gianelli
This month, a new company announced its entrance into the rapid prototyping space. It goes by the name of InPA Systems. I was lucky enough to be able to grab a few minutes with its VP of Marketing and Business Development, Joe Gianelli, in order to learn a little bit about this new start up, its exciting new technology and how it could impact the future of rapid prototyping.
Joe Gianelli
Liz: InPA….not an obvious name. What does it stand for?
Joe: Yeah, that’s an obvious question. It stands for integrated prototype automation, which are the characteristics of the technology we bring to the market.
So what InPA Systems is integrating is the RTL simulation and FPGA prototyping environments and automating a critical portion of the “bring up” that verifies that the mapping of the RTL code into the multiple FPGAs correlates to the original RTL code.
Liz: So InPA is in the rapid prototyping area, a segment that’s been around for, what, 20 years? What do you bring to the market that’s new?
Joe: InPA’s mission is to more fully harness the power of today’s FPGA rapid prototyping systems. Our most noteworthy technological capability is bringing debug visibility to users – who used to have to fly blind.
Basically, Tom (Huang) and Michael (Chang) saw the need for a more complete rapid prototype environment that integrated today’s RTL verification and rapid prototype environments with better visibility.
Liz: So technically, how does this work?
Joe: Without getting into a technical schpiel, InPA Systems integrates the RTL code and FPGA prototype environment so that engineers can debug in their RTL code while accessing their captured faulty conditions with full visibility. The automation here is to cross-link the RTL code with the captured faulty condition and to expand full signal visibility around the faulty condition.
We’re also enabling full system debug. This is when engineers are integrating the software and hardware design components enabling engineers to catch issues easier when integrating both HW/SW in the FPGA prototype environment. The automation here enables full system debug with “active debug” technology to dynamically control HW and to cross-trigger between FPGAs.
And finally, we’re automating the full capture of faulty conditions across multiple FPGAs. Today, engineers must capture and debug one FPGA at a time.
Liz: That’s got to be key! Why is it important or noteworthy to integrate and automate this?
Joe: It’s extremely tedious and difficult to isolate a hardware problem when it spans RTL code over multiple FPGAs. Giving the engineer the ability to fully capture the faulty scenario leads to much quicker isolation of the actual problem.
Liz: What does this new technology offer to the user that he or she hasn’t been able to accomplish up until now?
Joe: Right now, engineers probe around in the dark looking for problems in the hardware, one FPGA at a time. We give them the tools to explore various scenarios without having to recompile FPGA place and route…this is a real pain for engineers today. And we give them full visibility around their problem, making it easier to detect and fix.
Liz: What does “active debug” mean?
Joe: It’s allowing the engineer to remain active in the debug process; forcing certain circuit states, capturing data at speed, analyzing the data, and essentially remaining active in the debug process as opposed to probing around in the dark and waiting for another FPGA P&R iteration. What we call Active Debug is a combination of technology and methodology that increases the productivity of engineers who are integrating hardware and software and validating in-system with a rapid prototype .
Liz: So it’s an answer to the old debug visibility problem, right?
Joe: You got it.
Liz: So I have to ask, how is it different from existing debug? Passive debug, is it?
Joe: Yes. As most current systems use the passive debug approach, they only probe the circuit looking for possible problems with limited visibility, which doesn’t allow the user to dynamically create different conditions in the circuit that allow for testing of those conditions while running in the FPGAs.
In contrast, active debug allows the user to force various conditions in the circuit, capture over multiple FPGAs, analyze in a user friendly simulation environment, while reducing the number of FPGA P&R iterations.
Liz: Why is it important to debug in your “active” mode?
Joe: One of the biggest challenges of the SoC design team is debugging problems when integrating SW and HW together. Today, most SoC design teams are integrating their SW and HW on FPGA prototype systems and using the debug tools from the FPGA vendors which were not architected to debug large SoC designs over many multiple FPGAs. Consequently, engineers are not very productive using these tools as they search in the dark, one FPGA at a time, with limited visibility. Allowing engineers to become more “active” in their debug process moves them closer to isolating the bug much faster. It’s really allowing them to do their jobs much more efficiently.
Liz: I’m trying to hone in on the visibility function InPA brings to designers. What do you mean by “visibility” and how is that different from current prototyping methods again?
Joe: Visibility is really two things. First, it’s allowing engineers to capture their faulty conditions over multiple FPGAs as opposed to one FPGA at a time. This gives them much greater visibility into the potential problem. Secondly, our technology expands all the signals in the captured scenario giving engineers full signal visibility.
Part 2 of this interview will air on September 6.
The pre-DAC acquisitions of Denali and Virage drastically realign the core of the EDA industry. When IP first came on the scene here in the US, (I think 3Soft was the first IP company I saw), many people figured that IP would become another form of delivery for chip designs – and that they would come from the semiconductor companies.
This acquisition puts Synopsys squarely in the front of the pack as far as IP suppliers go. This trend could be quite significant. Successful IP reuse is a combination of the right EDA tools, best practices methodology and well-designed IP. The EDA vendor is a pretty good place for all that to come together. ARM remains the exception to this rule, and several other rules for that matter.
I don’t see how this doesn’t make Synopsys a competitor with ARM on physical IP and ARC processor. ARM should start feeling like it is getting surrounded by Synopsys.
With EDA trying to expand its scope and grow beyond its traditional boundaries (see EDA360), and with small and medium size IP vendors struggling to grow, basic economy forces are pushing this trend.
Mike Gianfagna, well known and long time EDA executive, has quite a bit to say about the EDA360 manifesto that’s electrified the EDA world. As vice president of marketing at Atrenta, Inc, Mike has been an astute, articulate participant in the EDA value discussion. I was able to grab a few minutes with Mike to ask how EDA360 helped define the 2010 and beyond definition of EDA value and how it might alter the industry’s direction.
