OpenDB supports on hierarchical blocks and cloned block instances

[by1e11]

Hi, OpenDB experts

I am now trying to use opendb as the design database in one of my projects. But I am not quite sure if opendb can support the features I am requiring.

Say I have a hierarchical design which has a "chip_top" block, then I have many child blocks (as instances) those may have child block instances (recursively) as well. In addition, some block instances may be complete clones of a "master block", of which the changes on their bterms and instances etc. will exactly mirror those of the "master block".

I have investigated a bit on the source codes, and I got basic ideas about the dbMaster, dbInst, dbLib and dbBlock. But I am still confused on the combination usage of them. Is that possible to use the current opendb structure to implement what I need? Or do you have some suggestions on implemeting this kind of design style?

Thanks in advance, Best wishes Bo

[rovinski]

If this comment is accurate https://github.com/The-OpenROAD-Project/OpenROAD/blob/282340eaf54d33a125214230e635c689acc1a75b/src/odb/include/odb/db.h#L790-L796

Then the max hierarchy supported is 2. I don't believe we've extensively tested anything other than 1 level of hierarchy.

The current best methodology for hierarchical design is to export LEF/DEF for child blocks and then use those blocks as macros in the parent design.

I believe support for deeper hierarchies has been discussed, but we haven't had enough resources to allocate to the issue. I'm sure any contributions towards this end would be welcomed.

[by1e11]

If this comment is accurate

https://github.com/The-OpenROAD-Project/OpenROAD/blob/282340eaf54d33a125214230e635c689acc1a75b/src/odb/include/odb/db.h#L790-L796

Then the max hierarchy supported is 2. I don't believe we've extensively tested anything other than 1 level of hierarchy.

The current best methodology for hierarchical design is to export LEF/DEF for child blocks and then use those blocks as macros in the parent design.

I believe support for deeper hierarchies has been discussed, but we haven't had enough resources to allocate to the issue. I'm sure any contributions towards this end would be welcomed.

Hi, dear Rovinski

Thanks for the reply, as my understanding of your comments, more than two levels is not theoretically unsupported, but is not extensively tested, which means that the current opendb actually has the ability to support more than two levels, however it is not "officially" supported by openroad. Am I correct in understanding this?

Also, do you have any further comment on implementing the cloned master block?

I am currently trying to implement this feature by removing the limit that "one block can only be bound to one instance" when bindBlock() and trying to make _parent_inst of the block as a dbVector to store all instances which instantiate the child block (the cloned block). Then in my opinion, once the block has updates in its status (bterms, instances placements), the parent_insts will all do the same updates.

I am very interested in extending the opendb functionalities in this direction, so any good suggestion will be very appreciated.

Best regards, Bo

[rovinski]

Thanks for the reply, as my understanding of your comments, more than two levels is not theoretically unsupported, but is not extensively tested

No: 1 level: Extensively tested 2 levels: Not tested 3+ levels: Unsupported

Also, do you have any further comment on implementing the cloned master block?

It sounds like you're asking if there can be multiple instances of the same block within the hierarchy, and to that end I don't know. @maliberty might.

[maliberty]

I think @rovinski description is correct. Before we dive into the db level questions, can you explain how you would use this capability if it existed? The model you describe is more commonly used in custom digital tools (eg Virtuoso) than P&R ones.

[by1e11]

Hi, @maliberty

Thanks. We need this feature because our design includes a predefined hierarchy (very deep) and abut blocks, we will never need to P&R over the blocks. Then we will perform P&R in each individual block, and optimizing the pin assignments between the blocks. So we need a way to store the complete hierarchy information with OpenDB.

Now we realized that actually we do not need block hier with that many levels, but multiple instances of the same block is a hard requirement.

What we are trying to do now is saving all blocks as the children of a "chip_top" block, binding the master block which is not necessarily the direct child of the owner block to multiple instances of the owener block is made available. In other words, we build the hierarchy using the instances and the bound blocks. The solution seem to work up to now (parsing our block hierarchy and netlists and storing the model)

It is difficult for me do explain the exact requirement, the following block diagram can roughly show our block structure. Where B1 and B3 are the first level block insts, B2 is a wrapper for second level block insts (B2_0 and B2_1). Hope it is not that difficult to understand.

I will be back reporting our experiment results.

Thanks a ton, BR, Bo

[rovinski]

Seems to me like it would be a lot easier to do a bottom-up hierarchy and just iterate on the design constraints. But if you'd like to contribute to ODB feel free.

[maliberty]

@rovinski I agree with you but we do lack a timing model generation capability so final signoff still needs to be flat.

[kongka001]

@rovinski could you shed more light in terms of how to load both block def and top def? ie: block1.def and top.def, dbChip chip = def_reader.createChip(search_libs, top_def_filename);
if (chip) {
dbBlock block = chip->getBlock();
string block_def_filename = "xxx.gz";
dbBlock* sub_block = def_reader.createBlock(block, search_libs, block_def_filename.c_str()); }

I tried above, both file got parsed, however, when I iterate the nets in chip->getBlock(), cannot find the nets in block.def.

Thanks!

[maliberty]

At best you will not see the nets in subblocks in the top block. You would have to manually traverse across the instance boundary. There is no flat view of the top block.

[kongka001]

@maliberty thanks