• Skip to main content
  • Skip to search
  • Skip to footer
Cadence Home
  • This search text may be transcribed, used, stored, or accessed by our third-party service providers per our Cookie Policy and Privacy Policy.

  1. Community Forums
  2. Functional Verification
  3. Jasper connectivity check

Stats

  • Locked Locked
  • Replies 7
  • Subscribers 65
  • Views 24925
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Jasper connectivity check

sraghapx
sraghapx over 9 years ago

** Did not find forum for Jasper tool. Filing here **

I am writing rules for connectivity app. Here, I am interested to write rule for a signal that is input to a module. It is expected to go through a flop stage and then come out. So, essentially, a delayed signal.

My rule looks like this:

CONNECTION,propogate_delay,,propogate_s1,,opropogate_s1
LATENCIES,,0,0,1,0

Based on my understanding, I assume that the signal output is delayed

In the above case, Jasper tool is taking condition that was defined before the above 2 lines.

I am not clear how condition comes into picture in case of latency of a signal.

Can someone clarify?

  • Cancel
Parents
  • sraghapx
    sraghapx over 9 years ago

    CrazyForFormal,

    Thanks a lot for detailed explanation. I think I understand where I was going wrong.

    I already have rules for the following case. So, I am good on these two cases. You can probably help me with the other 3 cases.

    1) input to a block is simply output

    2) input to a block is simply output with a fixed delay

    Now that I have started implementing rules for a real project, I do have some additional questions.

    1) Is a rule as follows allowed:

     

    CONNECTION, id_1, ,~inp,,op

    Please notice the ~ operator at the source signal. I ask this as I have seen most of the description for connectivity talk about input to output propagation with a lot of conditions. But in the above case, there is an change in signal value (inverted output).

    if this is not acceptable then is there an alternate way to describe this?

    2) I want to use constants while writing the rules

       a) can I use alias to do this?

       b) can I use `define from Verilog/SystemVerilog

     

      For example, is the following allowed:

      e.g. 1  (t_mode == `TRUE)

     TRUE is a define in my Verilog file

     

     e.g. 2 (t_mode = TRUE)

     TRUE is defined as 1'b1 Alias in the rule file

     

    3) One main use-case of Connectivity checker is for pin muxing logic.

    Normally, these modules don't have clock. So, how to specify to tool that there is no reset or clock to the module?

     

    4) When I have to write rules for a 2-1 mux function of DUT, do I have to write 2 connection rules or there is a way to compress this description using a single connection rule?

     

    For example,

    CONNECTION, id_1, ,inp_1,,op

    COND_EXPR, sel == 1'b0

    CONNECTION, id_2, ,inp_2,,op

    COND_EXPR, sel == 1'b1

     5) The pin mux design I am trying to verify has technology components for mux logic.

    I have simulation models for these technology components. These are behavioral codes.

    Is there any guideline for handling tech. components in Jasper?

     

    Thanks a lot ... 

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
Reply
  • sraghapx
    sraghapx over 9 years ago

    CrazyForFormal,

    Thanks a lot for detailed explanation. I think I understand where I was going wrong.

    I already have rules for the following case. So, I am good on these two cases. You can probably help me with the other 3 cases.

    1) input to a block is simply output

    2) input to a block is simply output with a fixed delay

    Now that I have started implementing rules for a real project, I do have some additional questions.

    1) Is a rule as follows allowed:

     

    CONNECTION, id_1, ,~inp,,op

    Please notice the ~ operator at the source signal. I ask this as I have seen most of the description for connectivity talk about input to output propagation with a lot of conditions. But in the above case, there is an change in signal value (inverted output).

    if this is not acceptable then is there an alternate way to describe this?

    2) I want to use constants while writing the rules

       a) can I use alias to do this?

       b) can I use `define from Verilog/SystemVerilog

     

      For example, is the following allowed:

      e.g. 1  (t_mode == `TRUE)

     TRUE is a define in my Verilog file

     

     e.g. 2 (t_mode = TRUE)

     TRUE is defined as 1'b1 Alias in the rule file

     

    3) One main use-case of Connectivity checker is for pin muxing logic.

    Normally, these modules don't have clock. So, how to specify to tool that there is no reset or clock to the module?

     

    4) When I have to write rules for a 2-1 mux function of DUT, do I have to write 2 connection rules or there is a way to compress this description using a single connection rule?

     

    For example,

    CONNECTION, id_1, ,inp_1,,op

    COND_EXPR, sel == 1'b0

    CONNECTION, id_2, ,inp_2,,op

    COND_EXPR, sel == 1'b1

     5) The pin mux design I am trying to verify has technology components for mux logic.

    I have simulation models for these technology components. These are behavioral codes.

    Is there any guideline for handling tech. components in Jasper?

     

    Thanks a lot ... 

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
Children
No Data

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.

© 2025 Cadence Design Systems, Inc. All Rights Reserved.

  • Terms of Use
  • Privacy
  • Cookie Policy
  • US Trademarks
  • Do Not Sell or Share My Personal Information