 |
 |
 |
 |
 |
Product Overview
All engineering disciplines use pictures to express design intent at some stage in the development process - the design and development of ASIC's and FPGA's (from now referred to as simply chip design) is a highly skilled engineering job, one that embodies enormous complexity at times, so why do we tend to use text, in the form of HDL (hardware design language), as the predominant input mechanism?
There have been numerous attempts at creating the 'ideal' or 'perfect' graphical design tool throughout the late 90's and on into the 21st century, most of these companies no longer exist in their original form or have been merged then de-merged as they try to find a way of creating a viable market to justify the continued development costs. For various reasons this seems to be a tough job and many have failed or just given up, yet the power of pictures is unwavering.
When you look back at the early days of chip design, designers working at the gate level (rather than polygons!) used a schematic tool to hook the gates together and ultimately to document what they had created. With the introduction of RTL (register transfer level) techniques the use of schematics diminished and, for a while, fell by the way side.
With the emergence of the RTL age designers acquired new skills to supplement their gate level expertise. A whole new way of thinking about design capture evolved - moving from gates to RTL fundamentally changes the way designers think about the design, no longer connecting low level gates but cleverly crafting concurrent processes, combinatorial logic equations, complex hierarchies, whilst at the same time considering the way in which the synthesis tool will interpret this effort. New skills, new tools,... but at the end of the day the fundamental goal remains the same - produce an efficient working design within the allotted time and on budget.
Obscured by the rush to RTL was the emergence of a new critical design entry tool, our old friend the text editor; this has become the most widely used tool in the EDA design flow. Every designer has one and uses one at some stage; thus the humble text editor has achieved the EDA holy grail of one-per-desk, something not managed by any other tool to date.
Whist RTL is an ideal vehicle for expressing design intent to a synthesis tool it is not the best way to share intent with other human beings. OK, in the early days, designs were not that big and it wouldn't take an engineer long to whip up a hierarchy diagram (if one was needed) or put together a block diagram showing the overall data flow. So the text editor-to-synthesis flow worked just fine. However, designs would eventually reach a point where manually writing HDL required assistance.
It was a number of years after the demise of the schematic before the first true built for purpose RTL graphical tools appeared on the market. Granted there were a few tools that pre-date RTL but these were originally developed for a different use and were then re-aligned to serve the RTL designer with limited success (SpeedChart comes to mind).
The number of lines of RTL code grew to a point where an opportunity for the re-introduction of graphical techniques arose. In terms of gate size, by today's standard, these were just babe-in-arms weighing in at around 50 to 200k gates. Designs of this size don't tend to be very hierarchical or have a large number of blocks so handling the interconnect graphically was not a burning issue. What had become complex to design were the state machines, especially those in control dominant devices.
So the first 'rush to graphics' was to provide support for complex state machine design. No new radical paradigm just an editable form of bubble charts or flow diagrams.
As the hierarchical needs were minimal all of the tool vendors took the exact same step - they just cloned the old schematic editor with the addition of HDL code generation. No new thinking, no consideration of the long term needs of designers, just a quick re-hash of an old idea. The new design tools spread themselves very wide across the design space adding a myriad of graphical editors to the point where they became inflexible. If design style and methodology did not fit the tool then you had to change. Designers like flexibility, they need flexibility to solve complex problems, the tool must not become part of the problem.
Today's designs are massive by comparison and the hierarchical content way beyond what a schematic tool was designed to handle. Its not that they can't handle lots of blocks, they can, but the pin centric model is unsuited to designing large devices. Individual blocks can have many hundreds of signals, placing and naming each individual pin is excessively time consuming, then routing each of these connections becomes a nightmare and you rapidly reach the point where the schematic no longer offers any value. Experienced designers at 3Com felt that when their designs reached 200k gates schematic capture no longer worked for them and they required a new solution.
In reality the file based structure of language (VHDL/Verilog) is a hindrance when trying to design a high quality hierarchical partition; fewer files saves time by reducing the amount of manual interconnect editing, but fewer files leads to larger more complex design units. This increased complexity reduces readability, all but eliminates opportunities for subsequent reuse and makes designs very hard to comprehend and hence share. Designs that are too coarsely partitioned (simply to reduce the editing overhead!) become inflexible, with small seemingly inconsequential changes having unexpected and unpredictable side effects. This results in early design decisions being locked in simply because they become too hard to change.
Language is just used to 'capture' the design; this implies that the real design work was carried out by other means. On a whiteboard, a notebook, bit of paper, napkins,... the choices are endless. Architectures are drawn, torn up, re-drawn, erased, drawn again until finally someone sits down and translates them into VHDL or Verilog. Then, for some reason we stop drawing pictures, and edit myriads of source files by hand. Every now and then engineers are forced to go through the review ritual and the HDL source is reverse engineered back to a picture just so that the audience can understand the design.
Restaurants frequented by engineers often use paper table cloths, not for the restaurant's convenience, but so that the customers can take their designs back to the lab after lunch!
What is needed is a new tool that combines the flexibility of text editing with the power of graphics. One that directly addresses the difficulties experienced with the text editor when used on large designs. We believe that combining the two techniques will yield a flexible and usable solution that will scale well, reduce the time spent in design capture, allow live design exploration and aid complex design debug.
The Expressive solution combines a graphical hierarchy editor with text entry for the functional behaviour. The new graphical metaphor that forms the corner stone of the Expressive solution is the switch from a pin centric to a net centric model. In a net centric model 'graphical lines' connect islands of functionality (posh name for a block!), each graphical line expresses data flow (be it data, control or address) and can carry 1 or more signals (single or multi-bit). The need for pins (to carry the signal names) on each terminating point disappears (and so does the need to name them), the number of graphical interconnects is significantly reduced so diagrams are easier to maintain, can carry more complexity and provides a unique ability to express abstract relationships between signals that is simply not possible with schematics.
Being a true hierarchy editor allows complex hierarchical edits to be performed with consummate ease; chasing a signal through a myriad of source files to make a name or width change is reduced to a single interaction with one signal instance. Navigating the hierarchy or visualising the hierarchical path of a signal is not only simple, but possible.
The benefits are not limited to the entry phase, but carry on through the debug loop. During a debug session problems isolated to a leaf block are typically easier to diagnose and fix; the correct data arrives at the block boundary, but the transform is incorrect. Much harder to diagnose are inter-block problems; complex signaling (interacting state machines, for example) , multi-step data transformations, etc can pose significant challenges. The first step in successfully tackling these is a good overview of the area under investigation. Which would you rather have to hand; half a dozen text files or an interactive, navigable graphical view?
Why not download the product and test drive it today. For a 15 day fully functional trial go to the download area
|
|
||
|
|
||
|
|
Platform Support
Expressive-IV is only supported on the Microsoft Windows-XP operating system although the current release will run under Windows-98.
Most system configurations will run Expressive-IV although it is an advantage to have a monitor supporting larger resolutions, 1024x768 and above. The processor and system memory requirements are quite moderate as are the disk space needs.
© 2005 - Expressive Systems (Europe) Ltd
webmaster@expressivesystems.com