SDF WARNING: INTERCONNECT not supported

[Yang-Xijie]

main.sh

iverilog -g2012 -gspecify \
-s testbench \
-D 'DUMP_FILE_NAME="./output/inverter.vcd"' \
-D 'SDF_FILE_NAME="./output/inverter.sdf"' \
-o ./output/iverilog_simulation_program
echo "iverilog end"
vvp ./output/iverilog_simulation_program -sdf-verbose

testbench.v

`timescale 1ns / 1ps

module testbench();
    reg in;
    wire out;
    inverter inverter(in, out);

    initial begin
        $dumpfile(`DUMP_FILE_NAME);
        $dumpvars;
    end

    initial begin
        $sdf_annotate(`SDF_FILE_NAME, testbench.inverter);
    end

    initial begin
        in = 0; #1
        in = 1; #1 
        in = 0; #1 
        $finish;
    end
endmodule

sdf

(DELAYFILE
 (SDFVERSION "3.0")
 (DESIGN "inverter")
 (DATE "Fri Jul 29 18:21:13 2022")
 (VENDOR "Parallax")
 (PROGRAM "STA")
 (VERSION "2.0.17")
 (DIVIDER /)
 (TIMESCALE 1ns)
 (CELL
  (CELLTYPE "inverter")
  (INSTANCE)
  (DELAY
   (ABSOLUTE
    (INTERCONNECT in _2_/A (0.000::0.000))
    (INTERCONNECT _2_/Y out (0.000::0.000))
   )
  )
 )
 (CELL
  (CELLTYPE "sky130_fd_sc_hd__clkinv_1")
  (INSTANCE _2_)
  (DELAY
   (ABSOLUTE
    (IOPATH A Y (0.011::0.011) (0.018::0.018))
   )
  )
 )
)

vvp log

iverilog end
VCD info: dumpfile ./output/inverter.vcd opened for output.
./output/inverter.sdf:3:SDF INFO: Design: inverter
./output/inverter.sdf:4:SDF INFO: Date: Fri Jul 29 18:09:54 2022
./output/inverter.sdf:5:SDF INFO: Vendor: Parallax
./output/inverter.sdf:6:SDF INFO: Program: STA
./output/inverter.sdf:7:SDF INFO: Program Version: 2.0.17
./output/inverter.sdf:9:SDF INFO: TIMESCALE : 1ns
./output/inverter.sdf:15: SDF WARNING: INTERCONNECT not supported.
./output/inverter.sdf:16: SDF WARNING: INTERCONNECT not supported.
SDF WARNING: ./inverter_testbench.v:14: Unable to match ModPath A -> Y in testbench.inverter._2_

I wonder whether I made the commands correct... got SDF WARNING: INTERCONNECT not supported...

[Yang-Xijie]

https://sourceforge.net/p/iverilog/mailman/iverilog-devel/thread/CADJOd7rNqmmNEoDFmJf41CiASEUosJcSbee1cma2Y2jJD%3DrErA%40mail.gmail.com/#msg35641024

Thread: [Iverilog-devel] SDF back annotation support

[Yang-Xijie]

https://github.com/steveicarus/iverilog/blob/d8cb29f6e0cb6ec08d40b2aefe6e83e064ced707/vpi/sdf_parse.y#L304-L307

[Yang-Xijie]

According to https://www.syncad.com/web_manual_bughunter_verilogger/bughunter_verilogger_main_index.html?using_a_standard_delay_file.htm

Note, this type of timing simulation is often unnecessary if you use a static timing analysis tool to verify the critical paths in your design meet the timing constraints of your design.

Is this the reason that iverilog and verilator do not support sdf annotated simulation?

[martinwhitaker]

Is this the reason that iverilog and verilator do not support sdf annotated simulation?

As discussed in the iverilog-devel thread you referenced earlier, Icarus Verilog does support SDF back-annotated simulation to a limited extent. It does not support all SDF features simply because nobody has had the time and/or motivation to do the work to implement them. But yes, the use of static timing analysis contributes to that lack of motivation.

Verilator on the other hand cannot support SDF back-annotated simulation because it is a cycle based simulator and ignores any delays in the Verilog models.

[mole99]

I just want to add another motivation for better SDF support because I see a sky130 cell here :)

For those who haven't heard of it, there is the Google-sponsored Open MPW Program to tape out on sky130. Currently, Icarus Verilog is the default simulator for RTL and GL simulations in the open flow.

Recently they made the neccessary changes for GL+SDF simulations, but have to use another simulator called CVC from Tachyon, which seems to be not maintained anymore, because Icarus Verilog does not (yet) support the neccessary SDF features.

[caryr]

The Open MPW Program is very interesting and you are correct that does have some motivation. The fundamental problem is time. All the primary developers have demanding full time jobs and this is unlikely to change anytime soon.

Regarding the SDF support in Icarus. Everything should be warnings about items that are being dropped because they are not supported. If that is not the case then an example would be appreciated. From memory their should be three categories of things not supported: timing checks, wire/interconnect delays and conditional path delays.

Timing checks should not be too hard. We just need to make sure support for negative setup/hold times are accounted for in the implementation. At one point in time I was very close to working on an implementation.

Wire/interconnect delays should probably be implemented as part of the net driver functionality Steve did a few years ago since the SDF cannot really change the structural nature of the design. For efficiency reasons we may want this to be polymorphic between nets with delay and nets without. Probably all nets should start out as no deay and then get updated to be a kind that supports delay later. The big difference between net delays and SDF interconnect delays is net delays support only a single delay value to all destinations where the SDF interconnect delays can have a different value to each end point. This implies changing from a point to multi point drive configuration like is needed for no delay and probably net delays to a point to point configuration. Also this all needs to have an efficient implementation since moving values around the system is primarily what a simulator does.

Handling conditional delays is a limitation because we need to match the expression in the SDF condition to the expression in the modpath and support for determining the modpath expression was never implemented. I also seem to remember there is a subtle bug in the modpath expression calculation . It should be computed when the input changes, but the actual implementation treats it like all other net where when an expression items change that part of the expression is recalculated. A very long time ago I started a general expression rework that should resolve both issues, but I have not worked on that in over a decade. The matching does not need to be that efficient since that is part of the SDF loading phase, but it certainly does need to handle expression order mismatches and possibly even expression optimizations/reductions.

This would all make a good GSOC project or two for an ambitious student, but we would need someone to make that happen.

[mole99]

Recently, GSoC 2023 was announced. Will there be a project submission around Icarus SDF support? Because I would be very interested in applying for it.

I would imagine a collaboration with the FOSSi Foundation would make sense, since it is specifically an umbrella organization for GSoC. Also, it would fit pretty well with their previous list of Ideas. This would reduce the administrative burden on the mentors side.

There needs to be a mentor for the project who has at least 2 hours a week available. I see that you, @caryr, already have a general idea about SDF support in Icarus. So maybe you could be the mentor for the project if time allows.

My driving force for this contribution is to get Icarus' SDF support in a working state for the OpenMPW program, which now covers even more PDKs, and of course to learn a lot :)

Sorry for spamming this issue, but I thought it would fit here because of the mention of GSoC. Maybe it makes more sense to continue talks about GSoC on another dedicated issue or under Discussions.