Archive for May, 2009

This is a technical posting for the firmware readership.

One of the most elegant ways of expressing register bit-fields in C/C++ firmware is using a union of a struct with a register word.  The problem with this is that there is no standard way for representing the bit field packing/ordering in C/C++, which restricts portability across compilers and architectures.  For the simple traffic light controller (TLC) example with the register-map shown here, the LightState Register’s Green, Amber and Red bit-fields can be represented as shown below, assuming most to least significant bit packing.

union TLC_STATUSREGISTERS_LIGHTSTATE {
    struct {
        volatile unsigned : 29;
        volatile unsigned green : 1;
        volatile unsigned amber : 1;
        volatile unsigned red : 1;
    } fields;
    volatile u32 reg;
};

If the bit-order packing is reversed, then it needs to look as follows:

union TLC_STATUSREGISTERS_LIGHTSTATE {
    struct {
        volatile unsigned red : 1;
        volatile unsigned amber : 1;
        volatile unsigned green : 1;
        volatile unsigned : 29;
    } fields;
    volatile u32 reg;
};

The reversal of the bit fields can be done using auto-generation based on a bit-ordering condition with a register automation tool like SpectaReg.  For non-generated static code, it can be accomplished using #ifdefs, and sometimes compiler pragmas.

The most portable way to deal with register bits in C/C++ is NOT to use this struct/union fanciness — instead do the required masking (and possibly shifting) using bitwise operators.  SpectaReg produces both the struct/union format and also the shift/mask format. How does the RegisterBits readership do it?

EDA Veteran Paul McLellan recently wrote an entry in his EDA Graffiti blog entitled SaaS for EDA.  Being a vendor providing the only real SaaS tool for register automation, I was naturally excited. I was a bit less enthused when McLellan indicated on twitter (he tweeted) that he didn’t think SaaS for EDA would fly.  Upon reading his blog posting, it seems his position is more along the lines that SaaS for EDA will not fly for the traditional, EDA bread and butter applications.  He did indicate that SaaS for EDA does have a chance for the front-end of chip design and for FPGA flows.  This is good to hear because it aligns with our coordinates at PDTi, where we focus on the firmware/software register interface.

I started to write a comment for McLellan’s posting but soon realized that I had a lot to say - more than should really be put in a comment.  Hence I decided to write this RegisterBits blog entry.

In general, I know about the front end of EDA tool-flows and not much about the back end.  That being said, having worked with complex IC development flows at Intel and a smaller startup, I understand how there is a common back-end flow and files are large.  At the RTL level and above it’s not so clear cut, there are often many different point tools, files are small, and each project can use a different set of tools and scripts.  Whether a point tool runs on the local machine or remote machine really makes no difference in this case, with negligible files sizes and local scripting environments that can access remote point-tools using web APIs.

McLellan assumes a tool/hour pricing model, and claims that using a metered usage pricing would not cause prices to go down.  With SaaS, however, there could be many different pricing models that better align the value between the user and vendor.  Pricing could be based on a project, per-user, or per unit of complexity (register, gate, area, …).  If the fabs were to take hold of the SaaS model and offer EDA tools, since they know the production output they could even use a royalty based pricing model.  If you look at the current EDA floating seat model, the longer jobs run for the more seats sold, and the more money for the EDA companies.  Could it be that EDA vendors using a per-seat model don’t have the incentive to improve runtimes as much as they could?

Another objection is that SaaS doesn’t work well with highly interactive software.  This has been true in the past, but is less and less true all the time with AJAX rich-client applications like Google maps.  If Google maps can do the magic that they do then I would argue that place and route and graphical waveform viewers are reasonably possible today.  For the most part, though, there is very little graphical instructiveness in EDA.

Perhaps the greatest SaaS for EDA benefit is the opportunity to reduce the maintenance and infrastructure costs that are so high for the traditional on-premise tools. Installing, patching, and upgrading EDA tools is a huge cost that must be considered into the total cost of ownership.  SaaS ends the customers’ maintenance of the application and enables the customer to focus more on value added differentiating work while the vendor manages the maintenance.  This is much more economical and cost effective.  Salesforce.com CEO Marc Benioff circulated an internal note related to the “End of Maintenance,” which is an excellent read on this very topic.    Then, there is always the argument that chip designers want to control what version of the tool they are using so everything is repeatable.  There are ways this can be built into the SaaS offering, and at PDTi with SpectaReg, we’ve got a way to do this.

Referring to the Innovator’s Dilemma and the way SalesForce.com disrupted the CRM market, McLellan states that EDA is not like CRM since there is no “non-competition” - under-serviced users who don’t currently have access to a tool due to it’s cost.  “EDA is not like that,” he said.  I, however, think there are certainly aspects of EDA that are like that, especially with new and innovative tools.  Register automation, where we at PDTi are focused, is one such area.  We often encounter customers who don’t have any solution (in-house or commercial), who could certainly use a solution.  There are a number of users in developing economies starting to work with EDA tools for ASIC and FPGA, who are waiting for better “legal” access to tools.  There is the embedded software industry that is starting to realize that they can use FPGA embedded processors platforms and build custom (multi) processors chips for their specialized application.  This is a new underserviced market for EDA.  It amazes me how the EDAC is so hyped up about trying to stop piracy of EDA tools, which seems futile since the hackers will almost always be able to crack or cheat the next attempt to stop them.  SaaS, however, does provide a solution to the piracy issue.  To expand into these highly price sensitive markets, EDA will need to compete on price, like it or not.

While competing on price is not ideal, SaaS has the potential to afford a better cost structure for both the producer and consumer.  More than the tool price needs to be looked at to get a true picture of the total cost of ownership.  The traditional EDA sales channel is super expensive and unnecessary in today’s Internet age.   The evaluation processes are too lengthy and difficult, the tool version release milestones are too long, onsite tool support is expensive, and the customer’s maintenance and infrastructure is very costly.  The cost of having CAD engineers worrying about tool setup and maintenance is more than just the associated labour cost - there is an opportunity cost of not focusing as intensely as possible on core competencies. A SaaS tool can evolve better based on aggregate vendor observations of usage patterns.  Also, it’s easier for the customer and vendor to work together to identify, reproduce and fix bugs.

There is much knowledge in EDA that is not packaged in an automated collaborative way.  Lincoln Murphy from 16 Ventures and Ken Boasso of Keychain Logic predict that 80% of SaaS success stories in the future will not be the CRM or ERP leaders of today’s SaaS, but rather productization of knowledge.  There is a lot of knowledge in EDA and chip design that has yet to be productized — the kind of stuff you find in the scripts, processes, procedures, emails, spreadsheets, and documents at a typical chip design company.  This could potentially be formalized into SaaS tools with a user community and network effect.

Utilizing the power of native web-applications, SaaS can bring about a new class of tools for EDA that use the Internet to help managers manage, and engineers collaborate across teams and locations.  Perhaps like a social networking application, but not social, instead it’s engineering workflow networking around the project work, tools and flows.  This is something that we’ve had good success with for our SpectaReg.com tool.  Memory mapped registers are collaborative and we tie all the stakeholders together in a formalized way.  This isn’t traditional EDA - it is a work-flow automation for electronics design, perhaps a new class of EDA that productizes what has traditionally been un-productized knowledge.

If you’re interested in EDA for SaaS be sure to join the EDA SaaS Enthusiasts LinkedIn Group.  If you are doing firmware/hardware addressable register maps, try a free demo/evaluation of SpectaReg.com.