# Can we use internal signal of DUT while writing the assertion property

**URL:** <https://verificationacademy.com/forums/t/can-we-use-internal-signal-of-dut-while-writing-the-assertion-property/39057>\
**Category:** SystemVerilog\
**Tags:** SVA, SystemVerilog\
**Created:** [May 8, 2021, 5:24pm UTC](https://verificationacademy.com/forums/t/can-we-use-internal-signal-of-dut-while-writing-the-assertion-property/39057 "2021-05-08T17:24:10Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![rkg1](https://verificationacademy.com/forums/letter_avatar_proxy/v4/letter/r/d6d6ee/32.png) [@rkg1](https://verificationacademy.com/forums/u/rkg1)\
**Post date:** [May 8, 2021, 5:24pm UTC](https://verificationacademy.com/forums/t/can-we-use-internal-signal-of-dut-while-writing-the-assertion-property/39057/1 "2021-05-08T17:24:10Z")

</div>

Hi,

While writing the assertion, Can we use the internal signal of DUT. or we should only use the input, output of DUT ?

Is their any recommendation ?

Thanks,

---

<div class="post-metadata">

**Author:** ![user49](https://verificationacademy.com/forums/user_avatar/verificationacademy.com/user49/32/1084_2.png) [@user49](https://verificationacademy.com/forums/u/user49)\
**Post date:** [May 8, 2021, 6:06pm UTC](https://verificationacademy.com/forums/t/can-we-use-internal-signal-of-dut-while-writing-the-assertion-property/39057/2 "2021-05-08T18:06:44Z")

</div>

_In reply to [rkg\_](https://verificationacademy.com/forums/t/can-we-use-internal-signal-of-dut-while-writing-the-assertion-property/39057):_

> While writing the assertion, Can we use the internal signal of DUT. or we should only use the input, output of DUT ? Are there recommendations?

1. When designing a DUT, write the assertions in a separate **checker** (or module) and bind it to the DUT.  
_(see below for sample code)_.

- 2. Binding isolates the verification code from RTL code.  
3. Verification code may include global local variables, not to be confused with the RTL.  
4. With binding, changes can be made to the verification without changing the timestamp of the RTL.  
  
- Assertions can (and should) address both the black-box and the white-box of the model.  
  
- Black-box verification address the requirements from an external viewpoint of the DUT.  
They also address assumptions imposed on the model. For example, sig\_x[3]==0 in the mode that the DUT is intended to be used; sig\_y is never asserted when sig\_z==1.  
- A good place to put the black-box assertions is in the interface or a **checker** bound to the interface.  
- White-box assertions and assumptions address items specific to the design. For example, when the FSM is in state\_X, sig\_Z is zero at the next cycle. State machines are internal to the DUT.  
  

Example uses a module instead of a checker.

 ![](https://verificationacademy.com/forums/uploads/default/original/1X/6ae544ec3cc04c99242c52d9a62fc340164fbbea.png)

 ![](https://verificationacademy.com/forums/uploads/default/original/1X/6ae544ec3cc04c99242c52d9a62fc340164fbbea.png)

Ben Cohen  
[http://www.systemverilog.us/](http://www.systemverilog.us/) [ben@systemverilog.us](mailto:ben@systemverilog.us)  
For training, consulting, services: contact [http://cvcblr.com/home.html](http://cvcblr.com/home.html)  
\*\* SVA Handbook 4th Edition, 2016 ISBN 978-1518681448  
…

1. SVA Package: Dynamic and range delays and repeats [SVA: Package for dynamic and range delays and repeats - SystemVerilog - Verification Academy](https://rb.gy/a89jlh)
2. Free books: Component Design by Example [https://rb.gy/9tcbhl](https://rb.gy/9tcbhl)  
Real Chip Design and Verification Using Verilog and VHDL($3) [https://rb.gy/cwy7nb](https://rb.gy/cwy7nb)
3. Papers:

- Understanding the SVA Engine,  
[https://verificationacademy.com/verification-horizons/july-2020-volume-16-issue-2](https://verificationacademy.com/verification-horizons/july-2020-volume-16-issue-2)
- SVA Alternative for Complex Assertions  
[https://verificationacademy.com/news/verification-horizons-march-2018-issue](https://verificationacademy.com/news/verification-horizons-march-2018-issue)
- SVA in a UVM Class-based Environment  
[https://verificationacademy.com/verification-horizons/february-2013-volume-9-issue-1/SVA-in-a-UVM-Class-based-Environment](https://verificationacademy.com/verification-horizons/february-2013-volume-9-issue-1/SVA-in-a-UVM-Class-based-Environment)

---

<div class="post-metadata">

**Author:** ![rkg1](https://verificationacademy.com/forums/letter_avatar_proxy/v4/letter/r/d6d6ee/32.png) [@rkg1](https://verificationacademy.com/forums/u/rkg1)\
**Post date:** [May 8, 2021, 6:37pm UTC](https://verificationacademy.com/forums/t/can-we-use-internal-signal-of-dut-while-writing-the-assertion-property/39057/3 "2021-05-08T18:37:43Z")

</div>

_In reply to [ben@SystemVerilog.us](https://verificationacademy.com/forums/t/can-we-use-internal-signal-of-dut-while-writing-the-assertion-property/39057/2):_

Thanks Ben :)

let me reframe my question in slightly diffrent way :-

- lets say design has output signal inc and dec. i need to write property where I have to use inc and dec signal. and condition is like if inc or dec happen consecutively 4 times lock will be de- asserted

- But in DUT they have used internal signal(fll\_unlock\_check\_timer) to detect inc or dec. and every inc or dec fll\_unlock check timer will change.

So my question is, **Can i directly use (fll\_unlock\_check\_timer == 4) lock should be de-asserted ?**

---

<div class="post-metadata">

**Author:** ![user49](https://verificationacademy.com/forums/user_avatar/verificationacademy.com/user49/32/1084_2.png) [@user49](https://verificationacademy.com/forums/u/user49)\
**Post date:** [May 8, 2021, 10:09pm UTC](https://verificationacademy.com/forums/t/can-we-use-internal-signal-of-dut-while-writing-the-assertion-property/39057/4 "2021-05-08T22:09:30Z")

</div>

_In reply to [rkg\_](https://verificationacademy.com/forums/t/can-we-use-internal-signal-of-dut-while-writing-the-assertion-property/39057/3):_  
I would write two assertions

1. An assertion based on the **inc, dec,** that impacts the **lock.**
2. An assertion on how **inc, dec** are generated based on **fll\_unlock\_check\_timer**.  
In other words, you need to check the creation of the outputs, making sure that they are according to spec. That spec may be other factors besides the timer. The timer is an implementation. In general, for black-box the implementation is irrelevant.  
Ben Cohen  
[http://www.systemverilog.us/](http://www.systemverilog.us/) [ben@systemverilog.us](mailto:ben@systemverilog.us)  
For training, consulting, services: contact [http://cvcblr.com/home.html](http://cvcblr.com/home.html)  
\*\* SVA Handbook 4th Edition, 2016 ISBN 978-1518681448  
…
3. SVA Package: Dynamic and range delays and repeats [SVA: Package for dynamic and range delays and repeats | Verification Academy](https://rb.gy/a89jlh)
4. Free books: Component Design by Example [FREE BOOK: Component Design by Example … A Step-by-Step Process Using VHDL with UART as Vehicle | Verification Academy](https://rb.gy/9tcbhl)  
Real Chip Design and Verification Using Verilog and VHDL($3) [Amazon.com](https://rb.gy/cwy7nb)
5. Papers:

- Understanding the SVA Engine,  
[Verification Horizons - July 2020 | Verification Academy](https://verificationacademy.com/verification-horizons/july-2020-volume-16-issue-2)
- SVA Alternative for Complex Assertions  
[Verification Horizons - March 2018 Issue | Verification Academy](https://verificationacademy.com/news/verification-horizons-march-2018-issue)
- SVA in a UVM Class-based Environment  
[SVA in a UVM Class-based Environment | Verification Horizons | Verification Academy](https://verificationacademy.com/verification-horizons/february-2013-volume-9-issue-1/SVA-in-a-UVM-Class-based-Environment)
