whitequark / boneless-cpu Goto Github PK

I am willing to accept that this may be clear to other people but the comment for the class ALSRU_4LUT left me confused. I read it as “here’s a great function but you need to do something different for an iCE40”.

file: alsru.py

class ALSRU_4LUT(ALSRU, Elaboratable):
    """ALSRU optimized for 4-LUT architecture with no adder pre-inversion.
    On iCE40 with Yosys, ABC, and -relut this synthesizes to the optimal 4n+3 LUTs.
    """

Whereas I think the meaning is more like: “This code will synthesise to the optimal 4*width+3 LUTs (Look Up Table) when targeting the Lattice iCE40 family and using Yosys with the ABC tool and -relut”

Your tweet gave me the insight that I needed to understand the above along with the Yosys documentation.

I am not sure what “-relut” is exactly and I assume that Yosys has to be run with a specific set of options to get this optimal outcome.

Currently, in the Python-based Boneless assembler, when specifying the name of a label in an instruction, e.g. MOVR(R3, "label"), the instruction operand is substituted by the PC-relative address of the label. This is the only way to use a label.

I propose a way to apply arbitrary calculations to labels before their values get substituted. Instead of specifying "label", the user could specify LabelCalc(lambda pc, lbl: label, "label") to the same effect.

By allowing an arbitrary lambda expression for the label, many other possibilities could be expressed. For example, LabelCalc(lambda pc, lbl: label-pc, "label") specifies the absolute location of "label". If there was an array with labels at the start and end, one could specify CMPI(R3, LabelCalc(lambda pc, s, e: e-s, "data_start", "data_end")) to test if R3 has reached the number of items in the array.

Based on my understanding of the assembler, this lambda expression would allow arbitrary calculations without changing its framework. However, there may be problems converging if the user specified a nonlinear calculation. In that case, there may need to be a check to fail assembly if there is no convergence after a reasonable number of iterations.

Currently, in the Python-based Boneless assembler, there is no difference between specifying a register Rn and the integer n as an argument to an instruction. As a consequence, the instruction SLLI(R3, R2, 1) assembles the same as SLLI(R3, R2, R1). Unfortunately, the second version might mislead one into believing the instruction is shifting R2 by the value of R1 instead of by the constant 1. At least in my experience, this behavior easily creates hard-to-find bugs.

I suggest that using a register where a constant is expected and vice versa should be treated as an error. For problems where being able to interchange a register and its number are useful, the Rn object could have e.g. an attribute containing its number: R3.number == 3 and have e.g. a constructor that takes a register number: Rn(3) == R3. This would eliminate the source of accidental bugs and still allow the flexibility of interchanging registers with their numbers in the syntax.