Re: [openrisc] Multiplier oddities...

["Damjan Lampret" <lampret@opencores.org>]

Christian,

could be that amult takes one clock cycle and it works properly because
generic takes two clock cycles (so amult with one
clock cycle works properly because multiplication in or1200 takes three
clock cycles). I was thinking for a while to change the amount of clock
cycles multiplication takes but never got to the point to actually do this.
Maybe now it will be a good time to do it.

regards,
Damjan

----- Original Message -----
From: Christian Melki <christian.melki@axis.com>
To: <openrisc@opencores.org>
Sent: Monday, March 31, 2003 1:48 AM
Subject: [openrisc] Multiplier oddities...


> Hello ppl,
>
> I have a few more questions about the multiplier in the OR1200.
> The gmultp2 and the amultp2 are instansiated in the same manner
> in the or1200.. yet when we rip the multiplier out of the design to test
> it separately in synthesis and simulation we get different results from
> the gmult and the amult. Most notably, a multiplication should take
> 2 cycles to complete, right? This is what we have learned from the
> gmultp2 at least. Yet it seems like the amult completes a multiplication
> in 1 cycle in simulation and the gmult completes in 2 cycles. How can this
> be? There is no logic around the multiplier or clock-division that makes
> such a thing work.. What am I missing here? To my knowledge the two
> designs should behave in the same way? We do have some other oddities with
> the asic multiplier but that has probably more to do with simulation
> technical details.. sometimes it seems like results come dilutedly out of
> order from the mutiplier.. lite a simulation with 2*(b=b+1 each cycle) = P
> could yield a sequence with 2 4 4 2 6 8 8 6 etc.. something like that.
> But im sure thats an error with the simulation and not the design.
> These oddities do not occur with the generic multiplier.
> Anyway, my main query is why it seems like the amult is a 1-cycle design
> and i cannot see anything that should take care of this?
>
> regards,
> Christian
>
> --
> To unsubscribe from openrisc mailing list please visit
http://www.opencores.org/mailinglists.shtml
>

--
To unsubscribe from openrisc mailing list please visit http://www.opencores.org/mailinglists.shtml