LMARV-1 reboot part 3: the shifter and ALU

This part codes and formally verifies the shifter and ALU cards.
github repo for code: github.com/RobertBaruch/riscv...
nMigen tutorial: github.com/RobertBaruch/nmige...
hackaday.io 74-series logic RISC-V project: hackaday.io/project/18491-wor...

[@arnauddurand127]

It would be awesome to build a FPGA tester card where any other card can be synthesized to it. It would require a FPGA with lots of I/O tho. I really love this LMARV-1 series.

[@tomd6410]

15:31 "Unless you shift it too far, in which case you should feel bad" xD

[@TomStorey96]

Can't believe we are already at the same stage as we were in the last series! Excited to see the sequencer!

[@RobertBaruch]

Well, minus all the actual building of the hardware angst and delay.

[@jamesrivettcarnac]

So.... We are further along then.

[@wmlye1]

Another way of building a left/right shifter is to add one more shift-by-1 stage (either leading or trailing) rather than adding the two "reverse" stages. You then feed the controls for the original shifters with the xor of the amount and the direction bit, and feed the direction bit into the control of the additional shift-by-1. You can look at it as a shifter with a 1's complement control word (the direction is the sign), or you can look at the xor's and the additional shift-1 as a 2's complement negation with the xor's as the "flip the bits" and the additional shift-1 as the "and add 1". The simplest structure is a wrap-around shifter (i.e. bits shifted off either end go to the other) but it's relatively straight-forward to add muxes and/or AND gates to the shift paths to do the sign extension/zero-insertion to perform SLL, SRL, and SRA. Of course, the question is whether the delay (or gate count) you save by removing one stage of shifters is worse than the delay (or gate count) you lose by having to add the up-front xor's and the muxes to do the sign extension/zero insertion, but in VLSI designs with access to a reasonable library of aoi/oai (or even aoai/oaoi) functions. For a board level implementation where you are using chips not complex gates it may be a less attractive option.

[@wmlye1]

Of course, if you really want to cut down on the number of shift/reverse stages you could insert a selectable complement function (flip the bits and add 1) to the shift amount and do away with the additional shift-1. That's probably a winning proposition from a gate/chip count perspective, but probably loses in speed. Depending on the carry propagate characteristics of the complement block, it may also result in some more glitch energy in the shifter core as the carry settles going from the LSB to the MSB.

[@JonSeverinsson]

If you specify your ALU_OP control signal to include an invalid op, you don't need an AUL_TO_Z control signal (As you got a 4 bit signal for only 10 values, there is no problem fitting an 11th value in there). Simply make sure the controller sets the ALU_OP signal to the invalid op whenever you want neither the ALU card nor the shifter card to output anything to the Z bus. To make this simple to do, I'd recommend specifying ALU_OP 0b0000 as the invalid op.

[@RobertBaruch]

I could, but then I would be imposing a new instruction on the ISA. The ALU op is constructed directly from the funct3 part of the instruction and bit 5 of the funct7 part of the instruction -- you'll see that when I get to the part about the sequencer. Sure, I can reserve an unused op, but who's to say that won't become used in a later revision of the ISA?

[@JonSeverinsson]

I didn't realize that the ALU_OP control signal was simply func3 + func7 bit 5 from the instruction word. So essentially you are trading 1 control signal on the backplane and some minor complexity in the ALU and shifter for a simpler sequencer, makes sense. I don't buy that there would be some future compatibility issue with a more compact control signal though, as there is also nothing to prevent a later revision of the ISA from using any other bits from func7. If you want future compatibility you would need to put the entire func3 and func7 on the backplane (as well as a single bit to indicate that the major op code is OP/OP_IMM, i.e. ALU_TO_Z). That way any new instruction would only need another card added to the backplane. With anything less, whether 4+1 bits or 4 bits total, you might still need a replacement sequencer card as well.

[@RobertBaruch]

@@JonSeverinsson Well... you're not wrong. That is a trade I made, and maybe it's a bad one. Still, I'd rather not decode the ALU op to something else.

[@mikescott58]

So happy that you decided to reboot the LMARV project. Any chance that the theme song will also be revived?

[@RobertBaruch]

OMG I totally forgot about that. I'll have to add that.

[@SugarBeetMC]

And the nMigen "How's that, cat?" outro.

[@b4tch3r]

This is amazing. How many years of knowledge do you have in Information Technology? Please keep on your great work. All the best to you. Cheers from Germany

[@maikmerten]

Thanks for rebooting the series and talking about that shifter-reversal trick from the 74-series logic RISC-V project. That one is so neat I had to steal it: github.com/maikmerten/spu32/blob/master/cpu/shifter.v

[@DantalionNl]

I was wondering does nmigen support to generate some kind of boilerplate verilog or vhdl? because I think that could be a feasible feature to implement.

[@reinoud6377]

In the example you only showed one shift variant in the formal specification. Are the others covered too only not shown?

[@lawrencemanning]

A dumb question probably, but how will the HDL scripts tell you how what TTL parts should be used? With your ALU there are many ICs that could be used to produce the same logical circuit, so what really does it add to the process of designing a RISCV processor put of TTL logic? Or have I missed the point?

[@RobertBaruch]

Ah, that will be a process of manually replacing each bit of code with other bits of code that emulate particular TTL parts in HDL. I would also have to start thinking about practical concerns like setup and hold times, which can't be emulated in the HDL.

[@lawrencemanning]

@@RobertBaruch Right! I must have missed that in your new Part 1. And of course the beauty of it will be you can reuse your tests, cool. Looking forward to seeing how this turns out!

[@MrLaserBenny]

This is really an interesting project, looking forward to when you start to create the actual boards! I saw this video by Ben Eater a couple of months ago where he use a EEPROM to implement combinational logic. m.kzbin.info/www/bejne/eHKUY41tnLZnhpI Basically, in the EEPROM you write the output bit pattern on the data bus for every bit pattern on the address bus. This way you could feed the EEPROM the risc v opcode and generate the right control signals for the ALU. (if this counts as a "fpga" I let you decide :)