case splitting

Why OSVVM™? Forums OSVVM case splitting

Viewing 2 posts - 1 through 2 (of 2 total)
  • Author
  • #2359

    In some cases i need a full coverage of cases when doing simulations of timing critial circuits which cause deviations in behaviour. I would like to know if OSVVM supports this in any way.

    To understand the issue I would like to describe the problem:

    Take a signal of unknown phase and level and a synchronizer to get it into a circuit with an input FF. For a certain point of time, the output of the signal changes and so does the subsequent logic after the FF. Now, for signal changes in beneath of the clock edge of the sampling clock, the signal might have been catched a clock cycle earlier.

    This already causes 2 cases of a possible timing constellation. If now the receiving circuit responds at any point of time and transports the signal back via this clock domain border, the same issue might occur. This means 4 possible timing cases and circuit 1 gets a response with a probability of 25% at n CCs, with 50% at n+1 CCs and wih 25% at n+2 CCs.

    Regarding this issue there are only 3 possible timing cases, which can be estimated and understood in advance.

    It becomes more complex if there is a unit having more than one CDCs and data of these have to be processed.
    The risk rises that one overlooks a possible case which might cause a problem.

    To simulate that I typically trigger these cases manually, hoping I do not overlook a critical case.

    This shall be automated! As a first approch, I setup a special simulation where a signal becomes “U” after a sampling case with a signal change and then takes over the correct lavel later. This way the U ist temperarily driven through the design so to speak “marking” the point of time, when there is a functionally uncertain situaion and check if the design recovers from this.

    Is there any idee in which way one could do this?

    In my opinion one neeads a kind of a splitted simulation where several paths of behaviour are investigated and possibly also joined as shown in the 1,2,1 example.


    Jim Lewis

    Step 1: If you have complex clock domain crossings, you probably need a clock domain crossing tool. Especially to find anything that might loop back.
    Step 2: Use your directed cases to explore the relationships you understand.
    Step 3: Add jitter to your clock (or clocks depending on the number of clock domains you have) so that your simulation explores more than interactions caused my the differences in frequency.

Viewing 2 posts - 1 through 2 (of 2 total)
  • You must be logged in to reply to this topic.