Register Bits

A quick snapshot on the poll described in my previous posting: “for System-on-Chip developers, where is the greatest hardware/software register interface pain?”

Of the 71 votes thus far, 59% indicated that synchronizing the firmware, RTL, hardware verification, and documentation was the greatest pain.  Then 16% voted for register documentation and 16% for hardware verification (like SystemVerilog, Vera, e, SystemC).  The RTL (like Verilog & VHDL) for coding the register-map hardware logic was a pain for 4% of voters and firmware was a pain for 2%.  The live version of the poll is available here, and below is a screenshot of the graph.

Snapshot of LinkedIn poll graph

 
That only 2% voted for firmware is surprising to me since when asked where greatest value was received, a SpectaReg.com register-map automation customer indicated that 50% of the value was provided to the firmware developer.  As a result, I would expect that anyone without a register code generation solution would experience a lot of firmware pain.  Perhaps that’s a synchronization pain and the proper solution provides more value for firmware than any other aspect as a result of cross-team synchronization.

For the 41% that did not vote for synchronization, perhaps they have no register map code generation solution, whether it be commercial or homemade.  Perhaps their solution does not sufficiently provide enough value for the option that they voted for.

For the 59% that voted for synchronization, I wonder:

• How many have a common machine readable data format for specifying registers that can used to generate code?
• How many auto-generate all deliverables from a common source at the same time using the same code generation (metaprogramming) engine.
• How many have an in-house vs. commercial solution (like our SpectaReg.com/SpectaReg Onsite or Duolog’s BitWise, Delani’s Blueprint, or Semifore’s CSRCompiler).

Many more polls could be created on these topics.

People are very passionate and opinionated when it comes to in-house tools, open source, register specification file formats, and register-map methodologies in general.   There was heated discussions on LinkedIn about the following topics, which make for good future blog posts:

• Open source tooling for register address maps, could it work?
• Is SystemRDL really needed in addition to IP-XACT?
• Which comes first, the code or the spec?
• With an in-house register solution, where’s the pain? (relates to Opportunity cost in build vs. buy decisions

If you have thoughts to share, be sure to leave a comment for discussion.  There is some good meat here for future RegisterBits.com postings so stay tuned.

Did you know that LinkedIn allows users to create polls?  I discovered this today and created my first poll to ask my network of SoC developers where their greatest hardware/software register interface pain lies.  Is it the firmware, RTL, hardware verification, documentation, or is it synchronizing all the different perspectives around the common specification?

Click on the below image or link to have your say!  Tell your colleagues too, and of course if you have a comment for discussion post it here.

LinkedIn SoC Register Interface pain poll.

http://polls.linkedin.com/p/31486/ovmia

Update: Someone mentioned that they don’t understand the poll because they have an in-house solution that solves these pains. For those with an in-house solution, read the poll as “where is the greatest value from your in-house solution?” I suppose a sixth option, “my in-house solution is the biggest pain” should have also been an option too, especially now that there are commercial solutions available.

Harry the ASIC guy recently did a posting on survey results from past DVCon conferences.  Harry listed percentages for languages used for design, verification, and property specification.  Having attended DAC 45 in Anaheim, I couldn’t help but notice all the buzz about the newly open-sourced VMM and OVM SystemVerilog verification methodologies (both of which we now support).  I commented that it would be interesting to know the popularity of OVM vs. VMM.  Harry picked up on this and has since created a poll at Doodle that poses the following question:

Which functional verification methodologies are you (or your group or your company) planning to use on future projects?

The poll has the following choices: VMM, OVM, AVM, RVM, eRM, Teal/Truss, Home Grown, Native SystemVerilog, Native Vera, Native e, Native VHDL, Native Verilog, and Other.

Click on the above-hyperlinked question to view the results and participate in the poll.  As it stands now, there have been more than 100 participants and OVM is winning.  There could be some possibility for vendor manipulation, given the way Doodle works…  hopefully people play fair.

Props to Harry for creating this poll!