In recent months, a number of EDA companies have stepped up to this challenge and announced plans to develop system-level languages for multidiscipline team communication. Options range from some version of C, C++, and Java, to a combination of all three in something known as Superlog. Some have even come together to form the Open SystemC initiative, comprised of a group of over 55 software, hardware, intellectual property (IP), and system companies. This group endorses the standardization of a common class library based on C++, known as SystemC.
Not everyone is convinced that defining a common language for use by every design discipline is the right approach, however. Another option might be for the EDA tools to play the role of interpreter. Better yet, what about the development of autotranslation tools? We already have tools that autotranslate from one language to another, so autotranslation of VHDL to Verilog or C between different sites is conceivable.
Think about it for a moment. You could work in the design language of your choice. Then, when you sent your portion of the design out to fellow team members, it would automatically be translated into their preferred design language. Suppose you speak Italian and have written comments next to your design in your native tongue. Why not have that translated as well, so that every team member can understand your comments?
Some might logically question the accuracy of these translations. To be on the safe side, you can always run an equivalence checker after the translation is complete. If you think that's wild, how about tool environments capable of reading multiple languages at the same time? This is far beyond an autotranslation capability. I'm talking about things like language-neutral simulation and language-neutral synthesis and placement tools.
File Not FoundShould I Fake It? (Y/N)
Continuing on our journey, it's now time to embark on a discussion of communication as it pertains to cores. The Internet offers an interesting platform from which designers will be able to get information about cores. It might include the technical data necessary to sample and use a core, and will most likely be available in a universal language, allowing different hierarchical views for functional verification and suitability.
In general, two levels of communication exist among cores: vertical and horizontal. The vertical direction deals with propagating the target function/performance through the entire design flow, while the horizontal is responsible for maintaining connectivity to other cores.
Most hardships faced by designers working with cores fall into the category of horizontal communication. They stem from interface issues. The search for a solution to this problem has centered on the idea of a platform-based design in which cores could be plugged into a design's standard internal bus architecture. If a standard bus existed, all cores could be designed up front to be compatible with it.
This idea of a high-bandwidth, on-chip bus architecture is appealing because it would enable efficient communication between the cores and other modules within the chip. It also would help to significantly reduce the interface headaches experienced by the different design teams working on a project.
There's only one problem: Which bus do you choose to standardize? Realistically, it's hard to imagine being able to design a standard bus that can handle the various cores' extremely different requirements for communication between devices.
It seems much more likely that designers will ultimately be driven to create custom bus architectures for every chip design. These architectures will meet the requirements of just that design. This approach will be less expensive in die area, and will offer better performance than using a standard platform to integrate cores onto a single chip. In other words, what might be needed is not so much a standard bus, but rather standards to support a fully custom bus.
Regardless of which approach garners the ultimate prize, there's no disputing the need for such a solution to enable reliable core-to-core communication. Just imagine verifying a 10- to 50-million gate design with multiple cores, analog and software content, and no standard interfaces. I'll save you the trouble and spell it out for you. It would take you years to verify and assemble a system of that complexity. Trust me when I say if you have to work that hard, don't even bother. Once standard interfaces are available, you'll be able to integrate, with relative ease, software/hardware cores with other standard components and system elements in a lot less time.
It's quite obvious that standards will play a large role in shaping the design industry in the coming years, and not just in terms of core-to-core communication. They'll make it possible for designers from different disciplines to transparently and accurately view each other's data at a true systems level. EDA and software tool vendors, for example, will need to jointly develop and establish higher-level graphical- and language-based standards that are flexible enough to encapsulate and verify different design types. Such standards will form the basis on which tools can be developed that bridge the gap between traditionally separate design disciplines. The only concern is whether we can count on vendors to bring the needed standards to life in a timely fashion.
It's ironic, but the EDA industryan industry attacked for failing to listen to the needs of the designers it serveswill play a crucial role in ensuring future communication with designers both on and off chip. Unfortunately, EDA vendors also are known for practicing a type of isolationism. Many companies offer integration with other tools, but it's still too proprietary to be of use to most designers.
Vendors need to break the boundaries among tools and flows as a way to encourage industry expansion and the design industry's use of tools. Endorsing standards will be key to overcoming this problem. Standards also will help address the lack of communication between component-vendor data and EDA tools.