Support Types other than uint32

[dcmid]

PeakRDL-Regblock supports User Defined Properties that specify the intwidth/fracwidth of a register. It would be extremely useful if these could be used to generate a HAL that automatically converts register values to floats in C++ so that the software doesn't have to be aware of the number of fractional bits in every register. It would also be convenient to support types such as bool, but that would require an additional UDP and be less of an improvement.

This is a feature that an internal tool has at my new company which I am leading the charge to replace with PeakRDL. This feature is the one roadblock remaining.

[Risto97]

Hello @dcmid ,

Thank you for the interest in PeakRDL-halcpp.
Indeed that looks like an interesting feature, and something C++ would shine compared to C.

Just to brainstorm a bit at this point, to estimate the difficulty.

---

First idea is that instead of FieldBase class that deals with integer fields:
https://github.com/Risto97/PeakRDL-halcpp/blob/0c8b5bd884686c5021123dc9598d00a898be7173/src/peakrdl_halcpp/include/field_node.h#L22-L23

We can add something like FixpFieldBase that would have additional parameters

template <uint32_t START_INT_BIT,
          uint32_t END_INT_BIT,
          uint32_t START_FRAC_BIT,
          uint32_t END_FRAC_BIT, 
          typename PARENT_TYPE>
class FieldBase

The new FixpFieldBase class would have:

static constexpr uint32_t get_int_width() { return int_width; }
static constexpr uint32_t get_frac_width() { return frac_width; }

The FixpFieldWrMixin would have a set method with float:
It should also do the conversion from float to fixp

static inline void set(float val){
   int_val = float_to_fixp_int(val);
   parent::set(int_val & mask ...);
}

While FieldRdMixin would have a get method that returns float.

static float get(){
   return fixp_to_float(parent::get() & mask ... );
}

---

Register Node or any other node should not be affected, only the generated top header will change:
For example if we have FIXP_VAL be fixp here and INT_VAL regular field.

    template <uint32_t BASE, uint32_t WIDTH, typename PARENT_TYPE>
    class FIXP_REG: public halcpp::RegRW<BASE, WIDTH, PARENT_TYPE>
    {
    public:
        using TYPE = FIXP_REG<BASE, WIDTH, PARENT_TYPE>;

        static halcpp::FixpFieldRW<0, 7, 8, 15, TYPE> FIXP_VAL;
        static halcpp::FieldRW<16, 31, TYPE> INT_VAL;

        using halcpp::RegRW<BASE, WIDTH, PARENT_TYPE>::operator=;
    };

---

Is this what you had in mind?
I have not been very active on this plugin recently, but I do want to put some more work in the future.
Would you be interested in providing some help in implementing this feature, or with testing?

[dcmid]

Thanks for the quick reply, and sorry I didn't match your speed! I think that is what I had in mind. I can definitely provide testing support and may be able to help with implementation, though I am mostly an RTL engineer, and this is a bit outside my wheelhouse.

I think what you have shared here will be very helpful if I can find the time to take a stab at it.

[Risto97]

Hello @dcmid ,

I had a quick try at it.
Its on the branch fixp.

There are some examples/tests I added here:

1. This one runs on the host machine and mocks the memory accesses.
   https://github.com/Risto97/PeakRDL-halcpp/tree/fixp/tests/simple
   And the fixp test is here https://github.com/Risto97/PeakRDL-halcpp/blob/fixp/tests/simple/test_fixp.cpp

In order to run it just run standard cmake flow:

cd tests/simple/
mkdir build && cd build
cmake ../
make -j16 && ctest

Generated hal will be in build/halcpp

2. If you want to see how it compiles to an embedded target check the following:
   https://github.com/Risto97/PeakRDL-halcpp/tree/fixp/tests/cross_compile

You cannot execute this one, but you can observe the generated assembly and the code size.
So to compile the fixp application do:

cd tests/cross_compile/fixp/
mkdir build && cd build
cmake -DCMAKE_TOOLCHAIN_FILE=../../../cmake/toolchains/riscv_toolchain.cmake ../
make 

That should produce for you the:

• build/test_cross_compile.asm if you want to look at disassembly
• build/halcpp the generated HAL
• ... elf file etc...

---

I need to focus on adding some testing to the halcpp, hopefully I would have time to work on it soon.

[dcmid]

This is great, thanks! I just got the base HAL (from the pip release) working on our hardware, so I should have some time to try this out soon.

[dcmid]

I just tested this on hardware successfully! I used this simple app to read/write/readback a fixp config register.

#include <iostream>
#include <cstdint>
#include "simple_arch_io.h"
#include "pic_board_carrier_hal.h"

int main() {
    PIC_BOARD_CARRIER_HAL<0> fpga;
    volatile float reg_val;

    std::cout << "Reading LED CFG..." << std::endl;
    reg_val = fpga.debug_intfc_regs.led_cfg.led_cfg;
    std::cout << "Value: " << reg_val << std::endl;
    std::cout << "Writing 5.45 to LED CFG..." << std::endl;
    fpga.debug_intfc_regs.led_cfg.led_cfg = 5.45;
    std::cout << "Reading LED CFG..." << std::endl;
    reg_val = fpga.debug_intfc_regs.led_cfg.led_cfg;
    std::cout << "Value: " << reg_val << std::endl;
}

The output was exactly as expected. I also verified the values by reading with devmem and independently doing float conversion.

raspberrypi $ ./testapp 
Reading LED CFG...
Value: 0.0212891
Writing 5.45 to LED CFG...
Reading LED CFG...
Value: 5.45

I repeated the test with different intwidth values as well as on another register that is only 8-bits Q3.5, which showed the expected loss of precision.

raspberrypi $ ./testapp2
Reading TEST REG...
Value: 0
Writing 5.45 to TEST REG...
Reading TEST REG...
Value: 5.4375

[dcmid]

It would also be very useful to support signed types from the UDP is_signed, which is also used by PeakRDL-Regblock. With the approach you used here, I suppose this could be done by creating 4 different field_node classes, one each for signed/unsigned int/float. I wonder if there is a good way to reduce it to one class so the number of classes doesn't increase exponentially with additional feature support... I will try to find some time to think about it. Right now, though, this is a great addition, and I really appreciate you putting in the work so quickly!

[Risto97]

Hello,

Great, happy to hear it works for you, thank you for testing it.
Just a small curiosity, are you using a custom ARCH_IO_NODE to override the memory io operation to some I2C or SPI transactions?

It would also be very useful to support signed types from the UDP is_signed, which is also used by PeakRDL-Regblock. With the approach you used here, I suppose this could be done by creating 4 different field_node classes, one each for signed/unsigned int/float. I wonder if there is a good way to reduce it to one class so the number of classes doesn't increase exponentially with additional feature support... I will try to find some time to think about it. Right now, though, this is a great addition, and I really appreciate you putting in the work so quickly!

This would be the next step. It should be fairly simple to support as well.
I think there is no need to have 4 different ones, the current template class can definitely be adapted.
I did not want to merge the FieldNode and FixpFieldNode yet, the main reason is I didn't want to break the existing code as I didn't have any testing.
However I started working now on test generator for the generated Hal's.
I have the concept on the branch testing.
You can generate the testing project using --generate-tests flag.
It runs on host CPU and mocks mem IO to check if rw to reg, fields produce expected writes/reads at correct addresses and correctly masked write values.
It generates a CMake project. I will extend the tests also to fixp, so I can finalize that as well.

[dcmid]

are you using a custom ARCH_IO_NODE to override the memory io operation to some I2C or SPI transactions?

Yes. I am running linux and using a custom ARCH_IO_NODE to mmap onto our FPGA device over a bus.