Open povik opened 3 months ago
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
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.
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
.
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?
Gentle ping. What can I do to push this forward?
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?
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 https://github.com/YosysHQ/yosys/pull/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.
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.
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.
So, here's my suggestion, after talking in private.
-lutlib
; there'll be less churn from needing to manually add that option everywhere.Then, somebody can achieve non-mapping by passing an abc9.script
which does not perform LUT mapping (&if
and friends).
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.
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?
actually, &unmap
looks like it does what you're asking for?
Exactly like it
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 anabc9_lut
attribute to be an available mapping primitive.Make the change to condition this behavior on a
-lutlib
option, and instead makeabc9
without any options perform a non-mapping mode in which the netlist is reimported back into Yosys as an and-inverter graph.