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

Add a Custom Name for CoreIR Generator When Generate Verilog #941

Open
joyliu37 opened this issue Aug 17, 2020 · 14 comments · May be fixed by #1016
Open

Add a Custom Name for CoreIR Generator When Generate Verilog #941

joyliu37 opened this issue Aug 17, 2020 · 14 comments · May be fixed by #1016
Assignees

Comments

@joyliu37
Copy link
Collaborator

joyliu37 commented Aug 17, 2020

I am using coreIR to generate a memory placeholder in RTL for further power analysis.
I want the RTL module which coreIR generator generated have the specific name matching with RTL implementation.
Currently the RTL module name is automatic generated from the gen_arg. For instance, my generated verilog have this wield name resulted from the type. https://github.com/dillonhuff/clockwork/blob/ef2d82ee46539c682c0f04263ece4b821def4da0/conv33_naive_compute.v#L118
Could we have a function to set custom name for RTL generation?

@joyliu37
Copy link
Collaborator Author

@rdaly525 Any update on this feature? I found the name is too long for some circumstances.

@leonardt
Copy link
Collaborator

There's a metadata field called verilog_name that can be used to override the default name generation in coreir. Perhaps inside your generator logic, when creating a module, you could try setting this field and seeing if it works for you?

Here's an example from the ice40 generator:

// Set verilog_name metadata to avoid ice40_ namespace prefix code generation
module->getMetaData()["verilog_name"] = "SB_LUT4";
(we need the generated verilog module to have a specific name for synthesis)

@joyliu37
Copy link
Collaborator Author

joyliu37 commented Jun 24, 2021

Thanks Lenny. It does not work for me. In the verilog generated from coreIR, the name of that module is not override by the verilog_name. Do I need to change other places? Like running a pass?
There are other data fields in my metadata, is that mattering?

@leonardt
Copy link
Collaborator

Hmm that's odd, any chance you can link me to a branch or something where the code is written? Perhaps we're setting the metadata in the wrong place, let me review the code generation logic for generators, maybe it's different and ignoring the metadata field (the example I provided was just a module not a generator, so maybe it only works for modules)

@joyliu37
Copy link
Collaborator Author

joyliu37 commented Jun 25, 2021

Yeah, I think the difference between module and generator may affect. I print out the meta-data in that instance and it's empty.
I push my code in the unsharp_fix branch in clockwork, and here is the part I encode the name into the generator module. https://github.com/dillonhuff/clockwork/blob/793ed8efadcfdb2d4511f06c9f406a9031b1fecf/ubuffer.cpp#L2366

@rdaly525
Copy link
Owner

@joyliu37 it looks like you are adding the verilog metadata to the instance instead of the module or generator.

The following should add it to the generator

    Generator* g = context->getGenerator("cgralib.Mem_amber");
    g->getMetaData()["verilog_name"] = "lake_"+genargs.at("ID")->get<string>();
    buf = def->addInstance(ub_ins_name, "cgralib.Mem_amber", genargs);
    buf->getMetaData()["config"] = config_file;
    buf->getMetaData()["mode"] = string("lake");
    //buf->getMetaData()["verilog_name"] = "lake_"+genargs.at("ID")->get<string>();

You could also try adding it to the generated module.

    Generator* g = context->getGenerator("cgralib.Mem_amber");
    Module* generatedModule = g->getModule(genargs);
    generatedModule->getMetaData()["verilog_name"] = "lake_"+genargs.at("ID")->get<string>();
    buf = def->addInstance(ub_ins_name, "cgralib.Mem_amber", genargs);
    buf->getMetaData()["config"] = config_file;
    buf->getMetaData()["mode"] = string("lake");
    //buf->getMetaData()["verilog_name"] = "lake_"+genargs.at("ID")->get<string>();

@joyliu37
Copy link
Collaborator Author

joyliu37 commented Jun 25, 2021

@rdaly525 Thanks for the suggestion. I try both way but none of them generate the corresponding name in verilog.
Should the Generator* and Module* variables used somewhere in the code?
I found in the generated coreIR json the metadata looks like this.

"ub_hw_input_global_wrapper_stencil_BANK_2":{
             "genref":"cgralib.Mem_amber",
             "genargs":{"ID":["String","_U29"], "has_chain_en":["Bool",true], "has_external_addrgen":["Bool",false], "has_flush":["Bool",true], "has_read_valid":["Bool",false], "has_reset":["Bool",false], "has_stencil_valid":["Bool",f     alse], "has_valid":["Bool",false], "is_rom":["Bool",false], "num_inputs":["Int",1], "num_outputs":["Int",1], "use_prebuilt_mem":["Bool",true], "width":["Int",16]},
             "metadata":{"config":{"agg2sram_0":{"cycle_starting_addr":[4],"cycle_stride":[4,64],"dimensionality":2,"extent":[16,64],"read_data_starting_addr":[0],"read_data_stride":[1,0],"write_data_starting_addr":[0],"write_data_str     ide":[1,16]},"in2agg_0":{"cycle_starting_addr":[0],"cycle_stride":[1,64],"dimensionality":2,"extent":[64,64],"write_data_starting_addr":[0],"write_data_stride":[1,0]},"sram2tb_0":{"cycle_starting_addr":[129],"cycle_stride":[4,64],"di     mensionality":2,"extent":[16,64],"read_data_starting_addr":[0],"read_data_stride":[1,16],"write_data_starting_addr":[0],"write_data_stride":[1,0]},"tb2out_0":{"cycle_starting_addr":[131],"cycle_stride":[1,64],"dimensionality":2,"exte     nt":[64,64],"read_data_starting_addr":[0],"read_data_stride":[1,0]}},"mode":"lake","verilog_name":"lake__U29"}
           },

Is this correct?

@rdaly525
Copy link
Owner

@joyliu37m that is still referencing an instance. Do you see the generator itself somewhere else in the json file?

@joyliu37
Copy link
Collaborator Author

joyliu37 commented Jun 25, 2021

No. I only see those instances of memory tile in the json. Should I add the rungenerator passes while save the json?

@leonardt
Copy link
Collaborator

Maybe something like:

buf->getModuleRef()->getMetaData()["verilog_name"] = "lake_"+genargs.at("ID")->get<string>();

could work?

Basically get the module that the instance is of and set the metadata on it.

@joyliu37
Copy link
Collaborator Author

joyliu37 commented Jun 25, 2021

It seems that if I dump the metadata in module or generator, the metadata will be lost when I save the top level into json.
I currently use the json file to generate verilog. Is there a way to generate verilog from run time?
My guess is that the generator is from another namespace cgralib, and the namespace is global when I save file to json. The newly added metadata is not saved.

@leonardt
Copy link
Collaborator

You could try doing it the way the binary does it.

You get a handle to the verilog pass: https://github.com/rdaly525/coreir/blob/master/src/binary/coreir.cpp#L250-L251
Then you write to stream (e.g. a file stream): https://github.com/rdaly525/coreir/blob/master/src/binary/coreir.cpp#L262

@leonardt
Copy link
Collaborator

You'll probably need to load the verilog libraries: https://github.com/rdaly525/coreir/blob/master/src/binary/coreir.cpp#L227-L229

There are also some passes you may need to run if you haven't already: https://github.com/rdaly525/coreir/blob/master/src/binary/coreir.cpp#L245-L247

@rdaly525 rdaly525 linked a pull request Jul 22, 2021 that will close this issue
@rdaly525
Copy link
Owner

rdaly525 commented Jul 22, 2021

@joyliu37

    buf = def->addInstance(ub_ins_name, "cgralib.Mem_amber", genargs);
    Module* generatedModule = buf->getModuleRef();
    generatedModule->getMetaData()["verilog_name"] = "lake_"+genargs.at("ID")->get<string>();
    buf->getMetaData()["config"] = config_file;
    buf->getMetaData()["mode"] = string("lake");

Should work with #1016

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

Successfully merging a pull request may close this issue.

3 participants