Fix/divu remainder larger than quotient

[KimiWu123]

Desc.

This PR is trying to integrate DivConfig introduced in #304 into divu opcode. However,DivConfig fails when divisor is zero.

Findings

assert_less_than should be None in this case since both of lhs: remainder and rhs: divisor are witnesses and range-checked.

ceno/ceno_zkvm/src/gadgets/div.rs

Lines 44 to 50 in 77a250c

	let r_lt = cb.less_than(
	|| "remainder < divisor",
	remainder.value(),
	divisor.value(),
	None,
	UINT_LIMBS,
	)?;

---

Update

In the first place, this PR is trying to fix a failure when divisor is zero. During fixing this issue, realized we don't really need DivConfig since there are not much duplicated code between SRL and DIVU. Therefore, we don't really need to "fix" this issue since it works well on SRL. But I need to add "remainder < divisor" constraints in DIVU.
I was trying to use DivConfig in this PR, but it made more complicated code. So, the current version is only to add remainder < divisor constraints in divu.

Changes

• Fixing under constraints in less_than
• Adding "remainder < divisor" constraint in divu
• Adding some tests for SRL and SLL

[zemse]

Is it better to merge the test cases?

When we do any change in the future, the cargo test console printing is good, it highlights the tests that fail and pass. This can be a good DX.

If we merge the tests in single one, the tests run serially until mock prover panics in one of them. But if we want just a single test for opcode for less verbosity while cargo test then ok.

[hero78119]

I vote +1 for the design, and think for now merge all of them in one place improve readibility, and we dont need to come up with function name for each small case. If we suffer one failed, we can easily targeting which is failed with small effort.

Later, we can have macro to rendering test cases, similar tricks we have in another project zkevm (sth like this https://github.com/privacy-scaling-explorations/zkevm-circuits/blob/main/integration-tests/tests/circuits.rs#L113-L128), so it looks like test are write in single place, but macro will help to expand to rust test implementation. With that, we can achieve both good readibility + rendering test individually.

[KimiWu123]

Is it better to merge the test cases?

When we do any change in the future, the cargo test console printing is good, it highlights the tests that fail and pass. This can be a good DX.

I completely understand your point. I’ve faced similar challenges when verifying tests, just as you mentioned. However, I find that this pattern helps me think about which types of tests might be missing. Having more tests is really important for me, so making the process easier is definitely helpful.

[hero78119]

LGTM
Thanks for fixing reported issue and refactor :)