VCS Mix Language Simulation and Coverage Enable

As usual I am putting mixed unstructured infromation on yet another tool, this time it is VCS.
I believe that it will provide a lot of practical information for users than the user guides or any other tutorial
provides. Any questions, please write to me at avimit at yahoo dat com.

VCS is 3 step process
1. Analyze (vhdlan vlogan) This command complies the given code and checks for syntax errors.
2. Elaborate ( vcs or or or )
3. Simulate ( simv )

While using VHDL design files, a simulaiton file 'synopsys_sim.setup' is usually defined, which defines
the compiled vhdl library.
Example 'synopsys_sim.setup' file:
------------
WORK > DEFAULT
DEFAULT : ./work
memlib : ./mem_lib
xm_bus_lib : ./xm_bus_lib
---------------------------------
The first line maps the WORK library to a name 'DEFAULT', and the second line maps the 'DEFAULT' library
to a physcial directory called './work'.
The second line defines a library memlib which is mapped to a physcial directory called 'mem_lib'.

In the absence of any 'synopsys_sim.setup' file in your working directory, vcs will look for the same file in your home directory,
and if there is no 'synopsys_sim.setup' in your home directory, it will look for the same file in the tool installation directory.
The default 'synopsys_sim.setup' is in the tool installation directory, which maps the default work directory to '.'.
You will see complied VHDL files in '.' in case you dont have a 'synopsys_sim.setup' file.

Example vhdlan commands:

vhdlan -w memlib../../pid_filter/rtl/fun_pkg.vhdl
vhdlan -w work ../vhdl/state_machine.vhd
vhdlan ./state_machine_tb.vhd

Example elaboration commands:
vcs -cm line+cond+fsm+tgl+path pid_filter_tb
This steps generates an executable file which is named simv by default. This name can be changed.

Example simulaiton commands:
simv -ucli -do file.cmds
Contents of a simple file.cmds
---------------
run 1 ms
exit
------------------------------------
simv -gui
simv -cm line+cond+fsm+tgl+path -gui
simv -g generics_file

contents of 'generic_file'
----------------
assign 1 /TOP/LEN
assign "OK.dat" /TOP/G1/vhdl1/FILE_NAME
assign (4 ns) /TOP/G1/VHDL1/delay
assign 16 /TOP/width
assign 4 /TOP/add_width
------------------------------------------

VCS can be a 2 step process if only verilog is being used
vcs [compile options]

Generating Makefile:
vcs -lca -makedepends=makefile state_machine_tb
It seems that the same above command is used to generate makefile, and to do an incrimental compliation.
Incremental compliation is enabled by default:

VCS commands
removing like ncrm
updating like ncupdate
hierarchy browsing using commands
dump values in a txt file like ncsim
how to define the hierarchy
forcing nets in simulation, syntax.

LEDA:
Latches, linting, cross clock domain checking. Can write the rule in leda.

setenv VCS_HOME <>
set path = ($VCS_HOME/bin $path)
syschk.sh -v : will tell about environment
vcs -doc
command_name -help

The simulation flow:
synopsys_sim.setup : to map logical and physcial libraries
vlogan
vhdlan
vcs
vsim

setenv SYNOPSYS_SIM_SETUP / : global preference
1 tools setup
2 home
3 current dir
4 $SYNOPSYS_SIM_SETUP

include: not sure.

WORK> logical_name
Example:
WORK > gate_lib
gate_lib : /libs/glib

LIBRARY_SCAN = TRUE | FALSE
ASSERT_IGNORE = NOTE
ASSERT_IGNORE_NOTE
ASSERT_IGNORE_WARNING
ASSERT_IGNORE_ERROR
ASSERT_IGNORE_FAILURE

TIME_RESOLUTION = 10 ps

ASSERT_STOP = NOTE | WARNING | ERROR | FAILURE | NOSTOP

RUNREAD =
run this file automatically when it starts.

show_setup

show_setup -lib

-v means file containing many modules
-y means directories where tech libs are

makedepends

-xlrm
uum : unified use model. $VCS_HOME/doc/uum.pdf

-ucli - Enable Tcl command-line interface
-debug : allows to dump waveforms
-debug_all : line debug
-cm : enable coverage options

vcs -makedepends =
gamke makefile

vcs -cflags "

vcs -hsopt improve gate-level and debug simulation speed

vcs -debug_pp (post processing)
for tcl and gui
use
vcs -debug

checkpointing:

$vcdpluson
$dumpvars

vcs -debug +memcbk to dump say vhdl record types, which are not dumped by default
initial $sdf_annotate(...);
vcs -sdf=[min|typ|max]:instance_name:

-P $VCS_ROOT/include/hdl_xmr.tab for
hdl_xmr instead of init_signal_spy in modelsim

library synopsys;
use synopsys.hdl_xmr_pkg.all

above to use the signal_spy kinda thing

ncmirror I guess is an eq in cadence.

add_wave /E/UUT/T_BLOCK/HRS_OUT
scope /E/UUT/A_BLOCK
add_wave RESET : will add a wave from A_BLOCK as the scope has been set

-gv -Override run time VHDL generics
-do instead of -i : because gives more than -i
-i

-gv can also be used with vcs -gv, which will help in changing all generics instead of limited as in vsim -gv

Recommendation: Always analyze verilog first

vcs -cm line : enable line coverage

IF it crashes, to clean up do the following:
rm -rf physcial_lib_dirs/*, simv*, csrc*
OPTIMISE = FALSE -- In synopsys_sim.setup

vcs -gui -debug : only show if compilation is successfull
vcs -debug_pp
vcs -debug_all
vcs -debug=1|2|3|4(level of debug)

simv -gui : preferred way of doing it. I.E first create a executable.

vcs -assert dve -Enable assertion debug
dve -vpd

run -posedge my_sig

restart

help -ucli
help -gui

alias

dump -file -type VPD
dump -add /tb
dump -add -depth
dump
dump -fid -VPD0 -add * -depth 0

fid is a file identifier returned by command dump -file -type VPD
add '-aggregates' in the dump command for dumping multi dim arrays

vpd2vcd +morevhdl
+morevhdl will dump 'records' type as well.

//VCS coverage off
//VCS coverage on

vcs -cm
simv -cm

urg : unified report generator
urg -dir ./simv.cm -grade -report ./reports

-------------------------------------
VCS libraries for VHDL compilation
-------------------------------------

VHDL files are compiled into a library.
Usually the default library is 'work' which is mapped to your current working directory i.e "."

Usually you will see that this 'work' library path is changed by defining the work library in synopsys_sim.setup file

WORK > DEFAULT
DEFAULT : ./work_lib

Then other libs may be defined in the same file i.e synopsys_sim.setup file:

memlib : ./memlib
pkg_lib : ./allcompiledpkgs
xm_bus_lib : ./xm_bus_lib

Further observation about vhdl library and vhdl compliation:

vhdlan -work work fun_pkg.vhdl
OR
vhdlan fun_pkg.vhdl

which means that 'fun_pkg.vhdl' is complied into work_lib
when you see the contents of work_lib you will see files FUN_PKG.sim FUN_PKG__.sim

Now I have another file called
xmbus_master.vhd which intends to use 'fun_pkg' package from the work lib
i.e the xmbus_master.vhd has the following lines

use work.fun_pkg.all

now if I compile the xmbus_master.vhd like this

vhdlan -w xm_bus_lib xmbus_master.vhd

I would expect that the complier picks up fun_pkg from work_lib. But it DOESNOT!

Which emplies that 'work' in the statemetn use work.fun_pkg.all refers to the library xm_bus_lib, to which xmbus_master.vhd is being complied into.

On the other hand if I do the following

vhdlan -w memlib fun_pkg.vhdl

Then I use the following lines in xmbus_master.vhd

library memlib;
use memlib.fun_pkg.all;

then I compile xmbus_master.vhd like

vhdlan -w xm_bus_lib xmbus_master.vhd

Then things are FINE, this time the complier picks up complied 'fun_pkg' from the memlib.

So the conclusion is:

when using 'use work.abcd.all', 'work' refers to the current compliation lib given with -w option while compliling the file
containing 'use work.abcd.all' , and NOT to the 'work_lib' which is the default compliation lib

IMP CMDS:

show_setup -lib
show_setup

llib

llib -l pidf
It will show the source file, dependency files

vhdlan options:

-q : quite
-nc : supress the copyright message
-l : log file

VCS OPTIONS:

vcs -debug_all : to enable force/line debug etc.

vcs -o gives named output executable

VCS/Synopsys Code Coverage:

3 Step Process: (after vhdlan or vlogan)
Step 1: Include -cm option during vcs: This step makes sure that the selected code is complied for selected type of coverage
Example:
vcs -cm line+cond+fsm+tgl+path pid_filter_tb
OR
vcs -cm_tgl mda -lca -cm line+cond+fsm+tgl+path -debug_all pidf_tb
OR
vcs -lca -cm line+cond+fsm+tgl+path -debug pidf_tb -cm_tgl mda -cm_hier cm_hier.file

Step 2: Include -cm option during simulation: This Step makes sures that simulator doesnot forget to collect coverage data during simulaiton
Example:
simv -cm line+cond+fsm+tgl+path -gui

Step 3: cmView : for gui based analysis : This Step will let you see coverage results in a GUI
Example:
cmView

Step 3: vcs -cm_pp : for batch mode post processing. This step outputs report files
Example:
vcs -cm_pp -cm_report summary
This will generate human viewable reports in the simv.cm/reports directory.
it also writes a summary file in the same directory, named 'cmView.summary'

vcs -cm line|cond|fsm|tgl|path|branch|assert

Example command
vcs -cm line+cond pid_filter_tb

vcs -cm line+cond+fsm+tgl+path pid_filter_tb

adding -path gives an Error to avoid it use -lca

vcs -lca -cm path pid_filter_tb

And dont forget the -debug, in case you want to see anything : ).

vcs -lca -debug_all -cm line+cond+fsm+tgl+path pid_filter_tb

Still I have to face problems, so the final command line looked like:

vcs -cm_tgl mda -lca -cm line+cond+fsm+tgl+path -debug_all pidf_tb

Now simulaiton may be launched, again all the coverage options given at the 'vcs' compilation
MUST be given to the simv as well or there will be NO coverage recorded.
But then you cant use '-cm_tgl mda'. You see dont apply your common sense, or nothing will work.
After all vcs is developed by Synopsys not Google.

simv -cm line+cond+fsm+tgl+path -gui

NOTES:

-cm option creates simv.cm directory

During Simulation following files are produced:
test.line and test.fsm etc.. depending upon the coverage option.

To over ride the default 'test' name you can use
vcs source.v -cm line -cm_name test1
vcs source.v -cm line -cm_name test2 ...etc
OR
simv -cm line -cm_name test2
simv -cm line -cm_name test3 etc...

Also, during simulation, VCS and VCS MX write the cm.decl_info file
in either the simv.cm/db/verilog directory (for Verilog) or the simv.cm/
db/vhdl directory (for VHDL). cmView needs this file to show
coverage information.

If you invoke your binary executable from a different location, then
use -cm_dir option at runtime to specify the the path for the
coverage database directory

By default VCS does not compile the following for coverage:
• The source code in Verilog library directories
• Verilog library files
• Any module defined under the celldefine compiler directive

yv
For compiling for coverage source code from Verilog libraries.
celldefine
For compiling for coverage modules defined under the

vcs source.v -v mylib.v -y /net/libs/teamlib -cm fsm -cm_libs yv+celldefine

To prevent this lowering of coverage percentages, use the
-cm_noconst compile-time option
Constant filtering for toggle coverage is available only for
Verilog-only designs

simv -cm fsm -cm_log run1.log

Hierarcy in the design, and inclusion/exclusion of modules/files/instances.
-tree instance_name [level_number]
A level number of 0 (or no level number) specifies the entire
subhierarchy, 1 specifies only this instance, 2 specifies this
instance and those instances directly under this instance, and so
on

vcs -lca -cm line+cond+fsm+tgl+path -debug pidf_tb -cm_tgl mda -cm_hier cm_hier.file

cm_hire.file contents
begin
line+cond+fsm+tgl+path -file ../../pid_filter/rtl/fun_pkg.vhdl
end
begin
line+cond+fsm+tgl+path -tree STATE_MACHINE_TB 1
end

Interesting observation
If I miss (all) coverage options on the command line, with this file its an error
If I miss (all) coverage options in the cm_hier.file, its an error.

Various hit and trials:
Works
vcs -lca -cm line+cond+fsm+tgl+path -debug pidf_tb -cm_tgl mda -cm_hier cm_hier.file
simv -cm line+cond+fsm+tgl+path -gui
cm_hier file is:
begin
line+cond+fsm+tgl+path -module pidf
//The above line means exclude line, cond, fsm, tgl, path coverage from module pidf
end

Another example which worked
begin
cond+tgl+path -module pidf
end

I intended to exclude cond+tgl+path, and include the fsm coverage.
The above does write the fsm coverage, since fsm is not excluded from the list inside the cm_hier.file
NOTE: line coverage is always opened for modules or instances that have cond/path/fsm/branch coverage ON.

After several unsuccessfull runs to use '-tree' options, I concluded that it is 'case sensitive', even though i have a VHDL design,
and in my vhdl design pidf_tb, and pidf_u1 are lower case.
For some reason I am required to put the instance name in upper case
Following works
begin
fsm+line -tree PIDF_TB.PIDF_U1
end
BUT the following DoestNOT work.
begin
fsm+line -tree pidf_tb.pidf_u1
end

Now my objective is only to remove the top level testbench from coverage collection. For this I will have to use [level number]
begin
line+cond+fsm+tgl+path -tree PIDF_TB 1
//using level number 1 will make sure only the testbench level is excluded from the coverage collection
end

If I dont use the [level number] in front of PIDF_TB, then by default all scopes under PIDF_TB will be excluded from coverage
This is the same as using level number 0.

PROBLEM: while trying to use the -file option
------------------------
Warning-[VCM-HFUFR] Hier Config: regions not found
In the hier config file ( given by -cm_hier option ), pattern "-file or
specified by -filelist ---
/projects/leota/amittal/block_design_flow_dev/pid_filter/rtl/pidf.vhd" did
not match any pattern.
Please check the hier config file "cm_hier.file".

Warning-[VCM-HFNM] Hier Config: No pattern match
None of the patterns in the hier config file ( given by -cm_hier option )
matched any pattern.
Please check the hier config file "cm_hier.file".
----------------------------------------------------------------------

I have been trying to use -file option and above is the warning message. The corresponding cm_hier.file is
Note that I have used full path for the file I wanted to exclude. This doesNOT work.
---------------
begin
line+cond+fsm+tgl+path -file /projects/leota/amittal/block_design_flow_dev/pid_filter/rtl/pidf.vhd
end
--------------------------------

Now if I use relative path, then vcs does not complain about the file and things go on fine: The corresponding cm_hier.file is
This Does Work.
-------------
begin
line+cond+fsm+tgl+path -file ../rtl/pidf.vhd
end
----------------------------

The HDL Compiler and Behavioral Compiler user can use the
//synopsys translate_off directive in place of the //VCS
coverage off pragma and the
//synopsys translate_on directive in place of the //VCS
coverage on pragma.
The //VCS coverage on pragma enables line coverage after a
//synopsys translate_off directive and a
//synopsys translate_off directive disables line coverage
after a //VCS coverage on pragma.
Similarly the //VCS coverage off pragma disables line coverage
after a //synopsys translate_on directive and a
//synopsys translate_on directive enables line coverage after
a //VCS coverage off pragma.

Pragmas do not exclude module instances. For example:
module test;
reg clk, a;
// Synopsys translate_off
mod1 inst1(a,clk);
// Synopsys translate_on
.
.
.
endmodule
This example does not exclude test.inst1 from coverage

--synopsys coverage_off or --VCS Cover off
--synopsys coverage_on or --VCS Cover on
--vhdlcoveroff
--vhdlcoveron

Glitch supression.
To prevent this, there is the -cm_glitch compile-time option. Its
syntax is as follows:
vcs -cm line+cond+tgl -cm_glitch period

The -cm_glitch option is also a runtime option, but it only works
for toggle coverage

Collecting an Execution Count
-cm_count compile-time option

Post Processing:
vcs -cm_pp -cm_report summary
The above command is used to post process the results of Code Coverage generated during simulaion.
This command produces results in simv.cm/reports directory.

Some more imp commands:
vcs -cm_pp -cm line+cond -cm_report testlists

NOTE:
The graphical user interface (GUI) for cmView does not display
path coverage information. You must have cmView write path
coverage reports

VCS and VCS MX do not monitor the if statement in the for loop
statement and the if statement in the user-defined task

Branch coverage is implemented for Verilog simulation only :(

NOTE:
By default VCS and VCS MX do not monitor for branch coverage if
and case statements and uses of the ternary operator (?:) if they
are in user-defined tasks or functions or in code that executes as a
result of a for loop. You can, however, enable branch coverage in
this code. See “For Loops and User-Defined Tasks and Functions”
on page 4

Assignment Coverage
-cm_line assigntgl compile-time option and keyword argument.
Note:
This is a Verilog-only feature. There is no similar report for VHDL

Glitch suppression does not work for VHDL code

Gamma Correction: what to know, and why it’s as important as ever

Mike Ogier, Intersil Corporation

10/31/2010 5:33 PM EDT

Rapid growth in the active matrix, thin-film transistor liquid-crystal display (TFT-LCD) market has redefined how many people live, work, and recreate. From High Definition (HD) televisions, to desktop and laptop computers, to smart phones, and automotive infotainment, the TFT-LCD in some form or another has become rather ubiquitous.

Although "gamma" itself is not generally used by TV makers as a selling feature, the term has been around since the days of cathode ray tube (CRT) TVs and is still an important behind-the-scenes characteristic of current TFT-LCDs.

When talking about modern LCD TVs, gamma has taken a slightly new definition. Every LCD TV maker must at some point in the development process pay attention to gamma. If not, then they could have the absolute best panel technology in the world, but no one would buy their panel because it would recreate images incorrectly. Where, “incorrectly” means that the color representation and luminance intensity would be far from what it should be to accurately reproduce/recreate the intended source image.

So what is this mysterious so called “gamma” in TVs? It’s not same thing as high energy “gamma radiation” many may associate with radioactive decay. First, we'll have a brief discussion about what gamma means in a CRT TV system. Then we'll have a discussion about how that translates to TFT-LCD TV systems, and why the average consumer should or would care about it.

Gamma and CRT TVs

CRT TVs operate by using an electron beam to excite phosphors on the screen. An image can be “painted” on the screen by scanning the electron beam accordingly, and exciting these phosphors. The relationship between the control voltage applied to the electron gun and the resulting light intensity on the screen is inherently non-linear. It can be approximated in first order by a power law equation (in the form of Y(x)=x ^a), and this is known as the gamma response of the CRT.

The human eye naturally has a non-linear sensitivity to luminance intensity (perceived brightness), which is referred to as “lightness”. The eye is most sensitive to changes at lower gray scale (darker) levels. It just so happens that the natural response of the eye is very close to being the inverse of the inherent response of the CRT. This is an unintended, but extremely useful, side effect, which allows for a single correction to be performed on source data to compensate for system nonlinearity and to create the perception of uniform luminance changes to the eye.

Source data must be encoded in a way that accounts for the CRT response and the known lightness response of the eye. Gamma correction is performed by the camera on the red, green, and blue color components (RGB) of a video signal. Simply, video needs to be encoded in such a way that the camera system reacts to luminance changes similarly to how the human eye does. Since the CRT has an inverse response to this, then the resulting luminance intensity will be perceptually linear. Gamma correction also has benefits such as reducing video signal noise and increasing effective resolution at low levels (both of which relate to creating uniformity).

In the power law equation, for a given system, the light intensity is (simply) equal to the applied electron gun voltage raised to some power. This power is the gamma coefficient (γ), and the formula approximately defines the overall transfer function of the CRT. In general, a typical CRT gamma would be about 2.2 to 2.5. Higher-number gamma coefficients tend to yield more image contrast but increase the amount of darkened area (due to an increase in resolution at low levels). Lower-number gamma coefficients tend to wash out or flatten the image (due to a decrease in resolution at low levels).

A system with a gamma response of 1.0 is considered to be linear and is not good for various reasons. The most critical is that it doesn’t reproduce gamma-corrected images with perceptually correct color and contrast.

In summary, gamma correction is needed compensate for the system gamma response and ensure that (at least approximately) the intensity of what goes into the camera is the same as what comes out of the CRT TV, thus yielding correct image representation to the eye, Figure 1.

Figure 1: Basic gamma correction and gamma response curves

Gamma and TFT-LCD TVs

The TFT-LCD has very little in common with a CRT, except that fact that they both can display video images. Most notably, an LCD does not have an electron gun and phosphors to generate intensity. Instead it uses voltage-controlled pixels to control the transmittance of light through the pixel. The light in sourced from a backlight, which is generally a cold cathode fluorescent lamp (CCFL) or light emitting diode (LED) array. In short, there is a voltage-transmission (V/T) curve that defines the panel’s response to an input and thus its luminance intensity.

Though not the same as a CRT, the TFT-LCD does have “gamma,” however, the term must be slightly redefined. In order for an LCD to illuminate a pixel, the liquid crystal (LC) pixel cell needs to have a voltage applied across it, thus allowing it to transmit light which is then perceived as brightness on the screen (note that the “light source” is the LCD panel’s backlight, which is generally CCFL or LED).

The analog voltage applied to a pixel is determined by a digital/analog converter, where the digital code is generated based on the incoming source image/video data (when talking about TV video content, historically it is gamma encoded from the days of CRT TV). The relationship between applied voltage and transmittance (the V/T transfer function) is the gamma response of the TFT-LCD and is inherently non-linear due to the nature of the transmittance capability of LC cell. Although, this response is not necessarily the desired non-linear response like we saw in the CRT TV.

Thus, LCD TV gamma is often desired to closely simulate the gamma response of a CRT. This is for a few main reasons: first is historical, since all legacy video has been gamma corrected for CRTs, and second is to take advantage of the natural response of the human eye (lightness). Of course, not all LCDs have the same inherent gamma response, which can vary by panel technology and manufacturer. A panel’s gamma response may be altered by the manufacturer, whom may choose to force a particular gamma response based on desired visual performance of the end system, Figure 2.

Figure 2: Various system gamma response curves

Digital video data (often in the form of LVDS) must be converted using a digital-to-analog converter (DAC) to generate an analog voltage for the pixel. Gamma is roughly corrected (intentionally made non-linear) by the use of piecewise non-linear DACs in the panel’s source/column drivers. The source driver DACs determine how many different voltage steps can be applied to the pixels (e.g. an 8-bit DAC yields 2⁸ or 256 steps of possible grayscale). The perception of changes in gray scale intensity caused by each voltage step is relative to the panel’s gamma response (V/T curve) and the response of the eye, Figure 3.

If luminance changes were simply allowed to be linear with code changes then a system would require many more bits of resolution (e.g. 12-bits or 14-bits instead of 8-bits) to achieve the sensitivity at low levels needed for the eye to not perceive changes from code to code differently (to keep changes uniform) across the entire range. This is, in fact, another advantage of using gamma correction. It allows a lower number of bits to be used to encode the video data in a form that “compresses” low level luminance data (most noticeable to the eye) while not affecting high level luminance data where small changes are not as distinguishable. This can also be viewed as a way to reduce noise in the video signal, such that potential small errors in the digital code are not as recognizable.

Figure 3: Changes in relative intensity compared to gamma response

To change the panel’s gamma response to a desired V/T transfer function, the panel’s source (column) driver DACs may use various reference voltages applied at multiple tap points. These voltages force the DAC(s) to have a certain desired non-linear operation. The reference voltages are often supplied by “gamma buffer” integrated circuits (ICs), which are generally buffer amplifiers that drive the analog voltages to the DAC taps. The gamma buffer ICs can be static or programmable.

Some such IC devices are Intersil’s EL5411/20T operational amplifiers, EL5421T buffer, and EL5x26 I²C programmable gamma buffers family. These devices are designed to drive accurate and steady DC reference voltages to a TFT-LCD source driver. For a simplified system block diagram of a TFT-LCD panel, Figure 4.

Figure 4: Simplified TFT-LCD block diagram

With the capability to control the DAC taps, LCD TV makers can fine-tune the voltages to further adjust/calibrate the panel’s non-linear gamma response, this is called gamma calibration. For example, this allows a TV maker to ensure that all their TV’s panels of a certain model exhibit the same gamma response from panel to panel. This means that any potential visual performance variations caused by things such as variances in LCD fabrication and manufacturing can be minimized, and thus the TV maker has a more consistent product. The consumer can then be assured that the TV they purchase and take home will visually perform like the one they saw on the sales floor at the local dealer.

[Often, TVs "on display" in a store will have a special “store” mode activated. This mode is intended to make the display have maximum contrast and extremely saturated colors to attract customers to the vividness of colors and brightness; however the consumer in a home environment would not generally use this setting.]

TV makers ultimately decide how they want to calibrate the gamma response (e.g. γ = 2.2, γ = 2.0, γ = 1.8, or even a combination of gammas such that the gamma changes based on the intended brightness), so that their display has a certain look. It’s noteworthy that gamma characteristics tend to shift with wide viewing angles and different ambient lighting conditions. So, when shopping for a new TV it is always a good idea to compare different TVs under similar conditions for a more apples-to-apples comparison.

Figure 5 compares the same image but with different overall gamma. The differences can be easily discerned by the viewer. The middle image is the nominal (original) gamma (e.g. γ = 2.2) while the top image is less than nominal and the lower is more than nominal. The top looses contrast as the darks disappear, and becomes more “washed out.” The lower image gets more contrast but overall has more darkened area.

Figure 5: Image comparison: shift in overall gamma: top is low gamma; middle is nominal gamma; bottom is high gamma (click on individual images to enlarge each).

Gamma and TV Settings

Historically, CRT TVs (and as much as these names don’t make sense) have a “brightness” control which changes the black level, and a “contrast” or “picture” control that changes the maximum white level. The gamma of the TV defines the response inside these end points. Ideally, these TV settings would be totally independent of gamma, however, once the maximum white level is fixed any changes to the black level effectively moves the gamma curve in the opposite directions (its shape changes).

This means the gamma coefficient has changed and now the system’s gamma response has been affected by a simple change to the black level. In the case of LCDs the end point levels are generally fixed by the source driver but digital adjustments can be made to the signal. Also, LCDs have the ability to have the intensity of the backlight changed, which adds another dimension to the performance of the system.

Some TFT-LCD and digital TVs offer other settings, which can be adjusted via a user control menu. These settings can be things like a “gamma” adjustment (generally not quantified, rather a +/- gamma adjustment), dynamic enhancements for contrast or blacks, different picture/video modes, and other manufacturer named features. These settings can alter some or all of the TV settings including the gamma curve. For example, a gamma that may have been defined by a single coefficient (e.g. γ = 2.2) in normal operation changes into a curve that has properties of multiple gamma coefficients, thus the TV response changes over the range of brightness (codes or voltages of the video signal).

It is also worth noting that ambient lighting from the environment or room can affect the perceived response of a video system. Unfortunately you will never know the exact conditions that were used when video editing was done to your favorite DVD movie or TV show and what the setting on their equipment was, thus it’s hard to set up viewing in your home to yield accurate reproduction. Likely your living room conditions will be very different from a studio and will change constantly.

For example, a dark room can reduce the perceived black level since you now reference it to the pitch-black ambient light (the blacks appear not as dark). Conversely, if you turn the lights on brightly then the ambient light can overpower the luminance of the panel, thus the perception is that the image looses contrast due to the loss of detail at the lower end (dark levels).

Overall, gamma may not be something simple to define, but as a consumer of hi-tech video products, it’s best to try and understand the concept with a system-level or top-down approach. It’s definitely a good thing that when you buy a new LCD TV, you are not required to calibrate the gamma. This would be quite frustrating and impossible for most. The TV manufacturer does the initial tough work by setting the transfer function of the source driver DACs such that the panel has their desired non-linear gamma response.

However, most TVs have a range of user-accessed adjustments, which control--to some extent--the response of the system, although many argue that more gamma-specific user adjustments controls would be valuable. Ultimately, the consumer doesn’t have much direct control of a TV’s gamma, but this tends to be perfectly fine for the average TV viewer.

About the author

Mike Ogier is a senior applications engineer for the Analog and Mixed-Signal Group at Intersil Corporation. He currently supports devices for LCD and video applications and has experience in test also. He earned a BSEE from San Jose State University.

Origianl Article Linke: http://www.eetimes.com/design/analog-design/4210265/Gamma-Correction--what-to-know--and-why-it-s-as-important-as-ever