Blogging Design-for-Test, Goodbye to Summer
Really, goodbye Summer – had enough of you. Sorry, I’m a spoiled Southern Californian: can’t stand the heat, or the cold. [I started this post over a week ago, when summer ended] Many people claim we have no seasons here in SoCal, but as a native, I feel them. Maybe it has to do with the cast of the sun, or maybe it’s just a combination of many different subtle cues (many colored trees, like those to the left are not really in the picture around here). Whatever it is, I look forward to the transition seasons, especially autumn.
I’m somewhat of a summer slacker – and slack I have done, when comes to DFT Digest… but it’s test conference season, so let’s pick it up! So I wanted to point out a couple things I’ve come across in the last couple of weeks, before I really get out of the habit of blogging!
First off, I want to put out the word to any of you, my readers that may be also blogging Test, Design-for-Test, or related subjects (or thinking of doing so), and will also be attending ITC – let’s meet up for a blogger beer, or something like that, at some point during the week. We can also network coverage of the conference if you’re up for it. Let me know, e-mail me: jford@dftdigest.com
As the press releases rolled out announcing this years ITC, I posted comments from my e-mail interview with Bill Eklow, Program Chair for this year’s conference. Rick Nelson of Test & Measurement World also interviewed Eklow – see his interview here.
As a matter of standards, Karen Bartleson of Synopsys, wrote, a couple weeks ago on her blog The Standards Game about ratifying the OCI (Open Compression Interface) standard – IEEE 1450.6.1. This is of particular interest to DFT Digest, and other Design-for-Test folks, since this standard decouples compression IP from ATPG and diagnosis tools – lifting the requirement to use one vendor’s tools for all three, which is the situation today.
Karen’s reason for posting this was to point out that the IEEE standards body does react to the need for such things, and listens to the needs of EDA customers. I agree, and appreciate this, but I have to say that I don’t necessarily think that EDA vendors follow through on creating tools to take advantage of the standards.
Take IEEE 1500 for example: it sure doesn’t seem that any EDA vendors have developed tools that customers can use to implement 1500-like structures on their own silicon. 1500 is used, so far, for more efficient internal interfaces for memory BIST operations, in some tools.
Did customer demand shape that standard?
Stumble It!
I never see IEEE do anything that their members don’t want to see done. Passing a standard through them is like birthing elephants (years of gestation followed by a lot of screaming) but it’s pretty damn vetted by the time it is done. My question is, however, is there now a disconnect between IEEE members and the design community. I know IEEE is facing shrinking membership (http://news.xinhuanet.com/english/2009-09/23/content_12101331.htm_) and is looking outside the United States for growth, and the design community is growing faster outside the US than it is shrinking inside, but until the organization grows in the customer community is there a real interrelationship?
As a membership organisation, the IEEE surely only does what members want to do. Regarding standards, the standards workgroup often has people that ‘represent’ a company.
Regarding the IEEE1500, I am actually quite happy to see that a standard was developped without waiting for the EDA vendors to have a vendor specific tool/constraint. That shows that the IEEE can drive innovation.