• Rapid IP integration using rules-based system assembly and connectivity
• Comprehensive HW/SW integration solutions utilizing standards such as UVM
• IP configuration and rendering flows

Visit here to register for DVCon 2013.

What a difference a year makes!

As a 3 day exhibitor and Gold Sponsor, Duolog had a much greater impact on the ARM TechCon and on the industry as a whole. Not only did visitors know who we were, they even sought us out.  A few of the highlights:

• Dave Murray reprised his DAC Concurrent Design Flow Experiment in a session entitled “Formalizing Programming Sequences To Streamline Hardware/Software Verification”, reinforcing the data crisis at the front-end of the SoC design flow. It was very well received.
• We exhibited at both the Chip Design (Day 1) and Software and Systems Design (Day 2 & 3) Sessions, right in the center of each hall. This gave us a chance to interact not only with our direct customers, but their customers as well, and to convey the value we bring them with our hardware / software solution.
• At our demo station, we provided live ongoing demonstrations of our Socrates Weaver IP integration tool that reduces IP integration time from months to days. This is a real customer need and was very well attended.
• A clever little golf game (my idea J) challenged passers-by to putt a golf ball through Virtual Prototype, RTL, Verification, and Software teams in order to achieve Project Success, reinforcing the value of our tools in aligning these teams and how one small mistake can kill the project.

On the last day of the conference, almost at closing time, a software engineer came by the booth, seemingly in a rush. He didn’t have a lot of time, he said, but he told us that we need to talk with the design team in his company to help them to get him the deliverables he needs to do his job. He had seen our demos in previous years and felt the need, but seeing how much we had advanced our solutions and that we were a Gold Sponsor, he remarked “you’ve come a long way.”

What a difference a year makes!

Duolog will be presenting its latest SoC integration technologies:

• Rapid ARM IP integration using rules-based system assembly and connectivity
• Formalizing programming sequences to streamline HW/SW interface automation and verification
• Comprehensive HW/SW integration solutions utilizing standards such as UVM, TLM
• Fast integration of your I/O layer

ARM / Mentor Demo – For ESDFair 2012 Duolog will present an integration flow using Mentor and ARM IP. This demo uses Duolog’s connection Rules methodology showing how to rapidly assemble the IPs into a SoC. The system is fully synthesible and by leveraging Mentor QVIP it allows the processing of images files from BMP to JPEG using a console interface. Bare metal software was defined for the Cortex A9 using Duolog’s Bitwise register management solution, automatically generating HAL C code based on a full memory map of the system.

Register Sequencer Demo. For EDSFair 2012, Duolog will showcase Socrates Sequencer which is a single source specification of operational and/or verification accesses to Hardware registers. It checks for coherency between register database and ensures correct and update generation of C-code, e-code, UVM and documentation for IPs and Systems, thus enabling the acceleration of verification and HAL development.

Visit here for more details on the EDSFair 2012.

According to Maged Attia, Vice President of  Sales and Marketing for Duolog, “Socrates Weaver is proven to significantly reduce SoC integration times by providing a fully automated, robust and reusable IP integration flow.” He goes on to explain, “Traditional attempts to implement automated IP integration flows work fine for well defined bus interface connections but fail to automate all the other connectivity present in an SoC. This results in the continued need for manual or low-level scripted commands. Socrates Weaver provides a complete automated solution for all connectivity types. The result according to Attia: “Socrates Weaver reduces the integration cycle to a few days resulting in a huge time-to-market competitive advantage. Up to now, integrating ARM and/or internal IP into a System on Chip (SoC) required five to eight weeks and up to 12 weeks for
complex designs.” See Fig. 1.

SoC development teams at leading consumer electronics, automotive, multimedia and medical device companies have proven Socrates Weaver. Faced with time-constrained next generation design rollouts, they have all enjoyed dramatic reductions in their IP integration flows, some to as little as 2 days.

Designers can integrate IP from any ARM provider or internal resource that uses standard interfaces. The full ARM IP catalogue has been used with Socrates Weaver to create SoC design and verification platforms. Socrates Weaver employs a correct-by-construction methodology resulting in high quality designs that conform to IP-XACT interface definitions. As a result, output from Socrates Weaver can be input into any leading design automation tool.

SoC development teams relish using Socrates Weaver because it eliminates bugs caused by human error and reduces the risk of re-spin. The tool allows a company to rapidly, concurrently and efficiently create a standardized IP repository, enabling large-scale reuse of IP and subsystems. As a result, design teams can accelerate their derivative product development cycles.

About Duolog

Duolog Technologies is a leading developer of EDA tools that address the increasingly complex challenges of IP integration.  We enable our customers to deliver integrated systems more quickly and cost effectively than their competitors.  Our innovative products and solutions allow for maximum productivity and control throughout the entire SoC lifecycle.

]]> http://www.duolog.com/duolog%e2%80%99s-socrates-weaver-delivers-arm%c2%ae-ip-integration-in-days-not-weeks/feed/ 0 http://www.duolog.com/arm-techcon-2012-duolog-will-exhibit-and-presenting-oct-30th-to-nov-1st/ http://www.duolog.com/arm-techcon-2012-duolog-will-exhibit-and-presenting-oct-30th-to-nov-1st/#comments Tue, 25 Sep 2012 16:25:53 +0000 duolog http://www.duolog.com/?p=2578 Learn more →]]> Duolog is a gold sponsor of Arm TechCon 2012. Come visit Duolog’s booths at Arm TechCon 2012 in Santa Clara Convention Centre, on Oct 30th to Nov 1st.

• Booth #40   – Chip Design Day (Tuesday, Oct 30)
• Booth #318 – Software & Systems Design Days (Wednesday, Oct 31 and Thursday, Nov 1)

where Duolog can show you our latest SoC integration technologies:

• Rapid ARM IP integration using rules-based system assembly and connectivity
• Formalizing programming sequences to streamline HW/SW interface automation and verification
• Comprehensive HW/SW integration solutions utilizing standards such as UVM, TLM
• Fast integration of your I/O layer

Don’t miss David Murray, CTO at Duolog Technologies, presenting at ARM TechCon:

Formalizing Programming Sequences to streamline HW/SW Verification

Track: Chip Design Day – SoC IP

Day / Time / Location: Tuesday 3:10- 4:00 / 212

Hardware and Software engineering teams often rely upon a paper-based programmer’s guide to describe their shared IP Usage interface which is often incomplete or ambiguous. This presentation will describe a methodology where a common suite of formal programming sequences and constraints can be used across the hardware, virtual prototype and software domains to ensure high quality and consistency verification. This presentation illustrates how these programming sequences can be used to generate documentation (programmer’s guide), verification test-cases and software setup routines and thus deliver major improvements in HW/SW verification productivity, quality and predictability.

Visit here for more details.

Duolog’s Socrates tool suite provide solutions to assist in the creation of an industrial strength virtual prototypes.

• Comprehensive HW/SW integration solutions
• Comprehensive IP/SOC integration solutions
• TLM model automation in both SystemC and SystemVerilog

Don’t miss Jack Donovan, participating in the panel session :

Technical Challenges for Industrial SystemC Applications

Tuesday, September 18th, 2012, 16:00 h-18:30 h, Room TBD

In the past a virtual prototype was used by a small number of users as an experiment in modelling the system in order to explore design characteristics. Software development is on the project critical path and a virtual prototype is key to shortening the time to market and enabling a concurrent design flow in tandem with the  hardware development stream.

The virtual prototype is now used by 100′s of users in the design flow therefore it needs to be very robust and must be an accurate model of the hardware under development. Maintaining a link between the virtual prototype and the actual hardware design poses a challenge. In determining whether you have an industrial strength virtual prototype the key questions to ask are:

• How closely does the virtual prototype match the HW/SW interface?
• How closely does the virtual prototype match the hardware connectivity and design hierarchy?

This panel session will discuss how these questions are being addressed.

From Duolog’s perspective, the solution is to provide a high level of automation producing significant proportions of RTL and TLM implementations from a single source description. This methodology relies on the formal definition of IP meta-data describing HW/SW interfaces and the description of the  hardware interconnect using high level rules. This methodology results in the creation of TLM (SystemC or SystemVerilog) and RTL code from a single source with a high percentage of automatically generated code thus enabling the creation of a robust virtual model which is synchronised with the hardware design.

Register to view this free Tutorial.

The tutorial was presented by members of the IP-XACT technical committee and features Dave Murray, CTO of Duolog.

1. Improving Verification Efficiency using IP-XACT
2. User Presentation: Verification and Automation Improvements using IP-XACT
3. IP-XACT and UVM
4. IP-XACT Extensions

Duolog is an active member of the technical committee working on developing the next generation of the standard. Duolog is committed to promoting the adoption of the standard in order to enhance IP/SOC integration, interoperatbility and automation.

IP-XACT 1685

The IP-XACT 1685 standard is available for free download from the IEEE.

IEEE 1685, “Standard for IP-XACT, Standard Structure for Packaging, Integrating and Re-Using IP Within Tool-Flows,” describes an XML Schema for meta-data documenting Intellectual Property (IP) used in the development, implementation and verification of electronic systems and an Application Programming Interface (API) to provide tool access to the meta-data. This schema provides a standard method to document IP that is compatible with automated integration techniques. The API provides a standard method for linking tools into a System Development framework, enabling a more flexible, optimized development environment. Tools compliant with this standard will be able to interpret, configure, integrate and manipulate IP blocks that comply with the proposed IP meta-data description. The standard will be independent of any specific design process. It does not cover the behavioural characteristics of the IP.

By: David Murray 3rd August 2012

At DAC this year I had a lot of fun doing a live experiment to demonstrate some of the issues with concurrent design flows.  I was at the Cadence Theatre doing a presentation called ‘Controlling the costs of SoC integration‘ and I decided to make the presentation more interactive by creating a design team and seeing some of the effect of getting this team to work concurrently.

Concurrency

The topic I introduced first was how system design flows are now highly concurrent.  In the production of a system within a very tight timescale, it would be normal to have architecture definition, software development, virtual prototype development, RTL design and verification all happening at the same time, be it IP, sub-system or SoC level design. I represented this as a set of rotating, interacting cogs.

Having the teams work concurrently means that the product can be delivered in a compressed timescale. However, there are some downsides to this process.  If any of the cogs lock, the whole process is disrupted.  This implies high levels of dependency and many things are on the critical path. In the animation it was clear that information was flowing around and across the cogs and this was where I was highlighting a major weakness – If the information flow is not fully automated (manual processes), then this could have severe consequences for the design flow.   I decided to conduct an experiment to prove this point.

‘The Experiment’

The goal of the experiment was to mimic a concurrent chip development. I wanted to get a system development team from the audience :

• An architect
• A hardware design engineer
• A verification engineer
• A virtual prototype engineer
• An embedded software developer

I managed to get 5 people (with the promise of a 16GB Memory stick )  and I volunteered as the 6th member of the team – the project manager.   The experiment was to complete a specific HW/SW implementation and integration task across the different design teams.  The focus was on the HW/SW interface as it is common to all of these teams. I brought along 4 copies of an ARM UART primecell specification.  The architect needed to publish (hand out) the specifications to other team members. These team members had to independently implement a single piece of information in these specifications, come together and agree that all implementations were aligned. I highlighted the piece of the specification to be implemented and where to find it in the specification.  The ‘implementation’ was simply to write down this single piece of information which was as follows

The reset value of the UARTCR register in Table 3.1 of Chapter 3.2.  Presented as follows:

Now for the fun bit: As project manager I gave the team a schedule to complete the HW/SW integration as follows:

1. The Architect had 5 seconds to hand out all the specs
2. Each of the implementation teams had 10 seconds to ‘implement’ the specs (Write down the value)
3. The teams then had 10 seconds to agree alignment
4. As project manager, I added 5 seconds contingency

.. which  I visually represented it as follows:

This was a total of 30 seconds. I got good buy-in from my teams and was ready to start the clock. First though, I had to separate two team members who were sitting close to each  other in order to simulate geographically dispersed teams     I then gave the teams a countdown; shouted ‘GO!’ and started the stopwatch.

Releasing the specifications. The first thing to do was fsor the architect to hand out the specifications: And here he is, releasing the specs :

This task took 6 seconds and I (as project manager) started whining that my project was already running late. I’m in the picture below keeping an eye on the stopwatch :

The implementation seemed to be delayed slightly as each team member started looking for the correct piece of information. I called out the chapter, table and register name (I also had the register circled on the specs)

You could see the benefit of working concurrently as these 4 teams were working independently and so I shouldn’t expect to wait a lot of time.   It took however 14 seconds to finish out the implementation at which time I was now complaining that my project has a 10%-15% slip and I wasn’t happy.   I asked the teams to get together quickly and agree that their implementations were aligned – and to hurry up as the project was already critically late.

After about 8 seconds of the integration phase, I could tell something was up. There was a lot of shaking of heads and a lot of finger pointing.  I heard someone say that there were incorrect values in the software, whilst someone else was pointing at the RTL design.  Some of the team went back to their chairs and return with the specs to prove their point.  Time passed and at this stage, as project manager I was getting exasperated with the schedule slip and ‘demanded’ to know what was wrong!

“It seems as if someone has a different version of the spec” , I was told by the Virtual Prototype engineer.

‘Really’, I said sarcastically, then asking the audience if anything like this had ever happened in projects before.  My team looked on not knowing what to do.  I said, quite curtly, ‘Well use the latest version of the spec!’  They looked at version numbers and dates and finally they aligned on the correct values for the register.  I thanked the team for their input and sent them back to their seats.

The Result

The team’s obeservation was correct, there were two different versions of the UART specification in play (PL010 and PL011) . In one specification the reset value was 0×000 and in the other is was 0×300. The effect on my project was devastating- from spec to alignment it took 136 seconds instead of the predicated 30 seconds over a 4x slip in the project schedule.   I presented an example slippage and asked the audience to consider that the timescale was days, not seconds and this seemed to show the gravity of misaligned teams working concurrently.   (Slides here show a slippage of 18 whereas it was really 106)

At this stage I introduced SID, the ‘insidious’ bug that can be very prevalent around manual processes and that can actually very quickly contaminate these types of concurrent design flows.

In this experiment SID was lurking behind team misalignments.  There weren’t any real implementation bugs but when it came to the misalignments, implementation bugs were raised (e.g. the RTL implementation was deemed to be wrong).   For document-driven design processes I showed the types of bugs that contaminate the concurrent design flows and effect design quality:

The types of bugs in this area are as follows:

• Specification bugs:  Bugs contained in the specifications themselves
• Interpretation bugs: Bugs introduced into an implementation by misinterpreting the spec
• Translation bugs:  Bugs involves in translating from a specification to a specific implementation
• Synchronization bugs: Bugs where teams misaligned.

All of these impact on quality and as seen with the experiment can have serious problems in integration schedule and costs.

The Solution

The proposed solution is ultimately more automation in the front-end of the design flow.  The main focus is on the transformation of paper-based specification to machine-readable or executable specifications and the automation of these specifications into the different implementation process. This essentially eliminates the aforementioned types of bugs.

This executable specification not only improves quality and synchronization but provides immediate turn-around-time for spec changes thus increasing productivity.

I gave an example of Duolog’s Socrates-Bitwisewhich can be considered an executable specification of HW/SW interface registers.  With Socrates-Bitwise, a user inputs information in a GUI (or imports txt/xml formats)  . Coherency checks are run on the specification to ensure all data is coherent. From this specification many different formats can be generated automatically, including documentation, RTL , UVM SystemVerilog,  SystemC and C API.

So does this make a difference? Absolutely – for something like the creation of a UART Primecell IP, the graph below the BLUE shows the percentage of Design collateral that is consumed with register implementation.

By automating this blue portion from an executable specification like Socrates-Bitwise we see huge productivity gains, immediate turn-around times for incremental flows and ZERO bugs as these implementations are all aligned to a single source.   Automating this at IP and SoC levels has a significant impact on the overall costs of SoC development.

Acknowledgements :

• Thanks to the audience members, my team for 3 minutes, who helped me on the day!
• Thanks to Joseph Hupcey III, Cadence who allowed me to use his photos in this blog
  

What makes platforms so attractive is the ability to quickly swap in different blocks for a particular market segment or application, and then to create derivatives using different platforms,” said Steve Erickson, vice president and general manager of IP and product development at Open-Silicon. “We’re already starting to see this with some ARM designs. There is a lot of software re-use and lower cost.”

At Duolog we are enabling our customers to create SoC platforms and re-usable subsystems which have all the characteristics described in the Chip Design article

• high levels of configurability;
• ability to seamlessly swap different variants of an IP;
• and support for derivative designs with high levels of re-use.

The really interesting thing that our customers are finding though is that they can achieve these goals using the same or fewer engineering resources and also improved design cycle times. However in order to achieve these results they have had to adopt best practice in terms of their design methodology and SoC integration tools.

Read the full article ‘SoC Platforms Gain Steam’.

• Jack Donovan, Duolog Technologies (Moderator) – @txdonovan
• Frank Schirrmeister, Cadence Design Systems – @fschirrmeister
• Kurt Shuler, Arteris
• Gary Stringham, Gary Stringham & Associates
• Harry Gries, “Harry, the ASIC Guy” – @harrytheASICguy

I was going to write up a full description of what was discussed, the relevant insights and discoveries, and maybe even give a blow by blow account of every question and response. But, then I realized that only Richard Goering is able to do that very well and I would not presume to follow in his footsteps. Instead, as I watched the video, provocative sound bites emerged that I think captured the flavor of the debate quite well. So, I thought we’d play a bit if a game I’ll call “Who Said What?” To play this game, match the quotes below with the panelists above. Then view the video of the session to find out if you are right. If you guess them all, let us know and we’ll have to recognize you in some fashion.

1. “Your customer is the pure SOB whose got to program whatever it is you made. That’s the bottom line. Your stuff is nothing more than melted sand unless a software programmer can use it and use it to the best of his ability.”
2. “When you finally get the HW team and the SW team in the same room, these guys introduce themselves with business cards.”
3. “I’m the customer. I know what I want. And in my conversations with the hardware engineers, they’d often say “oh, is that how you do it in firmware?”
4. “Which tools? Duolog’s tools! But I’m a little bit biased.”
5. “It’s amazing how many times that because somebody somewhere got a 1 and a 0 mixed up in transcribing something somewhere, it doesn’t work, we can’t figure out why, they spend 3 months hunting it down and it’s something like that. And that happens, it’s hard to believe, that happens so much nowadays.”

To find out the answers, view the video below:

The path to smoother HW/SW Interface Management.