Interface-based design sees both forest and trees

Interface-Based Design (IBD) is an exciting new approach to design entry that addresses these designer frustrations. It facilitates rapid design entry and fast modification by reducing the time it takes to describe ports and connect them. Equally important, IBD reduces complexity and improves the ability to visualize IP and document new designs.

IBD augments the existing block diagram and text-based interconnect description paradigms with a compact tabular format. This tabular editing environment allows designers to capture a given level of hierarchy piece by piece. A structure consisting of many modules can be captured as a set of interfaces between small numbers of these modules.

IBD is especially suitable for teams working on large, complex designs with high pin counts and numerous interconnects. Moreover, the approach can be applied to any design. Since the tabular representation is compact, a very complex netlist can be described rapidly in a minimum of space. This means the engineer can see both "the forest and the trees" during the design process without having to introduce unnecessary levels of hierarchy.

A changing design paradigm

One of the largest stumbling blocks in creating complex ASIC/FPGA designs is managing and describing the massive amount of I/O (input/output) between the various functional blocks. To date, two paradigms — text and graphics — have typically been used to enter and view those connections.

IBD bridges those options by employing a third paradigm: tabular. It appeals to those who have used text in the past, and does not force them to learn a completely new set of graphical tools. Tabular entry is easier to enter and comprehend than a complete text description.

More importantly, the tabular paradigm used with IBD provides an extremely fast way of entering and editing a design. Tabular entry is appealing because it is much like the familiar spreadsheet format.

As with block diagrams, IBD allows the reduction of a complicated design to a description of the interconnection between lower level components. Some of those components may be new; others will be components that are available for reuse from a company's previous designs or third-party IP. The difference with IBD is that designers need not worry about elements of graphical layout. Only the pure logical interconnections of a design need be described.

In practice, this spreadsheet paradigm means an IBD table typically has a list of nets down the left-hand side and columns of components. In the simplest case, to represent a connection between a given net and a specific block, a designer simply types in I's and O's for inputs and outputs and B's for bi-directional connections. One can instance components and very quickly add signal stubs, the ports, and the nets that go with those ports. These can then be connected up using I's, O's and B's. Alternatively, arbitrarily complex associations can be made by expanding the Port columns for a specific instance.

In a typical top-down design exercise, an engineer might initially enter an interface definition. Next, some internal signals and components would be added and the design built-up by dragging and dropping additional component blocks into the table.

Throughout the design process, adding additional nets is easy to do: just type in the name, or the name and the type.

Interfaced Based Design

This quick build-up capability is one reason IBD is particularly well suited for complex ASIC and FPGA designs with large numbers of design units. In such designs, it becomes a challenge to visualize what is very often a complex, system-on-chip type of design.

As any given real-world design is constructed, the interconnect tables (ICTs) within the IBD process become an important tool. They keep track of and show how the different design components are connected.

ICTs essentially provide a way to "slice and dice" a given level of hierarchy into smaller groups of inter-connected elements. At the same time, the IBD approach does not force designers to add levels of hierarchy just to simplify an otherwise complex description.

The interconnect tables themselves are visible within an IBD view. They are similar to the worksheets in a standard spreadsheet. Designers can create any number of ICTs, represented as additional tabs. Each ICT would represent a separate collection of signals and components.

The designer can create new, empty ICTs or simply select a number of nets or components of interest and the tool will automatically extract an ICT containing the appropriate components and connections between them. Instances (columns) in each ICT can be re-organized and the ports/nets (rows) sorted "on-the-fly" by any column.

The overriding goal is to enable the design to be built-up in a piece-wise manner while allowing the engineer to concentrate only on a manageable number of connections between a small number of interfaces at any one time. The designer retains the ability to look at the entire design any time.

Since ICTs are not mutually exclusive, an engineer can utilize as many as are desired and overlap them where needed. Logical edits within one ICT are immediately reflected in any overlapping ICTs and in the overall structural description for that level of hierarchy. Some can be expanded into detail; some may remain high level. In addition, a user may switch between them to examine the design.

The future for Interface Based Design

IBD offers its greatest benefits in the upstream portion of the design process. The downstream portion is facilitated by IBD's ability to generate HDL as the end result. A final but significant benefit of IBD is that it is easier to document. That benefit stems from IBD's compact representations of any given design.

With a click of the mouse, the tabular design data can be rendered as a block diagram. With support for Windows OLE and the ability to export the tables in HTML, JPEG, PNG and popular spreadsheet interchange formats such as CSV and TSV, full design documentation is easy and rapid.

While IBD is already an important tool in the complex ASIC/FPGA design process, it will contribute even more in months to come. Already, current releases allow the addition of synthesis constraints; a designer can add columns with property information which then creates constraints for the downstream portion of the design.

In the future, IBD will accommodate even more compact, complex designs, so engineers can portray extremely complicated relationships between many components. Additional support will continue to focus on the ability to describe repeating structures and complex interconnect, while further enhancing the speed and ease of entry, editing and documentation of complex designs.

Mark Dane is Chief Scientist, HDL Design Entry and FPGA Solutions, for Mentor Graphics Corp. He is located in Newbury, England.