Tag Archives: Hardware

So We Just Consider the Resistor’s Tolerance Right?


When designing precision electronics or performing a detailed worst-case analysis, one quickly learns to consider parameters that may not be so important in other applications. One of the more interesting things to learn is that the tolerance of a resistor is just the starting point. It does not actually define the maximum or minimum value the resistor could be within your circuit.

The key parameters associated with a resistor are as follows.

Tolerance: This defines how close to the nominal value is allowable for the resistor when it is manufactured. A nominal 1,000Ω resistor with a tolerance of ±5% will have a value ranging between 950 and 1,050Ω. This value will be fixed; the value of the resistor will not vary during its life due to the tolerance. However, the engineer has to consider the tolerance in design calculations and ensure the circuit will function across the entire potential value range.

Temperature coefficient: This describes how the value of the resistor changes as a function of temperature. It is defined as parts per million/Kelvin; common values are 5, 10, 20, and 100 PPM/K. Actually, the best way to think of this is parts per million per ohm/Kelvin. A 1,000Ω resistor with a temperature coefficient of 100 PPM experiencing a ±60K temperature change over the operating temperature range (240-360K, based on an ambient room temperature of 300K) will experience a resistance change of ±6Ω based on its nominal value. Obviously, the lower the temperature coefficient, the more expensive the resistor will be. (This is the same for low-tolerance resistors.)


Resistor self-heating: For really high-precision circuits, it is sometimes necessary to consider the power dissipation within the resistor. The resistor will have a specified thermal resistance from the case to ambient, and this will be specified in °C/W. The engineer will know the power dissipation within the resistor; this can be used to determine the temperature rise and hence the effect on the resistance.
To determine the maximum and minimum resistance applicable to your resistor, you must consider the tolerance, the temperature coefficient, and the self-heating effect. As you perform your analysis, you may notice some of the parameters are negligible and can be discounted, but you have to consider them first to know whether or not you can discount them.

For some precision circuits (gain stages in amplifiers, for example) it may be necessary to match resistors to ensure their values are within a specified tolerance of each other and have the same temperature coefficients.

In certain circuits, it is also important to make sure that critical resistors are positioned correctly to ensure both terminal ends of the resistor are subjected to the same heating or cooling effects. Otherwise, the Seebeck effect may need to be considered. When using forced airflow, for example, it may be necessary to ensure that both resistor terminals are perpendicular to the airflow, so the component is of uniform temperature.


Design Reliability: MTBF Is Just the Beginning Issue 88



When most engineers think about design reliability, their minds turn to a single, central metric: mean time between failures. MTBF is, in fact, an important parameter in assessing how dependable your design will be. But another factor, probability of success, is just as crucial, and you would do well to take note of other considerations as well to ensure an accurate reliability analysis and, ultimately, a reliable solution.

Link here



A Pain-Free Way to Bring Up Your Hardware Design Issue 85



One of the most exciting
moments in an engineering
project is when the
hardware arrives in the lab
for the first time, ready for commissioning
before integration testing. This
stage in the development process typically
can mean long hours and a certain
amount of stress for all the engineers
on the project. But tools and
techniques are available to help ease
the way and move the project along.
Let’s take a look at how we can minimize
any issues that may arise in getting
a design to the next level, and how
to get through the commissioning
phase in a timely manner.

Link here


Nuts and Bolts of Designing an FPGA into Your Hardware Issue 82



To many engineers and project
managers, implementing
the functionality within an
FPGA and achieving timing
closure are the main areas of focus.
However, actually designing the FPGA
onto the printed-circuit board at the
hardware level can provide a number
of interesting challenges that you must
surmount for a successful design.

Link here


Edge Detection on Signals


I was recently looking at some code for a friend who is learning VHDL (no, I am not going to name names as to who it was). Along the way, I came across an interesting mistake that they had made, and I thought this would make an excellent addition to our discussions here on All Programmable Planet.

The essence of the problem was that the coder was attempting to detect rising and falling edges on signals in a synthesisable module. Not unsurprisingly for someone new to VHDL working within a clocked process, they attempted to use the “rising_edge” and “falling_edge” functions to detect edges on the signals of interest. A snapshot of the code I was sent is demonstrated below. (I know there are additional issues with this code, but for the moment we will focus only upon the rising and falling edge usage.)


Those who know VHDL will not be surprised to hear that when this code was synthesized, it didn’t not get very far before failing with the following message:

“Logic for signal is controlled by a clock but does not appear to be a valid sequential description.”

To a beginner this might be a little confusing. Why can’t you use the “rising_edge” and “falling_edge” functions to detect these edges? Actually, things can quickly become even more confusing, because it’s possible to create code that will simulate quite happily, but that will fail to synthesize as expected.

Now, if the sort of code shown above was being employed for something like a testbench (i.e., if you never intended to synthesizis this code), then — with a little tweaking (in the case of the example above) — it would simulate perfectly fine and everyone would be happy.

In fact, this is all tied up with the levels of abstraction that are possible with VHDL. If you create something at too high a level of abstraction, it is possible that your code might simulate and appear to function as desired, thereby giving rise to false confidence that your solution is valid and good progress is being made on the project, only to run into issues downstream. One reason for this is that, depending on your simulation tool settings (see the example shown below), you may fail to receive a warning on how synthesizable/unsynthesizable your code will be.


In the case of our example code, the problem arises when we try and implement this code within an FPGA, because then we are working within the stricter confines of supported synthesizable instructions and templates.

Sadly, the example code presented earlier does fall outside the template recognized by most synthesis tools as a clocked process. This is due to the multiple “rising_edge” and “falling_edge” function calls, which make it impossible for the synthesis tool to determine which calls should clock the register elements and which calls are being used only to detect signal edges and hence are not clocking registers.

To ensure synthesis, your process must contain only one “rising_edge” or “falling_edge” function call as shown in the code below, which implements a simple D-Type register. (Some FPGAs do have flip-flops that support double data rate; i.e., data changing on both the rising and falling edge of the clock, but we will address these in a future column so as to keep things simple here.)


So, how do we detect edges on signals within a design without using the “rising_edge” or “falling_edge” functions? Actually, this is very simple and can be achieved using two registers connected in series, such that one register contains the same signal as the other register, but delayed by one clock cycle. The engineer can then use the values contained within these registers to determine if the signal is indeed rising or falling.

So what does this actually look like in code and when implemented? Well, take a look at the code below along with the corresponding schematic diagram:


Of course, the state of the “det_reg” could also be used in other synchronous processes and compared against a predefined constant to detect if the signal edge was rising or falling. This has the advantage that by simply changing the value of the constant, the type of edge being detected — and hence the action taken — can be changed without the need to modify the code itself.