New DFT Tool: Starting with scan replace

[fgaray]

Hello OpenROAD devs,

I am planning on contributing a new tool (following https://github.com/The-OpenROAD-Project/OpenROAD/blob/master/docs/contrib/DeveloperGuide.md, I will call this "dft") for DFT insertion into OpenROAD and I would like to discuss the user facing API.

User facing API

I think we should create two new main commands for DFT: preview_dft and insert_dft:

• preview_dft: will show a summary of what scan chains are we going to create (after scan architect) but will not apply any changes to the design. This is an immutable command and will not perform any modifications to the design or database. This is useful for debugging proposes and to help users to iterate any DFT option that could change the creation of the scan chains.
• insert_dft: will run again from scratch the immutable part of preview_dft, including scan architect and perform scan stitching. The result of insert_dft should be the same that the one presented by preview_dft but applied to the design.

I would say that it is better to configure the DFT compiler with commands like "set_dft_*" instead of receiving any argument in "preview_dft" or "insert_dft". For example: set_dft_no_scan (for cells that we don't want to scan replace), set_dft_chain_count (for the number of scan chains to be created) or set_dft_clock_mix (if we want or not to mix clock domains).

Now, I am not sure if this is going to be something you expect to see in the Python interface, this is a very TCL oriented API and I would like to see if you have any suggestion on doing this more programmatically for Python scripting (maybe this is totally fine as we can have a different API for Python?).

Where in the flow is DFT insertion going to be?

Looking into OpenROAD's flow, I think the best part to perform DFT insertion is between "Logic Synthesis" and "Floorplanning". That way we floorplanning will have all the info about DFT to perform optimizations in the design.

Feel free to suggest something different here :).

What is the plan?

For now, I will only be creating "insert_dft" and "set_no_scan" for scan replacement: I will replace sequential cells (excluding black boxes as we don't have support for CTLs yet!) in the design with scan equivalents if they are available and nothing more inside insert_dft. I will keep of of the scope adding scan muxes or any other kind of scan stitching as this is my first approach to OpenROAD.

Please, let me know if there is something I should be aware of or anything related to this idea or the user interface.

Thanks!,
Felipe

[maliberty]

I think it is best to do scan chain after global placement. You want to put the ff in the best placement for timing and only then construct the chain ordering based on neighbors.

It would be helpful to know what commands you intend to implement to define the chains. A small complete example would clarify the use model.

For python API please see the discussion in #2745

[fgaray]

Hi Matt,

Isn't global placement going to lose some optimization opportunities if they don't know about DFT?, I am thinking of a case where a cell is placed somewhere but after DFT we replace it with a scan cell (adding a scan mux at the input) changing the way we can place the cells. Could this happen?

The advantage is that we can create better scan chains as we will know where they are going to be in the design.

Regarding the scan chains, I am thinking something like this, where all the configs regarding dft are set by "set_dft_*" commands:

set_dft_chain_count 4 # To create in total 4 scan chains
set_dft_no_scan [cell1, cell3] # To omit cell1 and cell3 from DFT replace and insertion
set_dft_clock_mix no_mix # or mix_edge, for clock mixing

Then, we can get a preview of the scan chains to be generated and after that insert the DFT into the design:

preview_dft # This is just going to output what we will do with the design, think of this like --dry_run of some CLI programs
insert_dft # This command will perform the DFT insertion honoring the output of preview_dft

[maliberty]

Perhaps I should say that you'll have to do scan chain reordering after at least gpl (perhaps after CTS). Knowing the size of the scan ff is slightly helpful to placement but the scan connectivity is likely not to be (and probably should be ignored).

[fgaray]

Ah!, yes!. Scan reordering can be done after global placement!. For scan reordering, what you usually do is to generate a scandef (usually with a write_scan_def command in commercial tools) and use that for further optimizations.

The flow could be something like: Logic Synthesis -> scan insertion -> global placement -> scan reordering (using the scandef)

Does that makes sense?

[QuantamHD]

That flow makes a lot of sense to me.

[maliberty]

@rovinski @msaligane @louiic @Colin-Holehouse any comments?

[rovinski]

Seems like a chicken and egg problem in terms of where to insert in the flow. Insertion before global placement will influence the connectivity and placement potentially negatively, but inserting after GPL may cause congestion.

Is there a way in GPL to ignore certain nets? It might be useful to ignore scan nets until after reordering so that it doesn't affect placement of critical paths too much? Another alternative is to solve at the flow level where an extra GPL/DPL step is added after scan reordering. Overall, seems like a similar problem to buffer insertion.

In academia we essentially never do automated scan insertion, so my experience here is limited.

[maliberty]

My comment about scan connectivity "probably should be ignored" is in the same line. I think we should just always ignore scan nets (SOURCE TEST in DEF) during gpl.

[fgaray]

Yeah, that makes sense. Let's ignore any DFT in GPL and just perform a scan reordering after using a SCANDEF.

[rovinski]

Very cool! Always excited to see more functionality contributed 😃

[fgaray]

Awesome!

[maliberty]

Would you say more about scandef and how you intend to generate it?

[fgaray]

Sure!

A scandef is basically a machine readable DEF file with the specification of the scan chains. It is used by scan reordering optimizations to know what flops can be move inside a scan chain (reorder) or between scan chains (repartition).

We generate this file from the DFT stage (that is the point where we know about the scan chains). For each scan chain we have information like what is the scan in and the scan out. A PARTITION is also defined so we know what flops can be moved to other compatible scan chains.

Multiple scan chains can be in the same partition enabling repartition of flops between them and it usually defined as a string representation of the clock domain plus some other information (you can also define unique partition to disable repartition optimizations).

An invented example of a scandef could be

- chain1
+ START PIN scan_in1
+ FLOATING ff1 (IN si) (OUT q)
ff2 (IN si) (OUT q)
ff3 (IN si) (OUT q)
+ PARTITION clock1
+ STOP PIN scan_out1

This is only one scan chain for clock1. The FLOATING section defines flops that can be reorder inside the scan chain. If there is a another scan chain with also PARTITION clock1, we are allowed to also swap flops from this scan chain to the other one.

There are also ORDERED sections instead of FLOATING for cases where the user is defining a scan chain manually.

There are more complicated cases like with mixing clocks where some scan chain can be separated into two different scandef chains (basically, different partitions), but that is something out of the scope for now in my initial implementation.

Let me know if you would like more details!, thanks!

[maliberty]

Where will get this file from in an OSS flow?

Earlier you said "usually with a write_scan_def command in commercial tools" and "We generate this file from the DFT stage" but I don't know what that means in this context.

[fgaray]

I mean something like this:

insert_dft
write_scan_def my_design.scandef

With "We generate this file from the DFT stage" , I mean that after insert_dft, we can use write_scan_def to generate this scandef file to use later for scan reordering/repartition. This is the same flow that is used by commercial tools.

This has the advantage that the user could do the scan insertion in OpenROAD and later do the scan opto in a third party tool (as they all support this SCANDEF file) or, just use OpenROAD when we implement later the scan opto.

[maliberty]

If you are doing insert_drt in OR then I would pass this info through odb rather than a scandef. We could have an option to write one for other tools if needed.

[fgaray]

Cool!, I agree!

[maliberty]

Note that odb doesn't store any scan information from DEF today so you'll have to plan on enhancing it as part of this project.

[fgaray]

Thanks for the heads up!, Yes, I think it is fair to think on enhancing odb for a complete DFT solution on OpenROAD. I will keep that in mind!. For now, I am planning on just going with scan replace (replacing flops with scan flops) to get familiar with the tool and as a first approach to OpenROAD.

[maliberty]

In case its useful: http://vlsicad.eecs.umich.edu/BK/Slots/cache/vlsicad.ucsd.edu/GSRC/Bookshelf/Slots/ScanOpt/

[fgaray]

Wow, thank you for that!, really looks helpful

[fgaray]

Hey @maliberty ,

I am trying to write a function to perform the scan replace and I need to find a scan equivalent cell in the DB.

I am iterating over the libs in the odb::dbDatabase like this:

bool IsLibScanCell(odb::dbLib* lib) {
  for (odb::dbMaster* master: lib->getMasters()) {
    for (odb::dbMTerm* mterm: master->getMTerms()) {
        std::cout << mterm->getSigType().getString() << std::endl;
    }
  }
  return false;
}

But looks like the enum of getSigType does not have enough information to see if a pin is scan_enable or scan_in. Is this something that I need to implement or is there another way to access this information inside the lib? I see that in sta/ there are some parsing to detect scan signals, but I do not see them being used in any place outside sta/.

[maliberty]

The db represents what is in LEF and the most you'll find there is a pin marked as 'SCAN'. I suspect the information you need would be in Liberty in which case you'll have to look at sta which reads it.

Nothing in OR today care about scan so you won't find any uses afaik.

[fgaray]

Alright!, I will take a look at liberty then, thanks!

[fgaray]

For scan replace, I have a working demo where I collect the scan lib cells and then I try to iterate over the design's blocks applying "sta::dbNetwork" replaceCell, but I found that this and some methods in sta:: check before performing the replace if both cells are "equivalent" by counting the number of ports in each cell (See inDbInstSwapMasterBefore in dbSta/src/dbSta.cc ).

This is not really true when you try to replace a cell with an scan equivalent because the scan one will have additional ports like scan in and scan enable.

I was wondering if there is a function that I am missing that could help me with this kind of replace.

If not, should I provide a new method for dbSta and odb that checks for functional equivalent ports instead of index/name based matching (See swapMaster in odb/src/db/dbInst.cpp) or roll one myself just for DFT? Would you prefer this method to be available in odb or maybe just complete change the way we do the replaceCell?

Thanks!

[maliberty]

The operation you describe is not a cell swap. You should delete the old instance and create a new one. dbInst::swapMaster has the same check.

[fgaray]

That makes sense, thanks!

[fgaray]

Hi @maliberty,

Do you know how to test if two ports/pins are functional equivalent?, I am trying to use sta::LibertyPort's function() and sta::FuncExpr::equiv() but looks like sta::LibertyPort's function() returns most of the time nullptr. I see that in odb/src/db/dbInst.cpp:1201, we test that mterms are equivalent by checking that the name of the ports is the same (line 1236).

I can work with that but I think my scan replace function will be more robust if I can check if the ports are functional equivalent.

[maliberty]

If you want functional equivalence you'll need to look at Liberty. There will only be a function for an output port. You can look at your Liberty files to see what to expect in the API. Here is an example from ng45:

  cell (AND3_X1) {
	pin (A1) {
		direction		: input;
	}

	pin (A2) {
		direction		: input;
	}

	pin (A3) {
		direction		: input;
	}

	pin (ZN) {
		direction		: output;
		function		: "((A1 & A2) & A3)";
	}
  }

[fgaray]

Ah, you are totally right that inputs do not have a function, thanks for that! I will take a look at my lib

[fgaray]

Implemented basic DFT in #2900, #3079 and #3356