Archive for the ‘Uncategorized’ Category
Thursday, October 15th, 2015
At the Design Automation Conference in San Francisco, Real Intent did a survey of 201 visitors to our booth. We focused on RTL and gate-level verification issues. Below is a brief introduction and you can see the entire survey on the DeepChip.com web-site.
DAC’15 “When is your next design start?”
0-3 months : ########################################### (52%)
3-6 months : ###################### (26%)
6-12 months: ################## (22%)
These numbers are very similar to what was reported in 2012 on DeepChip. With half of the future design starts occurring in the next 3 months, this leads me to think design activity is remaining strong despite any EDA user consolidation we might have seen with the big mergers of various chip companies, and the slowing of the Chinese economy. However, the latest IC forecast from Gartner has 2015 growth falling from 5.4% at the beginning of 2015 down to 2.2% in July.
Thursday, October 8th, 2015
In this blog, we are presenting the highlights from Real Intent’s Fall 2015 Verification Newsletter. First are some thoughts from Prakash Narain, CEO, followed by an introduction to the new 2015 release of Meridian CDC for clock-domain and reset-domain crossing sign-off, and finally a review of our fall events including an ASICON tutorial.
Thoughts From Prakash Narain, President and CEO…
Most functional verification for SoC and FPGA designs is done prior to RTL hand-off to digital synthesis, since gate-level simulations take longer to complete and are significantly harder to debug. However, gate-level simulations are still needed to verify some circuit behavior. Unfortunately, X’s in gate-level simulations can cause differences in the RTL simulation output and the gate-level simulation output. X’s generally exist in all designs – it can be difficult to prevent this for practical reasons. Simulation results may be different because of X’s that are hidden in the RTL simulation by X-optimism, or additional X’s may exist due to X-pessimism in gate-level simulations. Pessimism can be fixed by overriding the simulator because you know that real hardware would always resolve to a deterministic value. The challenge is confirming that the X value is a result of X-pessimism and not simply X-propagation, and then forcing it to the right value at the right point in time so the simulation matches that of real hardware.
Thursday, October 1st, 2015
Part one of this article focused on the issues of X-pessimism at the netlist level and why the current solutions are inadequate. In In part two, we look at how the Ascent XV tool correctly addresses X-safe verification.
If a node is determined to be 1(or 0) pessimistic, that means its real circuit value is 1(or 0), but simulation produces an X. A pessimistic simulation value can be corrected by forcing a 1(or 0) on the node until the conditions for pessimism no longer hold, at which time, it is released. This does not mean that all X’s can be arbitrarily forced to a known value. Only X’s that result from pessimism should be forced, and they must be forced to represent the deterministic value that real hardware would see and released immediately when the pessimism stops.
Ascent XV-netlist makes your simulation hardware accurate by appropriately correcting pessimism. Ascent XV statically identifies the potentially pessimistic nodes and then uses that information to create SimPortal files that augment gate-level simulation to correct X-pessimism on the fly. By doing the analysis statically before the simulation starts, the number of nodes that must be analyzed during simulation is significantly reduced. Also, the X-analysis during simulation can be reduced to a table look-up when the potentially pessimistic node has an X-value. The SimPortal files monitor the potentially pessimistic nodes in the design on the fly, independent of the testbench. (more…)
Thursday, September 24th, 2015
Most functional verification for SoC and FPGA designs is done prior to RTL hand-off to digital synthesis because gate-level simulations take longer to complete and are significantly harder to debug. However, gate-level simulations are still needed to verify some circuit behavior. Ideally, the output of the RTL simulations will match the output of gate-level netlist simulations on the same design after synthesis. And why wouldn’t they? Besides the obvious things that are being verified in your gate-level simulations, there are also unknown values (X’s) that were not seen in RTL due to X-optimism, and additional X’s in the gate-level simulations due to X-pessimism. Part one of this article focuses on the issues of X-pessimism at the netlist level and why the current solutions are inadequate.
Thursday, September 17th, 2015
Calypto Design Systems was embraced by Mentor Graphics this week. Founded in 2002, the company was born out of discussions between founder Devadas Varma and Dado Banatao, partner at Tallwood Venture Capital. By early 2005, it had raised $22 million in venture capital, and had 42 employees, 18 with PhDs. It was tackling equivalence checking (SLEC) between ESL and RTL design representations.
In 2011, Mentor bought a 51% interest in the company and sold Calypto its Catapult-C synthesis technology, which seemed like a good match to their SLEC tool. With Calypto’s growing success, it was natural that Mentor would pull them into their fold.
For several years, Calypto Design Systems and Real Intent have co-operated in support of verification flows for mutual customers. Both companies shared the same distributor is Korea.
One flow we had jointly announced was our Ascent Lint with their Catapult synthesizer. Catapult lets designers use industry standard ANSI C++ or SystemC to describe functional intent at the ESL level. From these high-level descriptions, Catapult automatically generates production quality RTL. Ascent Lint ensures Catapult-generated RTL code is lint clean and error free for a safe and reliable implementation flow from RTL to GDSII layout.
Thursday, September 10th, 2015
As the computer, tablet and smartphone industries move toward adoption of the new USB Type-C connector, a new version of Thunderbolt is quickly approaching. With speeds topping 40 gigabits per second, Thunderbolt 3 promises to provide another solution to unify various display, docking, power, storage and network protocols currently available under the USB Type-C standard, with data transmission speeds beyond that of USB Type-C as well as other protocols like DisplayPort and PCI Express.
USB and Thunderbolt have been widely used to connect various peripheral devices providing storage, display, and recently, power capabilities though distinct ports on devices. And until now, these ports have been separate. When work by Intel began on the Thunderbolt 3 interface, the port was going to continue to be unique until standards began to emerge for USB Type-C.
USB Type-C connector
Thursday, September 3rd, 2015
Battery life in consumer electronics is dependent on the dynamic power behavior of their integrated circuits. If that dynamic behavior can be adjusted to fit the task at hand, then considerable power savings can be realized. In CMOS circuits most of the dynamic power is consumed in the parasitic capacitance of their digital gates.
The equation for dynamic or transient power can be written as follows:
The combination of supply voltage and frequency has a cubic impact on total power dissipation because dynamic power consumption has a quadratic dependence on voltage and a linear dependence on frequency. An intelligent power savings solution would reduce operating frequency and, at the same time, reduce the supply voltage. Some example commercial implementations of dynamic voltage frequency scaling (DVFS) technology are Intel’s SpeedStep and AMD’s PowerNow. According to the 2014 Calypto RTL Power Reduction Survey, 24% of designs used DVFS.
Click here to read the rest of this article originally published on EETimes SoC Designlines.
Thursday, August 27th, 2015
With the slow down in Moore’s law, technologists are now speculating on what future integrated circuits will look like. One constraint is the clock frequency of CMOS processors, which is topping out at around 4GHz for high-end processors in the 100W range, down to around 1-2GHz for ~5W processors used in laptop and mobile applications. With this constraint on clock speed, IC designers are adding more cores to increase processing throughput. Along with these additional processors is an increasing need for easy access to high-speed memory. Performance will not be achieved if multiple processors are contending for shared memory access.
One solution to this challenge are new 3D-manufacturing technologies in combination with new chip architectures to overcome the bandwidth-latency barrier in high-count multi-core chips.
The following will be the key enablers for 3D manufacturing: (more…)
Thursday, August 20th, 2015
The Wilson Research Group 2014 functional verification study exposes many interesting trends in the techniques used and troubles seen by both designers and verification engineers. Harry Foster of Mentor Graphics has been been blogging about the study for some time now.
As I was looking over the report slides, there was an interest trend that stood out for me.
Figure 1. The Mean Time that Design Engineers spend doing design versus doing verification.
Thursday, August 13th, 2015
The great thing about a standard is that once you decide to use it, your life as a designer is suddenly easier. Using a standard reduces the long list of choices and decisions that need to be made to get a working product out the door. It also gives assurance to the customer that you are following best practices of the industry.
A standard for the world of aviation electronics (avionics) is the RTCA/DO-254, Design Assurance Guidance For Airborne Electronic Hardware. It is a process assurance flow for civilian aerospace design of complex electronic hardware typically implemented using ASICs or big FPGAs. In the USA, the Federal Aviation Administration (FAA) requires that the DO-254 process is followed. In Europe there is an equivalent standard called EUROCAE ED-80.
At first glance the standard seems daunting. It defines how design and verification flows must be strongly tied to both implementation and traceability. In DO-254 projects, HDL coding standards must be documented, and any project code must be reviewed to ensure it follows these standards. They address the following issues: (more…)