Stats

  • Locked Locked
  • Replies 3
  • Subscribers 65
  • Views 6860
  • 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

ncsim TCL stop -condition

zvika23
Hi , i was trying to use stop condition in my condition i want to excute stop -condition{change in a port}{ assertion -off {"something"} run 4ns asserstion -on } but the problem is a) i can't seem to implent "change in port" in the TCL b) the run 4ns -- is not a good way to wait until assert on. pls help zvika
  • code looks somting like set a #port stop -condition {a != "#port } -execute { set a #port assertion -off asserstion_name run 4ns assertion -on assertion_name } -continue -silent the first set is for "prev value" the condition --- if value changed execute ..... next asserstion off , run a little , asserstion off, continue the question is a) is the value in a is really prev? and if not what is a better syntex? b) the "run 4ns" is not a good way to delay between the asserstion off/on, the ncsim doesn't like it... what sould i write instead tnx zvika

  • It is really hard to tell what you are trying to do. So I'll just make a couple of comments and refer you to the ncsim TCL documentation.

    To create a breakpoint when "port" changes value, there's not need to create a copy of the current value with "set a #port" and etc. Simply create an object breakpoint.

    stop -object port

    If you want to execute a command after that object change's value, use the -execute option.

    stop -object port -execute { assertion -off assertion_name } -continue -silent

    You can't issue a "run" command inside a breakpoint, because breakpoints don't nest. If you were in the middle of your "run 4 ns" and the port changed value again, what should the simulator do? Should it cancel the current "run" or ignore the break? To avoid this kind of conumdrum, ncsim simply forbids any "run" command inside a breakpoint.

    When I need a span of time between two actions taken on a breakpoint, it has been my practice to use the 1st breakpoint to create a second one to execute at the end of the time span. It can get a little complex to post in a forum, but it works.

    stop -object port -continue -silent \
      -execute { \
            assertion -off assertion_name; \
            stop -time -relative 4ns -execute { assert -enable assertion_name } -continue -silent -delbreak 1 \
        }

    This will turn off the assertion and schedule a 2nd breakpoint 4 ns in the future. When that breakpoint executes, it will turn the assertion back on and delete itself. Meanwhile the original stop is waiting for the next change on the object "port".

    You may need to massage the syntax in this example a little. My typing skills might be off. But hopefully you can get the general idea.

  • TAM1 thank you my script worked! the TCL saved me a lot of time changing my sv files... and it made me understand more about TCL so WIPPY! :) ZVIKA

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.