Re: [openrisc] Multiplier oddities...

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

Christian,

there has been a lot of changes around multiplier about a year ago. I'll
have a look what is the current behavior of pipeline when it is processing
multiply instructions and groups of instructions with an occasional multiply
instruction (I know in some cases it might completely stop pipeline for 2
clock cycles).

Unrelated to this is the fact that amult is not run as part of regression
tests. So one thing I'll do is to also add amult to regressions. In last
year I don't know if anyone even used amult since the tools got very good
instantiating their own multipliers (using gmult).

regards,
Damjan

----- Original Message -----
From: "Christian Melki" <christian.melki@axis.com>
To: <openrisc@opencores.org>
Cc: <lampret@opencores.org>
Sent: Wednesday, April 02, 2003 12:57 AM
Subject: Re: [openrisc] Multiplier oddities...


Hello Damjan & ppl.

Hmm. This is probably because im a bit thickheaded.. :)
I still don't get where the logic takes care of the problem that
the two different multipliers are constructed.. I mean. If two
instructions are on their way. Say 1. MAC(x1,y1) 2. MSB(x2,y2)
Since the forwarding is done in three stages before it enters the
accumulator.. how can it be ensured that if a AMULT unit is active and
ready  in one cycle, forwards it to the next stage.. and enters the
accumulator  in the third.. wheras the operation itself enters the MAC
unit after 3 complete forwarding-steps.. ( enters in the fourth step )..
.. How can it be ensured that it isn't working on the MSB instruction with
the wrong mul_prod_r? I can't see this happening.. The only thing that
could hold the unit back is mac_stall_r which checks if there is any
mac-operation at all in any of the forwarding stages.. not which order.
But that wouldnt affect the unit anyway.
Hmm.. This is hard for me to explain. I have included an "conceptual"
overview over the mult_mac.v file without div-instructions.. It is
included as an postscriptfile ( 27k ). Please comment.

best regards,
christian

On Mon, 31 Mar 2003, Damjan Lampret wrote:

> 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