GSoC23 — Workweek 11


Finally, the time has come! I was able to correctly simulate all interconnection delays for the example designs I created. You can find out how I did it and what happens next in this blog post - so read on.

Incorrect annotation

There was a slight bug in the intermodpath annotation code I wrote. When an output of a module was connected to more than one module inputs with different interconnection delays, this caused under certain circumstances the delay to be the same for all paths.

Fixing this bug pushed the success ratio for both example designs to almost 100% - almost. Now the only failed intermodpaths were from some module outputs to the outputs of the instance being annotated - e.g. to the primary outputs.

Output Signals

I had a look at the outputs of the annotated module inside the scope of the top module. There everything seemed to be alright, the output signals were delayed as they should be. Nevertheless, my script failed. Then I took a closer look at the same output signals in the scope of the annotated module and I could see that here the signals were not delayed as expected.

Strange, they should be the same signals :/

I took an even closer look at the generated VVP file and realized that the .net probe, as I will call it, for the output of the annotated module was connected to the output of the module feeding into it, because that's just as valid.

But now that I have inserted my intermodpath between the output of the module and the output of the annotated module it's no longer valid. When viewed from the inside, the non-delayed signal will be dumped and when viewed from the outside, the correct delayed signal will be dumped.

How can this be solved? First I tried to change IVL to connect the .net probes directly to the output buffers, but this proved to be particularly difficult because the NetNets for the inputs and outputs are created at parse time.

The solution I chose, which works well enough at the moment, is to simply move the .net probe from port1 to port2 under these circumstances.


The results speak for themselves.

First, we have a fully combinatorial design, alu_example.v:

║           Simulation Summary              ║
║ VCD File: alu_example.vcd                 ║
║ SDF File: alu_example.sdf                 ║
║ Instance: top.alu_example_inst            ║
║  Number of Interconnects: 139             ║
║  ✅ Number of Successes:  139             ║
║  ❌ Number of Failures:   0               ║
║  Success Ratio            100.00 %        ║

And then a sequential design, counter_example.v:

║           Simulation Summary              ║
║ VCD File: counter_example.vcd             ║
║ SDF File: counter_example.sdf             ║
║ Instance: top.counter_example_inst        ║
║  Number of Interconnects: 89              ║
║  ✅ Number of Successes:  89              ║
║  ❌ Number of Failures:   0               ║
║  Success Ratio            100.00 %        ║

All interconnection delays in the simulation match with the ones specified in the SDF file. 🎉

Of course, these are only two tests, and we will need further ones to be absolutely confident in this new feature. Still, this is very good progress and I am happy with what is already working.


There are still some limitations that need to be overcome before this feature can actually be useful for normal designs. For example, input and output vectors are currently not supported, only scalar values so far.

I'd like to work on that next, but before I do I'll make sure the current PR is ready for merging so that it doesn't accumulate too much code and functionality, which makes it much harder to review and maintain.

Also, I'm going to take a break from coding next week so I can continue motivated and re-energized the week after.

See you then!