Reading and Writing Binary files in Systemverilog

Reading a binary file in SystemVerilog might be required occasionally. I have tried to capture some basic information as a guide for someone starting out. 

Comments are embedded in the code: 

	function void read_binary_file();
	int fread;
	bit [7:0] rdata;
	int unsigned line_count;
	line_count=0;
	//Open file with binary read mode("rb"), b here specifies binary
	fread=$fopen("binary_file.bin","rb");
	if(fread==0)
	`uvm_error("NO_FILE_FOUND","Couldn't open file binary_file.bin for reading")
	//read until end of file is reached
	while(!$feof(fread)) begin
	//fgets reads one line at once and $fgetc reads a byte (a character) at once
	$fgets(rdata,fread);
	line_count+=1;
	//Do what's required of data here
	`uvm_info(get_name(),$sformatf("byte number %0d, Value= %08x",line_count,rdata),UVM_MEDIUM)
	end
	//close the opened binary file
	$fclose(fread)
	endfunction

view raw reading_binary_file_systemverilog.sv hosted with ❤ by GitHub

Similarly an example for writing a binary file

	function void writing_binary_file(int unsigned total_bytes_to_write=32);
	int fwrite;
	bit [7:0] wdata;
	//Open file with binary write mode("wb"), b here specifies binary
	fwrite=$fopen("binary_file.bin","wb");
	if(fwrite==0)
	`uvm_error("NO_FILE_FOUND","Couldn't open file binary_file.bin for writing")
	//iterate until all intended bytes are written
	for(int i=0,i<total_bytes_to_write,i++) begin
	//generate current random byte to write
	wdata=$urandom_range(0,255);
	//fwrite with %c writes only 1 byte at a time, use "%u" format for writing 32bit data
	$fwrite(fwrite,"%c",wdata);//Note that fwrite doesn't introduce newline character unless added with \n
	end
	//close the file
	$fclose(fwrite)
	endfunction

view raw writing_binary_file_systemverilog.sv hosted with ❤ by GitHub

Useful Vim Commands/Tips

	#Page up:
	Ctrl+u
	#Page down:
	Ctrl+d
	#Place curzor to center:
	Zz
	#select entire line from anywhere
	Shift+v
	#Visual mode:
	Control+v
	#To append to end:
	Ctrl+v
	$
	A(capital A)
	#Replace mode(similar to insert mode):
	R(capital R)
	#Change small letters to BIG or vice versa
	Select the letters and then press ~
	#Move around in vim:
	j ==> go down(think of it like fisherman J going down)
	k ==> go up(think of it as Kite)
	l ==> go right(next to kite)
	h ==> go left(next to jack)
	#To jump in column
	press any number followed by l
	#Increment number by 1
	ctrl+a
	#Decrement number by 1
	ctrl+x
	#Also increment by x
	x+ctrl+a
	#use version 8 in linux
	module load vim/8.0.0176
	#Increment in series(Below works in version 8 or above only):
	Ex:
	ctrl[0]
	ctrl[0]
	ctrl[0]
	ctrl[0]
	ctrl[0]
	ctrl[0]
	ctrl[0]
	ctrl[0]
	to
	ctrl[1]
	ctrl[2]
	ctrl[3]
	ctrl[4]
	ctrl[5]
	ctrl[6]
	ctrl[7]
	ctrl[8]
	Go to virtual mode and select vertically
	g followed by ctrl+a
	#delete word under the cursor
	d+w
	#go to end of word on the cursor
	e
	#find out full path of current file, % is replaced by fullpath of current file
	!ls %

view raw Useful_vim_commands hosted with ❤ by GitHub

Parsing file in systemverilog

We often need to read file generated by tools and use the data in systemverilog task/function to decide pass or fail for many verification tasks.

Systemverilog is not a language that is built for text parsing but it does provide some basic system functions to play with. Key is to read the data which is simple and easy to parse. one way is to pre process the data in external perl script which then be read by systemverilog.

Here is the sample file where the real numbers at the end of the file are to be extracted and result to be used in the task:

	sample_checks_184ms 47166.67
	sample_checks_370ms 41333.33

view raw sample_file_parsing.sv hosted with ❤ by GitHub

Below system tasks are used

$fopen()   Open file for reading

$feof()      Identify end of file

$fgets()    read the line from file

$fscanf()  parse a line

Sample Systemverilog Task for parsing :

	task parse_file_sv();
	int samplefile;
	string line_from_file, sub1;
	real sub2;
	string srcdir;
	if($value$plusargs("SRCDIR=%s", srcdir))
	`uvm_info(get_name(), $sformatf("+SRCDIR:%s",srcdir),UVM_MEDIUM)
	else
	`uvm_error(get_name(), $sformatf("+SRCDIR is not passed"));
	samplefile=$fopen({srcdir,"/log.txt"},"r");
	//check if path of logfile path is valid
	if(!samplefile)
	`uvm_error(get_name(),{srcdir,"/log.txt missing"})
	while(!$feof(samplefile) && $fgets(line_from_file, samplefile)) begin
	void'($sscanf(line_from_file, "%s %f\n", sub1, sub2));
	`uvm_info(get_name(), $sformatf("sub1=%s,sub2=%0f",sub1,sub2),UVM_MEDIUM)
	//operate on collected data or store in stack here
	end
	$fclose(samplefile);
	endtask

view raw parse_file_systemverilog.sv hosted with ❤ by GitHub

A snippet of task result:
sub1=sample_checks_184ms,sub2=47166.67
sub1=sample_checks_370ms,sub2=41333.33

Useful Synopsys ICC2(APR tool) Commands

	#start GUI
	icc_shell>start_gui
	#report max transition constaints
	icc_shell> report_constraint -max_transition -verbose
	#report timing with transition with pins (through that pin)
	icc_shell> report_timing -thr <instance_name>/<pin_name>
	#report timing from register clk to d of next flipflop
	icc_shell> report_timing -to <instance1_name>/<pin_name> -from <instance2_name>/clk
	#see complete clock path
	icc_shell>report_timing -to <pin_name> -path_type full_clock_expanded -delay max
	#high light path in GUI
	icc_shell>change_selection [get_timing_paths -to <instace_name>/<pin>]
	#see clock tree information
	icc_shell>report_clock_tree
	#shows the worst path timing with the given clock
	icc_shell>report_timing -group <group_name>
	#prints only end points
	icc_shell>report_timing -to readary -path_type short -max_paths 5
	#summary of all
	icc_shell>report_qor
	#insert buffer
	icc_shell>insert_buffer <instance_name>/d -lib_cell <lib_name>
	#insert clock inverters
	icc_shell>insert_buffer <instance_name>/<clk pin> -lib_cell <lib inverter> -inverter_pair
	#legalize placement incrementally
	icc_shell>legalize_placement -incremental
	#list the lib cells
	icc_shell>get_lib_cell
	#set false path
	icc_shell>set_false_path -from <instance1_name>/<pin_name> -to <instance2_name>/<pin_name>
	#list of all cells matching with instance name and also sequencial elements
	>get_cells *<name>* -filter "is_sequential==true"
	#finding sizeof of collection
	>sizeof_collections [get_cells *<name>* -filter "is_sequential==true"]
	#show the terminal names
	>get_terminals *<name>*
	#check the direction of port
	>get_attribute [get_ports <port_name>] direction
	#check if constant value is driven on any pin
	>get_attribute [get_pins <instance_name>/<pin>] constant_value
	#get any standardcells with xnor in the clock path
	>filter_collection [all_fanout -clock_tree -only_cells -flat -levels 1000000 ] "ref_name=~*xnor*"
	#list of all cells from previous flipflop
	>lsort -uniq [get_attribute [all_fanin -to <instance_name> -flat -only_cells] -fl_name]
	#get exceptions
	>get_exceptions -from <instance_name>
	#report exceptions
	>report_exceptions
	#possible list of command with given string
	icc2_shell> help *except*
	all_exceptions # Create a collection of exceptions in a mode
	ctm::get_exceptions # Returns ctmesh stopping cells/nets/pins collection
	ctm::is_exception # Check if -pin|-net|-cell is in ctmesh stopping
	get_exception_groups # Create a collection of exception groups
	get_exceptions # Create a collection of timing exceptions
	remove_supernet_exceptions # Removes supernet transparent pins
	report_exceptions # Report timing exceptions
	report_supernet_exceptions # Report supernet transparent pins
	set_supernet_exceptions # Mark supernet transparent pins
	#lists all the attibutes related to net
	>list_attributes -class net -application
	#filter collections based on the attribute
	>filter_collection [get_flat_cells *] "size_only==true && full_name=~*<name>*"
	>filter_collection [all_fanout -from <instance_name>/pin ] "full_name=~*<name1>* || full_name=~*<name2>*"
	#set don't touch attribute on all nets except nets connected to matching pin1 and pin2
	>set_dont_touch [get_nets -of_objects [get_pins -of_objects [get_cells *<instance_name>*] -filter "name!=<pin1> && name!=<pin2"] -filter "full_name=~*<net_name1>* || full_name=~*<net_name2>*]
	>set_attribute [get_nets -of_objects [get_pins -of_objects [get_flat_cells *<instance_name>* -filter "full_name!~*<match_name>*"] -filter "name!=<pin1> && name!=<pin2>"]] dont_touch true
	#report name rules
	>report_name_rules
	#define the rule if not there, Lower case only + numbers and _
	>define_name_rules LC_ONLY -allowed "a-z 0-9"
	#define renaming rule and then apply rules
	>define_name_rules my_map_rule -map {{"first","second_renamed"}}
	>change_names -rules my_map_rule
	#rename instances
	>set_attribute -objects [get_cells {{instance[1]_abcd}}] -name name -value instance_1_abcd
	#stop propogating clock
	>set_clock_sense -logical_stop_propagation <instance_name>/clk
	#report clock gating checks
	>report_clock_gating_check
	#reports all the violations
	>report_constraints -min_delay -all_violators -scenarios <scenario name>
	#reports if clock property is on the pin
	>get_attribute [get_selection] clocks or get_attribute [get_pins <instance_name>/<pin_name>] clocks
	#replace a cell with different size or refname, sometime helps to resolve shorts
	>change_link [get_cell <instance_name>] <lib_cell_to_be_replaced.
	#unfix objects(if only fixed) so that it can be moved on legalize placements
	>set_fixed_objects [get_cells <instance_name>*] -unfix
	#getting the lower left x for bbox, similarly upper right x(bbox_urx) and upper right y(bbox_ury)
	>get_attribute [gs] bbox_llx
	#get app options
	>get_app_options *hold*
	#hold fixing in icc2, run this after cts
	>set_app_options -name clock_opt.hold.effort -value high
	>set_app_options -name refine_opt.hold.effort -value high
	#finding the proc source
	>get_proc_source <proc_name>
	#max transition report
	>report_constraints -all_violators -max_transition > transition.txt
	#reports pvt etc about each corner
	>report_corners
	#reports derate setting for current corner
	>report_timing_derate
	#choose layer for a net
	>set_routing_rule -min_routing_layer <min_metal> -max_routing_layer <max_metal> {net_name1 net_name2}
	#set clock balance points
	>set_clock_balance_points -consider_for_balancing true -balance_points "instance1/clk_pin instance2/clk_pin"

view raw icc2_useful_commands.txt hosted with ❤ by GitHub

Least Recently Used(LRU) algorithm implementation in Hardware

LRU algorithm is one of the most commonly used cache page replacement algorithms. It’s often easy to imagine the implementation of LRU using linked list structure in software but hardware implementation could be tricky and requires some thoughtful analysis. Here I have made an attempt to put together steps of matrix method of LRU implementation in Hardware which could eventually be translated to code in Verilog or VHDL

Matrix implementation requires n*n matrix for n location cache i.e 4*4 memory(16 Flipflops) for 4 location cache. The algorithm should track all the locations as it gets updated and should output the least recently used location (or index of cache).

Let’s start with simple 4 location cache and then generalize the solution for n location cache.

4 location cache with each location of 8 bits:

4 * 4 matrix to store the history and help calculate the least recently used location in cache

Total of 16 Flipflops for 4 location cache 

We would save the information of relative age of each location with respect to other

Say    A > B   =>  A is older than B

          A > C   => A is older than C

Let’s represent this in the matrix as below:

Diagonal is always 1 as it tries to compare same elements like A vs A, B vs B etc

Also it’s easy to see that A is older than B  =  ! (B is older than A)

(A > B) =  !(B>A)

With the above logic, matrix would look like below:

It’s easy to see that left half of matrix across diagonal is exactly opposite to right half.

Right half of the matrix would entirely be enough to get the age relation between cache locations

Steps:

1) Initialize the matrix to any known value. Say D > C > B > A

     i.e, D is the oldest and A is newest location

Note that diagonal value is always one

2) If location I is accessed then row I is set to zero and column I is set to one except for diagonal. 
     Update the matrix every time cache is accessed

3) Oldest location will be the location for which 'AND' of each column is equal to 1

     i.e,  &[columns of location]==1

It’s turns out to be true to D as all of its columns has 1

Let’s take an example and see if this works

Say order of access of cache is C,B,D,A è oldest location at the end of this should be C

a) Initialization to D > C > B > A

    b) C is accessed  => C is the most recent. Change all of c rows to zeros and columns to one

All of D columns are one and D should be the oldest at this point of time.

From above matrix, we can also derive that

 A > B = 0 , A > C =1, A > D = 0 , B > C =1 , B > D = 0 , C > D = 0 
   => C < A < B < D

    c) B is accessed. i.e, C followed by B. Change all B rows to zeros and B columns to ones

   New matrix would be as below:

D is the oldest as all of it’s columns are 1

    d) D is accessed. C followed by B followed by D. Change all B rows to zero and B columns to one

  New matrix:

A is the oldest and least recently used

     e) A is accessed. i.e, C followed by B followed by D followed by A

C column is all one and hence the oldest as expected

Avoiding race around in Assertions

I have been coding assertions a lot recently to verify certain functionality at SOC/block level. I ended up with some false failures in regressions mainly due to Systemverilog race around and I could not find good online guidelines to avoid such conditions. After researching, I am putting up some learnings here and many of these directions are directly coming from CummingsSNUG2006Boston_SystemVerilog_Events paper.

Broadly assertions can be classified into 2 categories

1. Concurrent Assertions – describes logic behavior of signals that spans over time
2. Immediate Assertions – describes logic behavior of signals at an instant of time

Understanding SystemVerilog Scheduling semantics is crucial to understand simulation induced Race around conditions. I am summarizing some important aspects below:

Simulators simulate the Testbench based on IEEE Scheduling Semantics of SystemVerilog. A single and smallest timeslot can be visualized to have many regions as shown below 

Event Regions Diagram in SV(Picture taken from CummingsSNUG2006Boston_SystemVerilog_Events Paper)

Each of the regions(like preponed, active, observed, reactive) is associated with specific functionality.

Assertions are passive and they do not drive any stimulus into the design. If proper coding guidelines for RTL/Testbench are followed, we should not see any race around conditions.

Race around in Concurrent Assertions

All the signals in concurrent assertions are sampled in the preponed region before the clocking event. Values do not change in the preponed region(Read-only region) and hence sampled values of signals do not change during that particular time step of evaluation(in the observed region) multiple times. Hence if RTL/Testbench guidelines are followed, there is no special care to be taken while writing concurrent assertions as it is inherently protected.

Also, note that if ‘event.triggered’ is used in assertion then the current value(during that timestep) of the event is used for evaluation in the observed region. ‘triggered’ is a property of an event – evaluation do not happen until the statement is executed. If the event is getting updated in active region then triggered property will be a new value when evaluated in the observed region

Race around in Immediate Assertions

Simple immediate assertions are part of sequential statements (Ex part of ‘always’ construct) and their sampling & triggering depends on where they get executed.

If you observe the Event region, certain signals may get evaluated twice or more depending on when/if the value gets updated and hence might result in simulator seeing 2 or more values in one single time step although one values eventually settles. This could be one source of a possible misfire of immediate assertion. Signal value getting updated twice in a single step and during these scenarios $display prints 2 values of the same variable while $monitor/$strobe which executes in Postponed region prints only one value.

Looking at the possibility of assertions action block triggering twice or more than in immediate assertion, Systemverilog committee came up with a "final" deferred assertion to execute in the "postponed" region which is the last region before advancing time and all the values are settled to their final value. 

There 2 kinds of deferred assertions in SystemVerilog

1.  Observed deferred assertion –

·         Evaluation of immediate assertion is postponed to observed region.

·         Problem of glitch still exists if one decides to use program block which might      trigger loop back from reactive to active and multiple execution

·         Use #0 after assert keyword

Ex

assert_check: assert #0 (cs == 2'b00 && enable==1’b1) else $error ("cs and enable are in wrong combination");

2. Final deferred assertion

·         Evaluation of immediate assertion is postponed to postponed region

·         Works for all kinds of situation and most recommended

·         Use final keyword after assert keyword

Ex:

assert_check: assert final (cs == 2'b00 && enable==1’b1) else $error ("cs and enable are in wrong combination");

Binding in Systemverilog

Assertions are written both by design engineers and verification engineers depending on what is being checked and wherein the design hierarchy. If Assertions reside inside design modules which are going to be synthesized then these assertions which solely meant for checking/verification have to be enclosed inside compilation directives like ifdef so they can be hidden from Synthesis tools. As an alternative, Systemverilog provides bind feature which allows specific modules which contain all the assertions to be bound during elaboration. This feature essentially instantiates assertion module inside design module and all the assertions behave as if they reside inside the design. This enables engineers to keep verification code separate from design code.

Syntax:

bind <target RTL module> [:<name of the target instances>] <assertion module> <binding instance name> (<port list>);

where
[<name of target instance>] is optional. If nothing is specified, binding is done on all the target RTL module instances

<assertion module> is the module which contains all the assertion code.

<port list> is the port connections from target RTL module to assertion module.

Assertion module is like any other module. Keep below points in mind:

• Define all the inputs required for assertions as input ports.
• No outputs from assertion module as it is strictly not for driving anything into the design
• Input Port names can be name. If you decide to keep the same port names as the net name of target design module then you while binding .* would automap the connections. Connect by name if the input port name is different from the net in the target design module
• If any internal probes from instances below target design module are required for the assertion then same can be made as input to the assertion module and passed as an argument while making assign hierarchical probing at the target module. This should be avoided for any synthesizable block and usage is mostly intended for bmod assertions which requires internal probing

Ex:
Binding to all modules with name module_name:
bind module_name inst2_assert inst2a(.mode(mode_value),
                                                               .order(order)
                                                             );


Binding to the specific instance with name inst2 (Instance binding):
bind module_name:inst2 inst2_assert inst2a(.mode(mode_value),
                                                                       .order(order)
                                                                       );

Ex:

	//design example
	module design_module(
	input logic enable,
	input logic reset,
	input logic clk,
	output logic active);
	logic [1:0] fsm_cs;//current state
	logic [1:0] fsm_ns;//next state
	always @(posedge clk or posedge reset)
	begin
	if(reset)
	fsm_cs <= 2'b0;
	else
	fsm_cs <= fsm_ns;
	end
	always_comb
	case(fsm_cs)
	2'b00: if(enable==1'b1 && reset==1'b0)
	fsm_ns=2'b1;
	2'b01: if(enable==1'b0 || reset==1'b1)
	fsm_ns=2'b0;
	default: fsm_ns=2'b0;
	endcase
	assign active = (fsm_ns==2'b01) ? 1'b1:1'b0;
	endmodule
	//assertion module
	module assertion_module(input logic fsm_state,input logic enable,input logic reset,input logic clk);
	property fsm_check();
	@(posedge clk)
	disable iff(reset) $rose(enable)|=> (fsm_state==2'b1);
	endproperty
	FSM_ASSERT:assert property(fsm_check) else `uvm_error("assertion_module", $sformatf("fsm assertion failed");
	endmodule
	//testbench top
	module top();
	logic en,reset,tester_clk,active_out;
	initial
	begin
	tester_clk=1'b0;
	forever #10 tester_clk=~tester_clk;
	end
	design_module mydut(.enable(en),.reset(reset),.clk(tester_clk),.active(active_out));
	//binding assertion module(assertion_module) to design module(design_module)
	bind design_module assertion_module assert_instance(.fsm_state(fsm_cs),.enable(enable),.reset(reset),.clk(clk));
	initial
	begin
	#5;
	reset=1'b1;
	#10;
	reset=1'b0;
	#10
	en=1'b1;
	#100;
	$finish;
	end
	endmodule

view raw binding_assertion.sv hosted with ❤ by GitHub