GSoC 2023 Application

[mole99]

Recently, GSoC 2023 was announced. It would be great if a project for Icarus Verilog could be submitted.

I already talked in #746 about how this could work, but I am opening this issue for greater visibility.

FOSSi Foundation

The FOSSi Foundation is an umbrella organization for GSoC. Their list of previous project ideas shows that a project based on Icarus would fit in pretty well.

Submitting a project via the FOSSi Foundation would reduce the admistratice burden on the mentor as written on their website.

In this way we enable experienced community members to mentor mentees while the FOSSi Foundation takes care of the administrative parts of GSoC.

Mentor

There needs to be a mentor available for the project who has at least 2 hours a week available for mentoring.

For more information see the FOSSi Foundation GSoC House Rules.

Project Idea

I personally would like to work on the SDF support of Icarus. The ultimate goal would be to get Icarus' SDF support in a working state for the OpenMPW program. This is a worthwhile goal as the program becomes increasingly popular and now covers even more PDKs.

Please tell me what you think about all this :)

[mole99]

Hi @steveicarus, I'm pinging you to make sure you see this :)

Around January, the FOSSi Foundation asks for project ideas. There's still a lot of time before then, but time goes fast, especially in December. It probably makes sense to prepare a project idea a bit earlier if the intend to participate in GSoC is there.

If I can help in any way, please let me know.

[red0bear]

Where is community to put money on icarus on these days.

[mole99]

What do you mean, @red0bear?

While I agree with you that people should contribute when they can, be it with money, by opening bug reports or by writing code, I don't see exactly the connection to GSoC?

GSoC is sponsored by Google to allow students, and more recently even beginners in open source software development, to contribute to projects that interest them under the guidance of mentors. It allows students to dedicate their time during the summer to open source projects without having to worry about finances.

Of course, Google isn't doing this because they're just being nice, but because they too rely on open source software to a large extent ;)

In summary, participating in GSoC does not cost Icarus any money. It allows students to dedicate their time working on Icarus while being guided by a mentor.

I hope this made it a bit clearer.

[red0bear]

Google never was nice with anyone in globe. If they are good people icarus could be added there long time ago. Work with this is very frustrating. But what make things good is when community put money on it instead ask for a big corporation to do it. But thats only my personal opinion.

[steveicarus]

I have mentored GSoC projects for Icarus Verilog in the past, but I don't have the bandwidth to do so this go-round. If you can round up someone willing to do the mentoring, I'll gladly look at and approve any project you want to don.

[steveicarus]

@caryr has worked on the SDF part of things, so I suggest that you ping him to see if he's willing to mentor you. (He as also done GSoC mentoring in the past.)

[caryr]

I may be able to mentor, but have been very busy with work and the rest of my life the last couple years. I remember you talking about the SDF improvements in the other PR.

Lets start with figuring out what you think is critical to implement, because some of this will require significant improvements in the VPI interface and VVP internals to allow the SDF annotation to work properly. Also I would prefer someone else drive getting us sponsored. I can act as the figure head and mentor of record, but expect to continue to be very busy for the first half of next year and likely longer.

I should have some time over the next month to work on a proposal, but I want to make sure this is successful for the student so this may require those of with more experience to help out with the VVP internals. @steveicarus this is likely where you would be most helpful/needed (e.g. wire delays and how those get placed relative to the drivers). I think as a team we could make this work, but I don't think it is something I can support entirely on my own.

We also have to be ready to support related bugs as we start more completely testing gate level simulations. I think we are in a relatively good place and SDF annotation is the primary limitation, but we do need to make sure other items do not get in the way of the SDF work.

[caryr]

Another candidate for GSOC work is there are a number of items missing to allow proper mixed signal modelling, but this is likely a multi year project where different pieces are implements. I have bits and pieces of this started, but the big missing item is unpacked structures along with nettypes and efficient resolution functions. Think of a Thevenin type with a drive voltage and resistance that is an unpacked structure with two reals. You then need to be able to declare this as a nettype and give it a resolution function to resolve multiple drivers. The resolution function is written in Verilog code, but needs to be very efficient when executed since it is run each time one of the driver nets changes a value.

Adding DPI support while not required would also be nice.

[mole99]

Thank you @steveicarus and @caryr for your replies.

I understand that there is only so much time available, and mentoring takes up another chunk of that time. But I also don't think that I will need full-time mentoring, just someone to point me in the right direction.

It would be great if you caryr could be the official mentor of the project. I completely agree that it would be good to have multiple contact persons so that the individual load decreases and I can ask my questions more targeted.

Maybe there are a few more people who are familiar with the internals of Icarus and wouldn't mind answering some of my questions from time to time.

On to what I think is important to implement:

I had a look at some SDF file generated by the OpenLane flow. The missing features are in line with your comment on #746. There are three categories not yet supported in Icarus:

• wire/interconnect delays
• conditional path delays
• timing checks

As an example, I have two SDF files generated from one of my designs. One for the SKY130A PDK and the other one for the GF180 PDK:

wfg_top_sky130.sdf (wfg_top_sky130.zip)

wfg_top_gf180.sdf (wfg_top_gf180.zip)

From what I see in wfg_top_sky130, Icarus needs to support INTERCONNECT to simulate designs for SKY130.

wfg_top_gf180 additionally uses conditional path delays with the keyword COND. This would then be the next priority in order to support GF180.

Both SDF files use timing checks that would be ignored initially, but if there is enough time, an implementation for the following timing checks could be considered:

Timing Checks:

• setup
• hold
• recovery
• removal

All in all, the rough order of work would be as follows:

1. INTERCONNECT
2. COND
3. TIMINGCHECK

If possible, I would really like to work on SDF support :)

Of course there are also interesting topics like AMS or DPI support, but for me personally SDF support would be the most interesting to work on because of the ongoing OpenMPW shuttles and the recent releases of open source PDKs.

[caryr]

I'm sure we can come up with enough time to support you to be successful. Like I said previously I'm okay being the mentor of record. I will certainly need some help from others, but I don't expect that to be too much of a problem.

Have you verified that Icarus parses all the SDF files and generates appropriate warning messages or are there constructs that cause errors? If there are other errors do they fall into the existing categories or are there other missing constructs?

[mole99]

That sounds great :) I'm looking forward to working on this project.

I haven't checked it by simulation yet, which I should have done in hindsight. I have now run a simulation for wfg_top_sky130.sdf:

Icarus parses the file and generates warning messages. The output consists of two types of warnings. Once for INTERCONNECT:

wfg_top_sky130.sdf:18: SDF WARNING: INTERCONNECT not supported.
...
wfg_top_sky130.sdf:37063: SDF WARNING: INTERCONNECT not supported.

And other warnings in the form of:

SDF WARNING: top.sv:53: Unable to match ModPath A -> Y in tb.wfg_top._10050_
...
SDF WARNING: top.sv:53: Unable to match ModPath A -> X in tb.wfg_top.clkbuf_opt_4_0_io_wbs_clk

Which I am not sure if they are issued due to the unimplemented INTERCONNECT or because of a problem with IOPATH.

The entries for _10050_ in wfg_top_sky130.sdfare:

    (INTERCONNECT _10050_.Y _10066_.A1 (0.000:0.000:0.000) (0.000:0.000:0.000))
    (INTERCONNECT _10050_.Y _10069_.A (0.000:0.000:0.000) (0.000:0.000:0.000))
    (INTERCONNECT _10050_.Y _10091_.B1 (0.000:0.000:0.000) (0.000:0.000:0.000))
...
    (INTERCONNECT _20898_.Q _10050_.A (0.000:0.000:0.000) (0.000:0.000:0.000))
...
 (CELL
  (CELLTYPE "sky130_fd_sc_hd__inv_2")
  (INSTANCE _10050_)
  (DELAY
   (ABSOLUTE
    (IOPATH A Y (0.100:0.100:0.100) (0.075:0.075:0.075))
   )
  )
 )

The instantiation of _10050_ in wfg_top_sky130.v is:

 sky130_fd_sc_hd__inv_2 _10050_ (.A(\wfg_drive_spi_top.wfg_drive_spi.cur_state[1] ),
    .VGND(vssd1),
    .VNB(vssd1),
    .VPB(vccd1),
    .VPWR(vccd1),
    .Y(_02696_));

There are also no warnings issued that timing checks are not yet supported. This would be another point on the list, to first add a warning for unsupported timing checks.

I have also tried to simulate for GF180 but I did not yet manage to do so. There are some missing modules which I can not find anywhere in the PDK. There are also no example simulations available from Efabless' side yet. I think it makes sense to focus on SKY130 at the beginning.

[caryr]

If all you see is warnings then it is something I have looked at in the past and I usually remember the issues I was facing in the implementation once I start to look at the code again. Timing checks are currently removed by the compiler so I think the SDF annotator may incorrectly silently drops them. Adding an appropriate warning should be trivial.

I think the modpath issue is rooted in the conditional path delay limitations even though this specific instance only has a single path. My guess is the simple cases like this you can implement first and then enhance the code to handle the more complex cases.

Trying to get two larger examples to test with is good. Also look at the existing SDF tests to see how those were implemented so you can understand the methodology.

[mole99]

I see, you previously took the time to turn the crashes due to unsupported features into warnings.

Adding a warning for timing checks may then be a good starting point to familiarize myself with the codebase.

Yes I agree the SDF file from the GF180 process node would also be very useful for development. I will make sure that I get it to simulate, at the latest by the start of the project.

I will take a look at the SDF tests in Icarus.

Regarding the organizational:

I just saw that the FOSSi Foundation requires at least two mentors listed. While many projects from 2022 only have one mentor listed, I think it would be better to list two as per the FOSSi Foundation GSoC House Rules. Would it be possible to add you @steveicarus alongside caryr to the mentors list? Just for the official part of course.

The application seems to consist only of a PR in their Git repository with a description of the project, skill level, duration, language/tools and the mentors. I would like to do the project with a time commitment of ~350 hours.

Please see the PR for last year's GSoC ideas: https://github.com/fossi-foundation/fossi-foundation.github.io/pull/52

Caryr, you mentioned that you have time to write the proposal in the next month. So you would be handling the project submission to the FOSSi Foundation?

[caryr]

I believe they like to have two listed mentors so that if one needs to drop out for some unforeseen issue the student will not be negatively impacted.

Yes, reviewing the existing code that implements the current SDF annotation would be very beneficial. I try to leave comments regarding what I am working on and the basic issues I was facing. Reviewing these, understanding how the existing code works and understanding the basic work needed to finish the implementation will significantly improve the odds of you having a successful project.

I think most of the parsing is complete, so you will primarily need to work in C/C++. If you feel comfortable using these languages then it sounds like we have a good fit. I will start getting the proposal together next week. I will likely post it here for commenting before officially submitting it to the FOSSi Foundation.

[mole99]

Yes, I expected to work in C/C++.

Awesome, thank you!

[mole99]

Hi @caryr, kindly checking whether you had the opportunity yet to create a proposal? I could also give it a try if you want :)

From the latest El Correo Libre Issue: "the FOSSi Foundation will be announcing its slots as an umbrella organisation as soon as they are confirmed." Meaning there is still some time, but I would expect the submissions to open up soon-ish.

[mole99]

Hi!

It seems that the FOSSi Foundation is now accepting ideas for GSoC 2023: https://github.com/fossi-foundation/fossi-foundation.github.io/pull/75

I have prepared an application that we can submit as PR:

---

Improving SDF support in Icarus Verilog

Details: With the release of the open source PDKs from Skywater Technology and Globalfoundries and the associated OpenMPW program, ASIC design has never been more accessible. Icarus Verilog covers the parts for RTL and GL simulations. But when it comes to back-annotated timing simulations using the Standard Delay Format (SDF), Icarus lacks certain features.

There are three categories of features not yet supported in Icarus:

• wire/interconnect delays
• conditional path delays
• timing checks

The focus of this project is to improve Icarus' support for SDF files. Simple cases will be implemented first, and then the code will be extended to handle the more complex cases. The ultimate goal is to perform accurate SDF simulations for SKY130 (and possibly GF180).

Skill level: Intermediate to Advanced

Duration: ~350 hrs.

Language/Tools: C, C++, Verilog

Mentors: Cary R. (email), Stephen Williams (email)

---

@caryr @steveicarus

Are format and content of the application fine?

Then either you or I can open a PR here: https://github.com/Jbalkind/fossi-foundation.github.io.

If I submit the application, I would need your email addresses to put after your name so that the FOSSi Foundation can contact you.

Thank you very much!

[mole99]

I will now submit the project idea to the FOSSi Foundation. (Just to make sure our project is included).

For your emails, I'll use cygcary AT yahoo.com and steve AT icarus.com.

If there are things that need to be changed in the description or anywhere else, please tell me and I will make sure another PR is opened.

[mole99]

The project idea has been included in the project list for GSoC 2023: https://github.com/fossi-foundation/fossi-foundation.github.io/pull/78

The next item in the timeline is already the application for GSoC contributors on March 20. I will be working on a more detailed proposal before then.

If you have anything you want to discuss, just let me know :)

[mole99]

@steveicarus @caryr The project has been accepted for GSoC23 🎉️ I am looking forward to working on it over the summer.

My mentors for this project are Tim Edwards, Mohamed Shalan and you, Cary R. So it seems I also have some mentors from other projects that were not realized.

@caryr is this still your correct email address and preferred way to communicate for individual matters: cygcary AT yahoo.com ? Did you get some information from GSoC org or the FOSSi Foundation?

Also I want you to know that I would like to extend the project duration from 12 weeks to 16 weeks because I am a bit busy at the beginning. The workload stays the same (350 hours) but I have time until September the 25th for my final submission.

Next up are a couple of GSoC information sessions I'll be attending, with official coding beginning May 29.

[caryr]

I received notice of this a few days ago. I believe the day before you. I had previously completed my official mentor signup using my gmail account. For this GSOC work the yahoo email you referenced is correct.

I think any change in the timeline/deadlines needs to be approved by the GSOC folks so make sure that is taken care of.

I welcome the other mentors. I need to reach out to them to discuss, but having other perspectives regarding implementation advice will be a great benefit to you. I believe I am the primary mentor and will be responsible for handling reviews, etc.

Congratulations being accepted into the GSoC23!

Cary

[mole99]

Perfect, then I will use the email for our own little "mailing list" so that for general topics, I can write to everyone at once.

Yes, Tim Edwards has already contacted an Org Admin about it so that the project page can be updated.

As soon as Mohamed Shalan has replied, I will send an email to you all so that we can discuss everything. I too think it is good to have several mentors, it increases the chance for success and spreads the mentoring workload across everyone. For questions about Icarus' internals I will mainly ask you, as I believe that you have the most experience with that 😉️

Thank you 😃️

Leo

[caryr]

I really like the idea of us all communicating about all aspects of your project. Given the diligence and perseverance you have shown in getting to this point I expect this will be a success for you as well as Icarus. Please reach out if you have any questions.

Cary

[caryr]

Looking for a status update. I have not received any emails in a few weeks and wanted to make sure it was not some kind of configuration issue when you set up the email list, etc. I'm looking forward to working with you and the other mentors to make this a successful project.

[mole99]

Sorry for the radio silence! The last few weeks have been busy, but things are calming down now.

I was planning on sending out the email this weekend. So either tomorrow or on Sunday. By the way, I will write to you all directly, no need for a real mailing list :)

As the project gets underway next week, I will keep you all updated on a regular basis.

Leo

[caryr]

I completely understand. I was just making sure everything was okay for you to start next week.