GSoC23 — Workweek 9
Introduction
As a reminder, last time I wrote about the issue when multiple functors are connected to a single source. In that case it is unclear to which of the functors the interconnect path must be annotated.
This week I have spent some time in VVP to find out how to add input and output buffers to modules, so that this ambiguity can be solved.
I was also writing smaller tests to make sure that the implementation I am working on is functioning correctly, and to find out what situations are not annotated correctly.
VVP
My goal is to add input and output buffers to modules. This means I have to look where modules are elaborated: inside elaborate.cc
.
Two functions are of special interest to us:
PGModule::elaborate_mod_
Module::elaborate
Once the top modules have been identified, they are elaborated via Module::elaborate
. This function calls the elaborate
functions for tasks, functions, classes, gates etc., anything that can be in a module. Gates can be either UDP devices or modules. If the gate is a module then the PGModule::elaborate_mod_
function will be called for it to be instantiated. This is where the input and outputs of the instantiated module are connected to the parent module - which is exactly where we want to add our buffers. Also noteworthy before the instantiated module is connected, it is itself recursively elaborated via Module::elaborate
.
PGModule::elaborate_mod_
is quite long and took some time for me to understand. Luckily for us, there is already some logic to add input buffers. If need_bufz_for_input_port
returns true, a buffer will be added to the current input.
For now, I set this function to always return true to continue with my work. Later I might add a -ginterconnect
flag or something similar.
Tests
As mentioned in the introduction, I have written some smaller test cases that I am currently using to verify the current implementation - not everything works correctly so far.
For these few modules it is still possible to check the interconnection delays by hand (or rather by eye).
But once these tests work, I want to move on to larger designs. To do this, I want to create example designs with interconnection delays using the OpenLane/OpenROAD flow, because that's what this project is supposed to enable. For these designs, I plan to write some scripts to automatically check the delays for me.
Summary
That's it for this week. Next week I will work on adding output buffers, fixing up all the smaller test cases, and then go on to creating bigger ones with OpenLane.
See you then!