Register Bits

For the second year now I’m virtually attending the DAC, the 47th annual EDA conference held this week in Anaheim.  As a web oriented company we’ve yet to exhibit at the EDA industry’s biggest conference in Anaheim.  Not being there physically, I enjoy all the info I can obtain remotely using twitter, blogs, and other online media. This year there seems to be more chatter about cloud computing and EDA - a topic that’s of particularly interest to a web oriented EDA company like PDTi.

Firstly, I saw a twitter post from James Colgan, the CEO of EDA community provider Xuropa, indicating that Kevin Bushby claimed that the Cloud is the only way EDA can grow.   I’m assuming this is Kevin Busyby COO of FastScale Technology which was acquired by EMC, and who formerly worked at Cadence.  While I agree that the cloud can help EDA grow, I’m curious to understand how Kevin and others see it growing.

Here are some ways I can see EDA growing using the cloud:

1. Lower costs for compute resources could lead to larger EDA budgets.
2. The cost and overhead of supporting customer on-site installations and evaluations could be reduced due the more controlled deployment environment of the cloud.
3. The ability to use and get billed for tools at finer granularities could provide access to higher-end tools for companies that can’t afford the traditional EDA license models.
4. The availability of limitless computing resources in the cloud could result in EDA users paying a premium to get that synthesis job or verification regression suite done more quickly.
5. More visibility into how customers are using tools can provide opportunities to better server the customer, adding more value, resulting in greater revenues and profits.
6. Hosting EDA tools in the cloud could eliminate piracy and add to revenues.

Some of these are things that we have already realized with our SpectaReg web application for register management and automation, which is offered onsite, hosted by the customer, or online, hosted by us.  Whether hosted by the customer or us, the application is essentially the same, except the online user has the opportunity for some additional customizations. Interestingly, some of our customers are using virtualization technologies to create their own private cloud where they deploy SpectaReg onsite.

The great thing about the cloud is the ability to scale the compute resources, like RAM and CPUs on demand, and to have failover/redundancy available should some piece of hardware fail.  If one has a fairly static requirement for these then cloud computing might not make sense.  For example, a while back I ran the numbers on the cost of the equivalent of a dedicated machine would be on Amazon’s Elastic Compute Cloud (EC2).  To have the equivalent compute resources available 24 x 7 x 365 via EC2 would cost more; however, a lot of machines are not used full-time and the compute requirements are bursty. This burstyness of compute requirements is where cloud computing really adds value.

To really take advantage of cloud computing, the application must be able to monitor/predict it’s load and be able to scale things up or down dynamically as needed.  EDA applications or their wrapper scripts would need to get smarter to do this.

Another obstacle that critiques of EDA cloud computing often point out is that need to move files between tools and script flows.  Technically, I don’t think this is an issue, aside from perhaps the need for EDA users to increase the bandwidths of their network pipes.  Web service APIs would allow people to script all sorts of operations in their flows and move info between different EDA tools in the cloud, perhaps hosted by different cloud providers.

There are many other angles to cloud computing and EDA, and I could likely write 10 more blog postings on the topic.  In terms of an end market, the cloud is a electronic system and there are opportunities for EDA to serve this growing market . Lori Kate Smith of ARM wrote up the 47DAC reception, mentioning how Mary Olsson of Gary Smith EDA cites Cloud computing as an application driver for EDA.

Another opportunity for EDA and FPGA vendors would be to have a cloud of FPGAs that could be re-configured.  This re-configurable cloud computing would be pretty cool.  Perhaps we’d need FPGA virtualization first, if it doesn’t already exist. Wonder if the folks at Google are looking into stuff like that…

Of course there is also the issue of security when it comes to cloud computing.  I see Harry the ASIC guy was interviewing 2 cloud security experts at DAC and I’ve yet to check that out.  Knowing Harry it will be worthwile.  One concern is that if the cloud infrastructure becomes compromised then everything running on it can potentially become vulnerable.  This is a bit different than a data center with isolated and distinct dedicated machines where each machine would need to be compromised individually.

Clearly there are a lot of opportunities and challenges for EDA with respect to cloud computing.  It will be exciting to see how the future unravels.  Stay tuned.

Twitpic from S_Tomasello "How's the attendance at #46DAC today? Umm..."

Last week at the Moscone Center in San Fransisco, the 46th annual Design Automation Conference (DAC) took place.  I’ve attended this conference for the past 4 years and decided not to attend this year.  This year I attended virtually using the web.

In the EDA media and for EDA trade shows, as Bob Dylan sang, the times they are a-changin’.  It’s no secret that the incumbent media is struggling to find a business model that works in the uncharted waters of the future.  As history repeats itself, the “hidden hand of supply and demand” will no doubt fix some shortfall with the traditional model — a shortfall that may not be fully understood until it is solved.

With the electronic media shedding their top writers, the coverage of DAC by trade publications is diminishing.  At the same time, new media, such as blogs, Twitter, and LinkedIn are picking up some slack.  For example, Richard Goering and Michael Santarini who historically covered DAC for EETimes and EDN now write for Cadence and Xilinx respectively.  Some of the best DAC summaries that I read were blogged by:

• Peggy Aycinena’s on her Thursday’s Child (R U a Wizard of Management Warcraft?)
• Mike Demler on his “The World is Analog” blog (Highlights from the Design Automation Conference, #46DAC - Day 1)
  
• Richard Goering on his Cadence blog (Ten Takeaways From the EDA CEO Panel, 8 Design Managers Reveal Top Concerns, GPUs Or Multicore For EDA Applications?)
• JL Gray’s Cool Verification (The Past, Present and Future of the DAC)
• Paul McLellan on his EDA Graffiti blog (day 1, VC Panel, denial computing)
• Sean Murphy at SKMurphy.com (provides a great index of blog postings on the 46th DAC)

Additionally, on Twitter, the #46DAC tag provided useful information about what was going on at the tradeshow.  For me, some tweeps who provided informative DAC coverage via Twitter included:

• Dark_Faust — editor in chief of Chip Design & Embedded Intel magazines & editorial director of Extension Media
• harrytheASICguy — ASIC consultant & blogger, did a Synopsys XYZ conversation central sessions at DAC
• jlgray — Consultant with Verilab, photographer, coolverification.com blogger, conference presenter
• karenbartleson — Sr. Director of Community Marketing at Synopsys and blogger on “The Standards Game.”  Karen won “EDA’s Next Top Blogger” at DAC.  Karen did a lot of tweeting to inform people about the #46DAC and Synopsys Conversation Central had a “Twitter Tower” that displayed the #46DAC stream.
• MikeDemler — Tech industry analyst, former marketing insider (from Synopsys), blogs at “The world is Analog”
• paycinera — EDA Confidential editor Peggy Aycinena broke her cryptic series of gobbledygook biography tweets, the EDA Town & Gown Twitter Project, to provide some of the best Twitter coverage from DAC
• S_Tomasello — Marketing at Sonics, the providers of “On-chip communications networks for advanced SoCs”

Based on the various reports and summaries from DAC, there is an apparent need for collaboration (as mentioned by keynote Fu-Chieh Hsu of TSMC) and productivity (as mentioned by the CEO panel). The same forces that are changing EDA trade media and conferences — the power of the Internet, coupled with economic forces –may enable the solution to better collaboration and productivity. Cloud computing business models like Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), and Software-as-a-Service (SaaS) are starting to prove themselves in other industries and will continue to find their way into commonplace. Exactly what the “hidden hand of supply and demand” has in store for EDA and cloud computing has yet to be revealed and we are just in the early stages now.

From various blogs and Twitter, without having attended DAC, I understand that:

• there continues to be a need for better collaboration, productivity, and higher levels of abstraction
• today’s current economic situation, spurred by the US credit melt-down, has affected EDA
  • the traditional trade media is struggling
  • new chip design starts are down
  • Magma design Automation, released that they are re-negotiating debt as a result of an audit report regarding their solvency, just as the conference was kicking off
  • traffic on the trade floor was questionable: some said it was above expectations while others said it was below
  • new VC investment in EDA start-ups is pretty much non-existent
  • TSMC is becoming more and more of an ecosystem heavyweight
  • there is optimism about the future and the recovery of EDA — with change and crisis, there comes opportunity for those who see it
• the media landscape is changing
  • there is a struggle between the blogsphere and traditional press to cover EDA
  • blogs are gaining acceptance and playing more and more of a role
  • filtering through and connecting disperse info is a problem
  • John Cooley dismisses the utility of blogging, LinkedIn and Twitter and critics say Cooley just doesn’t get it (or virtual platforms and virtual prototypes for that matter)
• there are big opportunities for Software design, and EDA can play there
  • Embedded software has the possibility to double EDA, says Gary Smith, who has pointed to software as the problem for several years now
  • embedded software seats are growing but market is fragmented
  • software IP is of growing importance in the differentiation of SoC platforms
  • the programming models need to change for multi-core
  • multi-core and parallel computing programming models are still pretty low level, like assembly and micro-code
  • Mentor Graphics announced their acquisition of Embedded Alley Solutions, a leader in Android and Linux development systems, unveiling their new Android & Linux strategy
• System Level is big, particularly for SoC virtual platforms, architectural optimization and IP
  • the SPIRIT Consortium and IP-XACT has merged into Accellera, and there continues to be a need for better standards
  • IP still has a lot of potential and the business model is becoming clearer
  • Despite the importance of ESL, much work is still done at lower levels of abstraction
  • ARC International, the IP and configurable processor provider, is rumored to be under acquisition
• FPGA
  • Companies are moving to FPGAs and away from ASIC
  • ESL is big for FPGAs
  • Not nearly as much FPGA discussion at DAC as there should be
• Cloud computing opportunities are being underlooked by EDA (let’s start with the on-site private cloud then look at multi-tenant ecosystem clouds)

In conclusion, I was able to absorb a lot of details about DAC without attending thanks to all the bloggers, Tweeters and trade media.  EDA is changing in some exciting ways that scream opportunity for some and failure for others, and that’s what makes the future so exciting.

I met Gary Stringham, an embedded systems consultant, at the 45th DAC SPIRIT Consortium meeting in Anaheim where we demonstrated the SpectaReg web-app using IP-XACT.  Since then, I’ve been subscribing to Gary’s excellent Embedded Bridge monthly newsletter, which provides best practices for the hardware/firmware divide.  Gary is a big proponent for register module generation tools like SpectaReg and he recommends such tools as one of his best practices.

Issue #26, of the Embedded Bridge newsletter discusses level-triggered vs. edge-triggered interrupts and makes a good case for using edge-triggered interrupts. Why?  Well, because level-triggered interrupts are painful for the firmware engineer.  Level-triggered interrupts cause extra complexity, extra CPU cycles, and create a possibility for missed interrupts.

Consider the following example…

Imagine you are creating a packet receiver (PR) hardware component. When the PR processes an errored packet, it asserts a status signal (pkt_err_stat) until the next packet comes in. The following table shows the PR’s register bits, which are mapped into addressable registers and are all one bit wide.

When pkt_err_stat is asserted, an interrupt is generated (if enabled).   The interrupt causes firmware to vector to it’s interrupt handler, where it identifies that PR has an interrupt (since has_int for PR is asserted).  Firmware then reads PR’s interrupts to discover that pkt_err_int is asserted.

Level-triggered case: In the case where pkt_err_int is level-triggered and the next packet has yet to be received, then pkt_err_stat will still be asserted.  To exit the interrupt handler, the firmware must disable then clear the interrupt by writing one to it.  The issue now is… when does firmware re-enable the interrupt?  With the interrupt disabled, how does firmware know if the next packet is errored?  Answering these questions from firmware creates un-needed complexity.

Edge-triggered case: If pkt_err_int is an edge-triggered interrupt, then the firmware is simpler and less prone to missing back-to-back errored packets.  To exit the interrupt handler, the firmware simply clears the interrupt.  When the next packet comes in, if it’s errored another interrupt is generated and there is less risk of missing this event.

One objection to edge triggered interrupts, as Gary points out, is that they take up more logic gates.  When I read Gary’s level vs. edge triggered Embedded Bridge issue, I decided to look at SpectaReg’s generated VHDL and Verilog to see how we did our interrupts.  It turns out that we originally only had level-triggered interrupts.  To add support for positive edge-triggered interrupts, the RTL was pretty much identical to the level-triggered, it just required sampling the last value of the status (pkt_err_stat in the example) and using that to determine when to generate the interrupt. If the current value is 1 and the last value was 0 then the interrupt is generated.  This results in one additional flop per edge-triggered interrupt and a little more combinational logic.  The cost is insignificant compared to the benefit.

So…. all you Verilog and VHDL RTL developers, next time you go to create an interrupt bit do the firmware developer a favor and make it edge triggered.