#960 SDF back annotation fails/aborts for a tri-state buffer

I am using iverilog version 0.10.0 (devel) (s20130827).

I am trying to back annotate an SDF file into my design using "$sdf_annotate" command which is successful for all the cells in the design except for a tri-state buffer. The error message that I get upon running 'vpp' is as follows:

SDF WARNING: testbench.v:95: Unable to match ModPath A -> Z in m1.ph_sio_tri
SDF WARNING: testbench.v:95: Unable to match ModPath EN -> Z in m1.ph_sio_tri
Assertion failed: (0), function modpath_src_put_delays, file delay.cc, line 851.
Abort

And the lib looks like the followings for this tri-state buffer (m1.ph_sio_tri is an instantiation of TBUF_X2 module which is defined in the library as follows):

module TBUF_X2 (A, EN, Z);
input A;
input EN;
output Z;

bufif0(Z, Z_in, Z_enable);
buf(Z_enable, EN);
buf(Z_in, A);

specify
(A => Z) = (0.1, 0.1);
(EN => Z) = (0.1, 0.1);
endspecify

endmodule

Can anyone help please? Thanks.

---

I believe all the issues in this report have been resolved except for the issue originally described in br954. I am leaving this report open until br954 is fixed to make sure we confirm this assumption.

Cary R.

[Cary R.]

It would be easiest for us if we had the instantiation line and the appropriate SDF lines. Icarus is not great at SDF annotation. If you can provide this other information I will try to see if this issue can be fixed.

[Anonymous]

Here is the instantiation lines:
TBUF_X2 ph_sio_tri (.A ( n278 ) , .EN ( n31 ) , .Z ( ph_sio ) ) ;
TBUF_X2 ph_sen_tri (.A ( n279 ) , .EN ( n32 ) , .Z ( ph_sen ) ) ;

and here are the SDF lines:
(CELL
(CELLTYPE "TBUF_X2")
(INSTANCE ph_sio_tri)
(DELAY
(ABSOLUTE
(IOPATH A Z (0.247:0.261:0.261) (0.157:0.164:0.164))
(IOPATH EN Z () () (0.397:0.398:0.398) (0.185:0.199:0.199) (0.649:0.650:0.650) (0.125:0.131:0.131))
)
)
)

(CELL
(CELLTYPE "TBUF_X2")
(INSTANCE ph_sen_tri)
(DELAY
(ABSOLUTE
(IOPATH A Z (0.249:0.263:0.263) (0.158:0.165:0.165))
(IOPATH EN Z () () (0.398:0.398:0.398) (0.187:0.202:0.202) (0.649:0.650:0.650) (0.126:0.132:0.132))
)
)
)

Is it complete? Thanks for the help.

[Cary R.]

This should be enough. I'll try to build a working example from this input so that I can reproduce the problem. I will let you know if I need more information.

[Cary R.]

I can reproduce the assert. I am not currently getting any warnings so something is different. The assert is because the SDF file has six delays for the EN -> Z delay and Icarus currently only supports two or twelve delays. It also looks like the empty delays code may also have a bug. I would guess that they should get the delay from the model, but that doesn't appear to be working correctly. I need to do some research on exactly how the delays should be handled. This does not look like that complicated of a problem to fix.

[Anonymous]

You seem to be pointing to the right issue. These 2 lines seem to be the only ones specifying more than 2 delays in the entire sdf. But I have not been able to validate the above claim as the sdf file is rather large and my regular expression searches do not work properly!

[Cary R.]

In looking at this. The empty delay code is working correctly. I initially made a small mistake in test code regarding the timescale. I also uncovered some errors in how the to/from X values are calculated when there are less than twelve delays and the two delay code had an error in the z->1 and 1->z delay selection (they were swapped). There was also a significant problem in the code that selected a delay from a given edge combination. The X and Z entries were swapped. I have fixed and pushed changes for these and added support for putting three and six element delays.

The latest code from git should fix your assert issue. The warnings may be a different problem. I will leave this report open for a while so you can confirm that things are working correctly.

[Anonymous]

I did follow the instructions shown on http://iverilog.wikia.com/wiki/Installation_Guide and had to install "autoconf", "automake",etc on my mac (lion), yet when I issue the command "sh autoconf.sh", I get the following messages:
Autoconf in root...
Precompiling lexor_keyword.gperf
Precompiling vhdlpp/lexor_keyword.gperf

But my "iverilog" still seems to point out to the old installations:
Icarus Verilog version 0.10.0 (devel) (s20130827)

Did I miss anything here, or need to do extra for installing new iverilog?

[Martin Whitaker]

Those messages are normal, and indicate you've successfully built the configuration files. Have you also followed the instructions in http://iverilog.wikia.com/wiki/Installation_Guide#Compiling_on_Linux.2FUnix to compile and install iverilog?

[Anonymous]

Thanks Martin. My bad! I thought that was the last step. Now the version shows:
Icarus Verilog version 0.10.0 (devel) (s20140801-139-gaf85d44)

[Anonymous]

Carry: Unfortunately, even after your fixes (and after I installed the latest codes) I still see the same warnings and error messages:

WARNING: testbench.v:95: $sdf_annotate currently only uses the first two argument.
WARNING: testbench.v:96: $sdf_annotate currently only uses the first two argument.
SDF WARNING: testbench.v:95: Unable to match ModPath A -> Z in m1.ph_sio_tri
SDF WARNING: testbench.v:95: Unable to match ModPath EN -> Z in m1.ph_sio_tri
SDF WARNING: testbench.v:95: Unable to match ModPath A -> Z in m1.ph_sen_tri
SDF WARNING: testbench.v:95: Unable to match ModPath EN -> Z in m1.ph_sen_tri
Assertion failed: (0), function modpath_src_put_delays, file delay.cc, line 860.
Abort

[Anonymous]

I actually did another experiment, this time removing those tristate cells from the SDF file and although I did not get those warning messages anymore, the assertion failed:

WARNING: stim_helios_uart.v:95: $sdf_annotate currently only uses the first two argument.
WARNING: stim_helios_uart.v:96: $sdf_annotate currently only uses the first two argument.
Assertion failed: (0), function modpath_src_put_delays, file delay.cc, line 860.
Abort

[Anonymous]

I tried to locate the first location where the assertion fails by trial and error where I commented out the sdf lines. It turns out the first place that it fails is due to the following cell definition:
(CELL
(CELLTYPE "BUF_X2")
(INSTANCE sintf/U12)
(DELAY
(ABSOLUTE
(IOPATH A Q (0.092:0.093:0.093))
)
)
)

After commenting out this one, I get a large number of new warnings followed by a new assertion failure. The first sdf cell causing this warning looks like this:

(CELL
(CELLTYPE "AOI32_X2")
(INSTANCE sintf/U52)
(DELAY
(ABSOLUTE
(IOPATH A1 Q (0.190:0.191:0.191) (0.186:0.187:0.187))
(IOPATH A2 Q (0.216:0.216:0.216) (0.201:0.202:0.202))
(IOPATH A3 Q (0.238:0.240:0.240) (0.208:0.211:0.211))
(IOPATH B1 Q (0.143:0.143:0.143) (0.130:0.130:0.130))
(IOPATH B2 Q (0.171:0.172:0.172) (0.147:0.147:0.147))
)
)
)

and related warning is:
SDF WARNING: testbench.v:95: Unable to match ModPath B2 -> Q

[Cary R.]

After I pushed the patch I realized I forgot to add support for a single delay and that is what is causing the first assert. It is trivial to add this and I will try to add it later when I have some free time.

The warnings are likely more specific to your circuit topology and I would need a better representation to figure out the problem. This is usually caused because Icarus merges nets so it cannot find a net connection with the given name. There is already a report in the tracker concerning some of this (when two ports of an instance are driven by the same net).

For now lets ignore the warnings since they just represent delays that are not being back annotated and focus on the asserts. I know how to fix the first assert, but need information on the second one. We can help with suggestions regarding how to modify the source to get more diagnostic information to make it easier to find the failing cell information if needed.

[Anonymous]

I found the cause of the 2nd assert failure and I think it has to do again with single delay. Here is the cell:
(CELL
(CELLTYPE "NAND3_X2")
(INSTANCE read_mux/U222)
(DELAY
(ABSOLUTE
(IOPATH A1 Q (0.052:0.052:0.052))
(IOPATH A2 Q (0.077:0.078:0.078) (0.071:0.071:0.071))
(IOPATH A3 Q (0.081:0.081:0.081) (0.079:0.080:0.080))
)
)
)
What could be tremendously helpful is to give the line number in the SDF which caused the assertion failure (otherwise, I have to systematically comment the sdf file to find out which cells is the cause of the failure which takes a hell of time to do!!).

In regards to the warning, please let me know how I best can assist you to find the root of the issues.

Thanks

[Cary R.]

The problem with the current assert location is we do not have this information. We can hack the code to get better information by dumping a lot of extra information as we try to update each delay and the last line before the assert will be the one that has the issue. There is only one line in the sys_sdf.c file (located in the vpi directory) that puts delays (vpi_put_delays). You could take something like the lines that follows for the case when no match is found to display which ModPath is trying to be updated.

I have pushed support for putting a single delay from the VPI (SDF). I think this addresses all the delay types that can be put from the VPI. There are still a few things I want to double check. If this solves the asserts we can start looking at the delays that are not matching.

Regarding the warnings. The easiest is if you can give us access to the source file or a reduced set of the files that show the problem so we can debug the problem locally. Otherwise in the sdf_iopath_delays() routine in the sys_sdf.c file I mention earlier there is code that iterates over the ModPaths for the given instance. Printing out the input and output signals for each ModPath before it is matched should give us a clue which ModPath is not correct.

A comment about the VPI. It only supports having one active return string buffer at a time. So since you want to print both the ModPath input string, vpi_get_str(vpiName,path_in), and the output string, vpi_get_str(vpiName,path_out), you need to do these as separate print statements. For example

vpi_printf("Debug: Found a ModPath from %s to ", vpi_get_str(vpiName,path_in));
vpi_printf("%s.\n", vpi_get_str(vpiName,path_out));

I'm guessing some of these are not going to match what you expect for the cell. We then need to look at the input to VVP and try to figure out why the wrong name is being used.

To keep everything straight you probably want to start the debug output (outside the while loop) with something like the following:

vpi_printf("Debug: Dumping ModPaths for instance %s.\n", vpi_get_str(vpiFullName, sdf_cur_cell));

Since these do not appear to be edge sensitive structures I omitted the edge information in the debug output. We could also only emit the debug information for a specific cell type that is having a problem to minimize the output that is being generated.

[Anonymous]

Cary: You took me to a territory which I hesitated to enter! Yet here are some of my discoveries by adding some lines to sys_sdf.c:

1- The print statements for input/output are not a huge help -- at least not immediately to me. They look similar to

Debug: Now dealing with a ModPath 'm1.U31' from A to Q

2- I added a few more debugging statements and I see a lot of sources which do not match, or destination not being matched. But these do NOT cause any warning apparently.

3- The most important discovery is that those SDF warnings are generated due to the fact that as you enter the 'sdf_iopath_delays', the match_count is set to zero. For whatever reason, the line:

if (iter) while ( (path = vpi_scan(iter)) )

in the above routine fails, and thus the while statement does not get executed at all which takes you immediately to where you print the 'SDF WARNING' message due to the fact that the line:
if (match_count == 0) {
is obviously true.

Hope that helps. I am waiting to receive your correction for supporting one delay for the SDF file.

Thanks

[Cary R.]

Yes I understand, not everyone is multi-lingual.

In the previous message I said I had pushed the patch to support one delay constructs.

The difference between the debug and what I had for input/output is the warning is what is trying to be matched and the new output is the list of possible matches. To be successful we have to find a match in the possibilities and if there isn't a match we need to understand what is wrong in the possibilities.

If you are talking other SDF constructs that is probably correct. I believe conditional IOPATHs are also not matchable. These are likely thing that we already know Icarus cannot match. Like I said earlier Icarus has poor SDF support. We do not recommend it for verifying gate level simulations. That's why you have to pass -gspecify to turn the specify block on. If we thought it worked good enough specify support whould be enabled by default. I always run my gate level simulations in Icarus, but that is mostly as a check of Icarus not the actual circuit.

If the loop is immediately failing then that implies there are no ModPaths attached to the instance which is a bigger problem. My guess is that the loop is running, but the ModPath ports are not matching which is why the match count is zero. The debug lines I mentioned previously must be before the lines that are matching the input, output and edge constructs between the SDF entry and the current ModPath (i.e. line 168 just after the assert statements). This routine basically takes an IOPATH entry to match and an instance pointer. We iterate over the ModPaths in the instance looking for ones that matches the input, outut and edge. If we find a match then the delay is updated. If we get to the end of the ModPaths and a match is not found then we report this as an unmatches entry.

The output I was hoping to get was something like the following:

...
Debug: Dumping ModPaths for instance foo.
Debug: Found a ModPath from A to Q.
Debug: Found a ModPath from B to Q.
SDF WARNING: testbench.v:95: Unable to match ModPath B2 -> Q
...

The first information is what instance foo supports and the last line is what was being looked for. For matching cases you are going to get a lot of extra output, but for the failing cases we know what the instance thinks it supports. I am expecting something to be incorrect in what the instance thinks it supports relative to the model. Like I said earlier in the thread this is often because Icarus was not able to figure out the correct port because of how it handles the structural interconnect of the circuit. It will simulate correctly because it is connected correctly, but the named connections for the ModPaths are not always correct. For the bug that I previously mentioned (two instasnce ports connected to the same extern net) currently we have no way in the compiler to determine which of the two net names for the module should be used.

Here's probably more detail than you need, but does explain the problem. The ModPath in the compiler is given a net pointer for the input and output connections. When emitting the ModPath we look in this net structure for a net that is defined in this structure and use that as the name for the ModPath. The problem is when there is more than one port conneced to the net we have multiple choices so we cannot determine which of the names to use.

[Anonymous]

First of all thanks for pushing to support for 1 delay.
The lines were actually added at line number 169 right after the assertions. The thing that I need to emphasize is the fact that "Debug" is not going to be like the one that you have indicated in your resent post but instead resembles something like the followings:

Debug: Now dealing with a ModPath 'm1.U84' from A to Q.
Debug: Now dealing with a ModPath 'm1.U80' from A to Q.
Debug: Now dealing with a ModPath 'm1.U31' from A to Q.
SDF WARNING: testbench.v:95: Unable to match ModPath A -> Z in m1.ph_sio_tri
SDF WARNING: testbench.v:95: Unable to match ModPath EN -> Z in m1.ph_sio_tri
SDF WARNING: testbench.v:95: Unable to match ModPath A -> Z in m1.ph_sen_tri
SDF WARNING: testbench.v:95: Unable to match ModPath EN -> Z in m1.ph_sen_tri
Debug: Now dealing with a ModPath 'm1.m2.U4' from A1 to Q.
Debug: Now dealing with a ModPath 'm1.m2.U4' from A2 to Q.

And as you can see, "m1.U31" above is totally a different entity than "m1.ph_sio_tri".

Another important point is the fact that as I said in my previous post, the 'while' statement for 'm1.ph_sio_tri' NEVER gets executed as it immediately fails when you are testing it in:
if (iter) while ( (path = vpi_scan(iter)) ) {

At any rate, to give you a view of how I have modified the 'sdf_iopath_delays' routine in 'sys_sdf.c', here it is in its entirety (please note in particular the added integer 'test_failed' variable):

void sdf_iopath_delays(int vpi_edge, const charsrc, const chardst,
const struct sdf_delval_list_s*delval_list)
{
vpiHandle iter, path;
int match_count = 0;
int test_failed = 0;

  if (sdf_cur_cell == 0)
    return;

  iter = vpi_iterate(vpiModPath, sdf_cur_cell);

/* Search for the modpath that matches the IOPATH by looking
   for the modpath that uses the same ports as the ports that
   the parser has found. */
  if (iter) while ( (path = vpi_scan(iter)) ) {
    s_vpi_delay delays;
    struct t_vpi_time delay_vals[12];
    int idx;

    vpiHandle path_t_in = vpi_handle(vpiModPathIn,path);
    vpiHandle path_t_out = vpi_handle(vpiModPathOut,path);

    vpiHandle path_in = vpi_handle(vpiExpr,path_t_in);
    vpiHandle path_out = vpi_handle(vpiExpr,path_t_out);

      /* The expressions for the path terms must be signals,
         vpiNet or vpiReg. */
    assert(vpi_get(vpiType,path_in) == vpiNet);
    assert(vpi_get(vpiType,path_out) == vpiNet
       || vpi_get(vpiType,path_out) == vpiReg);
        vpi_printf("Debug: Now dealing with a ModPath '%s' ", vpi_get_str(vpiFullName, sdf_cur_cell));
        vpi_printf("from %s to ", vpi_get_str(vpiName,path_in));
        vpi_printf("%s.\n", vpi_get_str(vpiName,path_out));
        test_failed = 0;
      /* If the src name doesn't match, go on. */
    if (strcmp(src,vpi_get_str(vpiName,path_in)) != 0){
              test_failed = 1;
              vpi_printf("Debug2: sources do not match %s", src);
              vpi_printf(" %s\n", vpi_get_str(vpiName,path_in));
      continue;
        }
      /* The edge type must match too. But note that if this
         IOPATH has no edge, then it matches with all edges of
         the modpath object. */

/ --> Is this correct in the context of the 10, 01, etc. edges? /
if (vpi_edge != vpiNoEdge && vpi_get(vpiEdge,path_t_in) != vpi_edge){
test_failed = 2;
vpi_printf("Debug3: edge mismatch");
continue;
}

      /* If the dst name doesn't match, go on. */
    if (strcmp(dst,vpi_get_str(vpiName,path_out)) != 0){
              test_failed = 3;
              vpi_printf("Debug4: dst do not match %s", dst);
              vpi_printf(" %s\n", vpi_get_str(vpiName,path_out));
      continue;
    }

      /* Ah, this must be a match! */
    delays.da = delay_vals;
    delays.no_of_delays = delval_list->count;
    delays.time_type = vpiScaledRealTime;
    delays.mtm_flag = 0;
    delays.append_flag = 0;
    delays.plusere_flag = 0;
    vpi_get_delays(path, &delays);

    for (idx = 0 ; idx < delval_list->count ; idx += 1) {
      delay_vals[idx].type = vpiScaledRealTime;
      if (delval_list->val[idx].defined) {
        delay_vals[idx].real = delval_list->val[idx].value;
      }
    }

    vpi_put_delays(path, &delays);
    match_count += 1;
  }

  if (match_count == 0) {
    vpi_printf("(%d: 1== src; 2= edge; 3==dst) SDF WARNING: %s:%d: ", test_failed, vpi_get_str(vpiFile, sdf_callh),
               (int)vpi_get(vpiLineNo, sdf_callh));
    vpi_printf("Unable to match ModPath %s%s -> %s in %s\n",
           edge_str(vpi_edge), src, dst,
           vpi_get_str(vpiFullName, sdf_cur_cell));
  }

}

[Cary R.]

Interesting. From your output it truely does imply that there is no ModPaths for the m1.ph_sio_tri instance. To verify this look in the output from the compiler and look for the following:

S_0x<scope_number> .scope module, "<instance_name>" "<instance_type>" ...

so search for m1.ph_sio_tri in the instance name. I'm gussing the type will be TBUF_X2. After this should be a few lines that define the port information, the structural components that implement the functionality (e.g. BUFIF, BUF, etc.) and the nets in the module. What we care about is the scope number.

If you search for the full scope name S_0x<scope_number> you should find a line that has .scope <full_scope_name> followed by a .modpath definition. The name before the .modpath should match what was connected to the "Z" net in the original scope definition <some_name>/m the stuff after the .modpath should be the width and the instance name and output for the BUFIF after this should be lines for the "A" and "EN" delays.

If you can provide the pertinent .scope parts that would help (definition and modpath sections). Something very strange appears to be happening. I need this information to understand if the problem is in the compiler or the run time.

[Anonymous]

Do you mind telling me how to generate those type of outputs? Are there specific options for either 'vpp' or 'iverilog' which I need to turn on to get these compiler outputs?
I normally invoke the tools like this:
iverilog -o stim -f file_list.fl -g specify
followed by
vpp stim

and I have not yet seen the kind of outputs that you are talking about from the above commands.

Thanks

[Cary R.]

To verify this look in the output from the compiler...

This comment is referring to the output from the compiler and the input to the run-time or in your case the stim file. Errors in this file relative to the Verilog are compiler bugs. Misinterpretations of this file are run-time bugs. You can think of it as the assembly version of your circuit and test bench.

[Anonymous]

Sorry for a bit of delay, as I was trying to make sure that gate sim without SDF works first.
At any rate, here are the info that you had asked for:

S_0x7f9ab9f9b7b0 .scope module, "ph_sio_tri" "TBUF_X2" 4 27558, 5 27729 0, S_0x7f9ab5102950;
.timescale -9 -12;
.port_info 0 /INPUT 1 "A"
.port_info 1 /INPUT 1 "EN"
.port_info 2 /OUTPUT 1 "Z"
L_0x7f9aa7eece60 .functor BUFIF0 1, L_0x7f9aa7eecf80, L_0x7f9aa7eeced0, C4<0>, C4<0>;
L_0x7f9aa7eeced0 .functor BUF 1, V_0x7f9ab5109fb0/m, C4<0>, C4<0>, C4<0>;
L_0x7f9aa7eecf80 .functor BUF 1, V_0x7f9ab512a180/m, C4<0>, C4<0>, C4<0>;
v0x7f9ab9f9b9d0_0 .net "A", 0 0, V_0x7f9ab512a180/m; alias, 1 drivers
v0x7f9ab9f9ba60_0 .net "EN", 0 0, V_0x7f9ab5109fb0/m; alias, 1 drivers
v0x7f9ab9f9bb30_0 .net8 "Z", 0 0, RS_0x10e1c54f8; alias, 3 drivers, strength-aware
v0x7f9ab9f9bbc0_0 .net "Z_enable", 0 0, L_0x7f9aa7eeced0; 1 drivers
v0x7f9ab9f9bc50_0 .net "Z_in", 0 0, L_0x7f9aa7eecf80; 1 drivers

[Cary R.]

You did not provide the ModPath section, but from what you did show it looks like part/all of the problem is that since this is a tri-state net we are loosing the connection to the output. My simple example only had a single instance. If I create multiple instance then that will force something to resolve and that will likely break things at my end. It looks like you are getting ModPaths since there are /m connection on the two inputs. The output net is missing a /m connection since it is coming from the resolve circuitry. This is likely not trivial to fix, but I won't know for sure until I have a local example that reproduces the problem. For now just ignore the warnings. Icarus is already silently skipping a lot of your delays so a few more won't make things that much worse. As a minimum I would like to catch this condition as not supported like conditional delays, net delays, etc.