15:30 <rswarbrick> Hi all! Does Yosys (vanilla) support any form of the SystemVerilog 'bind' construct? I've got a whole host of formal assertions, which I think might be easier to foist on a project if they didn't appear at the bottom of the design RTL :-) I realise that I could do some nasty hack with `ifdef FORMAL and `include, but it would be nice if there was a cleaner option.

15:34 <daveshah> No, it doesn't support bind

15:34 <daveshah> It does support .* which is half the problem

15:40 <az0re> daveshah: .* ?

15:40 <rswarbrick> Oh, that's good news! I guess that support for the non-hierarchical version of the bind statement wouldn't be massively difficult? I don't know much about RTLIL though: after I've read a module, do I still have enough information to bind something in at the moment?

15:40 <daveshah> az0re: systemverilog automatic port connection

15:40 <az0re> You should have all information in the RTLIL

15:41 <daveshah> Yeah, bind shouldn't be too hard to implement, it is probably doable inside hierarchy

15:41 <az0re> Does it really? I haven't seen that in verilog_parser.y...

15:42 <daveshah> az0re: TOK_WILDCARD_CONNECT

15:43 <daveshah> All the parser does is set the wildcard_port_conns attribute

15:43 <daveshah> The connections are dealt with inside hierarchy

15:43 <daveshah> rswarbrick: as I understand bind, it could probably use similar code paths to a submodule instance

15:44 <rswarbrick> I think I don't know what submodule means here. Can you point me where I need to go look?

15:44 <az0re> Ah thanks

15:44 <daveshah> I mean a non-blackbox cell instance

15:44 <daveshah> Probably looking at how hierarchy resolves instantiations would be a starting point

15:44 <az0re> Yep I see

15:44 <rswarbrick> daveshah: Great, that makes sense. Thanks!

15:45 <rswarbrick> (Oh, submod.cc sounds promising!)

15:45 <daveshah> No, that is a special pass

15:45 <az0re> ./passes/hierarchy/hierarchy.cc:997

15:45 <rswarbrick> Ah, great. Thanks.

15:47 <rswarbrick> So am I right in thinking that a "bind" parser basically wants to shove a copy of the new module into each matching module? (And presumably leave itself a note in case the user reads anything else that will match in the future)

15:48 <az0re> And `find_implicit_port_wire()` at line 548

15:48 <daveshah> rswarbrick: I don't know how bind works well enough

15:49 <rswarbrick> Ok. I'm looking at the LRM and... I'm not sure I do yet either :-)

15:49 <daveshah> If you want to copy a module into another, then flatten/techmap might be the passes to look at

15:49 <daveshah> But if your bind implementation is more like creating an instance, which may or may not be flattened later, then it would be done in hierarchy

15:50 <daveshah> I don't think you want to be doing any copying in the parser, all that stuff should happen during or after hierarchy so parameterization and external frontends work properly

15:50 <az0re> From https://www.sunburst-design.com/papers/CummingsSNUG2009SJ_SVA_Bind.pdf: "Binding an SVA file to another design is like poking or projecting an instantiation of an SVA module into the unmodified target file. Binding an SVA file to a target file is an out-of-body experience for the target file!"

15:50 <rswarbrick> :-)

15:51 <rswarbrick> daveshah: Ah, good point. So it's more that I'll be setting some flags somewhere to tell the hierarchy pass what to do?

15:51 <daveshah> Yeah, creating an instantiation would be done in hierarchy

15:51 <daveshah> Yeah, you might create an empty "bind" module with attributes that tell hierarchy what to do

15:52 <az0re> Make sure to set the keep attribute, too

15:52 <rswarbrick> Right, that makes sense. Time to go and do some reading. Are there any similar things that already exist so that I can crib the rough shape?

15:53 <daveshah> Not really sure, tracing the general flow of cell instantiations and parameterised module derivations would make sense

15:53 <rswarbrick> Ok, that makes sense to me. Thank you very much for the help.