Webinar - Complex SoC Verification – What Next ?

Complex SoC Verification – What Next ?


Embitel is happy to announce the 16th Webinar on Embedded SoC verification Series which is titled: “Complex SoC Verification – What Next ?” on 6th March, 2013 at 3 PM CET. We are bringing in one of the latest and most discussed topic of this year which will give a fair idea on how to drive your newer SoC verification activities. This Webinar is part of a series of Webinar on complex SoC verification challenges which discuss the future of SoC complexities and the verification challenges.

Here’s why you should attend this Webinar:

To understand current challenges in Complex SoC verification
Understand the existing pit falls
Plan for early adoption of scalable SoC verification methodology
Learn Insights in to new generation methodology options
Learn Tips and tricks for first time silicon success

Speaker: Mr. Abey Thomas

Verification Competency Manager, Embitel Technologies
Industry expert with more than 16 years of experience in Embedded product design, SoC/ ASIC and ARM processor based design Consulting



Mystery Gift for Lucky Participant

"Do's and Don'ts" when considering an FPGA to structured ASIC design methodology

More and more engineers are considering structured ASICs when they are designing advanced systems, because these components offer low unit cost, low power, and high performance along with fast turn-around.

In a structured ASIC, the functional resources – such as logic, memory, I/O buffers – are embedded in a pre-engineered and pre-verified base layer. The device is then customized with the top few metal layers, requiring far less engineering effort to create a low cost ASIC (Fig 1). This reduces not only the time and development costs, but also the risk of design errors, since the ASIC vendor only needs to generate metallization layers. With 90-nm process technologies, structured ASICs offer the density and performance required to meet a wide range of advanced applications.


1. Standard cell ASIC (top) versus structured ASIC (bottom).
However, there is still risk involved when it comes to developing a structured ASIC. Errors in the logic design can still exist, so one way to avoid time-consuming and costly silicon re-spins is to use FPGA prototyping and to then convert the design from an FPGA to some form of ASIC. FPGA prototyping is more successful for structured ASICs compared to standard cell ASICs when the structured ASIC mirrors the resources available on the FPGA. The closer the match between the I/O and memory of the FPGA and the structured ASIC, the lower the risk when the design is converted to an ASIC.

Some "Do's and Don'ts" to take into account when considering a structured ASIC design methodology are as follows:
Do
Establish a design methodology you can use for a wide range of applications. Make sure your design teams are trained on the tools and the FPGA and ASIC architectures to create the best possible design.

Use a software development environment that reduces the risk of design problems, such as functional logic errors. Logic verification and simulation, along with prototyping the design in an FPGA, is a proven method to ensure the design will work in the system.

Prototype your design with an FPGA using the FPGA features that give you the best performance and functionality. Also, generate the prototype with the IP you need for the application, which may require a soft processor, hard multipliers, and memory. In addition, use high-speed LVDS or other I/O to ensure you are building in the signal integrity needed to have a reliable system.

Test your design in-system as much as possible to verify the design works according to requirements. Make sure the system is tested with the FPGA prototype across the entire voltage and temperature range that the system will experience. That will reduce the risk that when the design is converted to an ASIC it will only operate over a limited temperature range and at nominal voltage.

Design the system to use either an FPGA or the structured ASIC. This allows you two major advantages. First, you can go into production with the FPGA and then change to the ASIC once it is available. That provides the advantage of getting to market faster and promotes a market position. Secondly, if there is an unexpected increase in the demand for ASICs and supplies are insufficient, some systems with an FPGA can be manufactured, thus keeping the production lines running. Finally, using the FPGA at the system's end-of-life will save you from having to order more ASIC devices that are needed to fulfill manufacturing requirements.

An example is the Altera HardCopy II structured ASIC. Generate your prototype with a Stratix' II FPGA, then go into production with the Stratix II FPGA while the Altera HardCopy Design Center migrates the design to a pin-compatible HardCopy II device. Once the HardCopy II device is approved and production units are available, the system can be produced using the lower cost HardCopy II device.
The combination of Altera Stratix II FPGA and HardCopy II structured ASICs also gives you unique manufacturing flexibility, since you can use either in production. For example, you can use the HardCopy device for low cost, but if you have a sudden increase in demand and need more devices immediately, you can use off-the-shelf Stratix II FPGAs as a substitute. You can also go back to using Stratix II FPGAs exclusively if you need to update the design to fix an error or make a change for a specific customer.

Don't

Use an FPGA to prototype only logic and low-level I/O (such as LVTTL or LVCMOS). That will limit your design to low-end gate arrays that won't provide the performance edge needed. Too often, only the logic is prototyped in the FPGA, leading to a misconception of how well the design really works in the system. Many designs also require high-speed memory interfaces, and the best design practice is prototyping to ensure the interface performs as required, particularly across voltage and temperature variations.

Choose an ASIC methodology based only on unit cost. That may save some Bill-of-Material costs but make the system uncompetitive. Include factors such as realistic development time and costs along with total engineering effort. In the long run, an FPGA along with a structured ASIC can provide lower development costs and faster development turn-around time.

Consider only standard cell ASIC technology for ASSP designs. Sometimes, structured ASIC or even FPGAs are right for the annual volumes and the need for fast time to market.
Choose the structured ASIC before you look at the market needs for the design. Trying to shoehorn a design into a structured ASIC that is too small or feature limited, results in a system that is DOA in the market.

Consider only single-chip solutions. Sometimes the best way to architect a system can be using two devices rather than one large ASIC. Partitioning the design can reduce overall development time and simplify the design process. You can also reduce the risk of having to re-spin a large ASIC design.
Author : Rob Schreck, Aletra
Source :.design-reuse.com

Embedded Application and Product Engineering using ARM Processors

Reduced Instruction Set Computing [RISC] is a processor design that is analogous to high performance and high energy efficiency. One of the forerunners in production and supply of RISC Embedded microprocessors is ARM Holdings. ARM Holdings’ catalogs of processors are characterized by strong performance and high energy efficiency; a market-decider when it comes to digital products. Delivering high performance at low costs for the current market of advanced digital applications is now a reality because of the advancements in Embedded product engineering using ARM processors. Expert ARM architects are constantly in research and development to further improve [on the already advanced] ARM architecture, that has now become a staple architecture for embedded product design and engineering. ARM Holdings is also the world’s leading semiconductor Intellectual Property [IP] supplier, and is at the core of development of digital electronic products.

According to current industry experts, an excess of two million ARM-based processors are being used in the production of various kinds of machinery and equipment. The ARM Community [of developers worldwide] develops top-notch processors for the benefit of product design companies and designers around the globe. There is an endless list of ARM developers [with rich experience and a high industry reputation] for Embedded Product engineering with ARM processors, at highly competitive pricing. Development of advanced ARM processors, implementation of DSP algorithms, exception and interrupt handling, cache technology and memory management are some of the tasks that ARM developers manage for companies.
Embitel is a member of the ARM Connected Community and Partner Network, which is a global network of companies aligned to provide complete solutions, from design to manufacture, for embedded application and product engineering for products based on the ARM architecture. Embitel’s partnership with ARM includes digital multi-channel solutions for E-Commerce and Embedded technology development.

Webinar on Choosing Right Technology to Build HMI

Human Machine Interface (HMI) Systems provide the medium by which a user operates an automation process, system or a machine. The effectiveness of the HMI depends upon technical design process that incorporates all technical, commercial and ergonomic application requirements. HMI is a prominent tool for system automation which is used to configure, monitor and control the system. In this webinar we cover choosing right technologies for building HMI of automation components such as sensors, diagnostic equipment etc.

Key aspects of the webinar:

• HMI overview with respect to system automation
• Key factors for selecting different technologies for HMI development
• Comparison of commonly used frameworks in HMI development

About Speakers: 

Jitendra Kumar Tripathi, Technical Architect

Technical expert in different HMI technologies. Jitendra worked on various technologies such as Java, C++, Plugin Development, Qt framework, Microsoft technologies etc. He has built several HMIs for diagnostic equipment.

Vidya Sagar, Competency Head

12+ years of technical expertise in development of embedded systems. Vidya Sagar worked or various aspects of Embedded systems including building HMIs. He took part in building sensor devices and HMIs.

Webinar: Choosing right technology to build HMI

Duration: 45 Minutes + Q&A 

Date: Wednesday, November 21, 2012

Time:  3 PM CET/2 PM BST/9 AM EST/7:30 PM IST

For More Information about Webinar @ https://www2.gotomeeting.com/register/496403930

About Embitel :

Embitel offers services in Embedded system development namely Turnkey systems, Board support packages, Device drivers, Various OS platforms – Driver development, Porting, Cross Platform porting, Feature development / Enhancement, Software sustenance / Maintenance.

Embitel has created a niche for itself in Industrial automation domain. We have focused and specialized product development services in the area of Industrial Sensors, Motion controllers, protection relays, Integrated PLCs and HMI panels. We also execute projects in real time product development using variety of operating systems such as Embedded Linux, WinCE, VCRT, QNX etc.

For more information and support, please visit http://www.embitel.com/embedded-services/automation-services/

FPGA's vs. ASIC's

Deciding between ASICs and FPGAs requires designers to answer tough questions concerning costs, tool availability and effectiveness, as well as how best to present the information to management to guarantee support throughout the design process.
The first step is to make a block diagram of what you want to integrate. Sometimes it helps to get some help from an experienced field applications engineer. Remember that time is money. Your next move is to come up with some idea of production volume. Next, make a list of design objectives in order of importance. These could include cost (including nonrecurring engineering charges), die size, time-to-market, tools, performance and intellectual property requirements. You should also take into account your own design skills, what you have time to do and what you should farm out. Remember that it must make sense financially or you are doomed from the start.
Time-to-market is often at the top of the list. Some large ASICs can take a year or more to design. A good way to shorten development time is to make prototypes using FPGAs and then switch to an ASIC. But the most common mistake that designers make when they decide to build an ASIC is that they never formally pitch their idea to management. Then, after working on it for a week, the project is shot down for time-to-market or cost reasons. Designers should never overlook the important step of making their case to their managers.
Before starting on an ASIC, ask yourself or your management team if it is wise to spend $250,000 or more on NRE charges. If the answer is yes and you get the green light, then go. If the answer is no, then you'll need to gather more information before taking the ASIC route. Understand that most bean counters do not see any value in handing someone $250,000 for a one-time charge. They prefer to add cost to the production.
Say your project has a NRE of $300,000, a volume of 5,000, and it replaces circuitry that costs $80. The final ASIC cost is $40. You do some math and determine the break-even point is three years. If you amortize the same design over five years, this could save your company $400,000 even after NRE has been absorbed.
Another option is to do a "rapid ASIC" using preformed ASIC blocks, which saves time and lowers NRE costs. It could also make sense to convert an FPGA to ASIC directly, which lowers NRE a small amount from the rapid type.
Now let's say your company will not fund an ASIC effort. That means it's time to consider FPGAs. First, be aware that while the tools are free on the Web for the smaller FPGAs, you'll have to pay for a license file for the ones with high gate counts. The good news is that there are no NRE charges.
Modern FPGAs are packed with features that were not previously available. Today's FPGAs usually come with phase-locked loops), low-voltage differential signal, clock data recovery, more internal routing, high speed (most tools measure timing in picoseconds), hardware multipliers for DSPs, memory, programmable I/O, IP cores and microprocessor cores. You can integrate all your digital functions into one part and really have a system on a chip. When you look at all these features, it can be tough to argue for an ASIC.
Moreover, FPGA can be reprogrammed in a snap while an ASIC can take $50,000 and six weeks to make the same changes. FPGA costs start from a couple of dollars to several hundred or more depending on the features listed above.
So before you get moving, make sure to enlist some help, get the managers to support you, come up with a meaningful cost estimate, choose the right weapon -- be it ASIC or FPGA -- and then move into production.

Author : Jeff Kriegbaum

Source : http://www.design-reuse.com/articles/9010/fpga-s-vs-asic-s.html

Is DDR4 a bridge too far?

We’ve gone through two decades where the PC market made the rules for technology. The industry faces a question now: Can a new technology go mainstream without the PC?

By now, you’ve certainly read the news from Cadence on their DDR4 IP for TSMC 28nm. They are claiming a PHY implementation that exceeds the data rates specified for DDR-2400, which means things are blazing fast. What’s not talked about much is how the point-to-point interconnect needed for large memory spaces is going to be handled. 

Barring some earth-shattering announcement at IDF, Intel is way far way from DDR4. The nearest thing on their roadmap is Haswell-EX, a server platform for 2014. (Writing this when IDF is just getting underway is tempting fate, kind of like washing my car and then having it immediately rain.) AMD has been massively silent on the subject of DDR4 fitting into their processor roadmap. 

Meanwhile, both Samsung and Micron are ramping up 30nm production of DDR4, and Samsung is publically urging Intel to get moving. Both memory suppliers are slightly ahead of the curve, since the DDR4 spec isn’t official just yet. However, JEDEC has scheduled the promised DDR4 workshop for October 30, something they said would approximately coincide with the formal release of the specification. (In other words, it’s ready.)

We also have to factor in that LPDDR3 just hit the ground as a released specification this May, and memory chips implementing it won’t reach the pricing sweet spot for another year. Most phone manufacturers are still using LPDDR2 for that reason. (Again, iPhone 5 announcement this week, rain on my post forecasted.) Tablet types are just starting to pick up LPDDR3, amid talk the first implementations already need more bandwidth.

So, why the push for DDR4, especially in TSMC 28nm? DDR4 is obviously the answer to much higher memory bandwidth for cloud computing and the like. I’m sure there are others out there, but the was easy to find.

Interest in DDR4 has to be coming from somewhere in the ARM server camp, otherwise Cadence and TSMC wouldn’t be spending time on it. In spite of the power advances, DDR4 is no where near low-power enough to show up in a phone, and there’s no sign of a LPDDR4 specification yet. ARM 64-bit server implementations are just getting rolling, and Applied Micro’s X-Gene has sampled – with DDR3.

The volume driver for DDR4 – if it’s not PCs – is in question. The natural progression of speed that the PC markets have pushed for looks like it is about to run smack into the economics of affordable implementations, and that in turn could make life for the memory manufacturers interesting. (In a related side note,Elpida’s bondholders have come in saying the Micron bid is way too low.) Or, Intel and AMD could jump in and force the issue, betting on adoption farther down their PC supply chains.

DDR4 and IP supporting it in ARM server space could prove to be a turning point for technology investment, an inflection point in the way things have been done and a change from the PC driving. Or, it could end up being a bridge too far, but paving the way for another specification suited for mobile devices.

What are your thoughts on the outlook for DDR4, LPDDR3, an ARM server market, and the overalldynamics of PCs, servers, tablets and phones versus memory technology?

Author :Don Dingee

Source : http://www.semiwiki.com

The Unknown in Your Design Can be Dangerous

The System Verilog standard defines an X as an “unknown” value which is used to represent when 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 propagation of an unknown value by converting the unknown to a known, while gate-level simulations show additional Xs that will not exist in real hardware. The result is that bugs get masked in RTL simulation, and while they show up at the gate level, time consuming iterations between simulation and synthesis are required to debug and resolve them. Resolving differences between gate and RTL simulation results is painful because synthesized logic is less familiar to the user, and Xs make correlation between the two harder. Unwarranted X-propagation thus proves costly, causes painful debug, and sometimes allows functional bugs to slip through to silicon.

Continued increases in SOC integration and the interaction of blocks in various states of power management are exacerbating the X problem. In simulation, the X value is assigned to all memory elements by default. While hardware resets can be used to initialize registers to known values, resetting every flop or latch is not practical because of routing overhead. For synchronous resets, synthesis tools typically club these with data-path signals, thereby losing the distinction between X-free logic and X-prone logic. This in turn causes unwarranted X-propagation during the reset simulation phase. State-of-the-art low power designs have additional sources of Xs with the additional complexity that they manifest dynamically rather than only during chip power up.

Lisa Piper, from Real Intent, presented on this topic at DVCon 2012 and she described a flow in her paper that mitigates X-issues. The flow is reproduced here.

She describes a solution to the X-propagation problem that is part technology and part methodology. The flow brings together structural analysis, formal analysis, and simulation in a way that addresses all the problems and can be scaled. In the figure above, it shows the use model for the design engineer and the verification engineer. The solution is static analysis centered for the design engineer and is primarily simulation-based for the verification engineer. Also, the designer centric flow is preventative in nature while the verification flow is intended to identify and debug issues.

Author : Graham Bell
Source : www.semiwiki.com