DFT: Design for Testatbility

Any chip that is fabricated is going to have some defects during fabrication, which will cause some of the transistors or wires on the chip to not function properly. This may cause the chip to fail. One way to check if the chip manufactured is good or not, is to run thru the same functional patterns on the chip pins that the chip is going to go thru when it's in operation.

For small chips this method may work, but for large chips, it's practically not feasible for 2 reasons. First, there may be billions of such possible patterns on chip pins that we may have to aplly, which is time prohibitive. Secondly, it may still not find out all bad devices or bad connections in chip, since those patterns may not target 100% of the chip devices.

Without having 100% check to test each and every transistor and each and every connection, we can never be sure if the chip being shipped is 100% functional or not. This is where DFT comes. DFT simply means adding extra logic on chip so as to allow us to test the whole chip. DFT is a broad field by itself, an you will usually see thousands of job postings just for DFT engineers.

In this section, we will go thru the basics of DFT,

IEEE 1500:

IEEE 1500 defines a standard for test access of cores within a big chip. For small designs, we just do connections at top level, and pass on signals from 1 module to other. But for big designs, it can get very complex. For such designs, we treat each block as a chip in itself, having it's own controller for dft purpose, which handles all internal details of dft. Then, at top level we justhave a top level 1500 controller, which connects and controls these block level 1500 controllers. All connections are controlled via JTAG pins. These pins go into top level TAP controller, which processes and passes all the appr signals to each block.

We define standard port interface for IEEE 1500, to connect different blocks. Most signals are prefixed with W which stands for wrapper. WIR = wrapper instruction reg, while DR = data reg (WDR or wrapper data reg name not used for whatever reason). These IO signals are:

WRCK/WRCLK = Clock. This is actually connected to chip JTAG pin TCK.

WRSTN = Reset (active low). This resets all reg in WIR to 0, indicating func mod. This is actually connected to chip JTAG pin TRSTN.

SHIFTWR/SHIFTDR = Shift WIR or DR. With this signal high, Shift reg gets connected b/w WSI and WSO and starts getting values shifted in/out

UPDATEWR/UPDATEDR = Update WIR or DR. With this signal high, Update reg gets updated with values in shift reg.  These signals coming out of Update reg thenget stored in bunch of internal reg, which control all test related stuff in Func logic (i.e bist control signals, bypass, etc)

SELECTWIR = Operate on WIR. (we can have multiple SELECTWIR1, SELECTWIR2, etc if we have multiple partions within WIR, which we want to activate separately)

WSI / WSO Scan In/Out Data. These are single bit line for scanning data in and out of IR/DR. These are connected to chip JTAG pin TDI/TDO via daisy chain. First block's WSI comes from top TAP controller, which in ultimately connected to TDI pin, WSO pin connects to next block WSI pin, and so on. Last block's WSO pin goes to top TAP controller, which finally connects to chip TDO pin. The i/p pin WSI is captured on +ve clk edge, while o/p pin WSO is fired on -ve clk edge. This follows the same convention as for all other pins of JTAG which are fired on -ve edge, but captured on +ve edge of clk.

WPI /WPO Parallel In/Out Data. These are multi bit bus, and used for scanning data in and out of functional flops (i.e scan chain stitching of functional flops). These are same as SDI (scan Data in) and SDO (scan data out) pins that are used in designs for scan data in/out. The reason, we have a bus is to have mutiple chains of scan in/out for big designs (since they may have millions of flops, and shifting data in/out via just one pin is going to take hours). WPI/WPO are captured/fired on same clk edge as WSI/WSO.

 

See diagram.

Top level TAP:

We specify special JTAG inst to control the above signals at block level. We can define as many JTAG inst as needed to have control over various 1500 controllers in the design. We can have JTAG instructions for selecting specific 1500 controllers at block level ,

J1500I = JTAG 1500 inst for Inst Reg. This gets SELECTWIR signal high, and SHIFTWR or UPDATEWR signal high

J1500D = JTAG 1500 inst for Data Reg. This gets SELECTWIR signal low, and SHIFTDR or UPDATEDR signal high

Once you have all the pieces ready, we will download, qflow:

Head over to this link: http://opencircuitdesign.com/qflow/index.html

Download latest stable version that is under stable download link. I downloaded "qflow-1.3.13.tgz" (which was the latest version with release date of Mar 19, 2019). Extract it in a dir named "qflow-1.3.13". In this dir, we see a README file, which has all instructions for installing it:

cd qflow-1.3.13 => Now run below 3 cmds in this dir

1. ./configure => This will look for all tools that qflow needs. It shows configuration results at end.

Using yosys verilog synthesis tool at: /usr/local/bin/yosys
Using graywolf placement tool at: /usr/local/bin/graywolf
Using qrouter detail route tool at: /usr/local/bin/qrouter
Using Magic layout tool at: /usr/local/bin/magic
Using Netgen LVS tool at: /usr/local/bin/netgen
Using Vesta STA tool (internal)
Using Vesta STA tool (internal)

If some thing not found in std path, it will show warning: WARNING: Netgen LVS tool not found.  Use --with-netgen=<DIR>. We will need to fix this by downloading/installing that tool and specifying an alternate path for that tool (if it exists in some other dir).


2. make => make is run. Last 2 lines indicating successful compilation are:

make[2]: Leaving directory `/home/proj/qflow-1.3.13/tech/gscl45nm'
make[1]: Leaving directory `/home/proj/qflow-1.3.13/tech'

3. sudo make install => This puts qflow executable in correct dir. It shows same last 2 lines as in "make" step above.

/usr/local/bin/qflow => qflow script put here

/usr/local/share/qflow/* => all qflow related scripts, etc put here

Run "which qflow" to make sure it shows "/usr/local/bin/qflow" as the path. Type "qflow" on cmdline, and it should show you a help menu.

Project:

Now, we will setup a "experiment" dir where we will get a small project going.

mkdir test_ex1
cd test_ex1
emacs map9v3.v => this creates a new blank file called map93v3.v. This small file is on tutorials link on qflow page. Copy contents from there to this file.
qflow map9v3 => run qflow on this module named "map9v3". Note we do not provide the name of verilog file, but just the name of top level module. Then it will look for module named "map9v3", which it will find in file named map9v3.v. Screen shows this o/p:

--------------------------------
Qflow project setup
--------------------------------

No technology specified or found;  using default technology osu035

No actions specified on command line;
creating qflow script file /home/kailash/Project/test_ex1/qflow_exec.sh only.
Uncomment lines in this file and source the file to run the flow.

The flow created a csh file called qflow_exec.sh file, which is very simple wrapper for calling individual steps in the flow. All of these asteps re commented. We can uncomment lines 1 at a time, and run the script, or copy cmds from this cript, and run that cmd directly on the shell. All output files are generated in same dir. These are the steps, running them 1 by 1:

1. Synthesis => runs synthesis using Yosys and generates verilog gate netlist map9v3.rtlnopwr.v, map9v3.rtl.v, and bunch of other files.

/usr/local/share/qflow/scripts/synthesize.sh /home/Project/test_ex1 map9v3 /home/Project/test_ex1/map9v3.v || exit 1

2. Placement => runs placement using graywolf

/usr/local/share/qflow/scripts/placement.sh -d /home/Project/test_ex1 map9v3 || exit 1

3. Timing => runs timing using vesta. This is initial timing run on placed design (with no routing info)

/usr/local/share/qflow/scripts/vesta.sh  /home/Project/test_ex1 map9v3 || exit 1

4. Routing => runs detailed routing using qrouter

/usr/local/share/qflow/scripts/router.sh /home/Project/test_ex1 map9v3 || exit 1

5. Timing => runs timing using vesta. This is final timing run on routed design (with all wire delays included)

/usr/local/share/qflow/scripts/vesta.sh  -d /home/Project/test_ex1 map9v3 || exit 1

6. Migrate => runs magic to generate final layout

/usr/local/share/qflow/scripts/migrate.sh /home/Project/test_ex1 map9v3 || exit 1

7. DRC => runs drc using magic on final
/usr/local/share/qflow/scripts/drc.sh /home/Project/test_ex1 map9v3 || exit 1

8. LVS => run lvs using netgen
/usr/local/share/qflow/scripts/lvs.sh /home/Project/test_ex1 map9v3 || exit 1

9. GDS => run magic to generate gds
# /usr/local/share/qflow/scripts/gdsii.sh /home/Project/test_ex1 map9v3 || exit 1

10. cleanup => cleanup script to remove un-needed files
/usr/local/share/qflow/scripts/cleanup.sh /home/Project/test_ex1 map9v3 || exit 1

11. display => display final layout in gds using magic
 /usr/local/share/qflow/scripts/display.sh /home/Project/test_ex1 map9v3 || exit 1

 


Cadence IMC tool info:
---------------------------
IMC = Incisive Metrics Center. It is metrics anlysis tool for coverage (code, FSM and functional) analysis. It can analyze data generated from ICC (Incisive Comprehensive coverage) which is generated when irun is run with -coverage. Coverage file is generated in test_name/coverage/tests/*.ucd and *.ucm file

3 kinds of coverage:
1. Code coverage: consists of block, expresssion and toggle coverage
2. FSM coverage: coverage of all possible states and transitions in state machine.
3. Functional coverage: generated by inserting PSL, SystemVerilog assertions, or SystemVerilog covergroup statements into the code and simulating the design.

IMC reads metrics data from run dir which has all coverage database from single run. By default, metrics data is stored in:
cov_work/scope/*.ucm => model file. 8 digit hex is the checksum of design hier and code coverage metrics
cov_work/scope/test/*.ucd => data file. 8 digit hex is the checksum of design hier and func coverage metrics

By using option "irun -covworkdir coverage -covdesign tests -covtest <TEST1>", we set cov_work=coverage, scope=tests, test=TEST1. So, final coverage results stored in this dir:
coverage/tests/*.ucm
coverage/tests/TEST1/*.ucd

If we have multiple tests, we need to merge coverage results of all tests. To do this we run imc
imc -15.10-incisiv -batch -init imc_merge => -batch starts imc in cmd line interactive mode (otherwise it starts in gui mode)
imc_merge has these 2 lines:
merge test_*/coverage/tests/* -overwrite -out result
exit

This takes coverage results for all tests from "test_*/coverage/tests/*.ucm and <test_name>/*.ucd" and puts results in "cov_work/scope/result/*.ucm, *.ucd" (as specified in -out dir specified above).

Then run imc with the same version to look at coverage results:
imc -15.10-incisiv

imc window:
----------
on imc window, look in module interested in, and see "overall covered" results. This needs to be 100%. It's divided under 3 coverage: Code coverage (Block, Expression, Toggle), FSM coverage and Functional coverage.

Code coverage:
-------------
Block coverage:
Expresssion coverage:
Toggle coverage:

Expression coverage:
------
It shows terms T1, T2, etc. It looks for all possible 0/1 values of T1,T2,etc to see if everything is covered. tool should have entered that line in sim, by exercising whatever cond is needed to get there.
ex: state <= sel ? STATE1 : STATE0; It shows T1=sel, T2=STATE1, T3=STATE0. It looks for 8 possible combo of T1,T2,T3 from 000 to 111. If it says, it's looking for term T2=1, it means it's looking for STATE1 values of 0 and 1. STATE1 might be encoded as 001 => STATE1 is always 1. If STATE0 is encoded as 000 => STATE0 is always 0. Tool is smart to figure out that STATE1 can never be 0 and STATE0 can never be 1. So, it will automatically exclude these cond (shows as red with white line in b/w, reads "exclusion rule type = simulation time)

Exclusions:
-----------
We can apply exclude to whole block by clicking "Exclude" button on top after selecting amodule (shows up as red dot on LHS of that block).
We can save exclusions in *.vRefine file by clicking on Analysis->Save Refine. Then we can load it back when opening new session of imc. That way we won't have to type exclusions again.

Exclusions rule types can be 2 types:
1. Analysis time:
2. simulation time:

--------------
Vmanager:
-------------

vmanager is verification tool suite. It used to be emanager, but now it's all combined as vmanager.

It lets automate the process of verification planning, regression, collecting results and displaying them in tabular format. Vmanager provides capability to launch IMC from vPlan window for detailed coverage reports

emanager:
--------
regresssion:
--------
To run regression, do this:
emanager & => once emanager is up, click setup, then start and then open one of *.vsif file that has regression script in it. On clciking ok, it starts regression. It will show the session window that shows tests run (and how many pass, fail, run, wait, timeout(or dropped from lsf queue)

top vsif file to run is veridian_regress.vsif. It has parameters and calls another vsif file which has list of tests.

veridian_regress.vsif:
----------------
session veridian_regression {
   top_dir: $ENV(MY_REGRESSION_AREA)/top_dir; => dir to run sims
   master_submission_policy : execute_locally;
   drm    : lsf;
   default_dispatch_parameters: <text>-q regress -We 00:30 -R "select[ws60 && CCASE && mem>2000]" -o /dev/null -e /dev/null -u /dev/null</text>; => lsf parameters
   max_runs_in_parallel     : 1000;
   queuing_policy : round_robin;
};

group smoke { //there can be multiple groups with each group having separate tests to run
   runs_dispatch_parameters:<text>-q regress -We 04:00 -R "select[ws60 && CCASE && mem>2000]"  -o /dev/null -e /dev/null -u /dev/null </text>;
   sve_name : "$ENV(DVWORK)/software/rtl_sim/regress.sve";
   run_script: "$ENV(DVWORK)/software/rtl_sim/run_regress.csh"; => calls this run script which has irun cmd
   scan_script: "vm_scan.pl `vm_root -home`/bin/ius.flt `vm_root -home`/bin/uvm.flt"; //this is scan script that scans for errors  (*E) in log files, and reports them. provided by cadence. To have your own filtering for errors, provide your own filter file, i.e custom.flt which has these lines:
                add_filter ("error", 5, "ERROR:",failure(1,"ICS", "FAILED", "FAILED", "$ENV{BRUN_TEST_NAME} FAILED due to 'ERROR' in logs")); //This si to filter out ERROR from log file
   sv_seed: gen_random; //use random seed for svseed parameter on irun
   timeout : 200000; //timeout a test after 200K sec
   count : 1;
   #include "veridian_tests.vsif" => has a lit of tests (doesn't need to be vsif file). #include is needed (C pgm syntax for including files)
};
-----------------
Above file calls "run_regress.csh" which is the run script which has irun cmd. This script has "$BRUN_TEST_NAME" in place of testcase name in irun cmd line, so that test names get picked up from *_tests.vsif file
It also has include file for other vsif file which has list of tests with args:
veridian_tests.vsif:
------
test efuse_t1 { count: 5 }; => test to be run 5 times with 5 random seed (and no additional args)
test efuse_jtag {
     sim_args : ahb_bfm;
     test_dir : efuse;
     test_def : DISABLE_DAP_SW_BFM;
};
test pwr_smoke {
     sim_args : ahb_bfm;
     test_dir : pwr_if;
};
#include "veridian_other_tests.vsif" => can include other vsif files too
---------------

top vsif file is called by emanager and starts running regression. It saves results in *.vsof file, which can be loaded later to see the results of regression. This is helpful when we want to reopen the window later.

#to run regression from cmd line, do this:
emanager -c "start_session -vsif /vobs/../veridian_regress.vsif

--------
vPlan:
-------
To create/update vplan, click on vPlan icon (right before Config icon). That will bring new vPlan window.
To create new vplan, click on "New", while to read existing vPlan click on "Read".
vplan file looks like xml file. It is easy to read it in emanager, but difficult to read text.

For new vPlan, on the new window, edit Plan name on vplan editor on left to something meaningful like "refsys dv". Then goto specs on right, and "add a spec". As as many spec files (im pdf) that you want. Highlight the section, that you want to be added, right click and choose "New section (sibling or child=> child will create sub section within that test, i.e 1.1->1.1.1)". Put a name, and then it shows that item on vplan editor on left.  Now if you click on "Plan" (by side of spec), then it shows attributes for each testcase that you added (if you click on that testcase). You can add "implementation notes" here to show what the testcase does. Once done, save file by going to File->Save as "refsys.vPlan".

---------------
 

verilog-A & verilog-AMS:
-------------------------
both these languages don't support synthesis. They are used for simulation only to verify complex blocks.

Verilog-A:  
--------
In face of competition from VHDL (an IEEE standard), which was absorbing analog capability from other languages (e.g. MAST) and evolving into VHDL-AMS, OVI agreed to support standardization of spectre behavioral language to add analog capability to verilog. However, OVI wanted to create Verilog-AMS \ a single language covering both analog and digital design. Verilog-A was an all-analog subset of Verilog-AMS that was the first phase of the project.

Verilog-A standard does not exist stand-alone - it is part of the complete Verilog-AMS standard. It is the continuous-time subset of Verilog-AMS. Spectre/TI-spice runs verilog-A, while ncsim runs verilog. Then results are combined. At top level, ncsim (or irun) is run on combined netlist. spectre is called as needed.

Verilog AMS:
-----------
Verilog analog and mixed signal (V-AMS) is a derivative of Verilog which extends event based simulator loops of digital simulation(V/SV/VHDL) by continuous time simulator. So, can simulate analog, digital and mixed ckt. It's a superset of digital Verilog HDL. It combines both Verilog and verilog-A, and then adds additional capability to allow description of mixed signal components.

The original intention of the Verilog-AMS committee was a single language for both analog and digital design, however due to delays in the merger process it remains at Accellera while Verilog evolved into SystemVerilog and went to the IEEE. Final plan is to pass accellera VAMS std to IEEE.

Verilog/AMS is a superset of the Verilog digital HDL, so all statements in digital domain work as in Verilog (see there for examples). We add electrical, analog, contribution (<+) as extra keywords in Verilog-A. Rest all syntax remains same as digital verilog.

NOTE:
1. Any module can have as many digital process, but only ONE analog process.
2. VerilogA can't have any digital signals (we can still have real/integer var). Every signal has to be analog. That's why we switch to Verilog-AMS since it allows us to use digital or analog for any i/p, o/p or internal signals.
3. cross, transition and bound_step are most needed functions to model in verilogA.
4. In irun, digital verilog only supports verilog 2001 or before. It can't support "always @*", nor any SV constructs as "#2ms". This is a limitation of irun. So, any vams file shouldn't have any newer verilog code.

Extra keywords added in Verilog-A:
--------------------------------

disciplines:
------------
Verilog AMS supports multiple disciplines. A discipline is a collection of related physical signal types, which in Verilog-A/MS are referred to as natures. For example, the electrical discipline consists of voltages and currents, where both voltage and current are natures. Verilog-A/MS by itself defines only one discipline, the empty discipline, and it defines no natures. Thus, in order for the language to be able to describe models that operate on physical signals, the disciplines and natures associated with those signals must be defined. A collection of common disciplines and natures are defined in a file disciplines.vams that is provided with all implementations of Verilog-A/MS.

natures: specifies attributes of signal type
------
nature Voltage
  abstol = 1u; //absolute tolerance in real number
  units = "V";
  access = V; //access function name that we use in verilogA to get voltage of a node. Note capital V used, so using small v to get voltage of a node won't work
endnature

nature Current
  abstol = 1p; //absolute tolerance in real number
  units = "A";
  access = I; //access function name that we use in verilogA to get current b/w 2 nodes
endnature

disciplines: combines 2 natures to define potential/flow pair. One gives type for potential(voltage) while other for flow(current)
--------
discipline electrical
 potential Voltage;
 flow Current;
enddiscipline

discipline voltage //we use separate voltage discipline where currents are not needed. saves computation time
 potential Voltage;
enddiscipline

ex:
electrical in; //in can take both voltage and current value
voltage out;  //out can take only voltage value but not current. electrical and voltage ports can be connected directly.

mixed signal behaviour can be modeled from models which are built from purely digital and analog blocks, and these models can be freely interconnected with VAMS automatically performing the signal conversion.
discipline are not part of verilog, but were introduced in verilog-A for cont time signals. VAMS extended this concept to digital signals also, but disciplines were made optional for these discrete time signals by having default discrete time discipline as "logic", which is defined in discipline.vams.

discipline logic
  domain discrete;
enddiscipline

NOTE: logic in VAMS is diff than one in SV. It just says that these signals are not electrical, but digital 0/1.

VrilogA vs VerilogAMS: Since i/p, o/p signals in VerilogA can only be electrical, modeling digital signals in Verilog-A is difficult (see ex of nand gate on pg 71 of Designer's guide notes). Use Verilog-AMS instead. In verilogAMS, we can write digital code within analog block, so it's much easier to model digital signals.

probe: to probe voltage or current. If branch is empty, current probe shorts the branch, while voltage probe causes open ckt.  
---
These below stmt don't need to be in "analog block". They can be anywhere (i.e in digital always too) in vams file.
real x; x=V(a,b); //x gets voltage b/w a and b
real x; x=I(a);   //x gets current b/w a and ground. Everything is referenced in any schematic wrt ground. So, we need to have a ground node or else everything is floating. We provide gnd! on one node, then all nodes are solved wrt this node. If we do not provide gnd node, then tool can't solve as there will be infinite soln for node voltages. (i.e tool can choose gnd node at 1V, 2V, etc and all other node voltages will change based on that). ground node is provided as follows:

electrical gnd;
ground gnd;
 
$cds_iprobe => to probe volt/cur at any node. Can be used only inside "analog block"
real x; x=$cds_iprobe("TB.I0.net1); => this puts a current probe and continuously assigns value on net1 to var x.

NOTE: all signals in regular schematics of transistors are electrical (since transistors are verilogA models with electrical input/output). So, we can probe any of these signals same way as we can probe any signal in Verilog-A.

Simvision:
--------
1. A/D signals: On simvision gui, the way to know if a signal is digital or analog is to look at signal icon whenever we see at signal list to choose. If it shows a pulse type, it's digital, while if it shows sine wave, it' analog. If we see *_$flow as signal name, it represents a current for that signal as opposed to voltage.
NOTE: If a signal comes from srcVerilogAMS model, it's digital (0/1), while if it comes from schematic, it's analog (V/I). If a digital goes into analog or vice versa, D2A or A2D connect modules are placed. Depending on whether they are placed on o/p pin of 1st gate or i/p pin of next gate, the signal may show up as an analog or digital signal in waveform viewer. Only when both 1st and 2nd logic are both analog or both digital, only then the signal will show up as only analog or only digital. At interfaces of analog and digital, tool tries to keep digital signals as much as possible to save on sim time.

2. timestep: To know the timestep for analog signals, we can display any anlog signal on waveform. Then right click on signal value (where it shows the voltage/current number). then click on symbol->Points & Lines. Then click on triangle or plus, and it will show the all the points where analog values were calculated. This is a good way to see how tool is working with analog signals.


AMS simulator: see "running AMS" section in cadence_virtuoso.txt
-------------
See also in simulation.txt for probe of ams signals.

type:
----
We have signals as electrical/voltage type, and variables as integer/real type.
ex: real [3:0] vout;
reg [5:0] gain; real vgain; vgain = pow(10.0,(gain-32.0)/20); //here if we use integer 32 instead of real 32.0, then we get convergence error during sim complaining it's NaN. This happens because result of operations on unsigned registers/nets is unsigned. Here gain is unsigned, so when gain=0, then gain-32=-32 which is 0+(-32)=32'b0+32'b111...11100000=32'b111...11100000. However, since the result is supposed to be unsigned, this result is treated as unsigned number. Then this unsignned number represents 2^32-32=4294967296-32=4294967264. This is a huge +ve number which causes vgain to be infinite, and hence convergence issues. Use real as one of the inputs, which makes the result real, which is signed. Another soln is to assign reg "gain" to integer which is signed by defn, and then perform "-" which gives signed result.

wreal: wire with real value on it. This is useful as it can be used in digital block instead of using analog block
ex:
wreal out; real result;
assign out=result; => usually real number can be assigned to out in analog module (analog V(out) <+ result;)

wire porz; wreal VDD;
assign #10 porz = (VDD > 1.2) ? 1'b1 : 1'b0; => This converts from real to signal. very useful

expressions:
----------
1. If else: A ? cond1 : cond2; if (V(in) > 0) V(sw) <+ 0; else I(sw) <+0;
2. case: case (a) 0:.. 1:... endcase
3. for: for(i=0;i<=10;i=i+1) begin ... end
4. while: while(i<bits) begin ... end

Events: they force simulator to place time points at events, else simulator may miss that time point, and results may vary from run to un.
-----
@blocks : blocks of code executed upon an event. These are non-blocking so other smt can proceed.
analog begin
 @(initial_step or final_step) begin //simulator places time point at initial step and final step, and assigns hold to V(in) at that time
   hold=V(in); //since hold is variable, it retains it's value over time. So, initial value of hold is retained until the end.
   V(a,b) <+ 5; //since V(a,b) is electrical and assigned using <+, it is evaluated only at initial or final step. At other times, it's not evaluated, so, it's X or floating.So, <+ operator should not be used within event (@).
 end
 @(timer(Tstart,T)) //creates events every t=Tstart+kT, where k=0,1,2,..
 
 @cross(V(in),+1) //places event when V(in) is rising (-1 for falling, 0 for either) just after the crossing within tolerances. NOTE: V(in) needs to go from -ve to +ve for it to detect event. If V(in) goes from 0 to 1V, then cross never happens.
  ;               //It's placed simply to assure edges are not missed. Very imp to place it at start of every "analog" block.
end

always @above(V(in)-Vmax, 1n, 1m) $display("MAX exceeded"); //this looks for arg to be above 0 (V(in) >= Vmax) within 1mV tolerance, and a time delay of 1ns. NOTE: this is not within an "analog begin end" block, but is an always block as if in digital. This works !!

transition filter: converts piecewise constant signal to PWL signal. Can only be applied to piecewise constant and NOT to continuous signals.
-----------------
Out = transition(In, td, tt); //adds td delay to "In" signal with rise/fall time of tt. If different rise/fall desired, then ad 4th arg, i.e:
Out = transition(In, td, tr, tf); //NOTE: out is a "real" variable, and not a signal. IN shouldn't vary continuously, i.e it should be any voltage/current in analog domain
V(mid) <+ transition(en, 1n, 10n)*V(vdd); //causes "en" to rise/fall with 10ns time, delay of 1ns and goes from rail to rail. This stmt converted a digital signal (en) to analog signal (mid). NOTE: <+ is needed, since this needs to be evaluated continuously. So, needs to be in "analog begin .. end" block.

NOTE: transition stmt is used to ramp up power supplies:
ex:
real vsys_r =0;
electrical out;
initial begin
  #0   vsys_r = 0;
  #100 vsys_r = 1.8;
  #100 vsys_r = 1.2;
end

analog begin
   V(out) <+ transition(vsys_r, 10u, 1u);
end

contribution:
-------------
In analog domain, some new operators are defined, for example the "<+" branch contribution operator. It's called contribution operator, because it keeps on adding contributions.
For ex: A <+ 1; A <+ 2; will assign final value of 1+2=3 to A. A simple assign would have assigned value of 2 to A.
A contribution statement takes the form of a branch signal on the left side of a contribution operator, e<+f, followed by an expression on the right side. The branch signal on the left side is forced to be equal to the value of the expression at all times. So, it's different than other languages in the sense that it solcves differential eqn to arrive at a soln that satisifies this. So can be time intensive.

1. Ex of Resistor: V=I*R: model below models a liner resistor
-----------
`include gdisciplines.vamsh // It defines names V and I which are used in the model below.
module resistor (p, n);
  parameter real r=0; // resistance (Ohms)
  inout p, n; //port dirn is bidir (ports are optional as they aren't used in verilog-a/spice simulation)
  electrical p, n; //type of port is electrical (electrical is a discipline), meaning signals associated with the ports are expected to be voltage and current.
  //branch (p,n) res; //optional to specify branch. This gives more concise code, as we can use V(res) instead of V(p,n) below.
    analog // analog says that it's an analog process, which describes continuous time behaviour (similar to always).
       V(p,n) <+ r * I(p,n); //contribution stmt that defines relationship b/w voltage across branch b/w "p and n ports" and current flowing thru the branch b/w "p and n ports".
       //I(p,n) <+ c*ddt(V(p,n)); => for cap (ddt=time derivative, idt=time integral of its arg)
       //V(p,n) <+ l*ddt(I(p,n)); => for ind (idt used for integral, not needed here)
    //for more than one stmt in anlog section, use "analog begin .... end" stmt.
endmodule

resistor #(.r(50)) Rload (out, gnd); //instantiates a 50 ohm resistor

-----------------------


2. Ex of inverter:
-----------------
include gdisciplines.vamsh
module inverter (q, a);
 output q;
 input a;
 wire a, q; // digital net type (declaration optional)
 logic a, q; //discipline for a,q default to "logic" when not defined. So, this stmt optional

 assign q = ~a; //cont assignment
endmodule

3. Ex of sinusoid wave:
-------------
module sinwave(out);
 output out; electrical out;
 parameter real freq,phase; //these can be set wherever this module is instantiated
 analog begin
   V(out) <+ sin(2*`M_PI*(freq*$abstime + phase/360)); //$abstime returns time in seconds.
   $bound_step(0.1/freq); //specifies max time step that can be taken. else simulator may choose very large timestep exactly at same point every cycle that will still satisfy above eqn. $bound_step is usually needed for indep src which produce repetitive o/p with no i/p. This specs 10 timesteps every sinusoid, enough to generate smooth curve. For 1MHz sinewave, we'll see 100ns timestep on ams simulation.log window. But tran time on log window will show results every couple of steps, so that every 5% of simtime we see tran time and other info. That has nothing to do with timestep. step size shows in last 2 columns.
 end
endmodule

NOTE: In verilog (digital), we can model a sinewave with real numbers, by inc time step in a for loop. see system_verilog.txt for ex.

4.  module instantiations: we do it in same way as in verilog. By default, nets are electrical.
--------------
module das_top(ind, in0, in1, out0, out1);
 logic ind; //specifies tha this is digital signal
 electrical in0, in1, out0, out1; //specifies tha these are analog signals.
  diffamp Idiff0 (in0, out0);
  diffamp Idiff1 (in0, out1);
endmodule

5. mux in verilog-AMS: note: digital signals are freely used inside analog block (unlike in verilog-A). so easier to model digital. Make sure events are synchronized b/w digital and analog, else edges might be missed, since analog and digital have different time steps.
-----------
module (in0,in1,out,sel);
 input in0,in1; electrical in0,in1; //analog signal, so electrical. nature "electrical" of signal is figured out automatically by tool, depending on who's driving it
 input sel; logic sel; ///digital signal, voltage levels for digital signals are still unknown here, but we don't need them
 output out; logic out; //digital signal, nature "logic" of signal is figured out automatically by tool, depending on who's driving it
 real gain; //this variable cab shared b/w analog and digital modules
 
 always begin //digital block
  gain = V(in0)*20; //since var gain is assigned value in digital, digital owns it and analog block may only read it, but not modify it. Note: electrical signals can be read into digital and assigned to int/real to be used
  @(vgain); //we need @ stmt or else this always block gets into infinite loop
 end

 always @(cross(V(in0,in1),+1) count = count+1; //digital block. analog cross function can be used in digital

 analog begin //analog block
  @(posedge sel or negedge sel) //we need separate posedge and negedge, else tool complains. In pure verilog, we could do @(sel), but not here. This is limitation of AMS-Designer tool
   ; //forces time step at edge of sel signal. Any digital signal from digital block can be read into analog block. We synchronize analog kernel to avoid missing edges. However if sel signal is not wire/reg, but integer/real, then we need to do it as in pg 121 of Designer's guide book
  V(out) <+ V(in0)*(transition(sel==0 ? 1 : 0),0,1n); //sel=0
  V(out) <+ V(in1)*(transition(sel==1 ? 1 : 0),0,1n); //sel=1
 end
endmodule

6. DAC in verilog-AMS:
--------------
`timescale 1s/1ps => we should give 1s as timescale in digital modules also, as analog blocks always use 1s as timescale, so both digital and analog will remain in sync. Very important to do this and use #delay carefully as they have 1sec as timescale
module dac(in, out,clk);
 input [5:0] in; //in can take digital codes from 0 to 63
 input clk;
 output out; //no need to define electrical or logic as tool figures it out
 real result;
 analog begin
  @(posedge clk)
   result = in/63; //result varies from 0 to 1
  V(out) <+ transition(result,0,10n); out varies from 0V to 1V
 end
endmodule

7. AND gate in verilog-AMS in TI library (AN210 srcVerilogAMS file)
-------------
`include "disciplines.vams"
module AN210 (  A , B , Y  , VDD, VSS); //NOTE 2 extra pins VDD and VSS added. There's also srcVerilog file which doesn't have these vdd/vss pins
  electrical VDD; electrical VSS;
  input(* integer supplySensitivity = "VDD" ; integer groundSensitivity = "VSS" ; *) A; //pins voltages are VDD/VSS for 1/0
  input(* integer supplySensitivity = "VDD" ; integer groundSensitivity = "VSS" ; *) B;
  output(* integer supplySensitivity = "VDD" ;integer groundSensitivity = "VSS" ; *) Y;
     
  and #0 TI_AND_PRIM0 ( Y , A , B ) ;
endmodule

8. analog switch in  verilog-AMS:
-----------
module sw_ana (vin, control, vout); //control connects vin to vout
 inout      vin, vout;
 electrical vin, vout; //analog
 input      control;
 logic      control; //digital (this should be digital (piecewise constant) else can't be used in transition filter below)

 parameter real Ron=1, Roff=10M; //parameters that can be changed from outside
 real rout; //local variable

 initial begin .. end //digital process
 always @(...) begin .. end //digital process

 analog begin
  Rout = Ron/Roff * pow(Ron/Roff, transition(control, td, tr, tf)); //log func implemented for contonuously varying resistance from on->off or off->on. Note: here it's = sign (not <+ sign). If control signal can be "high z" or "x", we can add internal signal that forces "control_int" to 0, whenever control is anything other than 1 by writing this code as separate digital process => always @(control) if (control == 1'b1) control_int=1'b1 else control_int=1'b0;
  //Rout = Roff + ((Ron - Roff) * transition(control, td, tr, tf)); //linear func instead of log func above. simplistic but not accurate in how switches work.
  I(vin, vout) <+ V(vin, vout) / Rout; //solves for V,I with resistor in between nodes vin and vout
 end
endmodule

9. Fuse model: fuse is a resistor with 2 pins: P, M (used in silverfox, since fuse needed vams model)
----------
module FUSE_WRAPPER(M, P);
inout M;
electrical M;
inout P;
electrical P;
localparam  real rblown = 700000 ;
localparam  real rfuse_initial = 50;
integer numCross;
real t1, t2;
localparam real iBlow = 35e-3 ;
real rfuse ;
integer status;

analog begin
  @(initial_step("tran"))  begin
                  numCross = 0;
                  t1 = 0 ;
                  t2 = 0 ;
                  $display("INSTANCE PATH :- %m");
                  rfuse = rfuse_initial;
                  $display("VALUE OF RFUSE IS %f",rfuse);
                  status = 0;
  end
  @(cross(I(P,M)-iBlow,1)) begin //rising edge of current
                  if (numCross == 0 && status == 0)  begin
                    numCross=numCross+1;
                    t1 = $abstime ;
                end
  end
  @(cross(I(P,M)-iBlow,-1)) begin //falling edge of current
                  if (numCross == 1 && status == 0)  begin
                    numCross=numCross+1;
                    t2 = $abstime ;
                end
  end              
  if (numCross == 2 && status == 0)  begin //check how long current remained high. If met time spec, then blow it.
                  if((t2 - t1) > 300e-9) begin // make 300ns per design team
                    rfuse = rblown ;
                    status = 1;
                    $display("IN INSTANCE PATH :- %m");
                    $display("PROGRAMMED :- %m");
                  end
  end
                
  V(P,M) <+ rfuse*I(P,M) ;   //rfuse_unprog=50ohms, rfuse_prog=700Kohms                          
                
end //analog end
endmodule


10. Write top level TB for design:
-------------------------------
A. Create top level schematic. Instantiate sdtimulus block, and DUT block and connect pins as needed.
B. Create verilogams view of stimulus block. Write code to Drive stimulus to DUT (DUT is schematic for SilverFox or some other top level chip block)
--
creating a verilogams view of stimulus providing block:

`include "constants.vams"
`include "disciplines.vams"

module TOP_stim (A, VDD_TX, VDD_RX, VIO_OUT, VSS, Y, Z); //VDD_* are supply to blocks inside DUT, while VIO_OUT is supply to IO pad of DUT.
 input VSS;
 input  (* integer supplySensitivity = "VIO_OUT" ; integer groundSensitivity = "VSS" ; *) A; //indicates pin voltages for i/p pin A
 output (* integer supplySensitivity = "VIO_OUT" ; integer groundSensitivity = "VSS" ; *) Y; //indicates pin voltages for 0/p pin Y
 output  Z; //output pins can also be w/o any SS.
 output VDD_TX, VDD_RX, VIO_OUT;

 electrical Z;
 electrical VDD_TX, VDD_RX, VIO_OUT, VSS; //all supplies defined as electrical

 parameter real Vtx=0.0, Vrx=3.3, Vio=1.8, I_PD1; //specified as parameters so that they can be modified from other testcase module.
 reg A, Y, Z;
 reg [7:0] data, etc;
 reg [255*8:0] sim_description; //to display test name on waveform viewer

 //instantiate other modules
 switch_ana (* integer library_binding="SILVERFOX_TOPSIMS"; *) reset_sw (dut.RST, RST_SW, dut.VIO); //this adds an additional connection b/w VIO and RST pin of DUT. This helps us drive VIO on RST pin by controlling RST_SW signal.

 //include testcase file which has digital initial process
 `include "/db/.../fuse_tc.vams"; //explained in separate section below

 //digital initial process
 initial begin
  $sdf_annotate(...); //for max/min

     Y=0; Vtx=0; //NOTE: reg Y is written as 0 instead of 1'b0. That's valid as verilog treats this as 32 bit decimal and uses lsb of "32'd0".
  #5 Y=1; Vtx=5.0;

 end

 //analog process (runs at every timestep)
 analog begin
  I_PD1 = $cds_irprobe("ams_TOP.DUT.PD[1]"); //This is convenient way so that current can be displayed anytime desired in testcase, by displaying this variable. Else we'll need to include it in irun cmd line to dump current at that level of hierarchy.

  //to ramp up power supply
  V(VDD_TX) <+ transition(Vtx, td, tr, tf); //since Vtx is real and piecewise constant, transition func works on it.

  //to display thermal shutdown event
  @cross(V(ams_top.TSD)-0.7,0) begin
   TSD_temp = $temperature-273; //records tsd temp
   //vrx = V(VDD_RX); //record supply voltage
   $display("TSD temp = %g", TSD_temp); //%g is is used to display real var (can also use %f, %r, %e")
  end

 end

endmodule

fuse_tc.vams:
---
real diff; //any new var defined here
initial begin
  SCK =0;
  #5 LED=0;
  #1_000_000;
  Vtx=2.2; //Vtx is changed so analog block in stim file above causes V(VDD_TX) to ramp down to 2.2V.

  force ams_TOP.nPUC = 1'b0;
  spi_read(...);
  diff = V(ams_TOP.SILVER.I1.SH_OUT1) - V(ams_TOP.SILVER.I1.SH_OUT2); //analog sigs can be accessed directly in this digital block
  $finish;
end

--------------------------


VHDL: VHSIC (Very high speed IC) hardware description language. IEEE (std 1076) standardized the language in 1987 (called as VHD-1987). It was again updated in 1993 called as VHDL 1076-1993 which is the most widely used. Later VHDL-2000, VHDL-2002 and VHDL-2008 were released with minor improvements.

VHDL-1993: allowed a component to be directly instantiated by using entity name and also allowed use of shared variables. Also allowed string to be rep in binary/octal/hex.
VHDL-2000: protected types were added so that shared variables from VHDL-1993 can be used in a useful way.
VHDL-2002: rules on using buffer ports were relaxed.
VHDL-2008: enhanced significantly compared to previous versions. It allowed use of process(all) so that signals don't need to be put in sensitivity list (similar to always @* in verilog)

------
VHDL is CASE INSENSITIVE. So pin "EN" is same as pin "en", and can be considered as connected to each other. However, we use capital letters for reserved keywords for better readability.
VHDL is free-form in the sense that blank lines, spaces, etc may be included for readability w/o any ill effects.

VHDL Library:
--------------
VHDL requires all design sources to be in a library, VHDL also allows named libraries that can contain one or more files. VHDL design units can access other design units in the same and different libraries by declaring the name of the library and design unit to make visible. In VHDL, we've 3 kind of lib:
1. Project libraries: These are the libraries in which you store your designs. You have full read-write access to these libraries. These are our Source dir files. Usually compiled in WORK lib. i.e to access "module1", we reference it as "work.module1".
2. External libraries: These are libraries that you need in your design, but that can be treated as read-only. These are libraries from other designs or from somewhere else.
3. Built-in libraries: The standard VHDL libraries, STD and IEEE, are built-in built in lib. This means that they are always available without any additional configuration. This is done for convenience, as any VHDL project will need parts of them. For ex cadence simulators will have predefined vhdl package for vhdl std lib, std logic, etc.
 - Lib STANDARD: provides behavioral data types and operators: types=character, string, bit, boolean, integer, real, time
 - Lib IEEE: provides synthesis and simulation data types and operators:. Various pacakages:
     - std_logic_1164: It's IEEE pkg. inluded by default. added types= std_logic, std_logic_vector (also added std_ulogic and std_ulogic_vector).
     - std_logic_arith: It's synopsys pkg but included in IEEE. It defines arithmetic and comparison operators for std_logic_vector. It added new types "unsigned" and "signed" which are array of std_logic (similar to std_logic_vector but arithmetic operators can be used on these)
     - std_logic_signed/std_logic_unsigned: It's synopsys pkg but included in IEEE. It defines arithmetic and comparison operators for std_logic_vector. signed implies std_logic_vector is treated as signed number, while unsigned implies it's treated as unsigned. Don't use std_logic_signed.
     - numeric_std: It's IEEE pkg intended to replace above 2 synopsys pkg. It added new types "unsigned" and "signed" which are array of std_logic, and defines arith, comp and logic operatrs on these 2 types. Recommended to use this instead of 2 synopsys pkg above. However, it didn't allow arithmetic to be done directly on std_logic_vector. For this, VHDL-2008 added Numeric_Std_Unsigned and Numeric_Std_Signed, which can be used similar to std_logic_signed/std_logic_unsigned of synopsys pkg.

library STD; -- built in STD lib. no need to declare STD library as it's included by default
    use STD.standard.all;
    use STD.textio.all;

library IEEE; -- built in IEEE lib. only std_logic_1164 is included by default. Others have to be declared in order to be included.
    use IEEE.std_logic_1164.all; -- defines std_logic and std_logic_vector
    --use IEEE.std_logic_arith.all; -- defines arithmetic operations on std_logic_vector
    --use IEEE.std_logic_unsigned.all; -- defines std_logic_vector to be unsigned (for signed, use IEEE.std_logic_signed.all)
    use IEEE.numeric_std.all; -- instead of std_logic_arith and std_logic_signed/unsigned, use numeric_std

library TIDLIB; -- External libraries that contain common primitive defn, other common blocks, etc. We compile the files containing packages using option "-work TIDLIB". So, all compiles packages go into TIDLIB library.
    use TIDLIB.TID_COMMON_PKG.all; => contains package TID_COMMON_PKG (defining various constants and common component as CLK_SOURCE, CLK_DIV, CLK_GATER, etc) in TID_COMMON_PKG,vhd

library work; -- project library WORK
    use work.REGADDR_pkg.all; -- we use this as some pkg may have been compiled separately, but put in libraray work.

COMPILE: When we compile using irun or ncvhdl, we can provide option for work dir using "-work". For ex: "ncvhdl -work mylib" will put all compiled design in mylib design library as mylib/inca.lnx86.010.pak. Usually  *INCA_libs/worklib/* has compiled inca.lnx86*.pak binary files in separate dir for std(inca.std), ieee(inca.ieee), synopsys(inca.synopsys) and work(inca.work) library.

--------------------------------

cmds in vhdl: vhdl files are parsed for objects(identifiers), their types, operators and various reserved keywords.
------------------
#types: VHDL is strongly typed lang. Explicit conversion is usually required: ex: BIT'('1') => converts character '1' to bit '1'. (NOTE: '1' may have already been a bit, but converting it makes sure, it's become a bit). Lowest value or left most value is the default value for that type. 1 found in vhdl file is assigned type integer, -1.0 is assigned type real, 'a' is assigned type character, while a is considered an object identifier and has to be assigned one of the types shown below.

1. std types in STD pkg: (PACKAGE STANDARD is .... END STANDARD;). For cadence, this exists in /apps/cds/rc/10.1-s202/tools.lnx86/lib/vhdl/std/standard.vhdl
I. scalar
   A. boolean: type boolean is (false,true); (or TRUE, FALSE, True, False). default is FALSE.  Relational operators (=, <=, >=, /=) produce boolean result, which is tested in IF stmt.
   B. bit:     type bit is ('0','1'); (NOTE: different than integers 0,1. Bit '0','1' are just 2 character lierals '0','1', but explicit conversion may be required from bit to character or vice versa). To covert boolean type to bit, explicit conversion is required: ex: BIT'(FALSE). default is '0' as expected.
   C. integer: type integer is (-2,147,483,647 to +2,147,483,647) => no commas, shown only for clarity. interger can have subtypes defined.
      1. subtype NATURAL is INTEGER range 0 to INTEGER'HIGH;
      2. subtype POSITIVE is INTEGER range 1 to INTEGER'HIGH;
   D. charcter: single character enclosed in single quotes. type character is (NUL, SOH, etc .., 'a-z', 'A-Z','0-9', ' ',''','$','@','%'). ex: '@'. default is NUL (NOTE: NUL, etc are not enclosed in single quotes). character literal '0','1' are same as bit literal '0','1', though explicit conversion may be required. 'a' is different than 'A' (even though vhdl is NOT case sensitive).
   E. real: type real is (-1.7014110E +38 to +1.7014110E +38). ex: 1.2
   F. text: used for file operations. see below under files.
   G. time: type TIME is range -9223372036854775808 to 9223372036854775807 units fs; ps = 1000fs; ... hr=60min; end units; units are fs,ps,ns,us,ms,sec,min,hr. ex: 2.1 ns (integer/real number followed by space and unit)
   H. severity level: type SEVERITY_LEVEL is (NOTE, WARNING, ERROR, FAILURE); => this is enumerated type defined in some lib.

II. Array: all array type can have optional "range of index". we can have single dim array, multi dim arry or array of arrays.
o. single dimensional array:
    A. string: type STRING is array (POSITIVE range <>) of CHARACTER; => array of characters encloed in double quotes. ex: "hold time", "x" (array length=1). <> implies unconstrained range. So array range is positive integers (from 0 to max).
    B: bit_vector: type BIT_VECTOR is array (NATURAL range <>) of BIT; => array of bits enclosed in double quotes. ex: "0010_0111", x"00FF" (_, B, X, O were added in vhdl-93)

array objects must be declared with index constraint. i.e
variable A: STRING(0 to 2122); =>A(0) to A(2122) are all valid assgn
variable C: BIT_VECTOR (3 downto 0);
aggregate for array: C :=('1','0','1','0'); => 4 bit positional aggregate.
we can also have c as C:="1010"; --since "1010" is array of character
or C := '1' & '0' & "10"; -- concatenation. each operand of & can be an array or element of an array.

o. Multi dimensional array: ex:
TYPE mem is array (0 to 1, 0 to 3) OF bit; => mem is 2 dim array, with 1st index(0 to 1) and 2nd index(0 to 3)
CONSTANT ROM: mem:= ( ('0','0','1','0'),
                                        ('1','1','0','0'));
when referencing: data_bit := ROM(1,2) => implies row 1 col 2, which has a value of "0"

o. Array of array: ex:
TYPE word is array (0 to 3) of BIT;
TYPE mem is array (0 to 1) of word;
variable data: word;
data := ROM(1) => data is assigned value "1100".

2. types in TEXTIO pkg: (PACKAGE TEXTIO is .... END TEXTIO;) => also see in file section below for usage
I. 2 data types for textio: text, line. used in process and subpgm
 A. LINE: type LINE is access STRING;
 B. TEXT: type TEXT is file of STRING;
II. std text files
 A. FILE input: TEXT is in "STD_INPUT";
 B. FILE output: TEXT is out "STD_OUTPUT";
III. I/O routines => various flavours of READ/WRITE supported depending on whether in/out is BIT_VECTOR, STRING,etc.
 A. READLINE:  procedure READLINE (F: in TEXT; L: out LINE);
 B. READ:      procedure READ (L: inout LINE; VALUE: out BIT_VECTOR);
 C. WRITELINE: procedure WRITELINE (F: out TEXT; L: in LINE);
 D. WRITE:     procedure WRITE (L: inout LINE; VALUE: in BIT_VECTOR);

3A. extended type in IEEE std_logic_1164 pkg: ((PACKAGE IEEE is .... END IEEE;). For cadence, this file exists in /apps/cds/rc/10.1-s202/tools.lnx86/lib/vhdl/ieee/std_logic_1164.vhdl. It has (PACKAGE std_logic_1164 IS ... END std_logic_1164). In any logic level sim, std_logic type are required as opposed to BIT type. This pkg extends bit from 2 values(0,1) to std_logic 9 values. So, we have to include std_logic_1164.all package in all vhdl files.
I. scalar
   A. std_logic: type std_logic is ('U','X','0','1','Z','W','L','H','-'); U=uniniialized, X=unknown, Z=high impedance, W=weak unknown, while L=weak 0, H=weak 1. - is don't care.
II. vector
    A. std_logic_vector: TYPE std_logic_vector IS ARRAY ( NATURAL RANGE <> ) OF std_logic; => array of std_logic elements enclosed in ". ex: "101Z". So, a(3 downto 0)="101Z" => a(3)='1', a(2)='0', a(1)='1', a(0)='Z'.

3B. extended type in IEEE numeric_std pkg: It defines 2 new types: signed, unsigned which are similar to std_logic_vector except that arith,comp,logical operators work on them. These operators will also work on std_logic_vector by including this pkg.
I.  signed:   type SIGNED is array (natural range <>) of std_logic; -- 0 to 2^n-1
    ex: signal A_unsigned : unsigned(3 downto 0) ; A_unsigned <= "1111" assigns a value 15 to A_unsigned
II. unsigned: type UNSIGNED is array (natural range <>) of std_logic; -- -2^n-1 to 2^n-1 - 1
    ex: signal B_signed : signed (3 downto 0) ; B_signed <= "1111" assigns a value -1 to B_signed

4. enumerated type => defines new type. should be defined before being used. Can be used in entity, architecture, block, process, procedure in section where we define signals, variables etc (before "begin" section). Best place for type declaration is either in package declaration or package body.
type SPI_STATE_TYPE    is (COMMAND_WR_STATE, DATA_WR_STATE, DATA_RD_STATE); -- defines new type SPI_STATE_TYPE that can only take these 3 identifiers. During logic synthesis, an actual numeric coding is chosen for these 3 states (i.e 00, 01, 10) so if SPI_STATE_TYPE ever goes to 11, it would be invalid state. NOTE: in waveform of sims, we won't be able to see the value of SPI_STATE_TYPE as it's not a numeric value.
signal CURR_STATE, NEXT_STATE :SPI_STATE_TYPE => this defines these 2 fsm signals as one of the types in SPI_STATE_TYPE

subtype digit is integer range 0 to 9; => subtype are based upon existing type restricting them in some way. Now, we can declare variables/signals of this type:
variable MSD, NSD: digit; is equiv to
variable MSD, NSD: integer range 0 to 9;

#qualified expr: to cast a lieral to particular type
type' (lieral or expr)
ex: bit' ('1') => casts 1 to a bit type (1 could have been character, bit or std_logic)
ex: integer' (3.0) => cast 3.0 to integer 3

#aggregate
variable B: BIT;
variable C: BIT_VECTOR (8 downto 0);
C := BIT_VECTOR' ('1', 7 downto 3 =>B, others=>'0');

#File operations: 2 stage: identify logical file and read lines in file.
ex:
process (proc)
FILE infile: TEXT is in "path/test.data"; --identifies a logical file named infile of type text called test.data
FILE outfile: TEXT is in "path/out.data"; --files of type text are treated as group of lines
variable L1,L2:LINE; -- variables defined as type Line (1 line of text in a file)
variable av:bit_vector(3 downto 0); -- define 4 bit vectors
begin
WHILE NOT(ENOFFILE(infile)) LOOP
 READLINE (infile,L1); -- readline procedure to read a line L1 from text infile
 READ (L1,av); -- read procedure which reads an item off a particular line. here reads a 4 bit value from line L1
 WRITE (L2,av); -- writes a 4 bit value to line L2
 WRITELINE (outfile,L2); -- write line L2 to text outfile
END LOOP;
END process;

file test.data contains
0011
00_11 -- underscores are ignored
16#E# -- # indicates number in different radix. here 16# means in base 16, number is E
1010 0111

--------
conversion b/w different types: each element of signed/unsigned/std_logic_vector is still std_logic type. i.e A_unsigned(3) = '1' (std_logic type) in ex above. So, we need conversion, as vhdl is strongly typed.

1. signed/unsigned to/from intger: we need conversion functions:
A. std_numeric pkg:
   To convert signed/unsigned into integer:  to_integer() function
   To convert integer to signed/unsigned:    to_signed(signed_integer, width) or  to_unsigned(unsigned_integer, width) function.
B. std_logic_arith pkg:
   To convert signed/unsigned into integer:  conv_integer() function
   To convert integer to signed/unsigned:    conv_signed(signed_integer, width) or  conv_unsigned(unsigned_integer, width) function.

2. std_logic_vector to/from integer:
A. std_numeric pkg: 2 step process
   To convert std_logic_vector into integer:  to_integer(signed(A_slv)), to_integer(unsigned(A_slv)
   To convert integer to std_logic_vector:    std_logic_vector(to_signed(signed_integer, width))) or  std_logic_vector(to_unsigned(unsigned_integer, width)) function.
B. std_logic_arith pkg: use vhdl type qualifier: leaving out ' is an error with this pkg.
   To convert std_logic_vector into integer:  conv_integer(signed'("1010")) => type cast 1010 to signed number -2. If we use pkg "std_logic_signed", then all std_logic_vector will be converted to signed, so explicit cast not required: conv_integer("1010");
   To convert integer to std_logic_vector:    std_logic_vector'(conv_signed(signed_integer, width))) or std_logic_vector'(conv_unsigned(unsigned_integer, width)))

ex: signal count: std_logic_vector(3 downto 0); count <= count + 1; => this won't work with STD pkg as count is std_logic_vector while "1" is integer (+ not allowed on std_logic). To make it work, we need to use std_numeric or std_logic_arith pkg:
std_numeric:     count <= std_logic_vector(to_signed((to_integer(signed(count)) + 1)),4);
std_logic_arith: count <= count + 1; If pkg unsigned, then it's unsigned integer count added to 1. If pkg signed, then count is treated as 2's complement number and added to 1, result is a number in 2's complement

ex: + works on signed/unsigned.
signal A8, B8, Result8 : unsigned(7 downto 0) ;
Result8 <= A8 + B8 ; => this gives 8 bit result with no carry out
ex: "1011" > "0011": If pkg unsigned, then it's 11>3 => true. If pkg signed, then it's -5>3 => false. We can explicit conversion type too. i.e signed'("1011") > signed'("0011") => false.

ex: variable a,b,x: integer range 0 to 255; -- by default integer are 32 bit. By defining range, we make these 8 bit.
    x:=a+b; -- 8 bit adder built. If range was not defined above, then 32 bit adder would be built

ex: to add carryin to sum, we do a trick to extend addition to 1 extra lsb bit: Y[3:0] = A[3:0] + B[3:0] + Cin;
    Sum(4 downto 0) <= (A(3 downto 0) & '1') + (B(3 downto 0) & Cin) ; Y[3 downto 0) <= Sum(4 downto 1);
 
ex: signal A_uv, B_uv : unsigned( 7 downto 0) ; signal Z_uv : unsigned(15 downto 0) ;
    Z_uv <= A_uv * B_uv; => result width is sum of the width of 2 i/p.
    Z_uv <= A_uv * 2;    => result width is still 16 bits

-----
OBJECTS: Any name or identifier in vhdl is an object, which can be of any scalar or array literal type described above. Every object needs to have a type, as vhdl is strongly typed lang. A name must begin with an alphabetic char, followed by letter, _, or digit. OBJECTS in vhdl need to have a "kind" associated that says when to update the value of that object. In normal pgm language, values of objects are updated immediately on execution, but in h/w lang, they may need to be updated differently.
Any named object can be of 2 kinds: fixed or varying in value.
1. Fixed: only 1 type:
A. constant: name assigned to a fixed value. Can be assigned to scaler or Array. Can be declared in package, entity, arch or subpgm, but usually declared in user defined packages.

ex: constant vdd: REAL :=-2.0; --scalar. vdd is REAL type with val=2.0
ex: constant FIVE: std_logic_vector (8 to 11) := "0101"; --array FIVE(8)=0, FIVE(9)=1 and so on.

2. Varying in value: 2 types:
A. variable: name assigned to changing value within a process. variable assgn occurs immediately in simulation. variable can be used to document a physical wire or as temp sim value. variables can be local (declared in a process) or global (to communicate b/w process, only in VHDL92). Note that variables are declared within process in contrast to signals which cannot be declared within process. variables are assigned using :=.
ex: variable COUNT: TIME range 10ns to 50ns :=20ns;  -- scalar variable COUNT with initial value 20ns. default initial value is the leftmost value of that type(i.e fs in this ex?). Valid range of values is in between 10ns to 50ns only.
ex: variable MEM: BIT_VECTOR (0 to 7); -- index constraint is 0 to 7. so MEM(0) .. MEM(7) .. MEM(0 to 3) are all valid.
ex: variable x, y: INTEGER; x:= y+1; -- defaults to -2,147,483,647.

B. signal: connects design entities and communicates b/w process. signals can be used to document a physical wire. signals can be declared in 3 places: entity (as ports or global signals), arch (as local signals, declared before start of "begin ... end") or pkg(as global signals). signals can't be declared in a process, but can be used in a process. This is in contrast to variable which can be declared in process. However signal assgn within a process is delayed until a wait is executed. signals are assigned using <=. Examples of global/local signal decl are shown in Gemini code later. signals when declared as ports is shown next.

Range: we can define range constrint for variables and signals. We can also have index constraint for arrays.
ex: A in integer range 1 to 10 (or range 10 downto 1) => Note: range should be in compatible dirn with orig declaration of that type. Since, integer is defined from -ve to +ve, so we use small number to large number. Use downto to reverse dirn.

signals vs variables:
--------------------
signals and variables are no different when used within a process. Between processes, however we have to use signals.
We use variables within a process, when process is self contained. In such cases, we can define a variable "counter" and increment it within the process, to use it inside the process. It consumes less resources since the assignment happens immediately. signals consume more resources since they maintain their complete history and are only updated when a ¡°wait statement¡± or an inferred ¡°wait statement¡± (such as the end of a process that uses a sensitivity list) is reached. So, only signals can model seq behaviour of ckt. signals can be thought of as superset of variables. variable assgn using := is similar to blocking assgn of verilog. It synthesizes correctly, but is mostly used in testbenches. signal assgn using <= is similar to non-blocking assgn of verilog. So, for synthesizable logic, we exclusively use "signals".

Port syntax:
-----
port (names: dirn type [:=expr] [;more ports]); --expr is optional default initial value assigned to port.
#dirn is one of the 4 below:
1. In = RHS of variable or signal assgn (default is In when port dirn is not explicitly mentioned)
2. Out = LHS of signal assgn.
3. Inout = Both above (can have multiple drivers)
4. Buffer = Both above (can have 1 driver)

ex: ENTITY des is PORT (data_in: IN bit; data_out: OUT bit); end des; -- signals defined as ports

Note: a port defined with dirn Out can not be used internally in that entity. It can't be driving anything in that entity as that would mean it's not a pure output, but a Inout. If we try to compile with ncvhdl, we get error like:
ncvhdl_p: *E,RDOPRT : ports of mode OUT or LINKAGE may not be read 87[4.3.3] 93[4.3.2].

To fix this there are 2 options:
1. add -relax when running ncvhdl or irun.
2. We have to define the port as Inout or Buffer. But that would change the design, and some synthesis tools may have issues with Inout ports and buffer. so, better alternative is to declare an internal signal as *_INT, use this internal signal everywhere, and then assign this output port to the internal signal that can be read as well as assigned to output.
i.e. port(out_port: out std_logic); signal out_port_int: std_logic; some_sig <= out_port_int; out_port <= out_port_int; -- this works as out_port_int is defined as internal signal.
---

#operators (+,-,etc). operators manipulate objects and create new objects. Operators can only work on certain type (std_logic or real etc) of objects.
Most operators same as verilog, but vhdl doesn't have useful unary reduction op ( i.e |(val[7:0]). For this in vhdl, we've to use a "loop" stmt or do op on each bit. VHDL has "mod" op not found in verilog.

4 types of operators as shown below in terms of highest to lowest precedence:
1. Arithmetic operator: + - * / mod rem **(exponentiation) abs(absolute value). work on i/p types: integer, real. Package STANDARD doesn't allow arithmetic operators on bit_vector (or package std_logic_1164 on std_logic_vector). However, std_logic_arithmetic/numeric_std packages allow op on std_logic_vector, signed, unsigned. "-" operator creates a 2's complement in case of std_logic_vector.
NOTE: mod, rem only work on integer type. o/p type is same as i/p type, except in division o/p type is integer. These operators are also specification for synthesis tools to build logic.

2. concatenation operator: & concatenates.
For ex:
signal w, x, y, z :std_logic:='0';
signal t : std_logic_vector(1 downto 0);
t<= (w and x) & (y and z); => concatenates so that t(1) <= w and x; t(0) <= y and z;

3. relational operator: = /= < > <= >= . i/p type may be any scalar or 1-D array. o/p type is boolean. So may need conversion to std_logic if we want to assign it to a signal (which are usually std_logic type).

4. logical operator: not, xnor(in vhdl 92 only), xor, nor, nand, or, and. It takes 2 i/p operaand and returns one o/p operand. i/p type may be boolean(true/false), std_logic('0'/'1') or vectors of equal length. Does not work on integer. o/p type is same as i/p type. Note that even though logical operators are lowest in precedence, "not" has the highest precedence of all 4 types of operators.
ex: x <= a and b or c; -- not correct as it gives an error "illegal sequence of logical operators". Looks like and,or have same priority so that expr becomes ambiguous in absence of brackets. We don't know whether x=a and (b or c); or x=(a and b) or c; So we have to always use brackets so that there are atmost 2 logical operands, i.e x<=(a and b) or c;

5. shift operators (new VHDL92 operators): sll/srl (shift left/right logical), sla/sra (shift left/right arithmetic), rol/ror (rotate left/right logical).
ex: "1001" sll 3 = "1000" (since 0 gets shifted in from right/left for logical shift). For arithmetic shift, MSB/LSB bit are shifted in. For rotate, numbers are just rotated, so no new bits added.
------

#reserved keywords
1. open: can be used to connect to unused o/p. It implies it's floating
ex:
my_component : my_component
port map (
some_input => '0', -- unused i/p tied to 0
some_output(0)=> data(0),
some_output(1)=> open, -- unused o/p tied to open
);

2. loop/generate: to wrt code for seq of stmt that execute repeatedly. generate can be used outside of process, so it can be used to describe array of components.
L: for i in 1 to 10 loop
   q(i) := a(i);
end loop; -- or "end loop L;"

L: for i in 0 to 7 generate    
     q(i) <= reg_wrt and REG_WR_DATA(i);
end generate; -- or "end generate L;"

L: for i in 0 to 3 generate    
     U: dff port map (x(i), clk, x(I+1)); -- this generates 4 flops in a serial shift register fashion
end generate; -- or "end generate L;"

3. process: all process run concurrently, though stmt within it are executed sequentially. Process is an infinite loop which runs forever. It starts from beginning once it reaches the end. wait will cause the process to get suspended until an event occurs on that signal. If there is no wait, then a single process will keep on running forever, since there's nothing to stop it.

#ending simulation
In VHDL, we don't have something similar to $finish as in verilog. The simulation will stop if there are no more pending transactions. Unfortunately, if there is a free running clock process in the test bench, this will never occur. Or a process, which doesn't doesn't have any sensitivity list (as in a testbench process where we set signals to different values at different times), such a process will get to the end, and then come back to start of process and repeat the process again (similar to what happens in clk process). So, to stop a simulation, we can specify it to run for a particular length of time (which is bad as this may change every time a change is made to the test bench) or stop the simulaion using an "assert" stmt when we are done with our testbench. We just set the severity to Failure to guarantee that the simulator will stop regardless of the simulator assert level settings.  This is a common practice with VHDL simulations.

#assignment: concurrent (outside a process) or seqential (inside a process) assignments done to assign new values. Outside a process, we call it concurrent, because all these stmt seem to execute at same simulated time. Inside a process, stmt execute serially, so we call it seq assgn. However, if the assgn is using := then it happens immediately at that point in time. However, if it's using <= then the assginment is delayed until we reach the end of process, which has an implicit "wait" stmt. For ex if we have process(a,b,c) then implicit wait stmt is (wait on a,b,c) at end of process. signal assgn using <= are done after wait is executed.
In a process, last assgn to o/p is what counts. process in an infinite loop, which only waits at the end of the loop, if there is a sensitivity list, otherwise it doesn't have any wait stmt at the end. For ex, in clk generation logic, there is no sensitivity list, so there is no wait stmt at end, implying the process will run forever.

clock generation:
process -- NOTE: no sensitivity list, so process runs forever
begin
  wait for (PERIOD/2); -- wait for half cycle. We need to initialize CLK to 0 at time 0, else CLK will always be X.
  CLK <= not CLK;
end process

#########################################
Ex: various examples

1. D latch:
architecture behv of D_latch is
begin        
   process(data_in, enable)
    begin
        if (enable='1') then
            -- no clock signal here
        data_out <= data_in;  
    end if;
    end process;        
end behv;

2. DFF: D flip flop
architecture behv of dff is
begin
    process(resetz, clock) -- data_in is not provided in sensitivity list, as it's seq logic
    begin
        if resetz='0' then -- brackets not necessary
            data_out <= '0';
    elsif (clock='1' and clock'event) then -- clock rising edge. Or use rising_edge(clock)
        data_out <= data_in;
    end if;
    end process;    
end behv;

3. combinatorial logic: AND gate
architecture behv of AND_GATE is
begin
process(A,B) -- or use process(all) in VHDL-2008
begin
    F1 <= A and B;            -- behavior des.
end process;
end behv;

4. combinatorial logic: MUX written as seq and concurrent
A. sequential
architecture behv1 of Mux is
begin
    process(I3,I2,I1,I0,S)
    begin        
        O <= "ZZZ"; -- default o/p assgn so that if we leave the "others" condition below, the logic won't synthesize to latch
        case S is -- use case statement
        when "00" =>    O <= I0;
        when "01" =>    O <= I1;
        when "10" =>    O <= I2;
        when "11" =>    O <= I3;
        when others =>    O <= "ZZZ";
    end case;
    end process;
end behv1;

B. concurrent
architecture behv2 of Mux is
begin   
    O <=    I0 when S="00" else -- use when.. else statement
        I1 when S="01" else
        I2 when S="10" else
        I3 when S="11" else
        "ZZZ";
end behv2;

------------------------------------------------------
VHDL file format:
----------------
every design unit is compiled and put in library as a "component", which can be used in any other design.
A design unit has 4 kinds of declaration in it's vhdl file: package, entity, architecture, configuration. Each of these 4 are compiled separately and for each design unit, library will contain these 4 design units: compiled  package, entity, architecture and configuration. package and configuration are optional. configuration unit (if present) decides which arch of design unit is to be run (if no configuration specified, then latest complied arch of that entity is used).

Top level vhdl file for Gemini project (in /db/MOTGEMINI_DS/design1p0/HDL/Source/):

spi.vhd => this file just defines all lib.
---------
#declare lib IEEE so that we can open it and access pkg std_logic_1164, numeric_std.
library IEEE;
   use IEEE.std_logic_1164.all; => this needed for std_logic and std_logic_vector. see above.
   use IEEE.numeric_std.all; => this is preferred over std_logic_arith.

#user defined pkg SPI_TYPEDEFS (in file spi_typedefs.vhd  which has user defined constants) in user defined lib SPI_LIB.
library SPI_LIB;
   use SPI_LIB.SPI_TYPEDEFS.all;

ENTITY => defines entity with signal port defn. similar to module defn in verilog.
---------
entity SPI is -- top level entity is SPI
 generic ( -- similar to parameter in verilog. Different inst of SPI can use diff values of genric via port map.
   c2q_delay : time := 1ns; -- default value provided so that
   width: integer := 7 -- Note no semicolon
 );
 Port (
  SPI_CS_N         : In std_logic;  -- all i/o ports defined
  SPI_SO            : Out std_logic;
  SPARE_D_B5        : Out std_logic  -- Note no semicolon
 );
end SPI;

ARCHITECTURE => define internal logic od that entity. Can have multiple arch with different names.
------------------
architecture SCHEMATIC of SPI is

#define all signals and components here before starting the body "begin .. end architecture_name".
signal DATA_RD    : SPI_DATA_TYPE;  -- define signals (wires) to be used in this arch to connect components. SPI_DATA_TYPE is defined in pkg SPI_TYPEDEFS as std_logic_vector(7 downto 0)
....
signal WREN    : std_logic; -- defined as type std_logic
type mem is array (0 to num) of std_logic_vector (63 downto 0 ); //mem[num-1:0][63:0]

function write_fsm ( ...)
begin ...
end write_fsm;

procedure init_mem (...)
begin ...
end init_mem;

-- define components (modules) to be instantiated in this block as vhdl needs module defn, before instantiation of a module. In verilog, we could directly instantiate a module, as long as that module was present in some file. We have to do this, since in vhdl each entity gets compiled as a separate "component", so we need to tell simulator about existence of such components. We instantiate SPI_REGS later as: I_SPI_REGS : SPI_REGS Port Map ( ... )
NOTE: In VHDL-93, components are not necessary. we can directly instantiate an enity within an arch as: I_SPI_REGS : entity work.SPI_REGS Port Map ( ... )
component SPI_REGS -- component syntax is exactly same as entity
 generic (width: integer :=7); -- this genric defined in entity defn of SPI_REGS
 Port (
  ADDR            : In SPI_ADDR_TYPE; -- declare all i/o ports for SPI_REGS.
  ...
 SPARE_D_B5        : Out std_logic
 );
end component;

#begin architecture body
begin

fsm_U0: process (...) -- process defn. similar to always in verilog
begin
...
end process; -- or "end process fsm_U0;"

SPI_REGS_1 : SPI_REGS -- Instance of component SPI_REGS is named SPI_REGS_1
 generic map (width => 7) -- NOTE: no semicolon or comma here
 Port Map (
  ADDR            => ADDR_1, -- Port ADDR of SPI_REGS is mapped to ADDR_1 pin of SPI_REGS_1
  SPARE_D_B5        => SPARE_D_B5
 );

SPI_CONTROL_1 : SPI_CONTROL
 Port Map ( ...
 );

#end arch stmt
end SCHEMATIC;

CONFIGURATION
--------------------
configuration CFG_SPI_SCHEMATIC of SPI is -- cfg name is CFG_SPI_SCHEMATIC
 for SCHEMATIC -- arch being configured
    for SPI_REGS_1: SPI_REGS -- cfg component instance SPI_REGS_1 of component SPI_REGS
     use configuration WORK.CFG_SPI_REGS_BEHAVIORAL; -- says that for SPI_REGS component, use cfg CFG_SPI_REGS_BEHAVIORAL of SPI_REGS component (defined in spi_regs.vhd)
    end for;
   for SPI_CONTROL_1: SPI_CONTROL -- for SPI_CONTROL component
    use configuration WORK.CFG_SPI_CONTROL_BEHAVIORAL; -- (defined in spi_control.vhd)
   end for;
 end for;

end CFG_SPI_SCHEMATIC;

--------------------------------------------
Other files

---------
spi_typedefs.vhd
-----------
library IEEE;
    use IEEE.std_logic_1164.all;
    use IEEE.numeric_std.all;

#pkg declaration
package SPI_TYPEDEFS is

constant ACTIVE            : std_logic := '0';
constant INACTIVE        : std_logic := not ACTIVE;
constant SPI_DATA_BITS        : integer := 8;
subtype SPI_DATA_TYPE        is std_logic_vector(SPI_DATA_BITS - 1 downto 0); -- so we can access individual array element by using SPI_DATA_TYPE(0), SPI_DATA_TYPE(1), ..., SPI_DATA_TYPE(7).
signal ground: bit:=0; -- global signal declared to be used anywhere.

end SPI_TYPEDEFS;


---------
spi_regs.vhd
-----------
library IEEE;
   use IEEE.std_logic_1164.all;
   use IEEE.numeric_std.all;
library SPI_LIB;
   use SPI_LIB.SPI_TYPEDEFS.all;

#entity
entity SPI_REGS is
 Port (
  ADDR            : In SPI_ADDR_TYPE;
  SPARE_D_B5        : Out std_logic
 );
 SIGNAL sys_clk: bit :='1'; -- this is global signal as it's declared in entity.
end SPI_REGS;

#arch
architecture BEHAVIORAL of SPI_REGS is

signal BG_REG            : std_logic_vector(3 downto 0); -- this is local signal as declared within arch
....
signal SPARE_RD            : std_logic_vector(7 downto 0);

#no component declaration here as all componenets used (std gates, logic, etc) are in a pkg.
begin

#logic
RESET    <= ACTIVE when (DIG_RESET_N = '0' or PWR_ON_RST_N = '0') else -- assigns 0 to Reset if expr true else Reset assigned 1.
       INACTIVE;
CHIP_REV <= (CHIP_REV_B3, CHIP_REV_B2, CHIP_REV_B1, CHIP_REV_B0); -- chip_rev is defined as std_logic_vector(3 downto 0);

#define write process
WRITE_PARAMS: -- process label
process(RESET,SPI_SCK) -- sensitivity list

variable ADDR_INT    : integer range 0 to 2**SPI_ADDR_BITS - 1; -- variables defined

begin
 if (RESET = ACTIVE) then
  BG_REG                <= (3 => '1', others => '0'); -- implies BG_REG[3]=1 everything else =0
 elsif rising_edge(SPI_SCK) then
  if (WREN = ACTIVE) then
   case to_integer(ADDR) is
    when ADDR_00 => BG_HOLD_REG            <= DATA_WR(3 downto 0);
    when others => null;   -- default case
   end case;
  end if;
 end if;
end process;

#define read process
READ_PARAMS:
process(ADDR, ...) -- sensitivity list much larger since no clk, so data directly rd out.

variable POINTER    : integer range 0 to DATA_RD'high;

begin
 DATA_RD    <= (others => '0'); -- DATA_RD[7:0] assigned value of all 0.
  case to_integer(ADDR) is
   when ADDR_00 => DATA_RD(BG_REG'range)        <= BG_REG; -- range specifies the range
   when ADDR_10 => DATA_RD(5 downto 0)        <= MTR_OFST_REG;
            DATA_RD(6)            <= MTR_OFST_TRM_ENBL_REG;
   when others => null;   -- default case
  end case;
end process;

#o/p assignments
ENBL_AGC_LEAK        <= ENBL_AGC_LEAK_REG;

end BEHAVIORAL;

#configuration
configuration CFG_SPI_REGS_BEHAVIORAL of SPI_REGS is
    for BEHAVIORAL
    end for;
end CFG_SPI_REGS_BEHAVIORAL;

-------------
spi_control.vhd : similarly for control
------------

Running vhdl sims:
-------------------
To run sims, we need digtop_tb.vhd (similar to digtop_tb.v). 2 ways:
1. verilog tb: We have veriog file digtop_tb.v. In digtop_tb.v, we define a module "testbench" with no ports, define internal signals, creates clocks, assign initial values to required signals, and then instantiate the dut "digtop". We create a "initial begin .. end" block which provides patterns on specific io pins at varying times, and then have a $finish to finish the sim.

2. vhdl tb" we create tb_spi.vhd. It has empty entity (tb entity similar to tb module in verilog) defined, then architecture defn. Within architecture, we've internal signals to connect dut, then component "digtop" defined. then inside body of architecture, we've digtop instatntiation as "dut" with ports connected, and then multiple process to create clock, and read/write.
library IEEE; ...

entity E is == empty entity
end E

Architecture A of E is

signal SPI_CS_local : std_logic ....
component digtop Port (SPI_CS: In std_logic; ....); end component;

begin
DUT: digtop Port Map (SPI_CS => SPI_CS_local, ...);

TB: block
constant ...;
signal ...;
function FUNC_1 (STR: in string) return boolean is begin ... end FUNC_1;
#cmd interpretor process to read stimulus file and then finish the sim by asserting false (equiv to $finish)
cmd_intr: process  variable a .. begin .. read stimulus file ..loop thru each line .. at reading stim file
  assert FALSE report "stimulus complete" severity FAILURE;
end process

#clk genrator process: creates a clk of freq TB_CLK_PERIOD
CLK_GENERATOR: process begin
        TB_CLK <= '1'; wait for TB_CLK_PERIOD/2;
        TB_CLK <= '0'; wait for TB_CLK_PERIOD/2;
end process;

#spi_read, spi_wrt proces. has diff procedure inside process.
SPI_RD: process ... end process;

end block;
end A;

configuration CFG1 of E is
   for A
      for DUT : digtop
--         use configuration WORK.CFG_SPI_SCHEMATIC; => we don't use configuration for gate level netlist as digtop is verilog netlist, so no concept of configuration for verilog netlist.
      end for;
      for TB
      end for;
   end for;
end CFG1;

now, we run "irun" providing all .vhd files (exactly similar as in verilog sims).

---------------
Compile (analyze) files
---------------
To compile VHDL files, we put all src files in Source dir. Then when you start dc-shell, it creates a WORK dir for you, which is the default WORK lib for VHDL.
Then, if we want to analyze and store analyzed (compiled) results in user specified design lib, we use analyze cmd with -library option to put all compiled files in SPI_LIB dir.
dc_shell_t > analyze -format vhdl $RTL_DIR/spi_typedefs.vhd -library SPI_LIB


--------
cadence VHDL predefined package: included by default when running RC.
/apps/cds/rc/10.1-s202/tools.lnx86/lib/vhdl/std/standard.vhdl
/apps/cds/rc/10.1-s202/tools.lnx86/lib/vhdl/ieee/std_logic_1164.vhdl
/apps/cds/rc/10.1-s202/tools.lnx86/lib/vhdl/cadence/attributes.vhdl
/apps/cds/rc/10.1-s202/tools.lnx86/lib/vhdl/ieee/numeric_std.vhdl

std_logic_1164.vhdl:
--------------------
std logic file for cadence also has lot of conversion functions and basic gate functions defined. VHDL being strongly typed, conversion is needed from one type to other type. Ex:
A. and gate function   
SUBTYPE UX01    IS resolved std_ulogic RANGE 'U' TO '1'; -- ('U','X','0','1') only 4 states defined
FUNCTION "and"  ( l : std_ulogic; r : std_ulogic ) RETURN UX01;
FUNCTION "and"  ( l : std_ulogic; r : std_ulogic ) RETURN UX01 IS
BEGIN
        RETURN (and_table(l, r)); => and table defined below
END "and";
-- truth table for "and" function, o/p is always 1 of these 4 values => U,X,0,1
    CONSTANT and_table : stdlogic_table := (
    --      ----------------------------------------------------
    --      |  U    X    0    1    Z    W    L    H    -         |   |
    --      ----------------------------------------------------
            ( 'U', 'U', '0', 'U', 'U', 'U', '0', 'U', 'U' ),  -- | U |
            ( 'U', 'X', '0', 'X', 'X', 'X', '0', 'X', 'X' ),  -- | X |
            ( '0', '0', '0', '0', '0', '0', '0', '0', '0' ),  -- | 0 |
            ( 'U', 'X', '0', '1', 'X', 'X', '0', '1', 'X' ),  -- | 1 |
            ( 'U', 'X', '0', 'X', 'X', 'X', '0', 'X', 'X' ),  -- | Z |
            ( 'U', 'X', '0', 'X', 'X', 'X', '0', 'X', 'X' ),  -- | W |
            ( '0', '0', '0', '0', '0', '0', '0', '0', '0' ),  -- | L |
            ( 'U', 'X', '0', '1', 'X', 'X', '0', '1', 'X' ),  -- | H |
            ( 'U', 'X', '0', 'X', 'X', 'X', '0', 'X', 'X' )   -- | - |
    );

B. conversion functions:
FUNCTION To_StdULogic       ( b : BIT ) RETURN std_ulogic; => func declaration
FUNCTION To_StdULogic       ( b : BIT ) RETURN std_ulogic IS => function body
    BEGIN
        CASE b IS
            WHEN '0' => RETURN '0';
            WHEN '1' => RETURN '1';
        END CASE;
    END;

numeric_std.vhdl:
-----------------
implements std 1076.3 of IEEE. defines numeric types and arithmetic functions (+,-,*,/,rem,mod,<,>,=,/=,>=,<=) for use with synthesis tools. Two numeric types are defined: (The base element type is type STD_LOGIC)
UNSIGNED: represents UNSIGNED number in vector form
SIGNED: represents a SIGNED number in vector form (rep in 2's complement)

package numeric_std is
function "+" (L, R: UNSIGNED) return UNSIGNED; => function declaration
  function ADD_UNSIGNED (L, R: UNSIGNED; C: STD_LOGIC) return UNSIGNED is => called in function "+"
    constant L_LEFT: INTEGER := L'LENGTH-1;
    alias XL: UNSIGNED(L_LEFT downto 0) is L;
    alias XR: UNSIGNED(L_LEFT downto 0) is R;
    variable RESULT: UNSIGNED(L_LEFT downto 0);
    variable CBIT: STD_LOGIC := C;
  begin
    for I in 0 to L_LEFT loop
      RESULT(I) := CBIT xor XL(I) xor XR(I);
      CBIT := (CBIT and XL(I)) or (CBIT and XR(I)) or (XL(I) and XR(I));
    end loop;
    return RESULT;
  end ADD_UNSIGNED;

  function "+" (L, R: UNSIGNED) return UNSIGNED is
    -- cadence synthesis BUILTIN_OPERATOR
    constant SIZE: NATURAL := MAX(L'LENGTH, R'LENGTH);
    variable L01 : UNSIGNED(SIZE-1 downto 0);
    variable R01 : UNSIGNED(SIZE-1 downto 0);
  begin
    if ((L'LENGTH < 1) or (R'LENGTH < 1)) then return NAU;
    end if;
    L01 := TO_01(RESIZE(L, SIZE), 'X');
    if (L01(L01'LEFT)='X') then return L01;
    end if;
    R01 := TO_01(RESIZE(R, SIZE), 'X');
    if (R01(R01'LEFT)='X') then return R01;
    end if;
    return ADD_UNSIGNED(L01, R01, '0');
  end "+";
---
-------------------------------

generic:
------
generic can be set in 2 ways:
ex: entity flea is
generic (  PreLoadFile: STRING := "/dev/null";
           MODE: BOOLEAN := FALSE;
       VAL: std_logic_vector (7 downto 0) := "01011001");
port ( ... );

1. override using genric (similar to defparam): similar to verilog, we cannot do
   generic a_cont_deg.SREG_SIZE  = 3; // NOT allowed in vhdl

2. override during instantiation: similar to verilog. NOTE: tfilter is vhdl, but this file is verilog, so exact verilog syntax can be used for this file to override generics
ex: tfilter #(.MODE(1),.PreLoadFile(my.txt),.VAL(8'b0010_1011)) a_cont_deg (.reset(..), ...);

3. via irun cmdline:
//since designs are usually mix of verilog/vhdl, we need to use . for navigating verilog hier and : for vhdl hier.
irun -generic 'veridian_tb.u_h1.BANK_U0:PreLoadFile=>"flash.img"' -generic "veridian_tb.u_h1.BANK_U0:VAL=>11000011" \ => here everything upto u_h1 is verilog, but BANK_U0 is vhdl, so we use : for BANK_U0 but . for everything before then. NOTE: "" or '' not really necessary above. i.e this works too:
irun -generic veridian_tb.u_h1.BANK_U0:PreLoadFile=>"flash.img" -generic veridian_tb.u_h1.BANK_U0:VAL=>11000011

NOTE: if using it in csh script, we may want to define whole generic thing as variable. We do it as follows:
set BANK0 = "-generic veridian_tb.u_h1.BANK_U0:PreLoadFile=>"'"flash_boot.img"' //NOTE '. pair of '' protects all special char within it from shell interpretation. pair of "" allows shell to interpret ! and $.
set VAL   = "-generic veridian_tb.u_h1.BANK_U0:VAL=>00101001"
irun ${BANK0} ${VAL} ...

------------------------