Verilog-mode

Recent versions allow you to insert AUTOS in non-AUTO designs, so IP interconnect can be easily modified. You can also expand SystemVerilog ".*" port instantiations, to see what ports will be connected by the simulators.

emacs –f verilog-batch-auto {filename.v}
emacs -batch {filename.v} -f verilog-auto -f save-buffer

/*AUTOARG*/ parses the input/output/inout statements.

/*AUTOWIRE*/ takes the outputs  of sub modules and declares wires for them (if needed -- you can declare them yourself).

/*AUTOREG*/ saves having to duplicate reg statements for nets declared as outputs. (If it’s declared as a wire, it will be ignored, of course.)

AUTOINOUTMODULE will copy I/O from another module. AUTOTIEOFF will terminate undriven outputs, and AUTOUNUSED will terminate unused inputs.

/*AUTOINST*/ Look for the submod.v file, read its in/outputs.

Keep signal names consistent!
Note the simplest and most obvious case is to have the signal name on the upper level of hierarchy match the name on the lower level. Try to do this when possible.
Occasionally two designers will interconnect designs with different names. Rather then just connecting 
them up, it’s a 30 second job to use vrename from Verilog-Perl suite to make them consistent.


Method 1: AUTO_TEMPLATE lists 
exceptions for “submod.” The ports need not exist. (This is better if submod occurs many times.)
@ in the template takes the leading digits from the reference.(Or next slide.)
[] takes the bit range for the bus from the referenced module. Generally, always just add [].
Instantiations using RegExps


Method 2: List the signal before the AUTOINST. First put a // Input or // Output comment for AUTOWIRE.


See Cliff Cumming’s Paper
http://www.sunburst-design.com/papers/CummingsSNUG2007Boston_DotStarPorts.pdf


Where to Find Modules
// Local Variables:
// verilog-auto-library-flags:(”–f ../../input.vc”)

// End: 

// input.vc
-y dir1
-y dir2

You may also provide an optional regular expression, in which case only signals matching the regular expression will be included. For example the same expansion will result from only extracting outputs starting with ov:

    /*AUTOOUTPUT("^ov")*/

Techniques to exclude signals from AUTOOUTPUT (or AUTOINPUT etc).
1. Declare “fake” output
2. Use inclusive regexp
3. Set the output ignore regexp




#!/bin/bash

for i in "$@"

do

    xemacs -batch $i -f verilog-batch-auto -f save-buffer

done

예린이 가족 집사기

http://www.dqnews.com/Articles/2014/News/California/Bay-Area/RRBay140313.aspx

pocket !qAz2@3$

jitter concept

Jitter
“The deviation from the ideal timing of an event. … Jitter is composed
of both deterministic and Gaussian (random) content.”
T11.2 / Project 1230/ Rev 10 Fibre Channel - Methodologies for Jitter Specification page 7.

http://cp.literature.agilent.com/litweb/pdf/5989-3206EN.pdf

http://www.usb.org/developers/whitepapers/USB_3_0_Jitter_Budgeting_0p5_whitepaper.pdf

http://class.ee.iastate.edu/mmina/ee418/Notes/Introduction_to_Jitter.pdf

http://www.kenkundert.com/docs/aacd97.pdf

RJ
“Jitter that is characterized by a Gaussian distribution…Random jitter is
unbounded.”
T11.2 / Project 1230/ Rev 10 Fibre Channel - Methodologies for Jitter Specification page 8

Standard deviation (1sigma) is defined as the window in which
contains 68.26% of all [measurements] to one side of the mean.

Standard Deviation is used to predict the occurrence of

outlying measurements from the mean.

RJ = $dist_normal(seed, mean, std)

DJ
“Jitter with non-Gaussian probability density function. Deterministic jitter is always
bounded in amplitude and has specific causes. Four kinds of deterministic jitter are
identified: duty cycle distortion, data dependent, sinusoidal, and uncorrelated (to the
data) bounded. DJ is characterized by its bounded, peak-to-peak value.”
T11.2 / Project 1230/ Rev 10 Fibre Channel - Methodologies for Jitter Specification page 8.

DJ = $dist_uniform(seed, 0, DJmax) - DJmax/2

SJ
SJ = SJ*sin(2*phi*f*t)

ITU-T Definition:
A Measure of the short term time variations of the significant
instances of a digital signal from their ideal positions in time.
• MJSQ Definition:
The deviation of a signal edge time at a defined amplitude of the
signal from a reference time.

Jitter Tolerance
– How much jitter on the input signal can the DUT tolerate
and still produce an acceptable bit error ratio (BER)
– Receiver measurement

There are several ways in which jitter may be measured on
a single waveform. These are period jitter, cycle-cycle jitter, and
time interval error (TIE).

http://www.iml.ece.mcgill.ca/people/professors/zilic/documents/itc07.pdf

make small interpreter language

http://www.python.org/workshops/1998-11/proceedings/papers/aycock-little/aycock-little.html

http://home.adelphi.edu/~siegfried/cs272/272l4.pdf

make tips

VPATH: Search Path for All Prerequisites

The value of the make variable VPATH specifies a list of directories that make should search. Most often, the directories are expected to contain prerequisite files that are not in the current directory; however, make uses VPATH as a search list for both prerequisites and targets of rules.

Thus, if a file that is listed as a target or prerequisite does not exist in the current directory, make searches the directories listed in VPATH for a file with that name. If a file is found in one of them, that file may become the prerequisite (see below). Rules may then specify the names of files in the prerequisite list as if they all existed in the current directory. See Writing Recipes with Directory Search.
In the VPATH variable, directory names are separated by colons or blanks. The order in which directories are listed is the order followed by make in its search. (On MS-DOS and MS-Windows, semi-colons are used as separators of directory names in VPATH, since the colon can be used in the pathname itself, after the drive letter.)
For example,

     VPATH = src:../headers

specifies a path containing two directories, src and ../headers, which make searches in that order.

With this value of VPATH, the following rule,

     foo.o : foo.c

is interpreted as if it were written like this:

     foo.o : src/foo.c

assuming the file foo.c does not exist in the current directory but is found in the directory src.

The shell Function

The shell function is unlike any other function other than the wildcard function (see The Function wildcard) in that it communicates with the world outside of make.
The shell function performs the same function that backquotes (‘`’) perform in most shells: it does command expansion. This means that it takes as an argument a shell command and evaluates to the output of the command. The only processing make does on the result is to convert each newline (or carriage-return / newline pair) to a single space. If there is a trailing (carriage-return and) newline it will simply be removed.
The commands run by calls to the shell function are run when the function calls are expanded (see How make Reads a Makefile). Because this function involves spawning a new shell, you should carefully consider the performance implications of using the shell function within recursively expanded variables vs. simply expanded variables (see The Two Flavors of Variables).
Here are some examples of the use of the shell function:

     contents := $(shell cat foo)

sets contents to the contents of the file foo, with a space (rather than a newline) separating each line.

     files := $(shell echo *.c)

sets files to the expansion of ‘*.c’. Unless make is using a very strange shell, this has the same result as ‘$(wildcard *.c)’ (as long as at least one ‘.c’ file exists).

Using One Shell

Sometimes you would prefer that all the lines in the recipe be passed to a single invocation of the shell. There are generally two situations where this is useful: first, it can improve performance in makefiles where recipes consist of many command lines, by avoiding extra processes. Second, you might want newlines to be included in your recipe command (for example perhaps you are using a very different interpreter as your SHELL). If the .ONESHELL special target appears anywhere in the makefile then allrecipe lines for each target will be provided to a single invocation of the shell. Newlines between recipe lines will be preserved. For example:

     .ONESHELL:
     foo : bar/lose
             cd $(@D)
             gobble $(@F) > ../$@

would now work as expected even though the commands are on different recipe lines.

If .ONESHELL is provided, then only the first line of the recipe will be checked for the special prefix characters (‘@’, ‘-’, and ‘+’). Subsequent lines will include the special characters in the recipe line when the SHELL is invoked. If you want your recipe to start with one of these special characters you'll need to arrange for them to not be the first characters on the first line, perhaps by adding a comment or similar. For example, this would be a syntax error in Perl because the first ‘@’ is removed by make:

     .ONESHELL:
     SHELL = /usr/bin/perl
     .SHELLFLAGS = -e
     show :
             @f = qw(a b c);
             print "@f\n";

However, either of these alternatives would work properly:

     .ONESHELL:
     SHELL = /usr/bin/perl
     .SHELLFLAGS = -e
     show :
             # Make sure "@" is not the first character on the first line
             @f = qw(a b c);
             print "@f\n";

or

     .ONESHELL:
     SHELL = /usr/bin/perl
     .SHELLFLAGS = -e
     show :
             my @f = qw(a b c);
             print "@f\n";

As a special feature, if SHELL is determined to be a POSIX-style shell, the special prefix characters in “internal” recipe lines will removed before the recipe is processed. This feature is intended to allow existing makefiles to add the .ONESHELL special target and still run properly without extensive modifications. Since the special prefix characters are not legal at the beginning of a line in a POSIX shell script this is not a loss in functionality. For example, this works as expected:

     .ONESHELL:
     foo : bar/lose
             @cd $(@D)
             @gobble $(@F) > ../$@

Even with this special feature, however, makefiles with .ONESHELL will behave differently in ways that could be noticeable. For example, normally if any line in the recipe fails, that causes the rule to fail and no more recipe lines are processed. Under .ONESHELL a failure of any but the final recipe line will not be noticed by make. You can modify .SHELLFLAGS to add the -e option to the shell which will cause any failure anywhere in the command line to cause the shell to fail, but this could itself cause your recipe to behave differently. Ultimately you may need to harden your recipe lines to allow them to work with .ONESHELL.

Overriding Variables

An argument that contains ‘=’ specifies the value of a variable: ‘v=x’ sets the value of the variable v to x. If you specify a value in this way, all ordinary assignments of the same variable in the makefile are ignored; we say they have been overridden by the command line argument.
The most common way to use this facility is to pass extra flags to compilers. For example, in a properly written makefile, the variable CFLAGS is included in each recipe that runs the C compiler, so a file foo.c would be compiled something like this:

     cc -c $(CFLAGS) foo.c

Thus, whatever value you set for CFLAGS affects each compilation that occurs. The makefile probably specifies the usual value for CFLAGS, like this:

     CFLAGS=-g

Each time you run make, you can override this value if you wish. For example, if you say ‘make CFLAGS='-g -O'’, each C compilation will be done with ‘cc -c -g -O’. (This also illustrates how you can use quoting in the shell to enclose spaces and other special characters in the value of a variable when you override it.)
The variable CFLAGS is only one of many standard variables that exist just so that you can change them this way. See Variables Used by Implicit Rules, for a complete list.
You can also program the makefile to look at additional variables of your own, giving the user the ability to control other aspects of how the makefile works by changing the variables.
When you override a variable with a command line argument, you can define either a recursively-expanded variable or a simply-expanded variable. The examples shown above make a recursively-expanded variable; to make a simply-expanded variable, write ‘:=’ or ‘::=’ instead of ‘=’. But, unless you want to include a variable reference or function call in the value that you specify, it makes no difference which kind of variable you create.
There is one way that the makefile can change a variable that you have overridden. This is to use the override directive, which is a line that looks like this: ‘overridevariable = value’ (see The override Directive).