SIP and System Design

Electronic News,  Nov 6, 2000  by Frank Schirrmeister

• E-mail
• Print
• Link

San Jose

BEFORE JOINING THE FDA industry, I managed design teams that developed and licensed multimedia intellectual property (IP), and integrated these cores into customer system-on-a-chip (SOC) designs. At that time, we implemented a complete MPEG-2 decoder as a single-chip solution with all the functionality of transport decoding, video, audio, simple graphics and control. Since then, both the available silicon real estate and the demand for more application functionality on one chip have increased dramatically.

Understandably, these trends have an impact on present and future design teams. It strikes me though that one obvious result is a fundamental confusion about what system design means as compared to designing at the system level. Clearly, it starts with the term "system."

Well, we thought the system/video/audio decoder was already a pretty complex animal. However, to quote Anders Forsen from Ericsson, "Every system somehow becomes a component for somebody else who has to deal with a more complex, but in the components more abstract, view of the system." For example, our SOC was integrated with the processor and application software, and the actual board ended up in the set-top box that needed to be proven in the field's video broadcast network.

Previously, design teams numbering up to 25 members during the coding phase, often included a couple of "system gurus." In addition to their think-tank, meditation sessions (thanks to the Italian pizza delivery service), the system gurus maintained and protected the system-level interface specification, decided which functions were implemented in software or hardware, and delegated the module design tasks at hand. Critical decisions about the partitioning of systems were traditionally based on designer experience, ad hoc rules of thumb, and sometimes just "gut-level" instinct. It's no wonder Microsoft's Excel became a cool tool for implementing partitioning decisions.

Of course, the moment of truth was the actual "big bang" test--the hooking together of hardware and software implementation models with models representing the application software. The realization at this point that a function now in software really should have been implemented in hardware for performance reasons might well prove to be a pivotal point in the career of the system guru.

The chips in the field today contain even more system blocks and include DSPs and RISC cores. And, software-configurable solutions are also entering into the equation to make things even more interesting for the already challenged design teams. Fortunately, design teams today have access to commercial tools, which enable them to verify the hardware together with a detailed processor model.

So, what does this have to do with system design? Design teams today have little choice but to make design decisions and trade-offs much earlier in the development cycle--driven by the higher levels of system hardware and software integration required to achieve performance, functionality and cost specifications. This requires simulation of the entire system and at multiple levels of abstraction. On this point, there is no debate. However, what remains a topic for discussion is whether design teams are using the right tools and models to answer the right set of questions at the most critical points throughout the design process.

Take for example, the register transfer level (RTL) simulation of a single PAL frame, a fairly common operation that previously took my design teams 12 hours to complete. Okay, let's factor in the increased simulator efficiency available today, but also contrast that with the increased complexity of an SOC design, which is more than likely connected to a instruction-set simulator running 100,000 to 500,000 instructions per second. A possible synchronization issue between video and audio occurs after 40 frames. Yes, design teams can identify the issue by simulating the system at the RTL level. However, just two seconds in real-time will take 480 hours.

Is this the right level at which to make partitioning decisions based on a reasonable set of real-time data? Of course not! Design teams have to make these decisions while designing at the system level. This means, if simulation is involved, models at the right level of abstraction are a must.

We need to move up the abstraction curve and use models that enable us to make fundamental design implementation decisions at the system level. We made a similar journey about a decade ago when the industry went from gate to RTL models. Detailed information about the less abstract model--gate delay and connection delay--were modeled and abstracted upward to enable assessments using the faster, more abstract model.

Now, we must move from RTL models to IP blocks, which are defined using fast, timing-free simulation models in C, C++, SPW, etc. Functional models must be accompanied by performance models for the IP blocks as well as interconnect performance models that model the target hardware/software architecture. With access to these types of models, it becomes feasible and practical to make design decisions at the system level.