Currently, TechMapper pass uses a delay model that is too naive, with per-pin delay and area represented in discardable attribute hw.techlib.info. While this representation could be improved to be load or phase-aware, those changes would also require improvements to TechMapper and CutRewriter.
Therefore, a good incremental direction is to first obtain a simplified model from NLDM delay attribute (by fixing load capacities). We can perform load-aware tech-mapping based on the this attribute but sampling the center of the delay is a good starting point.
hw.module @XOR(in %a: i1, in %b: i1) attributes {
synth.mapping_cost = #synth.mapping_cost<
area = 10.0,
arcs = [
#synth.arc<
pin = "A",
intrinsic = 0.045,
sensitivity = 1.2,
polarity = #synth.polarity<negative>
>,
#synth.arc<
pin = "B",
intrinsic = 0.048,
sensitivity = 1.1,
polarity = #synth.polarity<positive>
>
],
input_caps = { "A" = 0.002, "B" = 0.002 }
>}
{
hw.output xor(%a, %b)
}
// FA
#synth.mapping_cost<
area = 10.0,
outputs = {
"sum" = [
#synth.arc<in = "A", intrinsic = 0.045, sensitivity = 1.2, polarity = #synth.polarity<positive>>,
#synth.arc<in = "B", intrinsic = 0.045, sensitivity = 1.2, polarity = #synth.polarity<positive>>,
#synth.arc<in = "cin", intrinsic = 0.030, sensitivity = 1.1, polarity = #synth.polarity<positive>>
],
"carry" = [
#synth.arc<in = "A", intrinsic = 0.025, sensitivity = 0.8, polarity = #synth.polarity<positive>>,
#synth.arc<in = "B", intrinsic = 0.025, sensitivity = 0.8, polarity = #synth.polarity<positive>>,
#synth.arc<in = "cin", intrinsic = 0.020, sensitivity = 0.7, polarity = #synth.polarity<positive>>
]
},
input_caps = {"A" = 0.002, "B" = 0.002, "cin" = 0.001}
>Current TechMapper's model corresponds to infinite input capacities + sensitivity=0 so we can replace the current usage of hw.techlib.info attribute with this.
Currently, TechMapper pass uses a delay model that is too naive, with per-pin delay and area represented in discardable attribute hw.techlib.info. While this representation could be improved to be load or phase-aware, those changes would also require improvements to TechMapper and CutRewriter.
Therefore, a good incremental direction is to first obtain a simplified model from NLDM delay attribute (by fixing load capacities). We can perform load-aware tech-mapping based on the this attribute but sampling the center of the delay is a good starting point.
Current TechMapper's model corresponds to infinite input capacities + sensitivity=0 so we can replace the current usage of hw.techlib.info attribute with this.