Some questions on work libraries

[Practical-UVM-Step-By-Step]

Hi Mike:

I was wondering if you envisioned the SourceLoader class being a singleton or whether
It would make sense to have multiple instances of the SourceLoader and CommandLine classes in a extended class of the Driver being created with a new command line argument of some sort.

Here is the background to the question:

Assuming that we have a collection of files (The UVM library for example) which has a set of +defines associated with it. These defines would shape the code pulling in specific code snippets.

Now assume that this is in a file called uvm_lib.f which contains:
/uvm_pkg.sv
+define+UVM_NO_DEPRECATED
+define+UVM_HAS_CONSTRUCTOR
+define+MY_MAX_WIDTH=128

A second set of source files could contain a different define or a different value for the define.
Example: rtl.f
MAX_WIDTH=32 // from above. Maybe the RTL cannot handle it? It uses 4 transactions.
/rtl_top.v

Test bench.f
// imports the UVM package.
-F Testbench1.f

Testbench.f
+define+MY_MAX_WIDTH=64 +define+THIS_IS_OPTIONAL. // Some testbench components need it and will split the transactions into 2 based on a test bench configuration.

I would have done something like this:
<path to slang -f list.f —single_unit // to get the diagnostics you’ve coded up.

Where list.f contains
-f uvm_lib.f
-f rtl.f.
-f test bench.f

I’d have liked to keep the work libraries separate because the MY_MAX_WIDTH= is different in each of the work libraries. All major simulators do support this. Each is effectively in a separate namespace (for lack of a better word, my vocabulary fails me at this point)

MY question:
Would the CommandLine class and the SourceLoader “Squish” them together because there is only one instance? IE: would it “trample” the defines? I was hopefully wishing that each -f in list.f had essentially one SourceLoader and one CommandLine instance associated with it but I dont think that's the case.

How do you suggest we can proceed?
i'm guessing that passing —single_unit also seems like it winds up squishing definitions all into one compilation unit. But I dont see a way to add compilation units in the Compilation class. That part wasnt clear from the docs or the code.

Thanks!

[MikePopoloski]

It sounds like what you want is to have separate compilation units and be able to specify which files go into which compilation units from the command line. Right now slang only supports two options: all files are in one compilation unit, or all files are in their own separate compilation units. It's not particularly hard to support other methods, the only difficult thing is figuring out how exactly to specify it on the command line to let people get what they want.

I don't think -F (command files) are the right level of abstraction for this; they're a higher level thing that lets you specify any set of command line options, not just ones related to which files end up where. There's also the related concept of source libraries (https://sv-lang.com/user-manual.html#source-libraries) which can be passed via library map files (--libmap) though the syntax provided by the LRM doesn't let you specify defines for them. Whatever we come up with should play nicely with libraries too.

To answer your last question, in the code each SyntaxTree instance is its own separate compilation unit. This is because you can't do any parsing at all if you don't know the full set of defines, and defines are separated per-compilation unit.

[Practical-UVM-Step-By-Step]

Thanks Mike for this insight. I was so tempted to go make multiple instances of SourceLoader and CommandLine, but after seeing your comment, you're probably right, this needs some thinking through. I didnt realize that Each SyntaxTree was its own Compilation Unit.

Let me run some more experiments with the code for the book I have.

[Practical-UVM-Step-By-Step]

I’d like to ask you for suggestions on what would be a good way to proceed on this particular topic.

The library concept doesn’t give warnings or other diagnostics as per the documentation and I’m
Trying to find a happy medium where I’m able to keep files in separate compilation units but somehow
Report diagnostics after adding them to a single compilation once I’ve read all the code.

One difficulty I had is that SourceLoader doesn’t seem to be documented on https://sv-lang.com/annotated.html

After reading through the code, I thought I’d propose the below and get your thoughts:

I dont know if it’s worth modifying the sourceLoader and CommandLine to add a -work-library option which takes in a and basically helps return a syntax tree or whatever that filename stands for. the filename is nothing more than a command file which slang already supports.

IE: slang -work_library ....

If there are multiple -work-library, each one is a separate syntax tree and it’s in a new array called workLibraryTrees inside the SourceLoader.

IE:

I’d like to essentially add to SourceLoader.h
SyntaxTreeList workLibraryTrees;

Add In Driver.h
 std::vector<std::shared_ptr<syntax::SyntaxTree>> workLibrarySyntaxTrees;

In Driver.

std::unique_ptr<Compilation> Driver::createCompilation() const {
    auto compilation = std::make_unique<Compilation>(createOptionBag());

    for (auto& tree : sourceLoader.getLibraryMaps())
        compilation->addSyntaxTree(tree);

    for (auto& tree : syntaxTrees)
        compilation->addSyntaxTree(tree);

	// haven’t shown how to get to the workLibrarySyntaxTrees here. It’s probably a call to something in SourceLoader to get the pointers backs.

    for (auto& tree : workLibrarySyntaxTrees)
        compilation->addSyntaxTree(tree);




    return compilation;
}

What I couldn’t figure out was how the flow of files happened from the optionBag to the methods in SourceLoader.cpp so that I could look at some interceptions to add code for these parts.

Any insight there would be helpful.

A request: Let me know if this is going on the wrong track or there’s a cleaner way to do this with SLANG or if you think this wouldnt work. if that's the case, I'm grateful for suggestions.

Thanks!

[MikePopoloski]

The idea I've been considering is to add some command line (and by extension command file) syntax to indicate how you want files grouped into compilation units. For example, something like:

slang file1.sv {file2.sv file3.sv -DSOME_DEF} {file4.sv file5.sv --lib=mylib -DOTHER_DEF}

Any files grouped in braces would go into a single compilation unit. Some limited subset of compilation flags will be allowed in braced groups, and will apply only to those files. If you specify --lib in that group then the compilation unit is placed inside the specified named library, otherwise it goes into the default library.

[Practical-UVM-Step-By-Step]

I would offer that Thats sounds interesting.

The --lib also looks like it can get complex from a user understanding point of view and a debug point of view. I'd ask that everything inside the braces stays inside that work library which is what I believe most tools do and it's intuitive.

I'd obviously request you'd prioritize the command file syntax, simply because post-processing some other output to produce a text file that can be fed into SLANG is a lot easier than constructing a long command line string which could be error prone.
it would simplify matters for vast majority of users who'll probably take the input of some other tool and feed it to slang as a command file anyways. This would be a preferred option since they can probably will just massage that text file if they're dealing with multiple libraries anyways. Most people may want to do that.

A request:
Would it be possible to essentially give it a name at that point (I forgot to do that in my upper discussion with you)
IE slang {-library library_name file2.sv file3.sv -DSOME_DEF -Y some_path -v some_file.v +incdir+some_place }

Please consider something like this:

slang -library mylib:command_file -library mylib2:commandfile2 ...
where mylib and mylib2 form the library namers and command_file/command_file2 are the command files to slang for each library.

I'd think that You would wind up using that library_name to support Section 33.3 Libraries in Section 33.4.2 configurations which is what i'd think you'll eventually be doing ?

Thank you.

[MikePopoloski]

Yes, the --lib in my example is the same as the -library in your example.

Command files cannot work in the way you keep suggesting; they can contain essentially any set of command line flags and so they can't on their own be associated with a library. It's easy enough to just put that info into the command file though with the same example syntax.

[Practical-UVM-Step-By-Step]

Thanks Mike.
Let me know when you have something to test. I have a few real designs I want to see how it behaves with. I was about to go make a hack, but if you'll have it, it'll probably be way better than anything I can remotely come up with.

[MikePopoloski]

Will do. I can't promise any particular timeline for it though; this project is a hobby I fit in between my day job and family life.

[Practical-UVM-Step-By-Step]

Mike:
Take your time. This is the same story with me also...

You've probably figured by now that I've a book on UVM out there, slowly making its way to a 3rd edition.. I was testing the examples with the book against SLANG and the queries to you come from that account... There's a full blown SOC in Edition 1 on Github as open-source... That thing has a number of opencores RTL cores in there as well which I'd love to check against SLANG.
You can click back and check it out if you will...

I've a number of UVM lint rules in the book that many people would probably want whenever your tool is ready. My friend Srini is probably trying all this on the pyslang side as well and he's probably a little further along than me, because I'm a tad bit enthralled by your C++ code and the slang-tidy application.

My interest in libraries is simply because if you go through my UVM examples, the UVM code is put in a separate library and it'd be easier for me (and probably many others) to migrate existing tool command lines to check out SLANG..

My interest is in a UVM-1.2 <=> UVM 1800.2 testbench converter which mostly could be based off your rewriter example. I was playing with a big ugly case statement inside the print() method of the SyntaxPrinter... There isnt a converter out there in open source and it would help a lot of people if I could make that thing available because I know the differences between the library versions...

[MikePopoloski]

I added this as a new -C flag similar to -F. Some documentation here: https://sv-lang.com/user-manual.html#unit-listing