case splitting

[fpgaphreak]

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.

Comments?

[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.

[Jim Lewis]

Just a quick note, release 2024.07 will have a CreateJitterClock. That said, you still would be better off with a good clock domain crossing tool.

The OsvvmLibraries Dev branch currently has the following defined:

  procedure CreateJitterClock (
    signal   Clk             : inout std_logic ;
    signal   CoverID         : inout CoverageIdType ; 
    constant Name            : in    string ;
    constant Period          : in    time ;
    constant DutyCycle       : in    real := 0.5 ;
    constant Offset          : in    time := 0 sec ;
    constant ClkActive       : in    std_logic := CLK_ACTIVE 
  ) ;

To use it you will need to create a signal of CoverageIdType:
signal Cov1 : CoverageIdType ;

However you are not obliged to do anything with it.

[Author]

Posts