Among the least likely events to take place at a conference as big and noisy as the Design Automation Conference is an intense, unplugged conversation with an industry leader, especially in the midst of the Exhibit Hall. Nonetheless, I had a chance to sit and talk with eSilicon co-founder and CEO Jack Harding for almost an hour in his company booth on Monday morning, June 2nd, at DAC in San Francisco.

In the background, outside the flimsy walls of the suite in which we were talking, one could hear the roar of the opening-hour crowd in the exhibit hall, mixed with the unmistakable sounds of Gary Smith revving up nearby for his annual Pavilion Panel in that blues band style he favors.

Prior to June 2nd, I hadn’t seen Jack Harding for 7 years. At that time, thanks to Brian Fuller’s eavesdropping on a private conversation, my disagreement with Jack about how tech leaders get their kids to study technology ended up in Brian’s blog for all the world to read. If Jack knew, he probably didn’t care – he’s always lived by his own rules – whereas I followed rules written by others, so I did care and hence approached this month’s appointment at DAC with marked trepidation. How unnecessary.

Harding never mentioned our disagreement in 2007. Instead I found him a great conversationalist, honest, self-effacing in a particular way, and interested in a wide range of issues. Naturally, I don’t regret Brian Fuller wasn’t hovering nearby to report out on the conversation, but I do regret Jack and I didn’t have an additional hour to chat in San Francisco. He began by reminding me that success in the tech sector can depend on a host of “exogenous variables.”

This year at DAC, a question asked repeatedly got our attention: Do you offer advanced formal training program?

While we are not surprised by the request itself, the number, size, type and location of companies that asked about this was surprising. It included a wide spectrum of companies, from the U.S., Japan, Korea, China, along with large companies with established formal teams as well as small start-ups with no formal experience. Even EDA vendors asked if we could do training for them.

Monday at DAC 2014 in San Francisco was IP Day. Part of the day’s program included a panel featuring entrepreneurs pursuing the business of third-party IP: CAST’s Hal Barbour, Truechip Solutions’ Shishir Gupta, IPextreme’s Warren Savage, Methods2Business’ Marleen Boonen, and Recore Systems’ Dirk Logie.

After the panel, I had a chance to speak with Hal Barbour, CEO at CAST. I asked him if the received wisdom is correct – most innovation in silicon IP comes from small companies.

Hal said, “Traditionally, almost all innovation in the SIP business has come from small entrepreneurial companies. Large companies have gained their position through aggressive acquisitions, and not through internal development. Unless things change in unforeseen ways, it’s going to be difficult for the large companies to dramatically change this model.”

The Agile methodology has been talked about for some years. To be frank, I have given the matter very little attention – I just had a basic idea of what it was all about. I suppose I had a feeling that the approach was rather chaotic and disorganized, which is at odds with my view of what programming should be like. However, I attended a talk at a conference a while ago which changed my mind. The presenter was, in essence, trying to sell some project management tools that support the Agile methodology. But he also described the philosophy in terms that I could appreciate. I realized that what was being proposed was very similar to the approach that I have espoused for many years …

We hope you enjoyed last week’s guest post from Jonah McLeod of Kilopass with his experiences at this year’s Design Automation Conference (DAC) in San Francisco. We’ve offered several of our friends in the EDA industry to write in with their assessments of the show. Next up is Lauro Rizzatti, another industry veteran perhaps best-known as general manager of EVE-USA. These days he’s a verification consultant, and he shares his story of going to DAC as a conference attendee rather than as a vendor:

This is the first DAC where I wasn’t responsible for an exhibitor booth and it was exhilarating. I was able to attend sessions, walk the exhibit floor and, generally, get a feel for what’s going on in our industry. I’m pleased to report the news is good. Very good, in fact.

This year at DAC, we asked attendees to participate in a guessing game – make an educated guess about how long it takes to formally verify a design based on the given design description and statistics.

How Long Does it Take to Formally Verify This Design?

Here is a recap of the information provided to participants:

Design Description
Reorder IP packets that can arrive out of order and dequeue them in order; when an exception occurs, the design flushes the IP packets for which exceptions has occurred. Support 36 different inputs that can send the data for one or more ports. Another interface provides dequeue requests for different ports. Design supports 48 different ports.

Design Interface
Packets arrive with valid signal; a request/grant mechanism for handling requests from 36 different sources; All 36 inputs are independent and can arrive concurrently; All 48 ports can be dequeued in parallel using another request/grant mechanism.

Design Micro-architecture Details
Supports enqueue and dequeue for IP packets for 362 different input and 48 different ports respectively; 48 different queues used to store IP packets for different ports; A round robin arbiter resolves contention between enqueue requests from different sources for the same port at the same cycle.