Please clarify ALU doc

[stacksmith]

The ALU writeup in doc folder is very interesting but does not seem match reality... In ALU mode, there seem to be only 3 inputs (I1, I2 and I3), unlike the documented A,B,C and D...

The lack of the 4th input and the severely limited ability to configure the LUT makes me wonder if the Gowin FPGAs really have a hardware carry chain, or is it faked in the LUT?

Which way does the carry chain run, topologically (and what is the best placement of registers to propagate the carry?)

Any information or pointers in the right direction are appreciated.

[yrabbit]

I can answer you only for the wires - they go as it is drawn on the first picture: from left to right along row of the chip from the left edge to the right, and inside each cell from roughly speaking from LUT0 to LUT5.

CIN and COUT wires are uncommutated and you can't connect to them directly, only using ALU.

[stacksmith]

Thanks... I'm trying to figure out how to get inside this.

To a suspicious outside observer it certainly looks as if one of the LUT inputs is used as CIN, and there is some partial output from the LUT (normally hidden) used as COUT... This could actually be useful, if there was a way to fully configure the damn LUT. I'd love to use the carry for incrementing, and the lut as a mux, for instance. Xilinx is pretty good that way.

But it does look like some kind of trickery, and I cannot yet see what is gained by this obfuscation. Perhaps the ability to pretend to have carry for marketing purposes?

[yrabbit]

Well, if you feel the craving for adventures, you can replace the lines

apicula/apycula/gowin_pack.py

Lines 2256 to 2261 in 4f87247

	if mode in alu_bel.modes:
	bits = alu_bel.modes[mode]
	else:
	bits = alu_bel.modes[str(int(mode, 2))]
	for r, c in bits:
	tile[r][c] = 1

with place_lut call. Naturally, taking care so that you have an INIT parameter with the content of LUT.
This make gowin_pack switch CFU to ALU mode, but use your LUT contents.

[pepijndevos]

Yeah you totally can program the LUT in any way you like when using it in ALU mode, just not using the vendor primitive. I demonstrate this in the last paragraph of the docs.

The ALU documentation is based on reverse engineering what is actually going on and not on any official documentation, so it is possible we've missed something, but what is described in the docs is very much how we observe it to work. It also closely matches how the Lattice ECP5 ALU works, which is known to have a very similar internal architecture.

I think it is actually possible to use the fourth LUT input in ALU mode, but you have to consider that the lower 4 bits are shared with the second LUT, which is conveniently circumvented by not using the inputs that would use those bits.

I would be open to supporting unofficial ALU modes that have practical applications.

[stacksmith]

yrabbit: Thanks, that is worth considering. Is mode 2 literally ALU mode 2 or does it mean something different?

pepinjdevos: Thank you, that's what I want to hear! How would you go about configuring the LUT and activating ALU? Is there a way without patching gowin_pack, or is yrabbit's patch the only way to go?

WIth all due respect, you do not demonstrate configuring the ALU in the last paragraph of the doc, only state that you have done so. I would love to see a demonstration!

And thank you for your great work!

[yrabbit]

yrabbit: Thanks, that is worth considering. Is mode 2 literally ALU mode 2 or does it mean something different?

As far as I remember, yes. You can see what LUT contents we use for which mode:

apicula/apycula/chipdb.py

Lines 347 to 380 in 4f87247

	# ADD INIT="0011 0000 1100 1100"
	# add 0 add carry
	add_alu_mode(mode, bel.modes, lut, "0", "0011000011001100")
	# SUB INIT="1010 0000 0101 1010"
	# add 0 add carry
	add_alu_mode(mode, bel.modes, lut, "1", "1010000001011010")
	# ADDSUB INIT="0110 0000 1001 1010"
	# add 0 sub carry
	add_alu_mode(mode, bel.modes, lut, "2", "0110000010011010")
	add_alu_mode(mode, bel.modes, lut, "hadder", "1111000000000000")
	# NE INIT="1001 0000 1001 1111"
	# add 0 sub carry
	add_alu_mode(mode, bel.modes, lut, "3", "1001000010011111")
	# GE
	add_alu_mode(mode, bel.modes, lut, "4", "1001000010011010")
	# LE
	# no mode, just swap I0 and I1
	# CUP
	add_alu_mode(mode, bel.modes, lut, "6", "1010000010100000")
	# CDN
	add_alu_mode(mode, bel.modes, lut, "7", "0101000001011111")
	# CUPCDN
	# The functionality of this seems to be the same with SUB
	# add_alu_mode(mode, bel.modes, lut, "8", "1010000001011010")
	# MULT INIT="0111 1000 1000 1000"
	#
	add_alu_mode(mode, bel.modes, lut, "9", "0111100010001000")
	# CIN->LOGIC INIT="0000 0000 0000 0000"
	# nop 0 nop carry
	# side effect: clears the carry
	add_alu_mode(mode, bel.modes, lut, "C2L", "0000000000000000")
	# 1->CIN INIT="0000 0000 0000 1111"
	# nop 0 nop carry
	add_alu_mode(mode, bel.modes, lut, "ONE2C", "0000000000001111")

[stacksmith]

Oh snap! So the modes are not hardwired, and you actually stuff the LUTS! I was assuming that the FPGA was somehow dereferencing a hidden ROM... That is actually good news!

I am particulary interested in using all 4 inputs of the LUT as follows: Two inputs into the adder, and a third input which can be muxed (with the fourth input), so I can get either adder result or the other input. All while using the carry to increment (and preferably suppressing the carry when muxing the non-adder input). I think it's doable, although I haven't constructed the bitmap yet.

This would make a perfect Program Counter, for instance, capable of running sequentially, adding an offset, or loading an address (returning from a subroutine, for instance).

Is there no way to use the carry chain with regular LUT configurations? Is the ALU mode a simplification for 'regular people' who feel figuring out a LUT is too hard?

[yrabbit]

Is there no way to use the carry chain with regular LUT configurations? Is the ALU mode a simplification for 'regular people' who feel figuring out a LUT is too hard?

Well, I'm one of those people. But there are gurus who, if you wake them up in the middle of the night, will draw any LUT with their eyes closed.

Note that it was not by chance that I indicated a specific place where you can substitute your INI in gowin_pack - the thing is that fuses are installed a little higher, which switch two adjacent LUTs to ALU mode. Without this, you won't get Carry at all, but with their inclusion, you must already take into account all the logic that is connected as in the picture in the documentation (where there are many AND, XOR, etc.). So these are two different configurations: LUT vs ALU.

[stacksmith]

yrabbit: Thanks. I just need a couple of clarifications (forgive my ignorance):

• are you suggesting that I add_alu_mode.. my own mode with the LUT the way I like?
• what about the code immediately below, which seems to limit access to only 3 inputs? Can I just add the missing 'I2':f"C{alu_idx}", right in there?

            bel.portmap = {
                'COUT': f"COUT{alu_idx}",
                'CIN': f"CIN{alu_idx}",
                'SUM': f"F{alu_idx}",
                'I0': f"A{alu_idx}",
                'I1': f"B{alu_idx}",
                'I3': f"D{alu_idx}",
            }

• I'm not familiar with the sequence of operation of the toolchain. After a modification here in chipdb.py, does anything need to be recompiled in the toolchain itself, or do I just run the usual makefile on my verilog?

Or should I change gowin_pack.py, replacing the lines indicated with place_lut(..)... Would that allow me to use LUT input names or the 3 ALU inputs from chipdb.py? And how would I get to this from verilog then?

Again, apologies for what may be dumb questions. I really appreciate your help.

[yrabbit]

The point is that it's relatively easy to experiment with the contents of the LUT and that's what the mechanism I suggested does.
To add an input is a completely different song - we will have to change the routing mechanism, which is located in nextpnr, and even before that we will have to change the script, which translates ‘our’ chip base into the one understandable for nextpnr.

I don't know your level of familiarity with nextpnr sources, but let's say individual ALUs are connected in clusters, if you have no problems with this piece of code, then of course you can add an input:

https://github.com/YosysHQ/nextpnr/blob/master/himbaechel/uarch/gowin/pack.cc#L1033-L1217

[stacksmith]

Just to be clear, you are saying that I can change the packer to modify LUT contents, but then I still have only 3 inputs to work with?

If I start that way and replace the lines indicated with a place_lut call, do I just create an ALU instance, but add an .INIT?

[yrabbit]

Just to be clear, you are saying that I can change the packer to modify LUT contents, but then I still have only 3 inputs to work with?

yes

If I start that way and replace the lines indicated with a place_lut call, do I just create an ALU instance, but add an .INIT?

yes, yosys may screw up, but you can always put this parameter directly in JSON after nextpnr.

To a first approximation, if you're serious about ALU, the steps are roughly as follows:

• change the file path to yosys/gowin/cells_sim.v so that the ALU has another input;
• compile yosys, check for errors on a test example;
• modify apycula/chipdb.py;
• generate a new apicula chip database;
• in nextpnr sources change file https://github.com/YosysHQ/nextpnr/blob/master/himbaechel/uarch/gowin/gowin_arch_gen.py so that your new input will be included in nextpnr chip database;
• modify nextpnr's pack.cc;
• ... if you got here and nextpnr generates the JSON you need, then fixing gowin_pack if necessary is a small thing ;)

[stacksmith]

Thank you so much! I have enough to work with now.

I am kind of serious -- here is a rare opportunity of a small change which is compatible, yet makes a hidden part of the circuit available to those who are up to the challenge.

With a full LUT and carry, this FPGA is almost as good as Xilinx... Well, they have a separate carry function generator but with a bit of ingenuity, you can make very interesting counters and ALUs.

I will work on the easy way and the JSON, and get a handle on the codebase, and see how feasible this is -- and maybe bug you some more later!

[stacksmith]

@pepinjdevos -- do you by any chance have a trick that allows you to use the LUT in ALU mode, with all 4 inputs? How did you do what you described in the last paragraph?

[pepijndevos]

You can only use the full lut if the bottom 4 bits happen to align with what you need in the second lut since they share those bits. So outside of super crafty hacks and lucky chances you can really only use 3 inputs.

What I did can be achieved by simply adding a new ALU mode with the contents as described.

It could be worthwhile trying to understand the packer. It takes tho yosys alu primitive and iirc breaks it down into the flag and lut primitives that gowin_pack actually deals with. So you might bypass the alu primitive and directly create the constituent Luts with all four inputs.

Fwiw I have played around a bit with trying to coax the alu into new and useful tricks but wasn't able to come up with something substantially more useful than the Gowin modes.