Integration Insights

Automation without abstraction is like a bicycle without pedals

I’ve noticed recently that the word ‘automation’ can be used very loosely in the EDA industry as a presumption of productivity and quality.  Here is a quirky take on 'Automation without abstraction'

 

IP Integration : What is the difference between stitching and weaving?

As a hardware design engineer, I was never comfortable when someone talked about IP integration as ‘stitching a chip together’.  First of all, it sounded like a painful process involving sharp needles, usually preceded by a painful accident. I happened to be the recipient of said stitches when, at 8 years of age, I contested a stairs post with my forehead, and sorely lost. I have to say, luckily, I have been quite adept at avoiding the needle and thread ever since. That was of course until once when, an hour before that important customer presentation, my top-shirt button, due to an over enthusiastic yawn, pinged across my hotel room floor like a nano-UFO. A panicked retrieval of the renegade button was followed quickly with a successful hunt for an elusive emergency sewing-kit.  The crisis quickly dissipated as I stitched back the button in a random-but-directed type of methodology. Needle-less to say stitching, whilst sometimes necessary, makes me uncomfortable.

  

 

Stitching, according to Wikipedia, is “.. the fastening of cloth, leather, furs, bark, or other flexible materials, using needle and thread. Its use is nearly universal among human populations and dates back to Paleolithic times (30,000 BCE).”  It also states that stitching predates the weaving of cloth. So, 32,000 years later, in these hi-tech times we are still stitching things together. It’s not fur this time, but ‘ports’. Stitching a chip together involves connecting ports together with wires. (Note the terminology also where, if you don’t use certain ports you ’tie’ them off).

  

 

Weaving is a different game altogether. One definition simplifies weaving as ‘creating fabric’. Thus a key differentiator between stitching and weaving is that stitching may refer to fixing/mending things whilst weaving is used to create. Stitching is an emergency, an ah-hoc approach (please refer to my stitched button above) whilst weaving is more structured, more planned. Stitching invokes the image of  being bent over, eyes squinted, immersed in the tiniest of detail. Weaving is more graceful and productive. In IC design flow terms, I equate stitching with scripting. It is task that is useful to join pieces of the flow together. Weaving creates something. It transforms thread to cloth, and therefore equates more to synthesis.  Weaving is a process.

  

 

So when it came to developing and naming a tool used to effectively integrate IP and create a chip hierarchy, in a structured manner, we didn’t consider consider ‘STITCHER’ - It had to be ‘WEAVER’.

  

 

Stitching is important to fix things, and is necessary in emergency situations, however it has its limitations and as if used as a core creation process, it may come  undone.   So as I ranted on during that vital presentation, as I got to the cusp of the value-add, I curbed my enthusiasm, keep it slightly in check just in case those button stitches came undone and resulted in a serious eye injury of an altogether innocent customer. What then, of those poor stitched chips? What if those threads start to unravel and your chip integration is running very late. You may have to resort to different type of Weaving, when dealing with your management, customers or partners.

  

 

Weaving (v) : A way of eluding punches by turning and twisting movements.

 

 

IP-XACT Usage Survey Results

I've compiled the complete IP-XACT survey results  here for anybody interested in them. Thanks to all who contributed.  In general, I think a lot of useful information is contained in this survey. As with all surveys, they are open to interpretation - I've detailed mine in the following paragraphs. If you have other optinons then you are more than welcome to post a response.  I also intend to offer some thoughts on my next post regarding how to address some of the issues raised.

Response

There were 41 respondents from 33 companies. Company names and emails have been omitted from the results (and sometimes company/individual and product names) have been removed. Most questions got and average of 30 responses. The only mandatory question to answer was the email address to qualify the survey. In general a good mix of IP provider, IP consumer and EDA companies have been represented.

IP-XACT Usage

The main point here are is that IP-XACT 1.4 is the most popular version at the moment.  There are still quite a few companies sitting on the fence and not using it. However it is clear that there is movement toward IP-XACT 1.5 (IEEE-1685-2009) as more companies started using IP-XACT so far this year than last year.  Most  respondents want to move to IP-XACT 1.5 within a year.

IP-XACT Adoption

Efficient IP integration and high-productivity is seen by most respondents as a very important reason to adopt IP-XACT.  Being an accepted industry standard is also quite important. In general it seems as if IP-XACT adoption has delivered benefits reasonably well.  While it has helped with providing standardized IP interfaces,  the HW/SW interface definition benefit is reasonable but the promise of providing an interoperable design environment doesn’t seem to have been delivered very well. 

IP-XACT seems to be more difficult than easy to adopt, especially for EDA vendors.

To help facilitate adoption, the main areas that stand out are proper EDA tool support with good documentation. Availability of design examples is not seen as extremely important.

When asked for feedback in facilitating adoption a point that was made several times was the lack of standardized bus-definitions or packaging standardisation provide poor interoperability for packaged IP.  

“IP_XACT Vendor bus definition and port mapping to bus def won't make any sense if the IP meta data exchanged between IP vendor and IP consumer. This requires agreement between all IP providers”.

Good documentation is another area that was highlighted in the open feedback as facilitating adoption. The proposed documentation however should probably be focused on usage and adoption rather than being a data format specification.

Another area to facilitate adoption is the proving of real benefits/ROI over current flows, so some real use-cases metrics would help here.

Other area for facilitating adoption included, better links to the physical data/design flow, provision of a proper validation suite, provision of an open source tool-kit, quicker consolidation of standard and become more inclusive of the SW domain.

Also a recommendation by a IP consumer/provider is to make improvements suggested by EDA vendors :)

IP-XACT Features

Main highlights here is that most current IP-XACT features are seen as important.

• Registers and memory maps were seen as extremely/very important.
• In general RTL modelling elements like ports, interfaces, instances, connections, ad-hoc/hierarchical connections and interconnections were seen as extremely/very important.
• Designconfigurators and component generators were seen as very important
• TLM definitions are seen as very-somewhat important with Bridges and channels and constraints slightly less important
• Abstractors/filesets, CPUs and configurators were somewhat important
• Whitebox elements were seen as not very important.

IP-XACT Interfacing

The majority of companies use EDA (or proprietary) tools to write/read IP-XACT. Surprisingly many companies use a text editor to edit the IP-XACT XML.

TGI doesn’t seem to have very a very successful adoption. Most companies (64%) don’t use the TGI at all and 12% use it infrequently. While 16% use it frequently and  8% all the time.

SystemRDL has had even a less successful adoption. Most companies (73%) don’t use the SystemRDL at all and 15% use it infrequently. While 7.7% use it frequently and 3.8% all the time. IP providers rarely use it .

The numbers shouldn’t be considered absolute and there are companies that do use TGI and SystemRDL but it seems that while most companies use IP-XACT EDA tools (industry or internal) , they don’t use the TGI or SystemRDL as an interface.

IP-XACT future enhancements

Most items presented rated fairly important. The enhancement that was considered the most important in the future was best-practice usage guidelines.  Other contenders are verification extensions (e.g. UVM) connectivity enhancements and simplification of the standard.  Items that scored the lowest were enhancements for raising abstraction, constraints extensions and generator enhancements.

Some interesting enhancements were proposed including a full read/write API on the full data model and a warning that the model shouldn’t evolve until there is a clear use-model and clear user demand.

Final Feedback

There were calls to make IP-XACT more of a system-oriented standard rather than being oriented more toward HW and allow an ecosystem where “designers from hardware, programmable hardware, and software domains can all work together within a single design platform.”

Fast standardization was mentioned again as was simplification and less verbosity.

Last but not least, some feedback :

"I have great hopes that IP-XACT can solve many of the IC design issues that we now face but so far it has not been widely accepted. It is time to start "Evangelizing" and show designers how it can really help them."

Most respondents want to  know more about the standardizion activities.  Hopefully they can become more involved and, through their contribution to this survey, they are! - thank you.