• 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. Custom IC SKILL
  3. skill code question: How can I go to next loop of the f...

Stats

  • Locked Locked
  • Replies 5
  • Subscribers 143
  • Views 19778
  • 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

skill code question: How can I go to next loop of the foreach

wenckey
wenckey over 5 years ago

Just like the "next" function in perl.

How can I jump to the the next iteration of the loop in foreach.

Thanks

Kevin

  • Cancel
  • mbracht
    mbracht over 5 years ago

    Hi Kevin,

    You don't have these "jump to wherever" statements in SKILL  - there's no perl like "continue" or "last"  in SKILL either. I think it's considered to be bad coding style by the "die hard" SKILL programmers. So assume you have a list of lines you want to iterate over but skip the comment lines..in perl you go like this:

    foreach my $line @line {
       next if $line ~= /^#/ ;
       <
       ...remaining foreach body
       >
    }

    ...but in SKILL you need to handle that with a conditional statement:

    (foreach line lines
       (unless (rexMatchp "^#" line)
          <
          ...remaining foreach body
          >
       )
    )

    There's quite a view paradigms that work different in SKILL as opposed to the "C"-like languages and this is one of them.
    Even an early return from a function is not recommended, it fact it works from a prog() block only.

    Max

    • Cancel
    • Vote Up +1 Vote Down
    • Cancel
  • Andrew Beckett
    Andrew Beckett over 5 years ago in reply to mbracht

    Max is right - there's no direct equivalent, although there are ways to achieve the same thing. I personally don't like these because they are in essence a glorified "goto" and that's is something that leads to "spaghetti programming" where it is very hard to follow the flow of control. For a functional language such as SKILL, you would normally use the return values of functions to determine what to do next and not have things which jump from one place to another which are easy to miss when reading the code. There are also forms of looping functions, such as forall and exists that allow early exit from the loop too, without needing to resort to next (or continue in C parlance), or break.

    You can implement what you want (at least) a couple of ways. One is to use the prog() function within the body of your foreach:

    The return() in this causes the prog() to return at that point, which would have the effect of moving onto the next point in the loop, without evaluating the rest of the body of the prog:

    listOfNums=list(1 2 3 4 5 6 7 8 9 10 11 12)
    sum=0
    foreach(elem listOfNums
      prog(()
        println(elem)
        when(oddp(elem)
          ; equivalent to break
          return()
        )
        sum=sum+elem
      )
    )
    printf("Sum is %d\n" sum)
    

    This outputs:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    Sum is 42

    Then another approach is to use the catch and throw functions to emulate both continue (a.k.a. next) and break. Note that the second argument of the throw function is what the corresponding catch would return, but we're not really using that here:

    sum=0
    catch('break
      foreach(elem listOfNums
        catch('continue
          println(elem)
          when(elem>8
            throw('break t)
          )
          when(oddp(elem)
            throw('continue t)
          )
          sum=sum+elem
        )
      )
    )
    printf("Sum is %d\n" sum)
    

    This then outputs:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    Sum is 20

    I'm not a fan of either of these approaches, primarily because I think it makes the code much harder to read. The second is a little better in terms of style, because at least the catch() announces to the reader that something is likely to throw within the body and so you look out for it when reading the code. However, it's still effectively a goto - and I guess I have more of a philosophical problem with that (thanks mainly to my high school teacher that taught me when I first was learning to program!)

    Regards,

    Andrew.

    • Cancel
    • Vote Up +1 Vote Down
    • Cancel
  • wenckey
    wenckey over 5 years ago in reply to Andrew Beckett

    Thanks for your explanation and demo.

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • wenckey
    wenckey over 5 years ago in reply to mbracht

    Thanks a lot!

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • Andrew Beckett
    Andrew Beckett over 5 years ago in reply to wenckey

    Happy to help!

    I meant to use a little analogy between programming languages and spoken languages. When speaking in French, it would be a little odd to use German grammar and idioms and would sound clumsy to a native French speaker. Similarly when writing in SKILL, using idioms and patterns from perl or C also can end up being rather clumsy - you're better off embracing the way that things would normally be done in the language you're using rather than trying to make it sound like another!

    Andrew,

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel

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