The `flops` keyword is not put into the liberty file

[Blebowski]

Problem Description
The flops keyword of sequential cells is not placed to the generated liberty file.
There is a TODO in the code here:

CharLib/charlib/characterizer/TestManager.py

Line 673 in 361d576

# TODO: Add flops

I would expect it to end-up in the liberty file to define the flip flop

 ff (P0002,P0003) {
    next_state : "D";
    clocked_on : "CLK";
    clear : "(!R)";
    preset : "(!S)";
    clear_preset_var1 : L;
  }

My assumption is, that this would be achieved by:

flops: [P0002, P0003]

but there is no way on how to specify which pin to put to the next_state attribute.
This is not obvious, since e.g. a scan flip-flop may be having pins like SE (Scan enable)
and SD (Scan D-Input). In such case the ff may look like:

    ff(IQ,IQN) { 
      clocked_on : "(CK)" ; 
      next_state : "((SE&SD)|(D&(!SE)))" ; 
    }

Further, the current format of the flop specification in YAML file is unsuitable if the cell contains
two flip-flops. Modern PDK libraries sometimes contain a "multi-bit flops". In such case,
there would be two entries:

ff(IQ1,IQN1) { 
      clocked_on : "(CK)" ; 
      next_state : "D1" ; 
}
ff(IQ2,IQN2) { 
      clocked_on : "(CK)" ; 
      next_state : "D2" ; 
}

I would suggest making the config file behave like so:

• flops may contain a single list of names, or "list of lists" if this is list of lists, there will be multiple FFs in the cell
• set / reset may contain a single edge or list of edges.

[infinitymdm]

I'm thinking we probably need to rethink the way flops are specified in the configuration file and handled by the characterizer. The current setup can't handle multi-bank, JK, or scan flip flops - just DFFs and variants thereof. And those aren't even very accurate.

[Blebowski]

Hi @infinitymdm ,

I agree that flops are not specified ideally at the moment.

TBH, I don't know how do multi-bit flip flops look like in a .lib file, I have yet not seen such .lib file (altough I know it is common thing in lower geometry nodes). As for the JK flops, I have not seen such flops either, are you familiar with some PDK that does contain such flops ? I have only seen: DF flops, DF flops with scan, SR latches and variants of these with async set/reset enable pins.

I think flops could be specified by flops keyword as now, e.g by putting:

flops: "IQ <= D"

where IQ is "internal flop value". This would be then put to the ff in the .lib file under the next_state.
The functions would then serve the same purpose as now, e.g. by putting:

functions: "Q <= IQ"

you would state that the "internal flop value" propagates to the Q output. IMHO this would be sufficient to encode
scan flops too since you can write something like:

flops: "IQ <= ((SE&SD)|(D&(!SE)))

and also flops with clock enable:

flops: "IQ <= ((D&E)|(IQ&(!E)))"

Alternatively, the IQ could be not part of the expression, but as a key,e.g.:

   flops:
       IQ: "D"

If the flops was a list (or there were more keys under it), then this would be a multi-bit flop.

Btw. as for the JK flip-flop, you could specify it like so:

flops: "IQ <= (J K IQ’) + (J K’) + (J’ K’ IQ)"

according to: https://users.cs.utah.edu/~elb/cadbook/color-figs/Chapter8-Char.pdf

Simply, I wouldn't over-specify for particular types of flop on the level of YAML syntax. As long as you are able to
create an internal node defined by a string whose syntax follows what liberty format allows for defining a flop...

[infinitymdm]

I've spent some time looking at how latch and ff groups are specified in the Liberty Reference Manual (see section 2.1.4 if you're interested). Trying to get this right as I wrap up #84.

Practically speaking, the only difference between flops and latches (at least relevant to reading them from the config) is that one is edge-triggered while the other is level-triggered. The names of the internal storage elements as plugged into the liberty file don't really matter, so we can construct those when setting up the cell object instead of having them in the config.

With those constraints in mind, the relevant sequential cells could be specified something like this without losing any specificity:

cells:
    active_low_enable_d_latch:
        functions: [Q <= D]
        enable: !E
    active_high_sr_latch:
        outputs: [Q]
        # note the lack of a functions key
        set: S
        reset: R
    posedge_dff_with_inverting_output:
        functions:
            - Q <= D
            - QN <= !D
        clock: posedge CLK
    negedge_dff_with_inverting_output_and_active_low_sr:
        functions:
            - Q <= D
            - QN <= !D
        clock: negedge CLK
        set: !S
        reset: !R

This essentially comes down to: flops have some sort of trigger specified with clock (even if it's not actually a clock), while latches don't. I think this way of specifying things in the yaml should work for charlib, but maybe I'll come up with some glaring flaw in it tomorrow.

[infinitymdm]

I've spent some time trying to implement the above, and the big drawback is that the present function parsing logic doesn't work well for recurrent relationships like those present in most latch cells. Here's an alternative that might work, and allows me to reuse the existing function logic with only a few small modifications. I'll use the same 4 examples as before.

cells:
    active_low_enable_d_latch:
        functions: [Q = !E & D | E & IQ]
        enable: !E
        state: [IQ = Q]
    active_high_sr_latch:
        functions:
            - Q = IQ
            - QN = IQN
        set: S
        reset: R
        state: 
            - IQ = Q
            - IQN = QN
    posedge_dff_with_inverting_output:
        functions:
            - Q <= D
            - QN <= !D
        clock: posedge CLK
        state:
            - IQ = Q
            - IQN = QN
    negedge_dff_with_inverting_output_and_active_low_sr:
        functions:
            - Q <= D
            - QN <= !D
        clock: negedge CLK
        set: !S
        reset: !R
        state:
            - IQ = Q
            - IQN = QN

Here state is used to specify which variables in the functions encode the cell's internal state, and how those state variables get their values. This matches up nicely with the physical layout of most sequential cells: state can be thought of as a list of feedback paths.

One quirk about this is that only the internal nodes which appear in functions have to be listed in state; the resulting latch group in the liberty file for the D-latch here will still have both IQ and IQN, as the spec requires. It won't hurt anything to list all feedback paths (and I guess it would provide a method to specify the name of the identifiers that appear in the latch/ff group), but it's not strictly necessary as long as they don't appear as variables in functions.

The gist is:

• Latch cells can use internal state in functions to specify their recurrence relationships, with feedback paths provided using the state key.
• Flip-flops use basically the same syntax as before, with internal state being implied EDIT: state will have to be explicitly expressed. Set and reset can be specified asynchronously (posedge/negedge) or synchronously (not/!, or no modifier).
• Certain pins (enable, set, reset, clock) have to be specifically pointed out to charlib so that we can do special timing tests or documentation in the liberty file related to those pins. Generally these shouldn't have to be specified in the cell's functions, as charlib should understand their special roles and how they interact with the cell's state.

[infinitymdm]

The config format as developed so far provides:

• Mapping physical inputs (and state) to physical outputs via boolean functions
• Identification of state via explicit recurrence expressions
• Explicit edge/level triggers for special pins (clock, enable, set, reset)

There's one more piece of information charlib needs: how can we tell when a physical output is the inverting member of a Q/QN pair? (This is especially difficult for banked sequential cells, with multiple inverting and non-inverting outputs.)

Perhaps a procedural way to identify inverting/non-inverting pairs can be added as part of #56. For the time being, however, this should be specified explicitly. Unfortunately this means more new syntax.

cells:
    active_high_sr_latch:
        functions:
            - Q = IQ
            - QN = IQN
        set: S
        reset: R
        state:
            - IQ = Q
            - IQN = QN
        pairs:
            - Q QN

This should only be necessary on cells with physical inverting output pins. For sequential cells that just have a single output, like the D-latch example used previously, we don't need the new pairs key.

One redeeming quality of adding this syntax: since this is effectively a differential output pair, we can use the same syntax in the future for supporting input diff pairs.