Posts Tagged ‘SOC’
Thursday, January 28th, 2016
We continue the short blog series that addresses the issue of doing clock domain crossing analysis where the clocks differ in frequency. In Part 1 and Part 2, we discussed the use of structural and formal checks when there is a fast-to-slow transition in a clock domain crossing. In this blog, we will present the third and final step using a design’s testbench.
The next step in the verification process of fast-to-slow clock domain crossings is to do metastability-aware simulation on the whole design. When running a regular simulation test bench, there is no concept of what could happen to the design if there was metastability present in the data or control paths within the design. One of the key reasons for doing CDC checks is to ensure that metastability does not affect a design. After structural analysis ensures that all crossings do contain synchronizers, and formal analysis ensures that the pulse width and data are stable, a whole-chip metastability-aware simulation is needed to see if the design is still sensitive to metastability. Functional monitors and metastability checkers are shown in Figure 7. No changes are made to the design, and the necessary monitors and checkers are written in an auxiliary Verilog simulation test bench file. This auxiliary file is simply referred to by the original simulation test bench file to invoke the metastability checking. As a prerequisite, this step requires that the design have a detailed simulation test bench. (more…)
Thursday, January 21st, 2016
We continue the short blog series that addresses the issue of doing clock domain crossing analysis where the clocks differ in frequency. In Part 1, we ended the discussion noting that when there is a fast-to-slow transition, there is a possibility that a short duration control pulse may be completely missed by the receive domain and a formal analysis is required to discover if this is a potential problem. We will look at how formal analysis can verify this kind of transition.
A formal check also is required on a slow-to-fast data crossing with feedback. In such a circuit, as shown in Figure 4, an acknowledge signal coming from the receiving fast-clock domain to the transmitting slow-clock domain also requires a formal Pulse Width check. Although the control pulse (request) is going from slow to fast and does not need a formal pulse width check, the acknowledge pulse-width check is necessary because the acknowledge signal (the feedback circuit) is going from a fast to a slow clock and, in order for the acknowledge to be properly captured, the acknowledge pulse (transmitted from the receiving side) must be sufficiently wide to be captured (received on the transmitting side) by the slower clock domain of the transmitting side flops. Failure to check for this condition is the reason behind many a request/acknowledge circuit not working as expected. Note that feedback circuits in a fast-to-slow crossing are operating in a slow-to-fast mode and the acknowledge signal in such a circuit does not need to be pulse-width checked. In short, all fast-to-slow control signal transitions, whether connected in a feed-forward or a feedback manner need to be formally pulse-width checked to ensure integrity of the control aspect of the clock domain crossing. (more…)
Thursday, January 14th, 2016
This is a reprise of a short blog series that addresses the issue of doing clock domain crossing analysis where the clocks differ in frequency, and the use of three different techniques for a complete analysis.
CDC checking of any asynchronous clock domain crossing requires that the data path and the control path be identified and that the receive clock domain data flow is controlled by a multiplexer with a select line that is fed by a correctly synchronized control line. Meridian CDC will always identify all the data and associated control paths in a design and will ensure that the control signals passing from a transmit clock domain to an asynchronous receive clock domain are correctly synchronized. There are three separate techniques that are used within Meridian CDC: structural checking, formal checks and simulation-based injected metastability checks.
Thursday, November 5th, 2015
Courtesy Ron Amadeo and Intel
Google is starting to push to have more say in the design and architecture of the chips that run the Android system in smart phones. They are also apparently making major investments into virtual reality, where some of the chip design effort is expected. And hiring staff from major SoC companies.
Ron Amadeo from the tech publication Ars Technica has published the following online report: According to a pair of reports from The Information (subscription required), Google has big ambitions for the inside of Android phones. The report says the search giant has sent a long list of requests to chip manufacturers for future SoC designs and that Google is even planning to build its own processors.
The report says that during discussions that happened this fall, “Google representatives put forward designs of chips it was interested in co-developing, including a phone’s main processor.” The new chips are reportedly needed for future Android features that Google hopes to release “in the next few years.” By designing its own chips, Google can make sure the right amount of horsepower gets assigned to all the right places and remove bottlenecks that would slow down these new features.
The report specifically calls out “virtual and augmented reality” as use cases for the new chips. Publicly, only Google Cardboard has surfaced from Google’s VR initiative, but internally, it seems like the company is gearing up for a huge VR push. Some of Google’s biggest names have left their posts on flagship products to go work on the virtual reality team: Jon Wiley, the lead designer of Google Search, and Alex Faaborg, the former lead designer for Firefox, Google Now, and Android Wear. An earlier report from The Wall Street Journal claimed Google was building a version of Android that would become a virtual reality operating system.
Read the rest of Ron Amadeo’s article here and learn who Google is hiring.
Thursday, October 22nd, 2015
The following CEO Insight was published in the October 2015 issue of SiliconIndia.
This year we are celebrating the 50th anniversary of Moore’s Law. On April 19, 1965, Electronics magazine published an article that profoundly impacted the world. It was authored by a Fairchild Semiconductor R&D Director, Gordon Moore, who forecast that transistors would decrease in cost and increase in performance at an exponential rate. The article predicted the availability of personal computers and mobile communications. Moore’s seminal observation became known as ‘Moore’s Law’, a prediction that established the path the semiconductor industry would take for the next 50 years or more and, in doing so would dramatically change our lives. Three years later Gordon Moore co-founded Intel, the number one semiconductor company in the world.
Thursday, June 25th, 2015
The propagation of unknown (“X”) states has become a more pressing issue with the move toward billion-gate SoC designs, and especially so with power-managed SoC designs. The SystemVerilog standard defines an X as an “unknown” value used to represent the state in which simulation cannot definitely resolve a signal to a “1,” a “0,” or a “Z.”
Synthesis, on the other hand, defines an X as a “don’t care,” enabling greater flexibility and optimization. Unfortunately, Verilog RTL simulation semantics often mask the propagation of an X value, while gate-level simulations show additional Xs that will not exist in real hardware.
The sheer complexity and common use of power management schemes increase the likelihood of an unknown “X” state in the design translating into a functional bug in the final chip. This possibility has been the subject of two technical presentations at the Design and Verification Conference during the last couple of years: I’m Still in Love With My X! But, Do I Want My X to Be an Optimist, a Pessimist, or Eliminated? and X-Propagation Woes: Masking Bugs at RTL and Unnecessary Debug at the Netlist. Let’s look more closely at this issue and the requirements for a solution.
Thursday, October 30th, 2014
I was musing the other day about the completeness of SoCs – they include a mix of embedded processors for programmable functionality, hardware engines that accelerate specific features such as graphics, and multiple interfaces for memory, buses, and peripherals. And this remarkably complete solution is delivered on a single die. We have the perfect building block for creating systems with high-value and low-cost. But, even with Moore’s law allowing us to build more complex silicon, is new feature integration a scalable future for SoCs?
My conclusion is that we are approaching a steady state. From what I see, SoC design is still a custom solution in many ways, tailored to fit a generation of parts that meet some specific requirements. While complete in itself, the features cast in silicon offer only a coarse control of functionality. This leaves the end-user having to provide additional software and hardware to fill in any feature gaps at additional cost and time spent. While the intended and configured functions of the SoC might been implemented, any feature extensions may have compromises in performance.
Thursday, September 18th, 2014
This article was originally published on TechDesignForums and is reproduced here by permission.
Consider the Wall Street controversy over High Frequency Trading (HFT). Set aside its ethical (and legal) aspects. Concentrate on the technology. HFT exploits customized IT systems that allow certain banks to place ‘buy’ or ‘sell’ stock orders just before rivals, sometimes just milliseconds before. That tiny advantage can make enough difference to the share price paid that HFT users are said to profit on more than 90% of trades.
Now look back to the early days of electronic trading. Competitive advantage then came down to how quickly you adopted an off-the-shelf, one-size-fits-all e-trading package.
Thursday, July 3rd, 2014
SoC companies are coming to rely on RTL sign-off of many verification objectives as a means to achieve a sensible division of labor between their RTL design team and their system-level verification team. Given the sign-off expectation, the verification of those objectives at the RT level must absolutely be comprehensive.
Increasingly, sign-off at the RTL level can be accomplished using static-verification technologies. Static verification stands on two pillars: Deep Semantic Analysis and Formal Methods. With the judicious synthesis of these two, the need for dynamic analysis (a euphemism for simulation) gets pushed to the margins. To be sure, dynamic analysis continues to have a role, but is increasingly as a backstop rather than the main thrust of the verification flow. Even where simulation is used, static methods play an important role in improving its efficacy.
Deep Semantic Analysis is about understanding the purpose or role of RTL structures (logic, flip-flops, state machines, etc.) in a design in the context of the verification objective being addressed. This type of intelligence is at the core of everything that Real Intent does, to the extent that it is even ingrained into the company’s name. Much of sign-off happens based just on the deep semantic intelligence in Real Intent’s tools without the invocation of classical formal analysis.
Thursday, June 19th, 2014
This article was originally published on TechDesignForums and is reproduced here by permission.
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.