Path: EDN Asia >> Design Centre >> IC/Board/Systems Design >> Addressing pre-silicon emulation challenges
IC/Board/Systems Design Share print

Addressing pre-silicon emulation challenges

25 Mar 2015  | Neha Srivastava, Saloni Raina, Akshay Bisht

Share this page with your friends

With the continuously growing demand for single-cut strategy with zero defects, it has become absolutely essential to have a well-defined pre-silicon emulation platform working along with SoC verification to find all the design faults early in the cycle, before they reach silicon. Both pre-silicon emulation and SoC verification environments have their pros and cons.

Simulation is highly controllable, observable, and hence easy to debug. But the primary disadvantage is that it is very slow, hence only limited coverage can be achieved with it. Emulation on the other hand is much faster, with good observability and controlability, and debug mechanisms such as hardware break points and trace buffers, but with limited wavedump capabilities. Emulation is typically very expensive, thus requiring a clever selection of features to be tested.

Mapping design to an emulator and initial emulator integration can be a difficult phase to progress mainly because a fully synthesisable testbench is needed. Also, many signals, mostly corresponding to the analogue blocks (Power management Unit, Phase Lock Loop, Flash etc) are forced and their models used on these Emulation platforms are very elementary. Stubbing the modules which are not intended to be tested, improves utilisation of costly emulator resources.

Even though pre-silicon emulation is a very powerful platform, there are some limitations that are holding it back. In this paper we highlight some key challenges faced and some suggestions to deal with them.

Stubbing of blocks
Stub is a black box without any functionality, and has all the signals at the block boundary forced to some appropriate value, which is supposed to remain the same throughout. Something to be noted here is that even though the block is not being tested functionally, it may play a role in some other block's functionality, which may get affected due to the forcing of signals to a static value.

Let's try and understand this with the help of a practical example:

Low Power Mode Entry hang due to low power acknowledgement signals forced to 0 at the boundary of Stubbed Modules

Initial Observation on Emulator: SOC unable to enter Low power mode. As soon as low power entry is initiated, the mode transition hangs, with a reset as the only recoverable option.

Detailed analysis: Entry of the entire SOC into low power mode is gated until an acknowledgement is received from each module that it is ready to go into low power. This _lp_ack signal (low power acknowledgement from the module) is nothing but an assign statement of the _lp_request(low power request sent to the module).
assign module_lp_ack = module_lp_request;
But since some module_lp_ack signals were tied to 0 while stubbing the respective modules, the modules weren't able to give an acknowledgement even after receiving a lp_request, hence causing a hang situation.

Dumping waves (logic analyser mode)
Debugging designs on emulation platform is a challenging task particularly because the wavedump capability is very limited. Debugging becomes more tedious as the design complexity increases. The wave capture depth is typically small and the wavedump upload speed very slow. Also, the user tends to miss the actual failure point with the chosen trigger and often has to sweep through the trigger point to actually reach the point of failure. This is again a very time consuming task, leading to more jobs in queue, waiting for the boards to be released.

What is loop-breaking?The Cadence Palladium compiler does not tolerate any combinational loops in its input netlist (design). Therefore, it checks the design for combinational loops, and breaks any loop it finds by inserting a delay at a point within the loop. The delay is usually 1 emulator internal clock cycle, but can also vary. A path from flipflop clock, reset or set to Q, or latch D, enable, set or reset to Q is considered combinational and this is where it mostly considers to break the loop.

Problems Caused by Loop-breaking

Although functionality is expected to be intact even after loop breaking but some times it is seen that it does affect the functionality.

1 • 2 • 3 Next Page Last Page

Want to more of this to be delivered to you for FREE?

Subscribe to EDN Asia alerts and receive the latest design ideas and product news in your inbox.

Got to make sure you're not a robot. Please enter the code displayed on the right.

Time to activate your subscription - it's easy!

We have sent an activate request to your registerd e-email. Simply click on the link to activate your subscription.

We're doing this to protect your privacy and ensure you successfully receive your e-mail alerts.

Add New Comment
Visitor (To avoid code verification, simply login or register with us. It is fast and free!)
*Verify code:
Tech Impact

Regional Roundup
Control this smart glass with the blink of an eye
K-Glass 2 detects users' eye movements to point the cursor to recognise computer icons or objects in the Internet, and uses winks for commands. The researchers call this interface the "i-Mouse."

GlobalFoundries extends grants to Singapore students
ARM, Tencent Games team up to improve mobile gaming

News | Products | Design Features | Regional Roundup | Tech Impact