Hello,
I'm trying to synthesize Pulpissimo. But there is a problem with the port width.

In the module soc_interconnect the width of AXI_Master_w_data_o is 32 but the port width of axi_to_cluster.w_data is 64 in soc_interconnect_wrap.

The port width was changed in commit 5d24368.
Can you tell me why you changed it and what the expected behaviour should be?

Thanks.

Add assertions to the parametric interconnct that warn about non-compliant bus interactions on slave and master side of TCDM ports. Also, illegal addresses on the interleaved only ports (addresses not within the interleaved memory space) are aliasing to the interleaved memory. This should be prevented with a TCDM demux+erro slave.

The tcdm_bus_0 and tcdm_bus_1 used in tcdm_arbiter_2x1.sv are missing default values the r_opc signal.
At the beginning of the FSM could be added the following:

tcdm_bus_0_i.r_opc   = 1'b0;
tcdm_bus_1_i.r_opc   = 1'b0;

this change would allows us to use xilinx parametrized macros for the FPGA port instead of separately synthesizing xilinx block memory IPs

With Ibex and CV32E40P, the two main processor cores supported inside PULP are no longer maintained by the PULP team itself. This has several advantages for the PULP team but it can complicate things around PULP-specific changes in those cores and it should probably be documented how the PULP team wants to deal with such changes.

For Ibex, we try to merge as many changes as possible upstream but for very PULP-specific stuff, we have a branch called pulpissimo upstream that contains such PULP-specific changes. From time to time, we rebase this branch on the current master and create a tag that survives future rebases. Between rebases, contributors can still do PRs into the pulpissimo branch and we try to carry those changes forward. This is not perfect but so far it meant quite low overhead.

For CV32E40P, the situation seems to be that PULP is using a slightly older version from Nov 2019 pulpissimo-v3.4.0. I can imagine that it would be quite some work to update the core to the latest version. Maybe someone is already working on that. However, it's not clear how even simple changes such as modifications to the Bender.yml file can be made and used within PULP.

Of course, the creation of a fork is always possible but IMO this should be avoided as it again introduced the risk of having different versions that drift apart over time.

I would be interested to get your views @davideschiavone @daviderossi1982 @bluewww @meggiman @accuminium @zarubaf
I don't have a strong preference but I feel the team should take a decision and document this to clarify the situation for everybody involved.

When I made zcu102 in https://github.com/pulp-platform/pulpissimo ，it happened. I can't find the package in it. What is dm??
ERROR: [Synth 8-1031] dm is not declared [/home/tc/tc/PULP/pulpissimo/ips/pulp_soc/rtl/pulp_soc/pulp_soc.sv:16]
ERROR: [Synth 8-1031] dm is not declared [/home/tc/tc/PULP/pulpissimo/ips/pulp_soc/rtl/pulp_soc/pulp_soc.sv:261]
ERROR: [Synth 8-1031] dm is not declared [/home/tc/tc/PULP/pulpissimo/ips/pulp_soc/rtl/pulp_soc/pulp_soc.sv:266]
ERROR: [Synth 8-1031] dm is not declared [/home/tc/tc/PULP/pulpissimo/ips/pulp_soc/rtl/pulp_soc/pulp_soc.sv:267]
ERROR: [Synth 8-2119] illegal context for assignment pattern [/home/tc/tc/PULP/pulpissimo/ips/pulp_soc/rtl/pulp_soc/pulp_soc.sv:268]
ERROR: [Synth 8-1031] dm is not declared [/home/tc/tc/PULP/pulpissimo/ips/pulp_soc/rtl/pulp_soc/pulp_soc.sv:270]
ERROR: [Synth 8-1031] dm is not declared [/home/tc/tc/PULP/pulpissimo/ips/pulp_soc/rtl/pulp_soc/pulp_soc.sv:325]
ERROR: [Synth 8-1031] dm is not declared [/home/tc/tc/PULP/pulpissimo/ips/pulp_soc/rtl/pulp_soc/pulp_soc.sv:326]
ERROR: [Synth 8-2119] illegal context for assignment pattern [/home/tc/tc/PULP/pulpissimo/ips/pulp_soc/rtl/pulp_soc/pulp_soc.sv:826]
INFO: [Synth 8-2350] module pulp_soc ignored due to previous errors [/home/tc/tc/PULP/pulpissimo/ips/pulp_soc/rtl/pulp_soc/pulp_soc.sv:15]

Error: ../../../rtl/pulp_soc/rtl/pulp_soc/pulp_soc.sv:355: Found expression without known width in context that requires one

The line is the following:

function logic [NB_CORES-1:0][10:0] CORE_CL_ID_FX();

Not that easy since we don't have space for more i2c event anymore. We need to map it probably at the end of the event signal space.

Some fixes are needed for synthesis.
There are wrong parameters when instantiating AXI bus to communicate with the cluster.

Current version:

AXI_BUS_ASYNC #(
.AXI_ADDR_WIDTH ( AXI_ADDR_WIDTH ),
.AXI_DATA_WIDTH ( AXI_DATA_OUT_WIDTH ),
.AXI_ID_WIDTH ( AXI_ID_OUT_WIDTH ),
.AXI_USER_WIDTH ( AXI_USER_WIDTH ),
.BUFFER_WIDTH ( BUFFER_WIDTH )
) s_data_master ();
AXI_BUS_ASYNC #(
.AXI_ADDR_WIDTH ( AXI_ADDR_WIDTH ),
.AXI_DATA_WIDTH ( AXI_DATA_IN_WIDTH ),
.AXI_ID_WIDTH ( AXI_ID_OUT_WIDTH ),
.AXI_USER_WIDTH ( AXI_USER_WIDTH ),
.BUFFER_WIDTH ( BUFFER_WIDTH )
) s_data_slave ();

AXI_BUS #(
    .AXI_ADDR_WIDTH ( AXI_ADDR_WIDTH    ),
    .AXI_DATA_WIDTH ( AXI_DATA_IN_WIDTH ),
    **.AXI_ID_WIDTH   ( AXI_ID_OUT_WIDTH  ),**
    .AXI_USER_WIDTH ( AXI_USER_WIDTH    )
) s_data_in_bus ();
AXI_BUS #(
    .AXI_ADDR_WIDTH ( AXI_ADDR_WIDTH    ),
    .AXI_DATA_WIDTH ( AXI_DATA_OUT_WIDTH),
    **.AXI_ID_WIDTH   ( AXI_ID_OUT_WIDTH  ),**
    .AXI_USER_WIDTH ( AXI_USER_WIDTH    )
) s_data_out_bus (); 

How it should be:
AXI_BUS_ASYNC #(
.AXI_ADDR_WIDTH ( AXI_ADDR_WIDTH ),
.AXI_DATA_WIDTH ( AXI_DATA_OUT_WIDTH ),
.AXI_ID_WIDTH ( AXI_ID_OUT_WIDTH ),
.AXI_USER_WIDTH ( AXI_USER_WIDTH ),
.BUFFER_WIDTH ( BUFFER_WIDTH )
) s_data_master ();

AXI_BUS_ASYNC #(
    .AXI_ADDR_WIDTH ( AXI_ADDR_WIDTH    ),
    .AXI_DATA_WIDTH ( AXI_DATA_IN_WIDTH ),
    **.AXI_ID_WIDTH   ( AXI_ID_IN_WIDTH   ),**
    .AXI_USER_WIDTH ( AXI_USER_WIDTH     ),
    .BUFFER_WIDTH   ( BUFFER_WIDTH       )
) s_data_slave ();

AXI_BUS #(
    .AXI_ADDR_WIDTH ( AXI_ADDR_WIDTH    ),
    .AXI_DATA_WIDTH ( AXI_DATA_IN_WIDTH ),
    **.AXI_ID_WIDTH   ( AXI_ID_IN_WIDTH   ),**
    .AXI_USER_WIDTH ( AXI_USER_WIDTH    )
) s_data_in_bus ();


AXI_BUS #(
    .AXI_ADDR_WIDTH ( AXI_ADDR_WIDTH    ),
    .AXI_DATA_WIDTH ( AXI_DATA_OUT_WIDTH),
    **.AXI_ID_WIDTH   ( AXI_ID_OUT_WIDTH  ),**
    .AXI_USER_WIDTH ( AXI_USER_WIDTH    )
) s_data_out_bus ();

Hi everyone,
I am implementing the pulpissimo project. I synthesize it with "SYNTHESIS" and "TARGET_SYNTHESIS" defined. This leads to the signals of s_stdout_bus to be forced to low in the soc_peripherals (specifically pready, pslverr and prdata ). I use genus as synthesis tool and it correctly then warns about the signals being multidriven.
Can you expand on the reasoning why these signals are special and why they are pulled low?

Warning : Signal or variable has multiple drivers, including a constant driver. [CDFG2G-623]
        : 's_stdout_bus_pready' in module 'soc_peripherals_MEM_ADDR_WIDTH17_APB_ADDR_WIDTH32_APB_DATA_WIDTH32_NB_CORES0_NB_CLUSTERS0_EVNT_WIDTH8_NGPIO32_NPAD64_NBIT_PADCFG6_NBIT_PADMUX2_N_UART32h00000001_N_SPI32h00000001_N_I2C32h00000002_SIM_STDOUT0_apb_slave_APB_BUS_Slave_apb_eu_master_APB_BUS_Master_apb_hwpe_master_APB_BUS_Master_apb_debug_master_APB_BUS_Master_l2_rx_master_XBAR_TCDM_BUS_Master_l2_tx_master_XBAR_TCDM_BUS_Master_soc_fll_master_FLL_BUS_out_per_fll_master_FLL_BUS_out_cluster_fll_master_FLL_BUS_out' in file '/home/lanius/code/pulp/pulpissimo/.bender/git/checkouts/apb-b24fbe74bd47ac2e/src/apb_intf.sv' on line 26, column 38.
        : Some tools may not accept this HDL.

Kind regards
Christian

Hi there,

I was doing a license audit and noticed that you have a file checked into your public repository that is expressly prohibited from distribution, which many users now have a copy of because it is automatically distributed when the repository is cloned.

Can you please clarify the disposition of this file?

In lint_jtag_wrap.sv there's an unconnected input port lint_r_aux_i of module dbg_module_i.

Updating pulp_soc to latest, rtl/pulp_soc/boot_rom.sv includes soc_mem_map.svh, but file does not exist. It it somewhere else?

I encountered a problem with the reduction of the memory addresses in the uDMA subsystem. I noticed it on the SPI peripheral so I will describe it with this example.

Whenever a memory address is needed to be stored (e.g. the start address of a TX buffer) only the relevant bits should be stored not the whole 32 bit address to save some resources. The number of bits is given as L2_AWIDTH_NOAL in udma_subsystem.sv .
Currently it is defined as L2_AWIDTH_NOAL = L2_ADDR_WIDTH + 2;. L2_ADDR_WIDTH is passed from in pulp_soc.sv through soc_peripherals.sv as
L2_MEM_ADDR_WIDTH = $clog2(L2_BANK_SIZE * NB_L2_BANKS)
(actually L2_MEM_ADDR_WIDTH = $clog2(L2_BANK_SIZE * NB_L2_BANKS) - $clog2(NB_L2_BANKS);, but $clog2(NB_L2_BANKS) is added back again when passed to soc_peripherals)

The problem lies in the hardcoded L2_AWIDTH_NOAL = L2_ADDR_WIDTH + 2; which is only valid for the preset memory configuration. It is wrong when using following memory configuration for example:

Two shared memory banks of 1024 lines/32b-words and two private memory banks of 1024 lines
L2_MEM_ADDR_WIDTH becomes 11 bits. Therefore L2_AWIDTH_NOAL becomes 13 bits.
But the highest possible Address 0x4000 requires 14 bits, thus the peripheral can not access half of the memory.

I suggest defining L2_AWIDTH_NOAL as
$clog2(L2_BANK_SIZE * NB_L2_BANKS * 4 + L2_BANK_SIZE_PRI * NB_L2_BANKS_PRI * 4),
which calculates the required bits for the highest memory address.

This could be done directly in pulp_soc, since all this
localparam L2_BANK_SIZE = 29184; // in 32-bit words
localparam L2_MEM_ADDR_WIDTH = $clog2(L2_BANK_SIZE * NB_L2_BANKS) - $clog2(NB_L2_BANKS);
localparam NB_L2_BANKS_PRI = 2;

is there only for the uDMA anyway..

Hi guys,

in the latest commit of pulp_soc the parameters mentioned in the issue title (NGPIO, NBIT_PADCFG and NBIT_PADMUX) are not used completely, i.e. line 964 to 991 looks as follows:

    //********************************************************
    //*** PAD AND GPIO CONFIGURATION SIGNALS PACK ************
    //********************************************************

    generate
        for (i=0; i<32; i++) begin
            for (j=0; j<6; j++) begin
                assign gpio_cfg_o[j+6*i] = s_gpio_cfg[i][j];
            end
        end
    endgenerate

    generate
        for (i=0; i<64; i++) begin
            for (j=0; j<2; j++) begin
                assign pad_mux_o[j+2*i] = s_pad_mux[i][j];
            end
        end
    endgenerate

    generate
        for (i=0; i<64; i++) begin
            for (j=0; j<6; j++) begin
                assign pad_cfg_o[j+6*i] = s_pad_cfg[i][j];
            end
        end
    endgenerate

This is basically correct for the configuration of these signals in line 304 to 306:

    logic [31:0][5:0]      s_gpio_cfg;
    logic [63:0][1:0]      s_pad_mux;
    logic [63:0][5:0]      s_pad_cfg;

Unfortunately, the corresponding connections to soc_peripherals look as follows:

    output logic [NGPIO-1:0][NBIT_PADCFG-1:0] gpio_padcfg,

    output logic [NPAD-1:0][NBIT_PADMUX-1:0] pad_mux_o,
    output logic [NPAD-1:0][NBIT_PADCFG-1:0] pad_cfg_o,

This leads to port width mismatch issues and - in case your parameterized pad configuration is bigger than the statically implemented there are also functional issues.

So, I assume that the signals in pulp_soc should be defined like this:

    logic [NGPIO-1:0][NBIT_PADCFG-1:0]     s_gpio_cfg;
    logic [NPAD-1:0][NBIT_PADMUX-1:0]      s_pad_mux;
    logic [NPAD-1:0][NBIT_PADCFG-1:0]      s_pad_cfg;

And then the configuration assignments (line 964 to 991) then need to be changed as follows:

    //********************************************************
    //*** PAD AND GPIO CONFIGURATION SIGNALS PACK ************
    //********************************************************

    generate

        for (i=0; i<NGPIO; i++) begin
            for (j=0; j<NBIT_PADCFG; j++) begin
                assign gpio_cfg_o[j+6*i] = s_gpio_cfg[i][j];
            end
        end
    endgenerate

    generate
        for (i=0; i<NPAD; i++) begin
            for (j=0; j<NBIT_PADMUX; j++) begin
                assign pad_mux_o[j+2*i] = s_pad_mux[i][j];
            end
        end
    endgenerate

    generate
        for (i=0; i<NPAD; i++) begin
            for (j=0; j<NBIT_PADCFG;j++) begin
                assign pad_cfg_o[j+6*i] = s_pad_cfg[i][j];
            end
        end
    endgenerate

Furthermore, you then need to add the pad parameters to apb_soc_ctrl.sv:

module apb_soc_ctrl
  #(
    parameter APB_ADDR_WIDTH = 12,  // APB slaves are 4KB by default
    parameter NB_CLUSTERS    = 0,   // N_CLUSTERS
    parameter NB_CORES       = 4,   // N_CORES
    parameter NPAD           = 64,
    parameter NBIT_PADCFG    = 4,
    parameter NBIT_PADMUX    = 2,
    parameter JTAG_REG_SIZE  = 8
    )

And the corresponding pad_mux and pad_cfg ports need also to be parameterized:

    output logic         [NPAD-1:0][NBIT_PADCFG-1:0] pad_cfg,
    output logic         [NPAD-1:0][NBIT_PADMUX-1:0] pad_mux,

Then all port width mismatch issues and also functional issues if you change the pad or gpio configuration width are gone.

Furthermore: Is it possible that there is a typo in the NGPIO setting? You set it to 43 in pulp_soc.sv (line 33) but you leave all gpio pin widths at 32 so I assume 32 is the right choice?

Thanks & Best Regards,
Dustin

when building RTL platform of PULP I get this error:

1. pulp-platform/axi @ v0.7.1 (retrieved from pulp-platform/pulp_soc @ pulp-next)
2. pulp-platform/axi @ v0.7.0 (retrieved from pulp-platform/axi_node @ v1.1.3)

Since I am using IPApproX tool to generate IP tree, we should update the version of axi fetched from axi_nod ips_list.yml to the same version in the pulp_soc ips_list.yml (i.e. v0.7.1).

This would increase debug performance. The debug ROM has constant latency of 1 cycles and is thus compatible with tcdm_xbar in the contiguous logarithmic interconnect.

Hi @FrancescoConti ,
@micprog just noted that pulp lo longer references master but instead the the v.1.4.3 tag on the update-hwpe branch of pulp_soc. This looks bad and could lead to problems and merge madness in later PRs. I think it would be much better to merge the update-hwpe branch into master and then delete the branch. Or is there a particular reason why not merging it into master?

Also pinging the repo owner @bluewww .

udma_core instance in udma_subsystem is not updated to last release of udma_core (v2.0.0)

I am currently working on a verification task involving LEC (Logical Equivalence Checking) using Formality. Unfortunately, I have encountered a verification failure in this process. The focus of this verification task is to compare the RTL (Register Transfer Level) design with the netlist. The netlist has been generated after synthesizing a specific block using the Fusion Compiler.The issue I am facing appears to be located within the FC_CORE portion of our design. The verification failure is primarily attributed to unmatched inputs or required input mismatches between the RTL and the synthesized netlist.

I am seeking help from anyone with expertise in logic equivalence checking or experience with similar verification tasks. If there is someone who can assist with debugging or provide insights into resolving this issue, your assistance would be greatly appreciated.

In l2_ram_multibank.sv the wrong bits are selected for the interleaved memory banks. Currently, only the 2 LSBs are striped which converts from byte addressing to 32-bit word addressing. However, for the interleaved memory banks, we also have to remove $clog2(Nr_of_banks) bits that index the bank due to the interleaved address space mapping. The effect of not doing this is that we start to alias as soon as we try to write more than 128KB into L2 memory.