feature article
Subscribe Now

Connecting the Camps

Mathworks Bridges System and Hardware Design

The MathWorks is bucking that trend, however, because they’ve approached the problem from a different direction. First, they won the hearts and minds of the electronic design community with their general purpose (non-EDA-specific) tools like MATLAB and Simulink. Then, when they apparently noticed that they had thousands of seats of software in places where only EDA companies typically played, they set about developing domain-specific technology to try and capitalize on that market presence.

This week, The MathWorks made another bold step across that line from supplier of general-purpose software tools to head-on competitor for some of EDA’s most prized software seats – those in the emerging electronic system-level design (ESL) space. For years, MATLAB has been the analysis and experimentation tool of choice for high-level system designers (you know the ones – they’re sitting down the hall from you right now wearing long flowing robes and staring knowingly at strange differential equations scrawled on their ivory whiteboards). These folks would enter their algorithms into MATLAB, twiddle a few coefficients and exponents, and officially pronounce the signal-to-noise problem solved. Actual hardware implementation was left as an exercise for the student (…or to the rest of us engineers that have to occasionally actually build stuff).

The path from all those MATLAB-proven algorithms to working hardware is the stuff careers are made of, requiring savvy hardware engineers to decode the system designers’ intent and then create complex micro-architectures hand-coded in VHDL or Verilog to implement the system guru’s vision. That gap, between the top-level theoretical system design and the implementation-level hardware and software, is the primary playground for EDA’s hottest new segment, ESL (Electronic System Level design).

Until now, The MathWorks has played a completely complementary role to EDA – filling in gaps and providing interfaces like their ModelSim verification interface that made life easier for people using EDA tools and MathWorks tools together. Now, however, The MathWorks has announced a new tool that almost certainly signals a deeper foray into EDA’s protected turf.

With this week’s introduction of their new “Simulink HDL Coder,” the company has launched directly into the implementation path for high-level system designs making their way into hardware from MATLAB and Simulink. Basically, given a design created in Simulink with The MathWorks’ model-based design approach, You can use HDL Coder to generate simulatable, synthesizable HDL code that can take you right along to your implementation flow for hardware. Sounds great, right? We just took that hardware engineer right out of the loop.

OK, it’s not quite that simple.

Like any high-level design methodology, you have to know the downstream tools and technologies and create your high-level design with some provisions for your chosen tool path. Perhaps the best way to explain the system is to begin with a discussion of what it is not – HDL Coder is not high-level or behavioral synthesis. It does not attempt to take a generic, untimed algorithm and create a micro-architecture that will implement that algorithm in hardware. Therefore, you will not see this tool competing directly with solutions like Mentor Graphics’ Catapult, Celoxica’s DK Design Suite, Forte’s Cynthesizer, etc. In creating your design for HDL Coder, you explicitly craft a data path and control logic in Simulink and its companion “Stateflow” tool. Unlike many of the existing Simulink-based design flows, however, HDL Coder does not require you to use a specialized library. This means that your source design is still generic in terms of implementation technology and could even be used to generate software implementations for something like a DSP processor.

Because The MathWorks is already in the analysis and verification business to some degree, the new tool has an already well-established verification flow – something that’s difficult to achieve with a typical “methodology shift” tool. Also, the new tool capitalizes on the fact that the entry mechanism – via Simulink and MATLAB — is already the dominant methodology for many types of high-level system design. If The MathWorks wanted to flex their substantial muscles and throw a wave of competitive fear into the EDA industry, this seems the perfect way to do it.

Of course, HDL Coder is designed to play nicely with the EDA tool chains already in place. By generating HDL, it lets you roll right into your existing synthesis, simulation, and verification tools on the back end. It also is compatible with your legacy HDL IP – an important consideration because almost every design today has a large legacy of pre-existing hardware behind it. Designing with a blank sheet is almost never an option in the real world. You can black-box import your legacy IP blocks and use them in your simulation, analysis and implementation process. HDL coder allows you some flexibility in your implementation with serial versus parallel implementations and some retiming options. It also provides automatic generation of HDL test benches for downstream simulation and verification.

The aspect of HDL Coder that will likely be the hardest to push into some teams is the subtle repartitioning of responsibility and the resulting requirement for slightly different skill sets in the engineering team. Traditionally, system designers have worked at a very abstract level with little consideration of details like the micro-architectural details of datapaths. Those details were the purview of hardware engineers with their knowledge of timing constraints, resource sharing, pipelining, and multiplexing. With the HDL Coder design methodology, some of the responsibility for the design of a successful microarchitecture comes back to the system designer. For many design teams, that expertise sharing has already begun, and the shift will be a non-issue. For some, however, such a shift of design responsibility could pose a significant challenge.

The benefits should be worth it, however. Bridging the gap between the abstract system-level design world of MATLAB and Simulink and the architecture and technology-specific world of HDL-based hardware design is a major step in the evolution of the system design process. Clearly The MathWorks’s work is not done here. One can extrapolate a large and challenging list of future capabilities that could bolster this product offering. One thing is clear, though. Notice has been served. The ESL space is up for grabs, and it won’t be just the traditional EDA companies fighting for a piece of it.

Leave a Reply

Connecting the Camps

MathWorks Bridges System and Hardware Design

It happens from time to time. Some well-meaning high-tech company notices that they’ve got some pretty cool design tool technology and says to themselves, “Hey, we’ve got some cool design tool technology. Let’s jump into the EDA market!” These are fateful thoughts, however – best pushed aside. In practical terms, they are akin to “Hey, I’ve got myself a pretty cool racing bike – I think I’ll compete in the Tour de France!” Sometimes, though, a company that, perhaps, developed some nice tools for their own internal use, feels just too tempted and takes that ill-advised plunge. The results are typically disastrous. These adventurers usually soon discover that creating tool technology is the easy part. Getting electronic designers to adopt and depend on your software, regardless of how novel and necessary it may seem, is a much more daunting challenge.

The MathWorks is bucking that trend, however, because they’ve approached the problem from a different direction. First, they won the hearts and minds of the electronic design community with their general purpose (non-EDA-specific) tools like MATLAB and Simulink. Then, when they apparently noticed that they had thousands of seats of software in places where only EDA companies typically played, they set about developing domain-specific technology to try and capitalize on that market presence.

This week, The MathWorks made another bold step across that line from supplier of general-purpose software tools to head-on competitor for some of EDA’s most prized software seats – those in the emerging electronic system-level design (ESL) space. For years, MATLAB has been the analysis and experimentation tool of choice for high-level system designers (you know the ones – they’re sitting down the hall from you right now wearing long flowing robes and staring knowingly at strange differential equations scrawled on their ivory whiteboards). These folks would enter their algorithms into MATLAB, twiddle a few coefficients and exponents, and officially pronounce the signal-to-noise problem solved. Actual hardware implementation was left as an exercise for the student (…or to the rest of us engineers that have to occasionally actually build stuff).

The path from all those MATLAB-proven algorithms to working hardware is the stuff careers are made of, requiring savvy hardware engineers to decode the system designers’ intent and then create complex micro-architectures hand-coded in VHDL or Verilog to implement the system guru’s vision. That gap, between the top-level theoretical system design and the implementation-level hardware and software, is the primary playground for EDA’s hottest new segment, ESL (Electronic System Level design).

Until now, The MathWorks has played a completely complementary role to EDA – filling in gaps and providing interfaces like their ModelSim verification interface that made life easier for people using EDA tools and MathWorks tools together. Now, however, The MathWorks has announced a new tool that almost certainly signals a deeper foray into EDA’s protected turf.

With this week’s introduction of their new “Simulink HDL Coder,” the company has launched directly into the implementation path for high-level system designs making their way into hardware from MATLAB and Simulink. Basically, given a design created in Simulink with The MathWorks’ model-based design approach, You can use HDL Coder to generate simulatable, synthesizable HDL code that can take you right along to your implementation flow for hardware. Sounds great, right? We just took that hardware engineer right out of the loop.

OK, it’s not quite that simple.

Like any high-level design methodology, you have to know the downstream tools and technologies and create your high-level design with some provisions for your chosen tool path. Perhaps the best way to explain the system is to begin with a discussion of what it is not – HDL Coder is not high-level or behavioral synthesis. It does not attempt to take a generic, untimed algorithm and create a micro-architecture that will implement that algorithm in hardware. Therefore, you will not see this tool competing directly with solutions like Mentor Graphics’ Catapult, Celoxica’s DK Design Suite, Forte’s Cynthesizer, etc. In creating your design for HDL Coder, you explicitly craft a data path and control logic in Simulink and its companion “Stateflow” tool. Unlike many of the existing Simulink-based design flows, however, HDL Coder does not require you to use a specialized library. This means that your source design is still generic in terms of implementation technology and could even be used to generate software implementations for something like a DSP processor.

Because The MathWorks is already in the analysis and verification business to some degree, the new tool has an already well-established verification flow – something that’s difficult to achieve with a typical “methodology shift” tool. Also, the new tool capitalizes on the fact that the entry mechanism – via Simulink and MATLAB — is already the dominant methodology for many types of high-level system design. If The MathWorks wanted to flex their substantial muscles and throw a wave of competitive fear into the EDA industry, this seems the perfect way to do it.

Of course, HDL Coder is designed to play nicely with the EDA tool chains already in place. By generating HDL, it lets you roll right into your existing synthesis, simulation, and verification tools on the back end. It also is compatible with your legacy HDL IP – an important consideration because almost every design today has a large legacy of pre-existing hardware behind it. Designing with a blank sheet is almost never an option in the real world. You can black-box import your legacy IP blocks and use them in your simulation, analysis and implementation process. HDL coder allows you some flexibility in your implementation with serial versus parallel implementations and some retiming options. It also provides automatic generation of HDL test benches for downstream simulation and verification.

The aspect of HDL Coder that will likely be the hardest to push into some teams is the subtle repartitioning of responsibility and the resulting requirement for slightly different skill sets in the engineering team. Traditionally, system designers have worked at a very abstract level with little consideration of details like the micro-architectural details of datapaths. Those details were the purview of hardware engineers with their knowledge of timing constraints, resource sharing, pipelining, and multiplexing. With the HDL Coder design methodology, some of the responsibility for the design of a successful microarchitecture comes back to the system designer. For many design teams, that expertise sharing has already begun, and the shift will be a non-issue. For some, however, such a shift of design responsibility could pose a significant challenge.

The benefits should be worth it, however. Bridging the gap between the abstract system-level design world of MATLAB and Simulink and the architecture and technology-specific world of HDL-based hardware design is a major step in the evolution of the system design process. Clearly The MathWorks’s work is not done here. One can extrapolate a large and challenging list of future capabilities that could bolster this product offering. One thing is clear, though. Notice has been served. The ESL space is up for grabs, and it won’t be just the traditional EDA companies fighting for a piece of it.

Leave a Reply

featured blogs
Aug 15, 2018
https://youtu.be/6a0znbVfFJk \ Coming from the Cadence parking lot (camera Sean) Monday: Jobs: Farmer, Baker Tuesday: Jobs: Printer, Chocolate Maker Wednesday: Jobs: Programmer, Caver Thursday: Jobs: Some Lessons Learned Friday: Jobs: Five Lessons www.breakfastbytes.com Sign ...
Aug 15, 2018
VITA 57.4 FMC+ Standard As an ANSI/VITA member, Samtec supports the release of the new ANSI/VITA 57.4-2018 FPGA Mezzanine Card Plus Standard. VITA 57.4, also referred to as FMC+, expands upon the I/O capabilities defined in ANSI/VITA 57.1 FMC by adding two new connectors that...
Aug 15, 2018
The world recognizes the American healthcare system for its innovation in precision medicine, surgical techniques, medical devices, and drug development. But they'€™ve been slow to adopt 21st century t...
Aug 14, 2018
I worked at HP in Ft. Collins, Colorado back in the 1970s. It was a heady experience. We were designing and building early, pre-PC desktop computers and we owned the market back then. The division I worked for eventually migrated to 32-bit workstations, chased from the deskto...
Jul 30, 2018
As discussed in part 1 of this blog post, each instance of an Achronix Speedcore eFPGA in your ASIC or SoC design must be configured after the system powers up because Speedcore eFPGAs employ nonvolatile SRAM technology to store its configuration bits. The time required to pr...