Month: December 2017

Electronics 101: Standard Resistor Values

When we learn the theory behind electronic circuits we often calculate the exact value a certain resistor, capacitor or inductance should have.

However, in reality there is no 23.94 Ohms resistor available as standard off-the-shelf (SOTS) electronic part. Go and check it if you don’t believe me.

In reality only a selected range of resistor values is available. The specific resistor values are standardized in the EIA “E range” of standards, with EIA E12 and EIA E24 being the most common. This way manufacturers only need to produce and store a limited variety of different resistors and consumers can rely on the fact that resistors of different manufacturers are interchangeable.

The following graphic shows the values and color codings for the E24 series. The E12-series is obtained by skipping even row numbers. Knowing the common resistor values can help a lot when trying to decode the colored stripes on a resistor 🙂


As an example, for the E12 set of resistor values every decade of resistance values is divided into 12 equal parts. This is done in a way that each part is equally spaced on a logarithmic scale, i.e. R_i = round(10 * 10^(i/12)) for i = 1..12. So for the range from 10 Ω to 100 Ω the resistor values become 10, 12, 15, 18, 22, 27, 33, 39, 47, 56, 68, 82, 100 Ω.

It works analogous for the other E-series. The higher the number of the E-series the more divisions per decade exist and thus the precision of the resistors values increases. The typical tolerances for the E12 series resistor values are 10%, for the E24 series it’s 5% and for the E96 series tolerances are down to 1%.

That’s the basic idea behind standard resistor series. In practice some deviations may occur, e.g. it is not uncommon to find resistors of the E24 series offered at 1% tolerance.



The Latest and Greatest vs. Outdated But Robust and Reliable

There are often multiple choices when we are looking for a software tool to do <something&gt;. Some of the possible softwares may be quite archaic, have been around for decades and were used for many different tasks and in many projects throughout their lifetime. Others may be the latest newcomers, have not even hit version 1.0 yet, are built on top of brand new frameworks, libraries and APIs, and come with a modern look-and-feel.

Of course we always want the latest features which make our lives easier and our coding more productive.

On the other hand our code should remain portable among tool chains and vendors, so we are able to migrate easily (many reasons for why this could become necessary).

Following the first guideline will always restrict us to the minimum feature set offered by all vendors in question. Even if some vendors already support a certain feature it can not be used for compatibility reasons if another vendor does not support it yet. That’s because doing so could prevent migration to this vendor at a later point. Hoping that by then this feature will be supported everywhere is not an viable option.

In practice the decision is mostly made on a case-by-case basis, considering the value of a new feature against the danger of portability issues.


A Git Branching Model

An interesting read about a Git branching model. Not really a novel approach, however still a nice summary on how to use git in the 21st century. Does not point out how to avoid common pitfalls and misses to give some reasoning on why things should be done the way they are shown. Does include a link to a comparison between Git and SVN.

Differences in the Handling of VHDL Code between Vivado and ISE

Today I did play around with Xilinx Vivado a little, take a look at an example project, look at the synthesis and implementation options (not much new) &cetera.
The last couple of years I have been exclusively working with Xilinx ISE 14.4, mostly avoiding the Project Navigator, but instead using the command line tools like xst, ngdbuild, par, trce and so on directly (from a Makefile). To get some feeling for what awaits me when migrating an existing VHDL project from ISE to Vivado I did create a new Vivado project and imported the code of an existing VHDL project. While doing this I stumbled over a few things that Vivado handles more correctly and a few other things which Vivado, for unknown reasons, does no longer handle as well as ISE (or fails to handle at all).
I am comparing ISE 14.4 against Vivado 2015.3 here!

+1 Vivado correctly complains about a subprogram definition inside a package declaration. ISE did just swallow this piece of code, which isn’t really evil (some people may feel it is comfortable), but not according to standard.

-1 Vivado refuses to synthesize code, which worked fine in ISE, claiming it “does not match the code template” for XYZ. In my case the error popped up for an inferred BRAM.

-1 Vivado refuses to synthesize code which writes to a text file, even if all text IO is masked out by a generic (which turns off all text output). ISE has no problem with this.

+-1 Vivado no longer accepts VHDL expressions in port assignment lists. Despite Vivado handling this according to the standard I do not feel very comfortable with this change. E.g. a lot of existing code uses a simple expression to invert reset polarity in a port assignment list like rstn_i =&gt; not rstp.

-1 Vivado will expect files used in read or write operations to actually exist, even if you never actually read from or write to them. In ISE this was not an issue, the file existence was only checked at run time.

Update 2018-01-31 (Vivado 2017.4 was used):

-1 Vivado type inference is not as “flexible” as in ISE. Assume that GTP_ENABLE is a generic of type std_logic_vector, then the following was possible in ISE: GTP_ENABLE =&gt; “0”. In Vivado this causes an error (“N visible types match here…“), assuming the standard libraries ieee.std_logic_1164 and ieee.numeric_std are imported (since that’s where those conflicting types come from I assume). Vivado requires explicit type markers: GTP_ENABLE =&gt; std_logic_vector'(“0”). This is a difference which can cause a lot of code changes when migrating from ISE to Vivado.

+-1 Vivado is strict when it comes to port association order. When doing sliced/partial port association all associations for a port must appear in contiguous order, otherwise Vivado will complain “Formal port association for ‘rxclk_i’ is non contiguous“.
To clearify this consider the following example:

port map ( …
rxclk_i(0) =&gt; fooclk,
rx_i(7 downto 0) =&gt; foo,
rxclk_i(1) =&gt; barclk,
rx_i(15 downto 8) =&gt; bar,
… );

The above is not accepted by Vivado. The port association for rxclk_i and rx_i is not contiguous.
The following port associations are contiguous and won’t trigger an error in Vivado.

port map ( …
rxclk_i(0) =&gt; fooclk,
rxclk_i(1) =&gt; barclk,w
rx_i(7 downto 0) =&gt; foo,
rx_i(15 downto 8) =&gt; bar,
… );

Note that this is a VHDL LRM restriction and not specific to Vivado (see stackoverflow). I mention it at this point because ISE is more relaxed about this and does accept non contiguous port association. I see no reason why this should not be allowed, maybe it will become valid in a future VHDL LRM release.


Semantic Versioning

A nice read about Semantic Versioning.