DFT: Storing scan chain information in odb

[fgaray]

Hello everyone,

To support drawing scan chains in OpenROAD in the gui and CTL (Core Test Language) parser/generator we need to make the scan info available in odb. Here I describe a DB schema to represent CTLs in odb.

Objective

• Make scan chains available to the gui to be able to highlight scan structures and display information related to scan.
• Provide a common source of true for other commands to query and find scan structures on the design.
• Provide support for a future parser for CTLs files.

Out of scope

• Parsing and writing a CTL file at this time.
• Handling test patterns.

CTLs

CTLs are files based on the STIL standard that allow us to share information between DFT tools for optimizations and interoperability between different vendors. They describe the internal scan structures and they are useful too to share information between internal commands inside OpenROAD, like scan insertion and the GUI.

Source: CTL for Test Information of Digital ICs, Rohit Kapur

The schema described here is not a 1:1 map of a CTL file but should be enough to create one or to store the information coming from a CTL.

dbScanChain

• name: string
• length: uint
• cells: list<dbInst>
• scanIn: dbScanPin
• scanOut: dbScanPin
• scanClock: dbScanPin
• scanEnable: dbScanPin
• testMode: string
• partitions: list<dbScanPartition>
• scanInsts: list<dbScanInst>

dbScanPin

Wrapper to handle either dbBTerm or dbITerm:

• bterm: dbBTerm
• iterm: dbITerm

dbScanPartition

• start: dbScanPin
• stop: dbScanPin
• name: string

dbScanInst

• scanIn: dbScanPin
• scanOut: dbScanPin
• bits: uint
• type: enum [OneBit, ShiftRegister, BlackBox]

Flow

At the end of insert_dft we will be storing the scan chain information into odb using the created dbCTL object. The gui will be able to query this information and display it. dbScanChain will be attached to the dbBlock that contains the scan chains that are inside it.

Open Questions

• Where can I add a new dbObject (dbCTL) to dbBlock?
• How can I represent maps (will std::map work?) string-> dbObject in the json db format?
• I am creating a wrapper for dbBTerm and dbITerm for cases where the scan pins are not coming from the block, is there any way to handle this in the json db format?

[fgaray]

Hi @maliberty , who do you think is the right person to review this? Specially the open questions at the end.

Thanks!

[fgaray]

Sorry, I missed the email. I replied there. Thanks!

[fgaray]

Thanks Matt for your time and for meeting with me, here are some notes:

• Pin signals are redundant and we can reuse what is already in the DB for seeing if they are IN or OUT.
• Environments are not needed in the DB because we already have that information in the form of dbBlocks
• It is better to not use CTL in the naming as it is related to the file format. It is better if we keep this schema separated of the text format.
• Adding new information to the dbBlock is done in cpp and not with the code generator, the code generator can create the classes for the other structs.

I will update the discussion tomorrow with this new info. Let me know if I am missing something or if I got something wrong!

Thanks!

[maliberty]

Also many uses of string can be replaced by actual db objects.

[fgaray]

Yes!, thanks for that

[fgaray]

Hi @maliberty, I updated the schema and now it is much more simple, Could you please take a look?, Thanks!

[maliberty]

Scan chain is used in both CTL and in DEF. Can dbScanChain accommodate both or do we need to consider having two classes? If the later, how would you suggest naming them ?

[fgaray]

The thing we need to remember is that the DEF scan chain is a subset of the CTL scan chain. Because of that, I would suggest using dbScanChain as a holder for the CTL info and creating a different class or generating the DEF scan chain.

Because the DEF scan chain is used for optimizations, I would suggest to name another class "dbScanOptChain", to not use any file format directly in the naming.

Just note that this dbScanOptChain will need to be generated at the end of the flow: after UPF and buffer insertion for example, because we need to wait for the final netlist to be able to generate the DEF scan chain (I can elaborate on the reason for this if you want).

[maliberty]

Can we treat one as a subset of the other rather than two independent structures?

(Elaborating on the waiting would be helpful as well)

[fgaray]

Re. Can we treat one as a subset of the other rather than two independent structures?

Now that you mention it, I think it may be possible but we will need additional information in the dbScanChain, something like:

• partitions: list<dbScanPartition>

And in dbScanPartition we store:

• from: dbScanPin
• to: dbScanPin
• chainName: string
• partitionName: string

I think that may be enough, the rest of the data (if the flops are FLOATING or ORDERING for example) I think we may be able to infer it from the design.

Re. Why we need to do the DEF scan chain at the end?

Because UPF could insert isolation cells between scan paths or some other stage insert buffers that we need to preserve when we optimize the scan chains.

If we have a scan chain with a change of voltage domain and we insert an ISO in the middle, we need to break the scan chain at that point. For example [FF1, FF2, FF3, FF4], with an ISO between FF2 and FF3, will create two DEF scan chains: FF1, FF2 and FF3, FF4. The two new DEF scan chains will have a different partition name, allowing reordering of the flops inside the partition but without mixing the flops between them.

Repartitioning (Moving a flop from one DEF scan chain to another) is allowed if the partition name is the same.

In this case, we could have two partition names composed by the voltage domain: "RISING_clk1_v1" and "RISING_clk1_v2" (v1 vs v2). Just because the voltage domain is different this will prevent cells of different voltage to be mixed together.

How does that sound?

[maliberty]

Would cells: list still be at dbScanChain or break up into the dbScanPartition ? Perhaps you can update the proposal with this idea.

Thanks for the explanation on the flow.

[fgaray]

The list is still in dbScanChain, just that with dbScanPartition we can store pointers (from, to) to the start and end of each partition.

I updated the original propose, let me know what do you think.

[maliberty]

Looking at DEF:

It looks like the dbScanPartition needs a way to store MAXBITS.

Each element of the chain also has a BITS field which seems hard to represent here. Perhaps we need a dbScanInst?

How would you infer FLOATING or ORDERED from the design?

[fgaray]

FLOATING vs ORDERED depends on the type of cell that we are dealing with. One example is if we have a shift register (We currently don't have a shift register identification in DFT or OR AFAIK), we need to keep those cells together so we will write ORDERED to prevent reordering between those elements.

Sames apply if we have don't touch cells. For all the other cells (normal flops) we can reorder them so we just write FLOATING.

So, now that I think about this, I believe we will need a wrapper over the list of cells to do this.

dbScanCell:

• cells: list<dbInst> // Most of the time this will be a list with just one element
• bits: uint
• type: enum [OneBit, ShiftRegister, BlackBox] // not exhaustive, this will be similar to the ScanCells implemented in dft/src/cells.

MAXBITS is usually equals to the number of bits of the DEF chain (because we know that they are more or less balanced from architect). With the field bits in dbScanCell we should be able to calculate it.

I updated the original proposal.

[maliberty]

I don't understand when a dbScanCell would be a list of insts. Why not just dbScanInst with two dbScanPin for in/out, bits, and type?

Do you think MAXBITS is obsolete? It seems to be a constraint on reordering given by the user.

[fgaray]

You mean like using a pointer (like partition) for grouping types of cells?, That would work too I think, thanks!

Re Do you think MAXBITS is obsolete?

In my experience, I don't remember using it as a constraint and was mostly ignored, that is, repartitioning just swap equivalent number of bits by same number of bits in each operation, preserving the original number of bits of the scan chain.

[fgaray]

Hi @maliberty ,

Do you think we are ready to start the implementation?

Thanks!,
Felipe

[maliberty]

Go ahead - we can always revise if needed

[QuantamHD]

LGTM. Thanks for the contirbution @fgaray