2022 2nd International Conference on Intelligent Technologies (CONIT)

Karnataka, India. June 24-26, 2022

Coverage of Meta-Stability Using Formal

Verification in Asynchronous Gray Code FIFO
Shivali Mamta Khosla
Department of Electronics and Communication Engineering Department of Electronics and Communication Engineering
Dr. B.R. Ambedkar National Institute of Technology Dr. B.R. Ambedkar National Institute of Technology
Jalandhar, Punjab Jalandhar, Punjab
[Link]@[Link] khoslam@[Link]

Abstract—In Formal Verification Environment, setup time and might be occasional. Whenever failure happen, output value
hold time are not honored by formal verification tool. To will go to an indeterminate state which means its value will
analyze the impact of metastability on functionality of the be in the middle of two valid states. The invalid output value
design in formal verification environment, buffer has been will sustain for time duration which is indefinite before
designed. Buffer induces the delay of either ‘0’, ‘1’ or ‘2’ clock output get resolve on its own or output may get delay before
cycles leading to metastability in the pointers of Asynchronous it makes the normal transition. In each of the event, there is
Gray Code FIFO in formal verification environment. an occurrence of metastability. FIFO are the buffers used to
Reference code has been written which describe the
2022 International Conference on Intelligent Technologies (CONIT) | 978-1-6654-8407-7/22/$31.00 ©2022 IEEE | DOI: 10.1109/CONIT55038.2022.9848195

store the data. FIFO find its use in many of the digital system
functionality of Asynchronous Gray Code FIFO in ideal case.
applications [3]. FIFO stands for First in first out which
Using formal equivalence checking, output of FIFO obtained
from design provided by the designer, is compared with the
signifies that the data which is first to be written in a buffer
output obtained from the reference code of FIFO. Formal will be first to be read from it. There are two pointers which
verification properties are written to do the verification of the keeps the track of addresses from where the data is to be read
design and check if the design is working as predicted or to be written in the FIFO. One is write pointer and another
specifications. Coverage written ensures no corner case is one is read pointer. The address to which write pointer is
skipped which may lead to escapism of potential design bugs. pointing to will be the one where the next data will be
The command language script containing the verification written while the address to which read pointer is pointing to
program has been run to invoke the JasperGold Tool. will be the one from where the data will be read.
Comparative analysis has been done between the waveforms Corresponding to both read and write operation, there are
obtained from the design including a buffer and the design two clock domains present. Two clock domains are write
without including a buffer. If both the waveforms are not same clock domain and read clock domain respectively on which
which means metastability has influenced the functionality of write and read operations will be performed. In synchronous
the design. So, to overcome the effect of metastability on FIFO, both read and write operations are performed on single
functionality of the design, there is need to add more clock domain only which means in this case both read and
synchronizers in the design. While if the waveforms obtained write clock domain are alike. While in asynchronous FIFO,
from the design with and without buffer are same, it means read operation is performed in rclk clock domain while the
synchronizers / Meta flops already present in the design are
write operation is performed in wclk clock domain. It is quite
enough to deal with the metastability which may arise during
difficult to deal with the circuits /systems which work in
functioning of the design.
different clock frequencies because there is a possibility for
Keywords—Meta-stability, Formal Verification, Formal the occurrence of metastability in the output of such
Environment, Asynchronous Gray Code FIFO circuits/systems when input is asynchronous in nature and
changes its value in the aperture window [13]. Synchronizers
are being used to avoid the metastability effects [2]. Formal
I. INTRODUCTION verification methods have become reliable methods to verify
The demand for the semiconductor technology is the correctness of the design [4]. As setup time and hold time
increasing rapidly day by day leading to the rapid growth of are not honored by formal verification tool so it’s difficult to
electronic industry since past 15 years. The capabilities of figure out the stability of input while doing the formal
the technology industry are also growing as focus of the verification of the designs which are working in two different
businesses is inclined more towards features and setting high clock domains. Formal verification plays an important role to
targets. So, with the increase in the complexity, there is a do the verification of such asynchronous designs as it helps
need to ensure the reliable transfer of data among different to eliminate the bugs, which might be present in the design,
parts of the system working at different clock domains. at early stage.
Digital systems lead to the occurrence of metastability when
signals which are asynchronous in nature combine in such a As setup time and hold time are not honored by formal
manner that the resultant output signal take the state which is verification tool hence the metastability coverage is not
indeterminate [1]. Synchronous systems have definite being done in the formal verification environment. In this
relation w.r.t clock. Output always takes some valid value paper, method has been proposed to inject the metastability
within the delay time of propagation which is specific for a in the formal verification environment of the design and then
device if the relation between the setup time and hold time is formal verification properties are written to check if the
being adhered. There isn't any fix relation between the data design is working as predicted specifications. A buffer has
and clock for asynchronous systems, so there are chances for been designed which injects the delay of either ‘0’, ‘1’ or ‘2’
the occurrence of failure in setup time and hold time which clock cycles which means metastability get injected in the
formal proof verification environment for the pointers of

978-1-6654-8407-7/22/$31.00 ©2022 IEEE 1

Authorized licensed use limited to: VIT University- Chennai Campus. Downloaded on February 06,2026 at [Link] UTC from IEEE Xplore. Restrictions apply.
asynchronous gray code FIFO. Reference code is written to synchronization circuits is very critical task. So, verification
duplicate the functionality of FIFO on how FIFO is predicted of asynchronous circuits is very essential. But due to the
to perform. Formal equivalence checking is performed to synchronization problems, verification of such circuits is not
check if both RTL design and reference code are behaving in straightforward. Simulation is effective to analyze only
similar fashion. The properties are written to check if the single synchronizer. In the SOC, which is very large,
design is working as per predicted specifications. Assertions simulation will be ineffective to analyze the correctness of
are written in System Verilog to check the correctness of many synchronizations. Formal verification comes into
design specifications [5]. Coverage plays an important role in picture which helps to analyze the design for entire input
the verification of the design. It helps to ensure that all the space instead of some specific input test cases, as done by
scenarios which are of interest are being covered while doing simulation, thereby giving more confidence [6], [15].
the verification hitting all the corner cases so that there is no
escapism of potential design bugs.
The paper is organized in 6 sections. Section 2 describes
the metastability which arises in Asynchronous FIFO and
gives an overview of formal verification technology. Section
3 describes the design and modelling of RTL for
asynchronous gray code FIFO and a buffer designing
methodology for injecting the metastability through random
delays in formal verification environment in the pointers of
Asynchronous Gray Code FIFO. It also discusses about the
generation of fastest clock on which properties which have
set signal under the cone of influence of both read and write
clock domain are concurrently adhered. Section 4 provides
the description of formal verification properties which are
written and implemented to do the formal verification of
Asynchronous Gray Code FIFO and the command language Fig. 1. Cross clocking of input from clock 1 to clock 2.
script writing which is run to invoke the JasperGold Tool.
Section 5 presents the results, in the form of snippets of the In Asynchronous Gray Code FIFO, it is assumed that
waveforms in JasperGold Tool. Section 6 discusses the good synchronizer has been selected for the synchronization
conclusion and future scope of the work. of the pointers which are in two different clock domains. For
the formal verification of Asynchronous gray code FIFO, a
buffer has been placed along with synchronizer. Buffer
II. COVERAGE OF METASTABILITY IN ASYNCHRONOUS injects the delay in pointers of the design which can be either
GRAY CODE FIFO USING FORMAL VERIFICATION '0', '1' or '2' clock cycles thereby leading to metastability in
the pointers of the Asynchronous gray code FIFO in formal
A. Metastability in Asynchronous FIFO verification environment. Then, formal verification
When there are violations in setup time and hold time in properties are written to check if metastability has an impact
any circuit element, as a result, output might take some on functionality of the design even in the presence of
unpredictable state. Such state which is not determined is synchronizers in design.
known as metastable state which is also known as quasi
stable state [1]. When this metastable state finishes, circuit B. Formal Verification Technology
output takes the value either '0' or '1'. This process is referred During the design project cycle, a lot of time is being
to as metastability. Fig. 1 shows the cross clocking of input spent in the verification which is troublesome. Today, many
from clock 1 to clock 2. companies use formal verification to verify if the designs are
functioning as predicted specifications. Formal verification is
There are various reasons for the occurrence of the main aspect in the strategy of the verification [4]. The
metastability. Some of them are: tools used for formal verification has fasten the verification
1. Input signals are asynchronous in nature. process. To meet the functionality as predicted
2. If there is high clock skew present which means specifications, code is being written by RTL designers in
FIFO rise time and fall time are greater than the Verilog or System Verilog. Once code depicting the
values which are tolerable. requirements needed in the design is completed. It's the
3. If both the interfaces are working in different clock responsibility of verification engineer to verify the code to
frequencies or at different phases. ensure that the code which RTL designer has provided is
functioning according to the specifications. When it comes to
4. If the total delay present in the circuit causes change
formal verification, the verification environment doesn’t
in input data inside the aperture window of setup require any stimuli for running the test. The formal tool will
time and hold time. explore all possible input state space in the design to verify
MTBF which stands for Mean time between failure gives the correctness of the design specifications. In formal
the information of average time which is possible between verification, assertions based on design specifications are
the two failures occurred in succession [12]. In the latch, being written [7]. The top module binds to SV and the
which is being driven by asynchronous inputs, there are the assertion file which is instantiated in the top module should
chances of metastability. Therefore, there is a need to contain all the required assertions needed to verify in the
compute reliability of failure caused by metastability [2]. design. There are many tools available for formal verification
Synchronizers are used in the design to minimize the of design but the tool which is used for verifying
probability at which failure occurs. Designing of

2
Authorized licensed use limited to: VIT University- Chennai Campus. Downloaded on February 06,2026 at [Link] UTC from IEEE Xplore. Restrictions apply.
Asynchronous gray code FIFO design proposed in this paper comparison is performed between synchronized write pointer
is JasperGold tool. JasperGold tool is the cadence tool used and read pointer as well as synchronized read pointer and
for the verification and checking of the design [8]. When tool write pointer to generate two signals which are FIFO empty
command language script (.tcl) is run to invoke the formal signal and FIFO full signal respectively. Design model for
tool, the tool will analyze and elaborate all the system Asynchronous Gray Code FIFO that has been exercised in
Verilog files included in the environment. Then, properties this paper consist of 6 modules which are described briefly
are being run by the formal engineer to verify the correctness below: [10]
of the design. For every assertion, JasperGold tool will create
related cover for that assertion. Assertions are always written 1. Async_fifo_top_rtl.v: This is the topmost Verilog
on the output of the design because assertions are used to module which acts as a wrapper in which all other
check if the design is working correctly as per the modules has been instantiated and includes all the
specifications which can be done only by observing the clock domains. If FIFO is a part of ASIC design,
output of the design which should be same as that of then this top wrapper module can be discarded to
predicted output. Failure of an assertion leads to two allow grouping of other modules.
possibilities. The first possibility can be the presence of 2. Fifomem.v: This is the memory buffer module of
potential bug in the design. It is essential for the code FIFO which can be access in both read and write
designer to be aware of such bugs present in the code. domain.
Another possibility can be that the specifications of the 3. Sync_r2w.v: This module performs the
design which are available are incorrect. In either of the case synchronization of read pointer in write clock
which might be, there will be release of RTL code and revise domain. The synchronized pointer obtained at the
for next patch. If all the properties which are written for the output is used to check the FIFO full condition. If
correct functionality of the design as predicted passes, it FIFO seems to be full after doing the comparison,
means there is no bug being discover in the RTL design. then wptr_full status flag is asserted high.
Another step will be to check the coverage on the 4. Sync_w2r.v: This module is used to do the
functionality of the design. Verification is completed if synchronization of the write pointer in read clock
sufficient coverage report has been obtained. With the help
domain. The synchronized pointer obtained at the
of assertion language, each of the specifications which are
output is used to check the FIFO empty condition.
specified in natural language transform to the properties in
formal. Instantiation of the statement is done with the use of If FIFO seems to be empty after doing the
assertions. comparison, then rptr_empty status flag is set high.
5. Rptr_empty.v: This module works in the read clock
domain and employs the logic for the empty status
III. DESIGNING OF ASYNCHRONOUS GRAY CODE FIFO AND
flag generation.
METHODOLOGY FOR INJECTING META-STABILITY IN FORMAL
6. Wptr_full.v: This module works in the write clock
VERIFICATION ENVIRONMENT
domain and employs the logic for full status flag
Considering Asynchronous FIFO, work of formal generation.
verification engineer is to first create the verification plan,
writing constraints for the property, writing script for formal The schematic obtained for the design is shown in Fig. 3.
verification and then debugging of results [9]. The formal
verification model is shown in Fig. 2.

Fig. 2. Formal Verification Model

A. Design and Modelling of RTL for Asynchronous gray Fig. 3. Schematic of Asynchronous gray code FIFO
code FIFO
Asynchronous FIFO is use to transfer the data between B. Metastability Injection in Formal Proof Verification
two different clock domains. For analyzing the FIFO Environment
operating in two different clock domains, gray pointers are To inject the metastability in formal proof verification
used because adjacent count words in gray code differ by environment of asynchronous gray code FIFO, buffer has
only one bit [11]. The read and write gray pointers are then been designed. Buffer will inject the random delays which
synchronized in their opposite clock domains respectively. It replicates the presence of metastability in the pointers of the
means that write gray pointer synchronizes in the read clock design while the pointers cross their respective clock domain
domain while the read pointer synchronizes in the write to the other clock domain. Fig. 4. depicts the method used
clock domain. After the synchronization of the pointers, for buffer designing. Buffer used to inject the metastability in

3
Authorized licensed use limited to: VIT University- Chennai Campus. Downloaded on February 06,2026 at [Link] UTC from IEEE Xplore. Restrictions apply.
the design exercised in this paper has 2 stages but it may
vary. Depending on the aperture window of the setup time
and hold time, number of stages for buffer are decided.
Larger the aperture window, more will the impact of
metastability on design functionality. Each stage will induce
the delay of either ‘0’ or ‘1’ clock cycles in the data flow
path of buffer. As, 2nd stage buffer has been used in this
design, so maximum delay which can be introduced by
whole buffer system will be either ‘0’, ‘1’ or ‘2’ clock Fig. 6. Second buffer stage introduces either delay 0 or 1 between the
cycles. output of buffer stage 1 and the output of buffer stage 2.

C. Methodology for Buffer Designing D. Generation of fastest clock

The method sequence for injecting the delay has been There is the requirement of fastest clock in the design
described below: from which read clock for read pointers and write clock for
As can be seen in Fig. 5 Buffer Stage 1 get input write pointers can be obtain. Coding is done to obtain this
Buffer_in. fastest clock. The ratio of read clock and write clock will be
with repect to this fastest clock generated. Assumptions are
Buffer_in input is then sampled at gray_pointer_clock, made to ensure that at every positive edge of this fastest
which is the clock at which pointers are interacting in a clock, neither read clock ratio nor write clock ratio is equal
buffer design. The gray_pointer_clock for read pointers is to zero. Properties which have set signal under the cone of
write clock domain while gray_pointer_clock for write influence of both read and write clock are concurrently
pointers is read clock domain. adhered at this fastest clock.
The logic delay_sel_stage_1 is one bit logic, for which
Formal tool covers all possible values in the design. IV. FORMAL VERIFICATION PROPERTIES

Buffer stage 1 gives the output metastable_out_1 which Property is the feature which is written for the design
can be either Buffer_Stage_1[0] or sampled signal as based on the understanding of intention of the design and
Buffer_Stage_1[1] depending on the value of specification which are required. Properties are the main
delay_sel_stage_1 which is random in nature. purpose for formal verification of the design. It skips
complex logic present in the design while focusing only on
Fig. 6. shows Buffer Stage 2 The input to this stage is the the results obtained for logic. Key points which are to be
output of Buffer stage 1 which is metastable_out_1. The kept in mind while writing the properties for formal
overall output obtained from a buffer is verification of any design includes:
metastable_buffer_out. The logic behind this buffer stage is
the same which has been used for Buffer stage 1. x Checking of the port is done from end to end. No
difference should arise in the input/output of RTL
Block diagram in Fig. 4 can well describe the flow of the while describing them with respect to the
design. Assumptions are required at each buffer stage to keep specifications required.
corresponding delay_sel_stage stable when there is no
change in the input to the buffer. This assumption keeps the x Properties written can be examined eventually,
randomization logic stable when there is no change in the always or never but at least it should apply one
input of a buffer. This assumption is evaluated at fastest design run.
clock of the formal proof verification environment. x Requires attention on preconditions while
Therefore, mapping of FV_FAST_CLK is done with the describing the properties.
fastest clock present in the setup from tcl control. Buffer
method discussed above is easy to implement and can be
A. Assumptions
placed in the formal verification environment. Coverage of
any pointer change due to random delay helps to observe the In the formal verification environment, assumptions are
results for this implemented method. All the permissible consider to be core for the checking of formal property.
delay values are covered by this method. Assumptions are the constraints which are included in the
formal verification environment while analyzing the design
so that only valid states are discovered in the design. Buffer
formal environment are tied with the validation of the
assumptions being applied. Assumptions which are made
according to functional requirements of asynchronous gray
Fig. 4. Block diagram of the flow of the method
code FIFO are listed below:
x Constant delay when there is no change in Buffer
stage input.
Description: The delay provided by a buffer stage 1 and 2
that is “delay_sel_stage_1” and “delay_sel_stage_2”
respectively, should remain constant if there is no change in
input to the stage 1 and stage 2 which are “Buffer_in” and
“metastable_out_1” respectively for both read and write
Fig. 5. First buffer stage introduces either delay 0 or 1 between the input pointers.
and output of buffer stage 1.

4
Authorized licensed use limited to: VIT University- Chennai Campus. Downloaded on February 06,2026 at [Link] UTC from IEEE Xplore. Restrictions apply.
generate Description : If no valid write “winc” has happened
for (genvar d=0; d<=4; d++) begin then there should not be valid read “rinc”.
assume_nor_read_before_write: assume property
FV_assume_gfifo_delay_if_w_pointer_is_changing_dela (@(posedge fv_clock) !winc[*1:$] |-> !rinc);
y_sel_stage_1_stable: assume property (@(posedge x No simultaneous write and read operation.
fv_clock) Description : If write gray pointer “wptr” is equal to
!$changed(genvar_loop_wclk[d].generic_gfifo_gray_gray_b read gray pointer “rptr”, then read valid “rinc” should not be
usdelay_inst_wclk.Buffer_in) |-˃ asserted high
$stable(genvar_loop_wclk[d].generic_gfifo_gray_gray_busd assume_no_write_and_read_together_same_address:
elay_inst_wclk.delay_sel_stage_1) );
assume property (@(posedge fv_clock) (wptr==rptr) |->
FV_assume_gfifo_delay_if_w_pointer_is_changing_dela !(rinc));
y_sel_stage_2_stable: assume property (@(posedge x No read/write data present in FIFO on reset.
fv_clock) Description: On write reset “wrst_n”,write data “wdata”
!$changed(genvar_loop_wclk[d].generic_gfifo_gray_gray_b and on read reset “rrst_n”, read data “rdata” should be equal
usdelay_inst_wclk.metastable_out_1) |-> to zero.
$stable(genvar_loop_wclk[d].generic_gfifo_gray_gray_busd assume_no_readdata_reset: assume property
elay_inst_wclk.delay_sel_stage_2)); (@(posedge rclk) rrst_n |-> (rdata == 0));
FV_assume_gfifo_delay_if_r_pointer_is_changing_delay assume_no_writedata_reset: assume property
_sel_stage_1_stable: assume property (@(posedge (@(posedge wclk) wrst_n |-> (wdata == 0));
fv_clock) x No valid read/write on reset.
!$changed(genvar_loop_rclk[d].generic_gfifo_gray_gray_b Description: On read/write reset “rrst_n”/ “wrst_n”,
usdelay_inst_rclk.Buffer_in) |-> read/write valid “rinc” and “winc”respectively should
$stable(genvar_loop_rclk[d].generic_gfifo_gray_gray_busd be asserted low giving no false results
elay_inst_rclk.delay_sel_stage_1) ); assume_no_readvalid_on_reset: assume property
FV_assume_gfifo_delay_if_r_pointer_is_changing_delay (@(posedge wclk) wrst_n |-> (winc == 0));
sel_stage_2_stable: assume property (@(posedge fv_clock) assume_no_writevalid_on_reset : assume property
!$changed(genvar_loop_rclk[d].generic_gfifo_gray_gray_b (@(posedge rclk) rrst_n |-> (rinc == 0));
usdelay_inst_rclk.metastable_out_1) |-> x No change of valid/data signals until there is rising
$stable(genvar_loop_rclk[d].generic_gfifo_gray_gray_busd edge of clock.
elay_inst_rclk.delay_sel_stage_2)); Description: If there is no rising edge of write/read
end clock “wclk” or “rclk” respectively, valid write/read “winc”
“rinc” or write data “wdata” should remain stable.
endgenerate assume_no_change_writevalid: assume property
(@(posedge wclk) !$rose(wclk) |-> $stable(winc));
x Frequency range for read/write clock domain.
assume_no_change_readvalid: assume property
Descritption : read/write clock ratio “rclk_ratio” and ”
(@(posedge rclk) !$rose(rclk) |-> $stable(rinc));
wclk_ratio”, can vary from 1 to 4 but shouldn’t be zero.
assume_no_change_writedata: assume property
wclk_ratio_range: assume property (@(posedge
(@(posedge wclk) !$rose(wclk) |-> $stable(wdata));
fv_clock) (wclk_ratio <=4) && (wclk_ratio != 0) );
rclk_ratio_range: assume property (@(posedge fv_clock) x Read/write clock frequency to be one on reset.
(rclk_ratio <=4) && (rclk_ratio != 0) ); Description: Read/write clock frequency “rclk_ratio”
and “wclk_ratio” should be equal to one on read/write reset
x Stability of read/write clock ratio between the two
“rrst_n” and “wrst_n” respectively.
clock edges.
assume_readclock_frequency_on_reset:
Description : read/write clock ratio “rclk_ratio” and
assume property (@(posedge rclk) rrst_n |->
“wclk_ratio” can change only on the rising edge of
(fv_async_fifo_top_inst.rclk_ratio == 1));
read/write clock “rclk” and “wclk” respectively otherwise
assume_writeclock_frequency_on_reset:
clock ratio should remain stable.
assume property (@(posedge wclk) wrst_n |->
wclk_stable_between_ticks: assume property
(fv_async_fifo_top_inst.wclk_ratio == 1));
(@(posedge fv_clock) !$rose(wclk) |-> $stable(wclk_ratio)
);
rclk_stable_between_ticks: assume property B. Covers
(@(posedge fv_clock) !$rose(rclk) |-> $stable(rclk_ratio) Coverage plays an important role while verifying the
); design. It helps to ensure that all the scenarios in which we
x Valid read/write after reset. are interested in is getting covered while doing the
Description : No valid read/write “rinc” and “winc” verification leaving no corner cases which may leads to
should happen for first 10 clock cycles after the rising edge escapism of potential design bugs.
of read/write reset “rrst_n” and “wrst_n” respectively.
Following are the covers written to examine the coverage
assume_no_winc_10_cycles_After_Reset : assume
for asynchronous gray code FIFO
property (@(posedge wclk) $rose(wrst_n) |-> !winc[*10]);
assume_no_rinc_10_cycles_After_Reset : assume x 2 clock cycles delay between input and end output
property (@(posedge rclk) $rose(rrst_n) |-> !rinc[*10]); of synchronizer for both read and write gray
x No read before write. pointers. Also, delay between the input and end

5
Authorized licensed use limited to: VIT University- Chennai Campus. Downloaded on February 06,2026 at [Link] UTC from IEEE Xplore. Restrictions apply.
 output of a buffer varies from “0” to “2” clock Description: Checks wheather the FIFO full “wfull” case
cycles. has been covered by the tool while during the formal
verification.
Description: When there is rise edge of read/write gray
pointers of synchronizer inputs “rq2_wptr” and “wq2_rptr” cover_fifo_full: cover property (@(posedge
respectively then after 2 clock cycles there should be rising wclk)(async_fifo_top_rtl.wfull));
edge of synchronizers read/write output gray pointers
“sync_rq2_wptr” and “sync_wq2_rptr” respectively. Also, x Coverage on sequence of the events including FIFO
there can be delay of “0”, “1” or “2” clock cycles between full then empty and again full.
input and output of buffer. Description: Check wheather tool has covered the case
generate of FIFO full “wfull” and then after 16 clock cycles FIFO
empty “rempty” and then again after minimum 17 clock
for(genvar g=0 ; g < =4 ; g++) begin cycles FIFO full “wfull”.
cover_2_rclk_metaflop :cover property (@(posedge cover_fifo_full_and_empty: cover property (@(fv_clock)
rclk ) $rose(sync_w2r.rq2_wptr[g]) ##2 (async_fifo_top_rtl.rempty ##16 async_fifo_top_rtl.wfull
$rose(sync_w2r.sync_rq2_wptr[g] ) ); ##[17:$] async_fifo_top_rtl.rempty));
cover_2_wclk_metaflop :cover property (@(posedge
wclk ) $rose(sync_r2w.wq2_rptr[g]) ##2 C. Assertions
$rose(sync_r2w.sync_wq2_rptr[g] ) ); Assertions are the statements of design intent proven or
violated by formal verification [14].
cover_random_delay_rclk_2: cover property
(@(posedge rclk ) Assertions written for the design perform the checking
$rose(genvar_loop_rclk[g].generic_gfifo_gray_gray_busdel for below mentioned scenarios:
ay_inst_rclk.Buffer_in) ##2
$rose(genvar_loop_rclk[g].generic_gfifo_gray_gray_busdel x Occurrence of conditions which are specific to the
ay_inst_rclk.metastable_buffer_out) ); design.
x Occurrence of some specific events sequences.
cover_random_delay_rclk_1: cover property Assertions results in errors or warnings in the following
(@(posedge rclk ) cases:
$rose(genvar_loop_rclk[g].generic_gfifo_gray_gray_busdel x When there is a failure of some specific design
ay_inst_rclk.Buffer_in) ##1
conditions.
$rose(genvar_loop_rclk[g].generic_gfifo_gray_gray_busdel
ay_inst_rclk.metastable_buffer_out) ); x incompletion of some specific design conditions.
Assertions are being use for monitoring and reporting:
cover_random_delay_rclk_0: cover property a. design behavior which is expected.
(@(posedge rclk ) b. design behavior which might be forbidden.
$rose(genvar_loop_rclk[g].generic_gfifo_gray_gray_busdel c. The protocols of the signals.
ay_inst_rclk.Buffer_in) ##0 Following is the assertion written to check if the design
$rose(genvar_loop_rclk[g].generic_gfifo_gray_gray_busdel functionality is meeting the specifications.
ay_inst_rclk.metastable_buffer_out) );
x Data Integrity Check.
cover_random_delay_wclk_2: cover property Description: To check if the output of rtl design “rdata”
(@(posedge wclk ) is same as that of output obtain from the reference logic of
$rose(genvar_loop_wclk[g].generic_gfifo_gray_gray_busdel
FIFO “Busout”
ay_inst_wclk.Buffer_in) ##2
assert_data_integrity_check: assert property
$rose(genvar_loop_wclk[g].generic_gfifo_gray_gray_busdel
ay_inst_wclk.metastable_buffer_out) ); (@(posedge rclk ) (rinc |-> (async_fifo_top_rtl.rdata ==
fv_async_fifo_top_inst.Busout)));
cover_random_delay_wclk_1: cover property
(@(posedge wclk ) D. Writing a script
$rose(genvar_loop_wclk[g].generic_gfifo_gray_gray_busdel After the development of strategy for formal verification,
ay_inst_wclk.Buffer_in) ##1 debugging and development may consume several weeks.
$rose(genvar_loop_wclk[g].generic_gfifo_gray_gray_busdel After the formulation of final solution, scripts are formed to
ay_inst_wclk.metastable_buffer_out) ); implement it. Following is the script used for the design
proposed in this paper:
cover_random_delay_wclk_0: cover property
(@(posedge wclk ) clear -all
$rose(genvar_loop_wclk[g].generic_gfifo_gray_gray_busdel analyze -sv async_fifo_rtl.vs fv_async_fifo_top.vs
ay_inst_wclk.Buffer_in) ##0 elaborate -top async_fifo_top_rtl
$rose(genvar_loop_wclk[g].generic_gfifo_gray_gray_busdel clock fv_async_fifo_top_inst.fv_clock -both_edges
ay_inst_wclk.metastable_buffer_out) ); reset !rrst_n !wrst_n
end set_trace_extension 10

endgenerate x clear -all command will rehash the verification

x Coverage on FIFO Full. session

6
Authorized licensed use limited to: VIT University- Chennai Campus. Downloaded on February 06,2026 at [Link] UTC from IEEE Xplore. Restrictions apply.
 x analyze command will read the design and property
files and check for syntactical errors.
x Elaborate command will synthesize, read the netlist
and build the design hierarchy.
x Clock command is to tell the tool the clock used for
formal verification along with specifying the edges
at which it got triggered. In the design proposed in Fig. 9. Data Integrity check property execution results for design with
this paper, clock is both edges triggered. Buffer
x Reset signifies the reset used in design. As, the
reset are active low so they are specifies as “! (reset
name)” .
x Set trace command is to give the no. of clock
cycles the waveform is to be extended. To check
for counter example, trace extension is done by 1
clock cycle. But as read and write clock ratios
frequency varies from 1 to 4 with respect to formal
fastest clock and they are both edges triggered. So, Fig. 10. Data Integrity check property execution results for design without
some pessimistic number needs to be specified. Buffer
Considering clock ratio as 4, [(4*2=8) + (1*2) trace
extension by 1 cycle = 10]. As can be seen in Fig. 9 data obtained at the output of
reference logic “Busout” is not the same as that of data
x
obtained at RTL output “rdata” at every edge of “rclk”
V. RESULTS because close look at the write pointer “wptr” and read
pointer “rptr” shows that there has been loss of read pointer
After the completion of above work, JasperGold tool
which is verification tool is invoked by running the tool “rptr” in RTL design which means read pointer doesn’t
command language script which contain the verification change its value at the read clock edge where maker has
program. been placed but there is change in value of reference code
read pointer. This leads to the difference in the output
As can be seen in Fig. 7 & Fig. 8, Property table depicts obtained from RTL design and output obtained from
all the formal properties written for the design. Properties reference code as read valid is high at that clock edge. It
with red mark in front in Fig. 7 indicates that the property means metastability injected by a buffer in the pointers of
written by FV engineer is not aligning with the RTL design, Asynchronous gray code FIFO has affected the functionality
so it needs the attention. Debugging is done to root cause the of the design.
error and make changes where required.
But in Fig. 10 which is design without buffer, no pointer
loss can be observed in the design without Buffer which
means whenever RTL read pointer changes its value, same
value is taken by reference code read pointer and the data
obtained from reference code output which is “Busout” is
always equal to RTL design output which is “rdata” at every
edge of “rclk”.
Fig. 7. Results of Property Execution for design with buffer
x Considering the cover property for FIFO Full
written as:
cover_fifo_full: cover property (@(posedge
wclk)(async_fifo_top_rtl.wfull));
Observing the waveforms shown in Fig. 11 and Fig. 12

Fig. 8. Results of Property Execution for design without buffer

x Considering the assertion property for data

integrity check written as: Fig. 11. FIFO Coverage property execution results for design with Buffer
assert_data_integrity_check: assert property
(@(posedge rclk ) (rinc |-> (async_fifo_top_rtl.rdata
== fv_async_fifo_top_inst.Busout)));
Fig. 9 shows the waveforms of the assertion for the
design with buffer in which metastability is present in Fig. 12. FIFO Coverage property execution results for design without
pointers of the design while Fig. 10 shows the Buffer
waveforms for design without buffer in which
metastability is absent in the pointers of the design. In the waveforms shown in Fig. 11 for design with buffer
and the waveforms in Fig. 12 for design without buffer, in
both the figures when there is write valid “winc” after 16

7
Authorized licensed use limited to: VIT University- Chennai Campus. Downloaded on February 06,2026 at [Link] UTC from IEEE Xplore. Restrictions apply.
clock cycles, FIFO Full “wfull” is asserted high which means [2] A. S. Patharkar, "Performance Analysis of Synchronizer and
cover is passing for both the designs. But metastability Measurement of Metastability," 2015 International Conference on
Computing Communication Control and Automation, 2015, pp. 494-
injected by a buffer has affected the data output obtained 498.
from RTL design as can be seen in Fig. 9. [3] G. N. Pham and K. C. Schmitt, "A high throughput, asynchronous,
dual port FIFO memory implemented in ASIC technology,"
VI. CONCLUSION Proceedings., Second Annual IEEE ASIC Seminar and Exhibit,,
1989, pp. P3-1/1.
A Buffer has been designed to inject the metastability in [4] G. Swamy, “Formal verification of digital systems,” in Proceedings
the formal proof verification environment of the pointers for Tenth International Conference on VLSI Design, 1997, pp. 213–217
Asynchronous Gray Code FIFO because setup time and hold [5] Y. Tao, "An introduction to assertion-based verification," 2009 IEEE
time are not being honored by formal verification tool. 8th International Conference on ASIC, 2009, pp. 1318-1323.
Comparative analysis of the waveforms obtained [6] M. Girish, G. Gopakumar and D. S. Divya, "Formal and Simulation
corresponding to the formal verification properties written Verification: Comparing and Contrasting the two Verification
Approaches," 2021 2nd International Conference on Advances in
for the Asynchronous Gray Code FIFO design with and Computing, Communication, Embedded and Secure Systems
without buffer has been performed. It has been observed that (ACCESS), 2021, pp. 41-44.
no metastability is witnessed when no such buffers are [7] J. Cortez and D. Torres, "Design and verification based on assertions:
placed in the setup. In this case, design is functioning as some statistics," 2005 2nd International Conference on Electrical and
predicted specifications and all the formal verification Electronics Engineering, 2005, pp. 132-135.
properties passes and their waveforms show expected [8] Cadence Design Systems, Inc., “Jaspergold apps user guide.”
behavior of the read and write pointers, as can be seen in Fig. [9] Y. Hu and D. Li, "Formal Verification Technology for Asynchronous
10. While including a buffer in the design, metastability gets Communication Protocol," 2019 IEEE 19th International Conference
injected in the pointers of Asynchronous Gray Code FIFO. It on Software Quality, Reliability and Security Companion (QRS-C),
2019, pp. 482-486.
has been observed that the design is not functioning as
[10] Verilog, Expert & Cummings, Clifford. (2002). Simulation and
predicted specifications and the formal verification Synthesis Techniques for Asynchronous FIFO Design.
properties waveform show unexpected behavior of the read [11] Z. Liu and M. Xie, “An effective as-fifo design for multiple
and write pointers, as can be seen in Fig. 9. This means asynchronous clock data transmission,” in 2008 International
synchronizers/Meta flops added by the RTL designer in the Conference on Communications,
design are not enough to deal with the metastability which Circuits and Systems, 2008, pp. 960–963.
might occur in the pointers of Asynchronous Gray Code [12] S. Walker and S. Foo, “Evaluating metastability in electronic
FIFO. To overcome the effect of the metastability, there is a circuits for random number generation,” in Proceedings IEEE
Computer Society Workshop
need to add more synchronizers in the design. Hence, on VLSI 2001. Emerging Technologies for VLSI Systems, 2001, pp.
proposed method for buffer placement in the formal 99–101.
verification environment can catch the issues of improper [13] M. Thakur, B. B. Soni, P. Gaur, and P. Yadav, “Analysis of
synchronization of pointers in Asynchronous Gray Code metastability performance in digital circuits on flip-flop,” in 2014
FIFO. Buffer design method can be utilized in formal International Conference
verification task of any gray code digital design. This method on Communication and Network Technologies, 2014, pp. 265–269.
can be extended to acquire higher number of delays. For the [14] A. T. Sonny and S. Lakshmiprabha, "OVL, PSL, SVA: Assertion
future scope of the work, similar methodology can be based verification using checkers and standard assertion languages,"
2013 International Conference on Advanced Computing and
exercised for any digital system/design where change in Communication Systems, 2013, pp. 1-4.
value is only one bit at a time, same as that of gray code. [15] R. M. Sarikhada and P. K Shah, "Speed up the validation process by
formal verification method," 2020 IEEE International Conference for
REFERENCES Innovation in Technology (INOCON), 2020, pp. 1-4.

[1] L. Kleeman and A. Cantoni, "Metastable Behavior in Digital

Systems," in IEEE Design & Test of Computers, vol. 4, no. 6, pp. 4-
19, Dec. 1987.

8
Authorized licensed use limited to: VIT University- Chennai Campus. Downloaded on February 06,2026 at [Link] UTC from IEEE Xplore. Restrictions apply.