Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A Parser For Vendor Provided .ini Files #205

Merged
merged 2 commits into from
Oct 29, 2023
Merged

Conversation

Seyviour
Copy link
Contributor

Purpose

This Pull Request adds a module apycula/ini_h4x.py for parsing vendor-provided .ini files and edits the documentation to reflect the availability of a .ini parser.

Structure of .ini Files

The .ini file is a somewhat compressed table of IO Types and associated configuration options. The table has four sections -- input, output, bidirectional, and the optional i3c_bank.

Interface

ini_h4x.py provides an IniParser class for parsing .ini files. After the parse() method is called, the various sections of a parsed .ini file(input, output, bidirectional, i3c_bank) may be accessed via dot notation, or modified and written to a csv.

    iniParser = IniParser("GW1N-4")
    iniParser.parse()
    input_dict = iniParser.input

ini_h4x.py also exposes a simple command line tool to parse .ini files into csv; it may be invoked as shown below:

python ini_h4x.py --section all --export_file parsed.csv --force  GW1N-4

Correctness

The .ini file seems to contain similar information to the vendor supplied IO CSV files: input.csv, output.csv and bidir.csv. To check that the parser .ini parser works correctly, I did a (visual) check to make sure that the output of the parser and the data in the csv files were in agreement.

Documentation

This PR updates doc/filestructure.md and readme.md with information on the structure of .ini file and the newly introduced parser.

@Seyviour Seyviour changed the title Adding a Parser for Vendor Provided .ini Files A Parser For Vendor Provided .ini Files Oct 27, 2023
@pepijndevos
Copy link
Member

Wow this is really great!

It's no doubt nice to have. The more pragmatic question is if it contains any additional information compared to the other files we're already parsing that is useful for generating bitstreams. If we can replace any hardcoded constants with info from this file that would be perfect.

@Seyviour
Copy link
Contributor Author

As it stands, it's more in the nice-to-have category. There's a lot of overlap between the contents of the .ini and the IO csv files.

That said, it should be possible (in theory at least) to modify a .ini to trick the vendor tool into thinking that a device has an IO type that it doesn't have in reality. It might be interesting to see what kind of bitstream is generated in that scenario, if any is generated at all. IniParser doesn't have a method for that at the moment, but I could implement it.

@pepijndevos pepijndevos merged commit 9497de6 into YosysHQ:master Oct 29, 2023
12 of 14 checks passed
@pepijndevos
Copy link
Member

Yeah my impression is the ini and dat are mostly UI settings while fse contains the meat of the bitstream info.

@Seyviour
Copy link
Contributor Author

Thanks for merging!

Yes, absolutely. Using inotify, I noticed that the IDE accesses the .ini when the FloorPlanner tool is opened. It also accesses the .ini (along with .dat) just before place-and-route, so I think .ini may be relevant to place-and-route at least.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants