abc9: Make the default a non-mapping mode

[povik]

Formerly when you didn't pass any options to abc9 it would source a LUT library from the current design by considering any module with an abc9_lut attribute to be an available mapping primitive.

Make the change to condition this behavior on a -lutlib option, and instead make abc9 without any options perform a non-mapping mode in which the netlist is reimported back into Yosys as an and-inverter graph.

[povik]

I would argue for making this change primarily for consistence, especially if we are starting to think of abc9 as a general mapper that's not limited to FPGA targets. The new non-mapping mode lowers the bar for experimentation, take e.g.

read_verilog -lib -specify <<EOF
(* abc9_box, lib_whitebox *)
module ADD1 (input [3:0] I, output [3:0] Y);
	assign Y = I + 1;
	specify
		(I => Y) = 140;
	endspecify
endmodule
EOF

read_verilog <<EOF
(* top *)
module top(a, y1, y2, y3, y4, y5, y6);
	input wire [2:0] a;
	output wire y1;
	output wire y2;
	output wire y3;
	output wire y4;
	output wire [2:0] y5;
	output wire [3:0] y6;

	wire [3:0] a1;
	ADD1 t1 (.I(a), .Y(a1));

	assign y1 = a1 + a; // resolved to const 1
	assign y2 = a1 > a; // resolved to const 1
	assign y3 = a1 < a; // resolved to const 0
	assign y4 = a1 == a; // resolved to const 0
	assign y5 = a + 1; // reconnected to ADD1
endmodule
EOF
opt_clean
abc9 -script +&sweep;;
dump

The output is then

  cell $_NOT_ $abc$1470$aig$not$aiger1469$1
    connect \A \a [0]
    connect \Y \y5 [0]
  end

  attribute \module_not_derived 1
  attribute \src "<<EOF:12.7-12.25"
  cell \ADD1 \t1
    connect \I { 1'0 \a }
    connect \Y { $abc$1470$aiger1469$11 \y5 [2:1] $abc$1470$aiger1469$8 }
  end

  connect \y1 1'1
  connect \y2 1'1
  connect \y3 1'0
  connect \y4 1'0

[Ravenslofty]

Hmm. I'm not entirely sure about this; I think it's reasonable to require -maxlut/-lut to explicitly indicate FPGA mapping, but these should imply -lutlib.

One of the nice things about abc9 is that it trended away from requiring a long command line in favour of autodetecting things; once upon a time you had to write your own .lut and .box files to pass to ABC9, but now they are autogenerated.

[povik]

I think it's reasonable to require -maxlut/-lut to explicitly indicate FPGA mapping, but these should imply -lutlib.

-lutlib means the LUT library is taken from the (* abc9_lut *) modules, so when doing FPGA mapping, you either put -lutlib or -lut, never both.

-maxlut you can only use with -lutlib, because in conjunction with -lut there's no value add. We could make -maxlut imply -lutlib, but I would say that's more confusing than not doing that. We could make -lutlib accept the -maxlut argument, so that you would do -lutlib 4 instead of -lutlib -maxlut 4, but I don't think we want to specify a maximum width every time we are invoking -lutlib.

[povik]

Btw the old help text said -maxlut means "discard greater than or equal", but as far as I can tell "discard greater than" is what's right

[povik]

We could make -maxlut imply -lutlib, but I would say that's more confusing than not doing that.

...or maybe it's not confusing, I am not sure anymore. If we made -maxlut imply -lutlib, would there be any other objections to the new cli?

[povik]

Gentle ping. What can I do to push this forward?

[Ravenslofty]

My understanding was that this was a precursor to trying to perform ASIC mapping with ABC9, right? But as we've discussed, ASIC mapping with ABC9 is presently nonviable because the timing models between FPGAs and ASICs is very different.

I'm also aware of #4283, but that's presented as an experiment. Is your intention there to use ABC9 to find choice nodes and then use a custom mapper?

[povik]

My understanding was that this was a precursor to trying to perform ASIC mapping with ABC9, right?

The interest here is to use ABC9 as a logic optimizer in ASIC flows.

But as we've discussed, ASIC mapping with ABC9 is presently nonviable because the timing models between FPGAs and ASICs is very different.

Not sure that's right: All the issues are with boxes; &nf is the preferred command for ASIC mapping already.

I'm also aware of #4283, but that's presented as an experiment. Is your intention there to use ABC9 to find choice nodes and then use a custom mapper?

That's an option but not something that's planned right now.

[Ravenslofty]

My understanding was that this was a precursor to trying to perform ASIC mapping with ABC9, right?

The interest here is to use ABC9 as a logic optimizer in ASIC flows.

My memory is admittedly poor, but I don't know of any ABC9 commands that don't directly translate into "classic" ABC commands. The advantage of ABC9 in FPGA flows is box support, as I understand it.

But as we've discussed, ASIC mapping with ABC9 is presently nonviable because the timing models between FPGAs and ASICs is very different.

Not sure that's right: All the issues are with boxes; &nf is the preferred command for ASIC mapping already.

And one of the issues with boxes is that the timing models are different between FPGAs and ASICs. (I think I've explained that to you, but maybe I'm misremembering)

I'm also aware of #4283, but that's presented as an experiment. Is your intention there to use ABC9 to find choice nodes and then use a custom mapper?

That's an option but not something that's planned right now.

Noted.

[povik]

The advantage of ABC9 in FPGA flows is box support, as I understand it.

Yes, and you can make use of the box support in ASIC flows at least for the technology-independent optimization, if nothing else. This is what this PR would allow you to do.

Not sure that's right: All the issues are with boxes; &nf is the preferred command for ASIC mapping already.

And one of the issues with boxes is that the timing models are different between FPGAs and ASICs. (I think I've explained that to you, but maybe I'm misremembering)

I don't think you have, or at least I am not aware of any principal obstacles. Either way you are working with the abstraction of actual arrival and required arrival times, and you can incorporate boxes into this the same on FPGAs and ASICs, even if on ASICs the arrival estimates are poorer.

[Ravenslofty]

So, here's my suggestion, after talking in private.

• leave the default as-is, and remove -lutlib; there'll be less churn from needing to manually add that option everywhere.
• instead, when there are no LUTs in the ABC output, map the output to AIG - this would normally cause ABC9 to error out, so this won't break anything.

Then, somebody can achieve non-mapping by passing an abc9.script which does not perform LUT mapping (&if and friends).

[povik]

Then, somebody can achieve non-mapping by passing an abc9.script which does not perform LUT mapping (&if and friends).

Is there a command to clear the last LUT mapping? &if can be a part of non-mapping flows too.

[Ravenslofty]

Then, somebody can achieve non-mapping by passing an abc9.script which does not perform LUT mapping (&if and friends).

Is there a command to clear the last LUT mapping? &if can be a part of non-mapping flows too.

&st. perhaps?

[Ravenslofty]

actually, &unmap looks like it does what you're asking for?

[povik]

Exactly like it