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.
