PROOF-OF-CONCEPT: THE DAY AFTER

JEFF MILLER, PRODUCT MARKETING AND STRATEGY, MENTOR, A SIEMENS BUSINESS

W H I T E P A P E R

A M S D E S I G N & V E R I F I C A T I O N

w w w . m e n t o r . c o m
Proof-of-Concept: The Day After

Recently, we have documented the journey of the new breed of designers that are inventing IoT edge devices and
implementing them with Mentor’s complete design flow that covers custom IC, PCB, embedded software, and
system simulation (Figure 1).

Figure 1: The IoT edge device solution.

We covered how to create a zero cost proof-of-concept of your custom IC in this whitepaper. In that whitepaper,
you learn how to create the thread of the system by coupling the custom IC with a processor and test software to
demonstrate the feasibility of your idea. The day after the successful conclusion of that activity you might ask “Now
what do we do?” The day after the proof-of-concept, it is time to make your idea real and take the following
actions:

•• Understand how to reduce non-recurring expense (NRE) from idea to product including EDA tooling, IP, and IC
fabrication (see this whitepaper).
•• Begin preparing for your IoT edge project (see this whitepaper).
•• Start development of a system prototype.
This whitepaper covers developing the system prototype of an IoT edge device. While the proof-of-concept activity
answers the question, “Is it possible?” the prototype answers the question, “Can the system be built to
specification?” The prototype contains the actual sensor, electronics, and operational software. After the prototype
is complete, detailed verification and analysis takes place, and downstream tasks, like layout, are performed, and
thoughts about additional features system come into play.

UNDERSTANDING THE SYSTEM

We are developing a tank fluid level monitoring system. This system can be deployed in breweries, wineries, and
other beverage facilities at the IoT edge to collect status on the fluid levels, whether there are leaks, and to notify
technicians when there is any problem. The system (Figure 2) consists of a pressure sensor that monitors fluid level
in the tank and periodically transmits measurements to a gateway device.

w w w. m e nto r. co m
2
Proof-of-Concept: The Day After

Figure 2: The block diagram of the tank level monitoring system.

The pressure sensor provides the interface to the tank contents by providing a small analog signal that needs
amplification. In the future, we plan on adding a temperature sensor which necessitates a MUX, but for the
prototype, we will not implement those two elements. An analog-to-digital converter (ADC) circuit converts the
sensor signal to digital as an input into the microcontroller that runs the software. The clock, PLL, and oscillator
circuits are supporting modules to the digital circuitry and the bias current generator, voltage regulator, and
bandgap reference are supporting modules to the analog circuitry. The RF transmitter sends the data to the
gateway, but for the prototype, we will not implement this block yet.

In the proof-of-concept, we used a stand-in for the pressure sensor that applied a set voltage and we designed a
digital thread through a very basic software program running on an Arm® Cortex®-M0 processor, obtained through
the Arm® DesignStart™ program. Now, we create a prototype with the actual sensor, switch to the Arm Cortex-M3
processor, and write real software.

MODELING THE SENSOR

A typical pressure sensor transduces pressure into an electrical signal such as change in resistance or capacitance.
For this project, we choose one with a resistive output. We model this sensor as a variable resistor that changes
with applied pressure.

A Wheatstone bridge circuit measures the change in resistance between resistors in different orientations, which is
correlated to the applied pressure. The difference is a measured voltage which is amplified, digitized, and converted
downstream to a pressure reading.

DESIGNING THE AMS CIRCUITRY

The pressure sensor in the Wheatstone bridge testbench (Figure 3) measures change in resistance due to the
applied pressure, resulting in a voltage that is directly proportional to the applied pressure. We use a full bridge
because it is the least sensitive to temperature and process variations.

The pressure sensor outputs 0.1 mv up to 35 mv at our 350.25k Pascal design pressure maximum. But the ADC
operates in the range of 0 to 2.2 volts. So we need to add an amplifier with a gain of 61 in order to provide optimal
resolution over our target dynamic range.

w w w. m e nto r. co m
3
Proof-of-Concept: The Day After

Figure 3: Pressure sensor testbench.

The actual sensor replaces the stand-in from the proof-of-concept and it is connected to the 8-bit, successive
approximation ADC, which in turn, is connected to the processor (Figure 4). We reuse the proof-of-concept ADC
that is described in this whitepaper.

Figure 4: Connecting to the proof-of-concept system.

PERFORMING INITIAL SYSTEM SIMULATION

With the actual sensor defined we can perform an initial system simulation. When launching the simulation, S-Edit
creates the complete Verilog-AMS netlist and passes it to T-Spice. T-Spice automatically adds Analog/Digital
connection modules and then partitions the design for simulation. T-Spice simulates the analog (SPICE and
Verilog-A) and sends the RTL to ModelSim for digital simulation. Both simulators are invoked automatically and
during simulation the signal values are passed back and forth between the simulators whenever there is a signal
change at the analog/digital boundary. This means, that regardless of the design implementation language, you
drive the simulation from S-Edit and the design is automatically partitioned across the simulators. Then, you can
interact with the results using the ModelSim and T-Spice waveform viewers. Figure 5 shows the results of the
simulation.

w w w. m e nto r. co m
4
Proof-of-Concept: The Day After

Figure 5: Initial system simulation results.

The initial system simulation results in Figure 5 show:

A. The pressure values of 150k and 300k Pascals from the pressure sensor provides inputs to the system.
B. The ADC computes a digital value corresponding to the pressure inputs using successive approximation.
C. Key digital signals are monitored in relation to the analog simulation.
UPGRADING THE PROCESSOR
The original proof-of-concept design employed the Arm Cortex-M0 processor. But, for the prototype, we decided
to move to the Arm Cortex-M3 processor, mostly because this paves the way for more advanced firmware and an
embedded operating system, such as Mentor’s Nucleus® OS, but also because the Cortex-M3 is now available in
Arm DesignStart™ along with the Cortex-M0. This means that we can develop ICs based on Cortext-M0 or
Cortex-M3 without any upfront license fee. In addition, we can also take advantage of the CodeBench™ software
development solution which supports both processors. We envision complex software development in the future
in support of other revenue models for the pressure monitor system, such as connected services, which will require
an embedded software solution.

The Arm Cortex-M3 DesignStart design kit provides you with a pre-integrated processor subsystem with peripheral
components. You connect the Control Block of the ADC to the AHB2APB interface, which connects to the AHB
interface. Figure 6 shows an example of connecting the pressure sensor via the ADC to the Cortex-M3 processor.
The main system interconnect is compliant with the Arm AMBA® Advanced High-Performance Bus (AHB)
specification and connects the processor to memories and peripheral components attached using the AMBA
Advanced Peripheral Bus (APB) specification.

w w w. m e nto r. co m
5
Proof-of-Concept: The Day After

Figure 6: Connecting to the Cortex-M3 processor.

DEVELOPING THE SOFTWARE

The initial software for the prototype runs on bare metal and it includes the code to periodically covert the sensor
data into fluid level data and to report any significant fluid level change to the monitoring system.

The main body of the software is the function for deriving the constants for the pressure sensor. Figure 7 shows
how these constants were derived (in the commented code) based on fluid physics. We first perform a linear curve
fit using the simulation data for the sensor to determine a slope value (8.8422 * 10 -6) and an intercept value
(0.12820) to calculate a voltage value. The offset and factor constants are calculated and used in the function return
value for the fluid depth:

(analogValue – offset) * factor

The output of the ADC is represented by the pseudo unit of counts. The full range of the ADC is 0 to
(2n-1) where n is the number of bits. So, our 8-bit ADC reads from 0 to 255. For the voltage range of 0 to 2.2V, an
ideal ADC would read 0V as 0 counts and 2.2V as 255 counts, with voltages in between placed in equal bins of size
(2.2V/256) = 8.5mV.

w w w. m e nto r. co m
6
Proof-of-Concept: The Day After

Figure 7: Function to calculate fluid depth.

The next section of code ensures that the processor stays asleep until an interrupt timer wakes up the processor to
periodically measure the fluid depth (Figure 8). This keeps power consumption to a minimum.

Figure 8: Using an interrupt timer to control sleep and awake times.

The system interrupt handler function (Figure 9) reads the voltage from the ADC, calls the function to calculate
fluid depth (as defined in Figure 7) then decides if the fluid level has changed by 500 mm or more. If it has, an alert
message is sent out to the monitoring system. The fluid level value is stored and used for comparison during the
next wake-up interrupt.

w w w. m e nto r. co m
7
Proof-of-Concept: The Day After

Figure 9: Checking fluid depth changes and reporting.

PERFORMING ACTUAL SYSTEM SIMULATION

Now that the software is ready, it is compiled and simulated to perform the actual system simulation. Because we
already verified the pressure sensor, and we want to significantly save simulation time, we use a stand-in Verilog
behavioral model (Figure 10) of the sensor that samples data using discrete simulation time steps instead of
continuous analog sampling.

Figure 10: Stand-in simulation model for the pressure sensor.

You can see that the same, real number constants are used to calculate the output voltage (vout) as those used in
the software. This model closely matches the analog sensor behavior, but samples the data every 1us for fast
simulation and it simulates a 1 percent leak every 10 us. Figure 15 shows the system simulation results. In the
transcript (A), you can see the liquid level change warning and the waveforms show the liquid level and pressure

w w w. m e nto r. co m
8
Proof-of-Concept: The Day After

sensor values corresponding to the leak (B). The system spends most of the simulation time asleep, waking up to
take pressure readings periodically (C).

Figure 15: System simulation results.

NEXT STEPS
With a successful prototype in hand, the next step is to add a communication block and a device ID to the design
in order to connect to the Internet. In addition, developing sophisticated software for the system and for the Web
opens the doors to many possibilities, including potentially: two-way communication (directing the system to act),
over-the-air software updates, preventative maintenance, and Cloud services. We also might move forward with
implementing the temperature sensor. Look for future whitepapers on developing, implementing, and verifying
this IoT system.

To learn more about the Tanner solution, view this website. To find out more about Arm DesignStart, view this
website.

For the latest product information, call us or visit: w w w . m e n t o r . c o m

©2018 Mentor Graphics Corporation, all rights reserved. This document contains information that is proprietary to Mentor Graphics Corporation and may
be duplicated in whole or in part by the original recipient for internal business purposes only, provided that this entire notice appears in all copies.
In accepting this document, the recipient agrees to make every reasonable effort to prevent unauthorized use of this information. All trademarks
mentioned in this document are the trademarks of their respective owners.

TFD 6-18 TECH17150-w