spec: DMA memcpy accelerator by nicole-graus · Pull Request #931 · yetanotherco/lambda_vm

nicole-graus · 2026-08-11T20:01:13Z

Description

Specifies the DMA memcpy table added by #874. It has one row per eight copied bytes (one on the tail), rows chained over a new DMA_NEXT bus, ECALL number -3. Adds the ADDNW template (ADD without wraparound) used for the address updates, and lists -3 in the ECALL overview.

One deliberate deviation from #874's Rust: 31 columns rather than 32, because the spec models timestamp as a Word, as every other chapter does.

…apter

…nation, end-detection and row-count arguments

…the unit address increments

erik-3milabs · 2026-08-19T12:18:01Z

Quick review:

As mentioned during yesterday's meeting, this chip was implemented to adhere to the EF's standardization efforts.
Consider linking the standard (https://github.com/eth-act/zkevm-standards/tree/main/standards/accelerated-memory-operations) in the accelerator's description.
I don't know whether 'DMA' is the right name for this: DMA refers to a category of operations, while this is just one of them.

Do you want us to perform an in-depth analysis next? We might be able to find some optimizations (which could be very beneficial, given that this chip is expected to see a large volume of traffic).

erik-3milabs

see above

erik-3milabs

first batch of comments; I'll review the remainder on Monday

erik-3milabs · 2026-08-28T15:01:15Z

+
+The #dma chip copies a range of bytes from one location in memory to another, that is, it performs a `memcpy`.
+#footnote([Linux man-page on `memcpy`; man7.org. #link("https://man7.org/linux/man-pages/man3/memcpy.3.html")[[src]]])
+The guest performs such a copy with a RISC-V loop --- per copied doubleword a load, a store, two pointer increments and a branch, each of them a `CPU` row (@cpu) together with its memory operations.


Well, not any more. 😄
Rephrase to indicate that this is how this would be done if this chip did NOT exist, i.e., if you were to have the CPU do this "manually"

erik-3milabs · 2026-08-28T15:04:23Z

+The #dma chip copies a range of bytes from one location in memory to another, that is, it performs a `memcpy`.
+#footnote([Linux man-page on `memcpy`; man7.org. #link("https://man7.org/linux/man-pages/man3/memcpy.3.html")[[src]]])
+The guest performs such a copy with a RISC-V loop --- per copied doubleword a load, a store, two pointer increments and a branch, each of them a `CPU` row (@cpu) together with its memory operations.
+This accelerator replaces all of that with a single row per eight copied bytes.


I'd recommend rewriting this in higher-level terms; after all, the reader does not immediately know how a CPU row compares to one of these rows.

erik-3milabs · 2026-08-28T15:05:19Z

+#footnote([Linux man-page on `memcpy`; man7.org. #link("https://man7.org/linux/man-pages/man3/memcpy.3.html")[[src]]])
+The guest performs such a copy with a RISC-V loop --- per copied doubleword a load, a store, two pointer increments and a branch, each of them a `CPU` row (@cpu) together with its memory operations.
+This accelerator replaces all of that with a single row per eight copied bytes.
+An accelerated `memcpy` is expected to conform to the Ethereum Foundation's Accelerated Memory Operations standard, which fixes the semantics the symbol must keep and how it must win linking.


The standard is set, right? In that case, it either conforms or it does not. Either we can get rid of "expected", or the entire sentence can be removed.

Also, what does the following mean:

... the semantics the symbol must keep and how it must win linking

?

erik-3milabs · 2026-08-28T15:07:26Z

+This accelerator replaces all of that with a single row per eight copied bytes.
+An accelerated `memcpy` is expected to conform to the Ethereum Foundation's Accelerated Memory Operations standard, which fixes the semantics the symbol must keep and how it must win linking.
+#footnote([Accelerated Memory Operations; eth-act/zkevm-standards. #link("https://github.com/eth-act/zkevm-standards/tree/main/standards/accelerated-memory-operations")[[src]]])
+Both obligations fall on the guest-side stub and on the link, outside this chapter; what the standard asks of the chip itself is that it assume no particular alignment of `dst`, `src` or `count`, which @dma:c:tail guarantees by choosing the width from `count` alone.


I would move the analysis of why this adheres to the eth spec to a separate subsection somewhere at the bottom; this is the chapter header and things should be as concrete/short as reasonably possible here.

erik-3milabs · 2026-08-28T15:12:24Z

+= Assumptions
+#render_chip_assumptions(chip, config)
+
+The obligations on `src`, `dst` and `count` concern the _first_ row of a copy sequence only:


"obligations" => "assumptions"

"On the first row they are discharged by the register file, outside
this chapter."
Don't understand what that is supposed to mean. Consider rephrasing.

erik-3milabs · 2026-08-28T15:18:56Z

+
+#let config = load_config()
+#let chip = load_chip("src/dma.toml", config)
+#let dma = raw(chip.name)


Consider renaming the chip from dma to memmove; that more accurately describes what this chip actually does.

erik-3milabs · 2026-08-28T15:21:14Z

+The #dma chip copies a range of bytes from one location in memory to another, that is, it performs a `memcpy`.
+#footnote([Linux man-page on `memcpy`; man7.org. #link("https://man7.org/linux/man-pages/man3/memcpy.3.html")[[src]]])


this chip does memmove, not (just) memcpy (which does not work for overlapping data ranges)

erik-3milabs · 2026-08-28T15:22:09Z

+That is to say,
+- `A0` contains the address of the first byte to write,
+- `A1` contains the address of the first byte to read, and
+- `A2` contains `count`.


Suggested change

- `A2` contains `count`.

- `A2` contains `count`; the number of bytes to copy.

erik-3milabs · 2026-08-28T15:23:40Z

+
+@dma:c:read_dst, @dma:c:read_src and @dma:c:read_count read these three registers.
+Each of them writes back the value that was read, so the copy leaves the registers untouched;
+the guest is responsible for producing `memcpy`'s return value.


there is no return value? it is a void* function.

erik-3milabs · 2026-08-28T15:28:48Z

+A copy of $n$ bytes is therefore laid out as $floor(n \/ 8)$ eight-byte rows, followed by $n mod 8$ one-byte rows, followed by one terminal row.
+
+Because a row is the unit in which this chip charges for a copy, an unbounded `count` would let a single guest instruction append an unbounded number of rows to the trace.
+@dma:c:bound therefore proves $#`count` < 257$ on the first row of every sequence, which caps a sequence at $39$ rows --- attained at $n = 255$, not at $n = 256$, since a byte short of the bound trades one eight-byte row for seven one-byte rows.


Why limit the chip to copying 256 bytes at a time? We have the IS_HALF and IS_B20 range checks that can assert count < 65536 or even count < 1048576 at a smaller cost than calling the LT chip.

nicole-graus added 2 commits August 11, 2026 16:28

Add DMA memcpy accelerator to the spec

4a39c38

Correct the padding, chunk-width and zero-length claims in the DMA ch…

1dd720b

…apter

nicole-graus changed the base branch from main to spec/main August 11, 2026 20:04

nicole-graus added 2 commits August 12, 2026 10:42

Match ADDNW to the implementation and correct the DMA chapter's termi…

dc0d71d

…nation, end-detection and row-count arguments

Say that the padding row's low-limb carry permits rather than forces …

6a16bfc

…the unit address increments

erik-3milabs requested changes Aug 19, 2026

View reviewed changes

jotabulacios added 2 commits August 27, 2026 17:20

Cite the accelerated-memory-operations standard

3b9e775

Say where a copy's cost actually lives

d5c13e3

erik-3milabs reviewed Aug 28, 2026

View reviewed changes

		The #dma chip copies a range of bytes from one location in memory to another, that is, it performs a `memcpy`.
		#footnote([Linux man-page on `memcpy`; man7.org. #link("https://man7.org/linux/man-pages/man3/memcpy.3.html")[[src]]])

	- `A2` contains `count`.
	- `A2` contains `count`; the number of bytes to copy.

Uh oh!

Conversation

nicole-graus commented Aug 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Uh oh!

erik-3milabs commented Aug 19, 2026

Uh oh!

erik-3milabs left a comment

Choose a reason for hiding this comment

Uh oh!

erik-3milabs left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

nicole-graus commented Aug 11, 2026 •

edited

Loading