<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hellwig<div class=""><br class=""></div><div class="">Indeed, for signed integers Multiplier.v works correctly.<div class="">For unsigned the code is wrong.</div><div class="">Perhaps there are more elegant solutions but a quick fix would be as follows.<br class=""><div><br class=""></div><div>Change this line</div><div><pre style="word-wrap: break-word; white-space: pre-wrap;" class="">assign w1 = (S == 32) & u ? {P[63], P[63:32]} - {w0[31], w0} :
       {P[63], P[63:32]} + {w0[31], w0};</pre><div class="">to this</div><div class=""><pre style="word-wrap: break-word; white-space: pre-wrap;" class="">assign w1 = (S == 32) & u ? {P[63], P[63:32]} - {w0[31], w0} :
       u ? {P[63], P[63:32]} + {w0[31], w0} : {1’b0, P[63:32]} + {1b'0, w0};</pre><div class=""><br class=""></div></div></div><div>Jörg</div><div><br class=""><blockquote type="cite" class=""><div class="">Am 04.03.2018 um 10:13 schrieb Hellwig Geisse <<a href="mailto:hellwig.geisse@mni.thm.de" class="">hellwig.geisse@mni.thm.de</a>>:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hi all,<br class=""><br class="">I'm trying to understand the RISC5 implementation and<br class="">stumbled over a corner case in unsigned multiplication.<br class="">What exactly is "Multiplier.v" supposed to compute in<br class="">case u=1 in the instruction (i.e., u=0 in Multiplier.v,<br class="">because of ".u(~u)" in the instantiation of the module)?<br class=""><br class="">In NW's "The Design of a RISC Architecture and its<br class="">implementation with an FPGA" (revision 1.9.2015) I read<br class="">"..., and the MUL instruction with u set to 1 considers<br class="">the operands as unsigned numbers, yielding a 64-bit<br class="">unsigned product". So (1 << 31)*(1 << 31) should give<br class="">a result of (1 << 62). But when I feed the multiplier's<br class="">x and y inputs both with 0x80000000, the result is<br class="">0xC000000000000000 instead of 0x4000000000000000, at<br class="">least in my simulation of the module.<br class=""><br class="">Am I missing something?<br class=""><br class="">Hellwig<br class="">--<br class=""><a href="mailto:Oberon@lists.inf.ethz.ch" class="">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems<br class=""><a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" class="">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a><br class=""></div></div></blockquote></div><br class=""></div></div></body></html>