Interview with Duolog
Tool name: Bitwise™
Vendor: Duolog Technologies
Webpage: http://www.duolog.com/products/bitwise-register-management/
Interviewee: David Murray, CTO
Gary Stringham: I’m talking with David Murray. Tell me the name of your product.
David Murray: Our register management product is called Bitwise, which is part of our Socrates suite of integration tools.
GS: Tell me two or three key features of Bitwise. I’m limiting this discussion to Bitwise itself.
DM: The three main features are the ability to formally define the hardware/software interface by migrating legacy data or manual entry to check if the information defined is correct, to ensure that there are no mistakes or missing information, and to automatically generate the register specification and resulting register implementation across the different design domains. The combined benefit is a centralized specification from which you can ensure specification correctness and then generate different design views. This ensures that all teams working at the HW/SW interface are synchronized.
GS: Describe to me a typical customer.
DM: There is no such thing as a ‘typical’ customer as every customer’s design flow is unique and contains registers in a wide range of formats. Their register information could be described in Excel sheets, Word or FrameMaker documents, XML, text, or IP-XACT, even paper-only documents! The users of register information are wide and varied but there are some common users. There are users that basically define the data and then there are users that consume that data. For instance, IP architects or owners are typically focused on the HW/SW interface definition. The consumers of this definition are typically HW design and verification teams, and SW design and verification teams. Also, more recently, teams who develop virtual system models also use this information. Using manual methods, the HW/SW interface definition would typically need to be interpreted and translated into the required implementation format. This is an extremely error prone process, however, using Bitwise ensures that stringent quality checks are performed on the definition thus removing any specification errors. Implementation formats are automatically generated thus removing all translation activities and eliminating errors. As far as customer types, these tools are used on massive SoCs, to AMS chips, small and large FPGA users and IP providers – the whole semiconductor spectrum benefits from this type of methodology.
GS: Do you have an IP vendor who would sell this and also provide these Bitwise files to the customer/consumer?
DM: Yes, we’ve done a few different things here. Our IP customers typically do not provide Bitwise files but actually publish or provide the generated files. We work in many fields including the medical device domain where data quality is mission critical. If they’re providing IP, they need to ensure the highest quality and using Bitwise guarantees this. A lot of our IP customers are the IP teams of large semiconductor companies. These provide register descriptions to sub-system or chip teams in Bitwise format (which is XML). Bitwise can be used to build up a full hierarchy of the hardware/software interface. With fabrics/interconnect IP providers we are able to read their memory-map architecture in IP-XACT format and this allows us to easily integrate these fabrics into our customers flows.
GS: Can you give me two or three examples of success stories of customers, things that they like about your product?
DM: A good success story would be the OMAP platform, which is TI’s platform. We’ve been using Bitwise on the OMAP platform for a number of years and every enumerated type of every bitfield of every register of every IP has been captured in our environment. And that doesn’t necessarily mean captured manually. We can extract formats from IP-XACT, Excel, and CSV. But we formalized those IP descriptions and then the integrators can put together the software. We’ve done that very successfully for OMAP.
Our customers go from that mega platform to FPGA. Some of the customers are really, really getting into this centralized specification. One particular customer used Bitwise as the center of the hardware/software model. They generated full RTL. What they’ve actually done is completely abstracted away the register implementation details. They enter an offset once in the spec and they never see it again. Through synchronization they have eliminated whole categories of bugs.
Bugs on the hardware/software interface are extremely difficult to find and to resolve. They cross multiple domains and are a pain for everyone. Bitwise consistently removes this pain.
GS: You mentioned you support several different types of input file. You mentioned IP-XACT, …
DM: As far as input formats, we can support any format. The first question that customers ask is what format we support and we say that we support almost all. We make it a point to work with customers to bring the data into Bitwise because once it’s in there – they can immediately see the benefits. We have default, production hardened importers for all the industry standard formats including all the versions of the IP-XACT standard.
GS: In other words, you can create input formatters, converters…
DM: Yes, we actually have script-controlled and template based importers. You can script the importer to the different format that you want. It’s very, very successful. However, before you get to the importer, you might have a very, very large specification. One type of specification we’ve seen is with a set of registers that are repeated several times throughout the document. In our world, that can be in a very optimized format as an array of register sets or register files. We look at the spec and know that we can confidently capture this in five minutes and sometimes you don’t even need to translate.
We can help our customers get their data into Bitwise. We especially love Excel because that’s the most common format. It is actually not IP-XACT, it is Excel or CSV. We have done hundreds of translations. We usually find errors in the customer data, especially if it comes from Excel but we also regularly uncover errors in customer’s IP-XACT data as well.
GS: I assume that you are also able to customize the format of the output files that are generated.
DM: Yes, the Bitwise generator framework is one of our differentiators. First of all, the register specification is actually well optimized with one property in one place. Its modular structure means that we can build up a full system hierarchy from child blocks. It is also fully parameterizable. Before we generate a format in Bitwise we do a full elaboration of the model. Bitwise does all the heavy lifting; it calculates all the offsets, all the masks of all registers and bitfields. It can take a specific processor view or flatten a full hierarchical system. It can resolve parameters or leave them unresolved. It is from this elaborated model that we can generate different implementation formats and at this stage it is more about rendering than processing. Our rendering is done by a template-based generator which is completely customizable and very easy to extend. Bitwise gives the ability to specify your entry point, the ability to elaborate or resolve your parameters, and the ability, for instance, to flatten your view of the system. These are all capabilities that our users need, depending on the formats of their actual target.
GS: So a particular peripheral might be accessible by multiple processors and so they look different from each of them?
DM: Yes, they might look differently. The view from one processor may be completely different than the other processor. What our users are interested in is not a model of the system, like in IP-XACT, they’re interested in a model of the programmer’s view, i.e. what can the processor see?
The output formats are generally documentation, design, verification, and software. And from that we generate literally hundreds of formats. For instance, Word, PDF, HTML, IP-XACT, XML, Excel, CSV, doc, CMSIS, OVM, UVM…
GS: So basically, you have an ability of creating any kind of an output format.
DM: Yes, we can create a huge variety of formats. We even have a concept of a ‘structure generator’. If a customer doesn’t like our generator or template engine, they can create one. We can output the register definition in a perl hashmap or python dictionary so they can write their own version of the generator.
However, what we have found is that while customers like the flexibility of Bitwise and how it can handle their data, they also want to ensure that they are using best-practice flows. So we say it’s more about flows rather than formats. We have a catalogue of production hardened default generators that can be slotted into design flows or tailored to existing design flow. For example, Bitwise can generate a UVM register package that works in their reference flow. We work closely with Cadence, Mentor Graphics and Synopsys and ensure that we have reference designs that work on their environments.
GS: Do you have any size constraints like maximum number of registers that you can support?
DM: No, there are no constraints regarding the number of registers in Bitwise. We’re working on designs of 10s of 1000s of registers, and 100s of 1000s of bitfields. Generation times for different implementation formats can be < 5 minutes for extremely large designs, so we scale very well.
GS: That’s all the questions I have for now. Thank you very much for your time.
DM: My pleasure.
Back to product comparison table.
|
