This “Product How-To” article focuses how to use a certain product in an embedded system and is written by a company representative.
Custom integrated SoC designs are a great way to replace multiple individual ICs and support circuitry (as well as PCB space and traces). The benefits are many: you save space, power and money. However, there is a challenge to overcome. Traditional (non-SoC) designs can be tested, probed and monitored during the design cycle with little advanced planning.
Even when a circuit board does not have a required test point exposed, almost any technician can solder a test lead where needed. This is not the case once a design is captured into a highly integrated SoC. Debug and optimization late in the game can be extremely painful unless you have a strategy and built-in support.
Chipmakers have faced this problem for a long time, and we can take a page out of their playbook when we design our own custom IC. Typically, one of three methods is used: built-in test support vectors, a built-in command-driven supervisor or a background debugger.
The problem in using built-in test vectors is the design of suitable vectors. You need to be very familiar with the expected behavior in order to define the vectors, so this approach is better for lowlevel testing of functions, rather than whole-system optimization.
Using a built-in command driven supervisor is better for SoC because it supports ad-hoc testing and debugging, which means you don't need to know exactly what you are looking for before you begin. The downside of a built-in command-driven supervisor approach is that the debugging is intrusive, thus you are not getting real-world, real time behavior.
The simplest approach, using a background debugger, also looks like the best approach. You get to run, debug and optimize your design, and you can perform your tuning in an ad-hoc fashion, changing the method as you learn. The rest of this article explores the use of a specialized background debugger, which is referred to as a tuner, aimed at optimization of the SoC.
The system example is a capacitive touch-sensing SoC. For the hardware, a Cypress CY8C21434 device is used. This SoC device has capacitive sensing, I2C communications, general-purpose I/O, and an 8bit microcontroller with flash memory and SRAM.
The system consists of a single capacitive button, a 16-segment capacitive linear slider (diplexed so that a single pin is connected to two different segments) and a 400kHz I2C slave interface to communicate the results. This interface will also serve as the transport layer for the tuner .
The tuner consists of an I2C slave communications module that has access to a set of dualmapped SRAM registers and flash constants. The I2C slave interface provides access to an I2C master device only those values designated to be accessible.
Specifically, the I2C slave can only read from the designated SRAM registers, and it uses a standard register-based sub-addressing access scheme for SRAM (the I2C master writes first a byte to the slave to set the offset pointer and then reads back one or more bytes beginning at the register indicated by the offset pointer).
For the flash constants, the I2C slave interface has additional commands to access the flash constants, copy the constants to SRAM and write the constants from SRAM to flash. While the constants are in SRAM, they are treated as SRAM registers with a similar register-based sub-addressing scheme.
The values in the SRAM registers are the dynamic values of our system, both the “results” like slider position and button status, and the lower-level values that help our system determine when a button is pressed or which slider segments are being pressed.
By making all dynamic values available and readable from the outside, we can design an external tuner that can visualize the system and provide a window into what is really going on. Alternatively, any standard I2C master can read these registers and log the data for analysis.
The constants, on the other hand, are properties that control how the system will behave. For instance, “FingerThreshold” is the value that controls the level at which a capacitance or finger touch is strong enough to trigger a button-pressed detection.
Once we put our SoC into hardware, by monitoring the dynamic values, we can watch the system perform and adjust the constant properties until the system, our real system, is performing optimally.
We now have our completed SoC; we have a built-in tuner, we have exposed the dynamic values for read access (protecting our system from outside disturbance), and we have exposed the behavioral property constants with a protocol for accessing and updating the properties.
While we have not gone into the details of our protocol, it is worth mentioning that it contains a non-trivial key and specific coded command tokens to prevent inadvertent or spurious updates from outside. A review of the tuning session lets us see the real value of building the tuner into our SOC.
|Figure 1: The CapSense button-tuning GUI is a built-in feature of the Cypress development tool called PSoC Designer.|
Figure 1a above shows the CapSense button-tuning GUI, a built-in feature of the Cypress development tool called PSoC Designer, which uses an in-expensive USB-to-I2C master interface board to communicate with an SoC design.
In the upper-left of the tuning window is a block labeled “Button Properties” that contains the four button-specific properties from the constants table. Below this is the “Global Properties” block that contains properties shared by all capacitive functions. Each property has a pull-down and/or entry box where the value can be changed. The last block is the “Variable Watch” that contains the four dynamic values, updated in real-time, from the SRAM registers that are associated with the capacitive button.
Figure 1a shows the bare PCB with a business card and all other properties left in their default state. When we start adjusting properties and applying them to the system, the tuning GUI will display the results visually and numerically.
In Figure 1b, the property “Ref Value” has been increased from 4 to 6, reducing the sensitivity of the button and with the same finger touch as Figure 1a, the signal level is much lower – below the finger threshold. Based upon how sensitive we wanted the button in our system, we could set Ref Value and quickly verify how the hardware operates. Other properties can likewise be explored and adjusted in real-time using this button tuning GUI.
|Figure 2: Shown is the tuning GUI for the slider, a 16-segment capacitive linear slider that uses diplexing.|
From the sample tuning session, the tuner coupled with a visualization GUI on a PC has enabled us to quickly evaluate and optimize the performance of the capacitive button in our system on real hardware. The beauty of a visual tuning GUI is that you can present the available data differently for different applications.
Figure 2 above shows the tuning GUI for the slider, a 16-segment capacitive linear slider that uses diplexing, a scheme that connects two segments to the same pins in different order. For a slider with diplexing, good signal levels, not too high nor too low, is essential to determine the true finger position, distinguishing it from the diplexed signals spread around the other half of the slider.
Just because you have integrated a lot of circuitry into a single SoC, hiding all possibility of probing intermediate signals, you do not have to fly blind.
By inserting a tuner (including the necessary protections to prevent inadvertent or malicious access to sensitive values) and using tuning and visualization tools, you can effectively debug and optimize even the most integrated device. However, the key is planning. Design in a tuner from the start for a smooth finish.
Jon Pearson is Development Tools Marketing Director at A href=”http://www.cypress.com”>Cypress Semiconductor Corp.