I agree with the observation that low-power is a largely unsolved problem. We have seen a tremendous change in the past decade and a half in low-power research, particularly in the context of micro-architecture for small devices and embedded systems. The chief catalyst for this research is the unprecedented growth in the proliferation of handheld mobile devices. In today’s design flows, power management has emerged as the second most important challenge, next only to timing closure, ahead of meeting timing and area goals and taping out on schedule.
Process technology for low-power gains has come a long way. In the early days, a low-power process typically meant a 20% hit in performance. Such performance hits are no longer acceptable, and process technology has improved to offer several standard cell height choices with different threshold voltages for different performance, power and density tradeoffs. Despite all these advances, process technology will not deliver all the gains needed in an optimal low-power device. See the figure below. (more…)
This years Design Automation Conference in San Francisco was excellent! You don’t have to take my word for it. At the Industry Liaison Committee meeting for DAC exhibitors on Thursday June 11, the various members were in agreement that show traffic was up, and the quality of the customer meetings exceeded expectations. Why is that? It is in large part of due to the tremendous efforts of Anne Cerkel senior director for technology marketing at Mentor Graphics, who was the general chair for the 52nd DAC.
One innovation at this year’s show was opening the exhibitor floor at 10 am. This made it more convenient to see the morning keynotes and also more flexibility in commuting to the show from around the Bay area. I think you can expect to see this again at the next 53rd DAC show in Austin Texas.
Our two GRID racing car simulators was one reason the show was excellent for Real Intent. We were able to draw a large crowd to our booth. Budding race car drivers could challenge their friends and colleagues to a race and enjoy our license-to-speed verification solutions. A special thank you to Shama Jawaid and the team at OpenText who was our partner for the license-to-speed promotion.
Here are some quick photos from the show for you to enjoy.
One trend we’re seeing in Asia is the number of FPGA design starts — now counting in the thousands. Getting a functionally correct design is the first goal for designers. It is easy to think that once that is achieved FPGAs can shipped out in finished products. But that’s not a robust model. For example, we have had customers with failures in the field due to a subtle timing change between FPGA part lots.Larger FPGA designs have grown in complexity, resulting in an amalgamation of disparate IP that can lead to clock domain challenges. A robust model for FPGA designs requires advanced signoff tools, a design flow that works easily with Xilinx and Altera tools, and support for high-reliability standards like DO-254. This is where Real Intent’s Meridian and Ascent products excel. For high-performance, our CDC and Lint tools provide the confidence design teams need, with unsurpassed verification and sign-off support.
Come visit us in Booth #1422 at DAC in San Francisco, June 8-10 to see our latest technical presentations. To choose your technical presentation clickhere.
Can’t attend DAC? Check out some of our latest video interviews with Real Intent technologists or email us for a personal presentation to you or your team.
The last two weeks before the Design Automation Conference in San Francisco are a busy time. For us marketeers, it has been called “our Superbowl.” We want to get the word out that we have something new and important to show visitors to at our exhibit booth. But there is more going on which I will mention after I talk about our booth activities.
Real Intent is number two on the GarySmithEDA What to See @ DAC list. I know why we are number two on the list. But I don’t want to give the secret away. If you know the reason, then please let everyone know in the comments section at the end of the blog.
Here are the quick titles for our technical presentation in our demo suites.
Ascent Lint with 3rd Generation iDebug Platform and DO-254
Meridian CDC for RTL with New 3rd Generation iDebug Platform
Ascent XV with Advanced Gate-level Pessimism Analysis
Accelerate Your RTL Sign-off
Hierarchical CDC Analysis and Reporting for Giga-gate Designs
In the stories of the Wild West from the 1800s, the image of a cattle drive often is depicted. A small team of cowboys delivers thousands of heads of cattle to market. The cowboys spend many days crossing open land until they reach their destination – one with stock yards to accept their precious herd, and a rail station to deliver it quickly to market. Along the way there are dangers, including losses by predators and mad stampedes by cattle rushing blindly when frightened or disturbed. The primary job of the cowboys is to keep the herd on track and settled as they move to ship-out.
I see immediate parallels between the cowboys of the Wild West and today’s system-on-chip (SoC) design and verification engineers. Cowhands struggle to control and move a big herd. Similarly, today’s design teams grapple with how to keep a project on target and converging to tape-out and success when the gate count of SoCs has become so large it can stretch and even overwhelm their ability to stay on track. How big are these new SoCs? (more…)
Did you know there will be 50 billion connected devices by 2020?
I am not making it up!
This was the future painted by Dr. Martin Scott, SVP and GM, Cryptography Research Division, Rambus, in a scintillating session on the Internet of Things (IoT) at the Silicon Summit 2015 event organized by Global Semiconductor Alliance in April.
What will the future look like when there will be more than six devices for every person on the planet?
I’ll summarize what I learned regarding three IoT topics: the components, the scope and the challenges.
Components of an IoT System
Dr. Scott laid out the high-level components of an IoT system: (more…)
In late March, Brian Bailey of Semiconductor Engineering published an article on standards: “Design by Architect or Committee?” This made me think of my own experience with the Accellera Unified Coverage Interoperability Standard (UCIS), something of which I am both proud and embarrassed. Proud, because when I was at Mentor Graphics I was the architect of the winning donation, and that’s a rare thing in any career — to contribute the design and architecture for an industry standard. However, I am embarrassed because I know I could have done better in a re-design. Any software engineer will tell you this: the second design is always better, because you’ve learned from the first. We did some re-design as part of the standardization effort, but not to the degree I wanted. (more…)
This article was originally published on TechDesignForums and is reproduced here by permission.
At first glance the DO-254 aviation standard, ‘Design Assurance Guideline for Airborne Electronic Hardware’, seems daunting. It defines design and verification flows tightly with regard to both implementation and traceability.
Here’s an example of the granularity within the standard: a sizeable block addresses how you write state machines, the coding style you use and the conformity of those state machines to that style.
This kind of stylistic, lower-level semantic requirement – and there are many within DO-254 – makes design managers stop and think. So it should. The standard is focused on aviation’s safety-critical demands, assessing the hardware design’s execution and functionality in appropriate depth right up to the consequences of a catastrophic failure.
Nevertheless, one pervasive and understandable concern has been the degree to which such a tightly-drawn standard will impact on and be compatible with established flows. This particularly goes for new entrants in avionics and its related markets.
Your company has a certain way of doing things so you inevitably wonder how easily that can be adapted and extended to meet the requirements of DO-254… or will a painful and expensive rethink be necessary? Can we realistically do this? (more…)
Thanks to the widespread reuse of intellectual property (IP) blocks and the difficulty of distributing a system-wide clock across an entire device, today’s system-on-chip (SoC) designs use a large number of clock domains that run asynchronously to each other. A design involving hundreds of millions of transistors can easily incorporate 50 or more clock domains and hundreds of thousands of signals that cross between them.
Although the use of smaller individual clock domains helps improve verification of subsystems apart from the context of the full SoC, the checks required to ensure that the full SoC meets its timing constraints have become increasingly time consuming.
Signals involved in clock domain crossing (CDC), for example where a flip-flip driven by one clock signal feeds data to a flop driven by a different clock signal raise the potential issue of metastability and data loss. Tools based on static verification technology exist to perform CDC checks and recommend the inclusion of more robust synchronizers or other changes to remove the risk of metastability and data loss.
In a recent blog, Does Your Synthesis Code Play Well With Others?, I explored some of the requirements for verifying the quality of the RTL code generated by high-level synthesis (HLS) tools. At a minimum, a state-of-the-art lint tool should be used to ensure that there are no issues with the generated code. Results can be achieved in minutes, if not seconds for generated blocks.
What else can be done to ensure the quality of the generated RTL code? For functional verification, an autoformal tools, like Real Intent’s Ascent IIV product can be used to ensure that basic operation is correct. The IIV tools will automatically generate sequences and detect whether incorrect or undesirable behavior can occur. Here is a quick list of what IIV can catch in the generated code:
FSM deadlocks and unreachable states
Bus contention and floating busses
Full- and Parallel-case pragma violations
Constant RTL expressions, nets & state vector bits
Designers are are also concerned about the resettability of their designs and if they power-up into a known good state. (more…)