WP_Term Object
(
    [term_id] => 17268
    [name] => Semifore
    [slug] => semifore
    [term_group] => 0
    [term_taxonomy_id] => 17268
    [taxonomy] => category
    [description] => 
    [parent] => 157
    [count] => 1
    [filter] => raw
    [cat_ID] => 17268
    [category_count] => 1
    [category_description] => 
    [cat_name] => Semifore
    [category_nicename] => semifore
    [category_parent] => 157
)
            
Semifore banner 1
WP_Term Object
(
    [term_id] => 17268
    [name] => Semifore
    [slug] => semifore
    [term_group] => 0
    [term_taxonomy_id] => 17268
    [taxonomy] => category
    [description] => 
    [parent] => 157
    [count] => 1
    [filter] => raw
    [cat_ID] => 17268
    [category_count] => 1
    [category_description] => 
    [cat_name] => Semifore
    [category_nicename] => semifore
    [category_parent] => 157
)

CEO Interview: Rich Weber of Semifore, Inc.

CEO Interview: Rich Weber of Semifore, Inc.
by Daniel Nenni on 04-30-2021 at 6:00 am

Rich Weber SemiforeRich Weber co-founded Semifore in 2006 with Jamsheed Agahi. Rich has a long history of complex chip and system design at companies including Data General, Stardent, Silicon Graphics, StratumOne and Cisco Systems. He received an MS in Electrical Engineering and a BS in Computer Engineering from the University of Illinois, Urbana-Champaign. Rich’s pioneering work at Cisco formed the basis of what became the SPIRIT / Accellera SystemRDL1.0 standard in 2009. Rich is a long-standing member of the Accellera IEEE 1685 IP-XACT steering committee. He has a deep understanding of industry standards, including their limitations.

What drove you to form Semifore in 2006?
I’ve been responsible for system architecture throughout my career – things like how the hardware interacts with the operating system and embedded software. In virtually every project, I was the system architect responsible for defining the address map and how device drivers would interact with it across many different operating systems. My experience with all those projects led me to conclude that the hardware/software interface, let’s call it the HSI, was a source of significant risk in the development process.

I can recall working at Silicon Graphics on high-end graphics processors and supercomputers. Often, there would be a fire drill in our Monday morning meeting because someone changed a bit in one of the registers and all the regressions failed over the weekend. At that point, the documentation was out of synch with the design RTL and many header files were likely incorrect. Those changes were made with good intentions, but the result was always the same – chaos.

After that, I began working on high-performance networking designs at a startup. These designs had a much more complex HSI, probably a factor of ten times more complex than what I had seen at Silicon Graphics. Based on that, we decided to automate HSI generation – the RTL, design descriptions, verification files, device driver development and support for bench measurements.  The HSI represented a large portion of the design, so this automation had far-reaching impact on the overall project. In those days, there was no commercially available tool to perform this automation, so roughly half the effort of the design team was dedicated to building the necessary scripts.

This company was quite successful and ultimately bought by Cisco. Now, as part of Cisco, the networking designs we were working on became much larger. In those days, Cisco had a specific focus on engineering best practices to reduce re-spins and time-to-market for its complex ASICs. Since Cisco was the result of many acquisitions, there was a need to converge the design methodology at an enterprise level. As part of that effort, I championed the need for an automated system to guide the implementation of the HSI. This part of the design had clearly become much too large and complex to be done either manually or with ad-hoc scripts and spreadsheets.

A project to address this automation was created. While the work had a positive impact on the design projects at Cisco, I saw an opportunity to do so much more. Handling complex designs with large register counts is virtually impossible without sophisticated automation. I knew I could build such a system that would scale efficiently for the largest designs. Without such a system it is very likely there would be missed deadlines, late tape-outs and hidden bugs in the field. In fact, studies have shown that one out of seven chips are re-spun due to a problem with the HSI. So, I left Cisco and formed Semifore.

Tell us about Semifore, what is the impact of their products on chip design?
Advanced semiconductor designs have many components, including multi-core architectures, programmable peripherals and purpose-built accelerators. These design elements require a pathway for embedded software to communicate with them. This is the HSI and it forms the foundation for the entire design project. Building an HSI that is correct and reliable puts demands on many parts of the design team. Beyond building an accurate, robust register map, the validation of the interface needs to be complete, and all supporting information also needs to be complete since the software team will build device drivers and high-level firmware from these specifications.

The stakes are quite high regarding getting all these pieces done correctly. Unlike timing or power closure, which can be verified rigorously, the verification of the HSI is a multi-dimensional problem that is bounded only by the imagination of the software team. I have seen cases where, years after a chip was put into production, it became impossible to add a new feature.  Why? During the software update process, it was discovered a device driver couldn’t be written. This was because a subtle error in the address map didn’t allow for the functionality. This is something of a nightmare scenario since the only fix is to deploy a new version of the chip to all systems in the field needing the new feature.

Subtle errors can escape into production. The only viable way to minimize this risk is to build an HSI with robust automation to ensure a correct-by-construction result. Add to that automated and accurate dissemination of the information needed by all members of the design team and you have a winning methodology. This is the methodology delivered by Semifore.

Scalability is another real problem for this kind of methodology. A typical HSI may contain millions of registers. The design team will require updates to these registers often, many times a day for example. The process of generating all this information needs to be extremely efficient, or the whole system will collapse under its own weight. The Semifore methodology can generate a five million register HSI in a matter of minutes. Problem solved.

This is the mission of Semifore. Deliver a winning methodology to allow design teams to focus on innovation, knowing the HSI is complete, robust and well-understood by everyone. The result is significantly lower risk, improved time-to-market and superior performance. In fact, without a methodology like this the chances of a working design are quite low.

A final question – How does Semifore fit with existing standards?
Standards provide great benefit. We fully support these efforts at Semifore, and I’ve personally been involved in the development of many standards. But standards cannot realize the ultimate goal, which is to develop an executable specification of the design. An executable specification is the only way to capture design intent and ensure a correct-by-construction HSI. Design teams maintain specifications in formats such as SystemRDL, IP-XACT and large spreadsheets.

These are all useful, but individually and even together they are missing many of the constructs needed to create a true executable specification and this is why standards fall short. Let me give you some examples. Moving up the level of abstraction and letting tools do the heavy lifting delivers a great productivity boost. To do this, programming constructs such as IF statements, LOOPS and CASE statements are needed, but they aren’t supported by existing standards. Often, the design may require a certain structure be imposed on a set of registers and the structure be captured in memory instead of flip flops. This is what is referred to as virtual registers. This is also not supported by existing standards.

To address these requirements, Semifore developed a domain-specific language called CSRSpec™. This language supports all the constructs mentioned and many, many more. It evolves with design requirements in real time, whereas a standard language would take years to encapsulate new requirements. CSRSpec includes over 200 unique properties and 6,000 register behavior combinations and complements existing standards and adds many more needed capabilities, so design intent can be accurately captured to create that all-important executable specification.

The CSRCompiler™ system generates high quality synthesizable RTL and all the support files needed to build the complete HSI and associated software drivers. CSRCompiler supports customization with a robust output tailoring capability that doesn’t require scripting. Through many years of development, CSRCompiler delivers extensive error checking and validation, with over 1,000 checks built in. All inputs are verified for semantic and syntactic correctness. Design practices that can lead to sub-optimal results are also flagged. This entire system can scale effortlessly to handle the largest, most complex designs.

This is the winning methodology I referred to. It provides the margin of victory for Semifore’s many customers across a diverse set of disciplines. We support many promising startups and large enterprises such as Microsoft as well. I am very proud of our accomplishments and our growing customer base.

Share this post via:

Comments

There are no comments yet.

You must register or log in to view/post comments.