Target.... Device Fw Mismatch

[Jesper Sahu]

Invalidvalue 'armeabi' in $(AndroidSupportedAbis). This ABI is no longer supported. Please update your project properties to remove the old value. If the properties page does not show an 'armeabi' checkbox, un-check and re-check one of the other ABIs and save the changes.

ADB0020: Android ABI mismatch. You are deploying an app supporting 'x86;x86_64;arm64-v8a' ABIs to an incompatible device of ABI 'armeabi-v7a;armeabi'. You should either create an emulator matching one of your app's ABIs or add 'armeabi-v7a' to the list of ABIs your app builds for.

I recently received a LP-EM-CC2340R5 and LP-XDS110 to evaluate the performance of the CC2340R5. I have followed the install and bringup instructions in software-dl.ti.com/.../quickstart-intro-cc23xx.html but I'm having issues connecting to the device and flashing new firmware in the 'Flash the device' section.

When attempting to connect to the device using the default target settings I get the following message:

I've tried modifying the TCLK speed with no success, but I am able to get slightly further by enabling the 'Apply pin reset' option in the XDS110 settings within the target configuration. When I do this it gets partway through programming before I get an error:

Otherwise, the issue could be a faulty connection to the XDS110. This would be surprising if you have used different LP-XDS110 and LP-EM-CC2340R5 hardware. Are you using the LP-XDS110 Quick Start Guide as a reference to connect the LP-EM-CC2340R5?

The Tools Team has confirmed that the issue is most likely because debug access is disabled (inside ccfg) in the flashed program. This would be caused by a hardware/software mismatch as described earlier (i.e. RevA/PG1 SDK example on RevB/PG2 board or RevA/PG1 ccfg in an RevB/PG2 example and flashed on RevB/PG2 board.

There is no way to unlock from CCS or Uniflash. This is by design, as the debug interface is supposed to be closed permanently if selected by the developer. This was not enabled in RevA/PG1. Here is a script for customers to recover from this situation.

You have a mismatch between the resolution or DPI (Dots Per Inch) on the label in relation to the target device's print head's resolution. The labels resolution must match the resolution of the target device's print head.

If the label's resolution is higher than that of the device print head, the label will appear too large. For example:

I am runnig some Monte Carlo simulations and there are some options for model libraries like Global+Local and Local. Also, after choosing model setup in ADE, in Monte Carlo simulation, you can choose Process only, Mismatch Only and Process and Mismatch. First, I want to learn what the diffrence is between model setup(Global+Local vs Local) and difference between Monte Carlo Options(Process&Mismatch vs Process vs Mismatch). I have searched a litlle bit and I have talked with colleagues but I couldn't find so much useful info.

1. In Corner (ss/tt/fs/sf/ff) simulations the variation from wafer-to-wafer and lot-to-lot is simulated. But all devices do have the same model-parameters during simulation - means "deviceA" behaves the same as its adjacent "deviceB" with model parameters of the actual simulated corner. No mismatch between devices.

2. "MC_local" simulates the variation (mismatch) of devices within one wafer - means "deviceA" has slightly different model-parameters as its adjacent "deviceB", but at the typical "tt" process corner. So it is assumed that the process corner is "tt".

3. "MC global" simulates the variation (mismatch) of devices from wafer-to-wafer and lot-to-lot. This is like a Corner simulation, but "deviceA" can have the "slow"-corner-parameters, whereas its adjacent "deviceB" can have "fast"-corner-parameters.

Now, what I have difficulties with, is to understand the use-case for point 3. As an example, in a differential amplifier, it might not happen that one device is at "fast" whereas the other device is at "slow",right ? What instead can happen is, that both devices are at "slow", but do have the "local" variation around this "slow" process corner.

I'm not sure what this "MC global" is that you are taking about. This might be something in the particular PDK/models you've got, but it's not how Spectre normally works. Other than corners (which are straightforward to understand), spectre has three different things it can simulate with monte carlo:

Some foundry models are a bit odd however - they require you to use "All" all the time, and then the model section you pick ensures that the variation is appropriately computed. You'd need to check with the foundry (or their documentation) to understand exactly what they are doing.

I always point out too that "mismatch" is actually modelling the remaining random local variation and is not trying to model systematic effects (e.g. due to poor layout alignment or proximity). Sometimes people worry about how they should be correlating the parameters to capture how well the layout is aligned, but in general that's not what Monte Carlo models capture. That said, a design which is sensitive to random local variation of instances is likely to also require well matched layout, so information about mismatch contributions can be useful to prioritise good layout practice (although understanding the design normally tells you that too).

Dear HoWei,

I might be able to shed a little more light on your question based on experience with our foundry. What may, or may not, be confusing you is the process cases offered by your foundry. Our foundry offers a set of process corners with two options - the standard corners (ss,ff,tt,sf, fs...) - as well as a second smaller set called "global" corners. They happened to be named similarly to the standard corners but include a "g" suffix. Hence, as an example, for the slow process case there are two corners - what are termed a "total corner" and a "global corner". The "total corner" is representative of the maximum device parameter variation including local device variation effects. However, it is not a statistical corner. The "global" corner is defined as the "total" corner minus the impact of "local variation". Hence, if you were to examine simulation results for a parameter using a "total" and "global" corner, you would find the range of variation will be less with the "global" corner than with the "total" corner.

The "global" corner is provided for use in statistical simulations. Hence, when performing a Monte-Carlo simulation, the "global" corner is selected - NOT the "total" corner.

When simulating the impact of local variation in Monte-Carlo using ADE-XL, Assembler, or Maestro using the "global" corner, one must check the radio button to simulate "Mismatch" under the "Statistical Variation" section of the "Monte-Carlo Sampling..." panel and not the "All" nor the "Process" radio buttons to assess the impact of local variation.

To address your specific question:

a set of three Monte-Carlo simulation sets is required using the respective "global" corner for each case (ss/ff/tt) using the "Mismatch" radio button selected. You will find each will provide a different level of statistical variation. As a side note, in lieu of telling spectre to automatically determine the proper number of simulations to run to estimate parameter standard deviation, I usually initially run a large set (200 to 1000) and plot the value of the resulting standard deviation as a function of the number of simulations run. This provides a very good estimate of the impact of the number of Monte-Carlo simulations and its impact of my estimate for the standard deviation.

I hope this helps explain your situation based on my experience with our foundry.

Shawn

I spend some hours on investigating the behaviour by observing the "Vth" for two NMOS instances (M0 and M1) versus different corners and MC setups. Our PDK-modelfile offers 4 different "sections" of Corner/MC simulation cases:

This sets the "Vth" for both M0/M1 to the same value without any difference between the two devices. It has no mismatch included. it does not matter whether I select "Process/Mismatch/All" - I always get the "Vth" for the selected corner.

E.g. if I want to see the mismatch of devices at the process corner "fs", I just select the section "fsg_localmc" and apply "Mismatch or All" (give same results because process cannot be varied, as it has been selected via section already).

Selecting "Process" varies the "Vth" somehow between the process corners (with normal-distribution around the "tt" mean), but both devices doe have the same "Vth" - no mismatch included. That is the only case, where the "Vth" is varied over the full range of "Process" corners.

Selecting "All" (this is actually the only case where "All" gives a different result as "Mismatch") combines the "Process" and "Mismatch" variations. The simulator first selects a "Vth" from the "Process" variation and applies it to both M0/M1, and then applies "Mismatch" to the instances, causing a different "Vth" in M0/M1 within the distribution of "localmc". The result is a full range of process and mismatch variation - but one cannot distinguish anymore which point belong to what corner (because it can be any value between corners) and it does not tell the distribution around dedicated corners. It might only be useful for yield-estimation, but not for matching in e.g. diffamp or for R2R-resistors.

As I understand the NMOS values are varied with their mismatch distribution around a specific Global (Process) point. But will the resistor values have an independent GlobalMC (Process) point - means can it be the case that the NMOS are at the ff-corner and the resistor is at ss-corner, and at the next MC point, the NMOS are still at ff-corner and the resistors at ff-corner ?

Let me attempt to provide my thoughts on your additional questions.

> can you tell me how the variation resistors and MOS is simulated in Global_LocalMC ?

> As I understand the NMOS values are varied with their mismatch distribution

> around a specific Global (Process) point.

I assume you also mean to include PMOS devices as well as NMOS devices as both will show variation if this condition is selected for your Monte-Carlo analysis.

> But will the resistor values have an independent GlobalMC (Process) point

> - means can it be the case that the NMOS are at the ff-corner and the

> resistor is at ss-corner, and at the next MC point,

> the NMOS are still at ff-corner and the resistors at ff-corner ?

> I am wondering anyways if the resistor-values (in reality - not simulation)

> are dependent or independent of the Process corner ?

If you examine the PDK you are using, this Monte-Carlo condition is mapped to the typical silicon process. It only invokes modeling information from the typical corner case. For each Monte-Carlo iteration, the process variation applied to MOS devices is identical, but the local variation will vary from device to device if Mismatch is selected. Discrete resistor variation (i.e., those not composed of MOS devices), however, is independent of MOS device variation based on how they are fabricated. Its sheet rho and dimensional parameters are not related physically to the sheet resistance nor dimensional varation of MOS devices. Hence, it is very possible that the resistor value in a given Monte-Carlo iteration may appear "slower" or "faster" than the corresponding MOS devices in the same iteration.

Did I understand your concern, and does this make sense HoWei? I hope so anyway.

Shawn

3a8082e126