[Open-graphics] Synthesizing oga1hq

Mark mark at jarvin.net
Mon Aug 13 15:06:50 EDT 2007


Petter Urkedal wrote:
> If we want to do a compromise, we could instead implement 32x16->32
> multiply.  That is, two multipliers in the ALU stage, and an adder in
> the IO stage.  If again we incorporate the shifts, we are down to 4
> instructions for to compute a 32x32->32 product:
> 
> mul_32x32_from_32x16:
>         mul/h   r0, r1, r3	; r3 := r0 * r1[31:16]
>         mul/l   r0, r1, r2	; r2 := r0 * r1[15:0]
>         shift   r3, 16, r3
>         add     r2, r3, r2
> 
> Note that register forwarding does not work fully for the mul
> instruction in this case, since it's split over two stages.  There is a
> 1 cycle delay before we can use the result, which means this is the only
> way to order the instructions.
> 
> My guess is that the 16x16->32 multiplier with shifts on both the second
> operand and the result is much cheaper than the extra adder and
> multiplier of the 32x16->32 solution, and we save only one instruction
> by by going to 32x16->32.
> 
How about if the shift was implicit in mul/h?  That should be cheap in 
terms of hardware and it would decrease the cost of the soft 32x32 
multiply to three cycles -- wouldn't it? (Sorry -- I have yet to read up 
on your architecture in detail.)

You can do 32x32 multiplies at nearly 200 MHz on the XC3S4000 with the 
caveat that they must be fully pipelined (4 stages -- just add the extra 
stages to the output of the inferred multiplier and XST will retime them 
back in).  Can you afford to deepen the pipeline or stall on 32x32 
multiplications?

Which exact part is on the OGD1 (speed grade & package)?  (I may be 
totally lost, but you're using a Xilinx part, not the Lattice part on 
the svn schematic, right?)


More information about the Open-graphics mailing list