spcl / pspin Goto Github PK

The assertion looks like the following:

sim_slp_l1: src/NICInbound.hpp:475: void PsPIN::NICInbound<AXIPortType>::feedback_progress() [with AXIPortType = PsPIN::AXIPort<unsigned int, long unsigned int>]: Assertion `*ni_ctrl.feedback_her_size_i == pktentry.size' failed.

I'm currently on commit cf70804.

This happens if the fill_packet function does not return max_pkt_size (even if just off by one i.e. max_pkt_size-1). I'm pretty sure I'm not overflowing the packet buffer.

In this Document page https://spcl.github.io/pspin/compile/, should define VERILATOR_ROOT not the VERILATOR_HOME.

If a handler issues a buggy command (e.g., to an undefined command interface) then the command request gets lost and no response is sent back.

We should:

• (1) add an error bit to the command response;
• (2) have a "sink" command interface that replies with responses flagged as errors;
• (3) propagate success/fail status to the handler whenever it tests/waits for a command.

What happens if a handler issued a buggy command and then exits without checking? We should probably send an event to the host in this case. This would probably make (3) redundant because we shouldn't spend too much time into the handlers, e.g., checking for status codes: if sth goes wrong, it could be enough to signal this to the host via an event.

handler_args should carry flag to tell if is first pkt

Hi,
I'm reading your article (A RISC-V in-network accelerator for flexible high-performance low-power packet processing) and I noticed that there were some experiments conducted regarding KVS in the article.

It was mentioned in the article that:

We generate a YCSB [17] workload of 1,000 requests (50/50 read/write ratio, θ=1.1).

The experiments were conducted using simulated network interface devices, as mentioned in the article.
I wonder how to generate such a KVS YCSB packet trace? is there any reference code available as well?

Thanks.

I'm recently reading your paper "A RISC-V in-network accelerator for flexible high-performance low-power packet processing", along with the source code. And I find there're some mismatches between the paper and the source code, which are quite confusing for me.

I'm reading the source code on tag v0.6.1, and I make no changes to the source files. There's no significant changes for hardware design in hw/ according to git diff with branch master, so I think it's okay to consider v0.6.1 as "update-to-date".

There are connections in hw/deps/pulp_cluster/rtl/pulp_cluster.sv, that I believe play the role of clock-gating the core_region.

// line 1031
cluster_peripherals #(
...
) cluster_peripherals_i (
...
  .core_busy_i(core_busy),
  .core_clk_en_o(clk_core_en),
...
);

// line 1155
core_region #(
...
) core_region_i (
...
  .clock_en_i(clk_core_en[i]),
...
  .core_busy_o(core_busy[i]),
...
);

Looks like that this cluster_peripherals_i instance is controlling/clock-gating the RISC-V cores. However, the paper mentions that

If the HPU driver has no task/handler to execute, it stops the HPUs by clock-gating it.

But I didn't find any connection between HPU driver and cluster_peripherals_i in the source code... Yet I don't find much description about this instance in the paper. So here are my questions:

1. In current implemenation, by which module is core controlled/clock-gated, and what behavior is the module to control the core?
2. What role is cluster_peripherals_i playing in the design? I noticed that it manages "events" from timer, DMA and etc., but how do these events and their sources work as a part of the design?