Sorry about text not wrapping at 75 characters in the previous post! My
mail config is a little messed up.
On Sat, September 15, 2007 10:54 pm, Farhan Mohamed Ali said:
> On Mon, September 3, 2007 2:05 pm, Petter Urkedal said:
>> On 2007-09-02, Farhan Mohamed Ali wrote:
>>> Attached is the new version with a 16 bit mode switch (input 0
>>> detection removed). Inputs are assumed to be 16bit sign extended to
>>> 32bits. Output is 32bit sign extended to 64bits. This design
>>> achieves 128MHz. Also added in the copyright and license statement.
>>
>> I had a better read of your code. I assume that the carry chain of
>> the 32 bit add/subtract is the bottle-neck? That makes me wounder if
>> we could combine the radix-4 aspect of your design with full locality
>> aspect of my design, though I haven't tried to work it out. Anyway, it
>> makes it above 100 MHz, which is also good news considering that the
>> nanocontroller also includes a 32 bit one-stage adder.
>>
> I have read a little about bit-serial multipliers, but i'm still not
> perfectly clear about it. I'm having some trouble visualizing the
> dataflow. Do you have any good references for your design?
>
>
>> Allow me to pick on a few things in the code:
>>
>> Orig:
>>
>> 110 initial count = 0;
>>
>> If you need initialisation also in hardware, use
>>
>> always @(posedge clk or negedge reset_) begin if (!reset_) count <= 0;
>> else begin // The block where count is updated. end
>>
>> instead.
>>
>> Orig:
>>
>> 170 if (mode16reg & count==1) // or count-1 == 0
>>
>> I think it is more clear to use the boolean && here, rather than
>> exploiting the fact that comparisons return 0 or 1.
>>
>> Orig:
>>
>> 174 if (product_nxt[64]) 175 product[64:49] <=
>> 16'hFFFF; 176 else 177 product[64:49] <= 0;
>>
>> This can be simplified to
>>
>> 174 product[64:49] <= {16{product_nxt[64]}};
>>
>> The synthesiser should be able to figure it out, so never mind this if
>> you prefer your own version.
>>
>> Lastly, coding style; I'll not argue what's better or worse, but I
>> think it'll be nice if everything checked into Subversion repository is
>> roughly consistent. I don't think there is an official document, but
>> see e.g. rtl/pci/master_fsm.v.
>
> Attached is the updated version of my 32bit multiplier and a 16bit only
> version. I have included your suggestion about the hardware reset. Other
> than that there are some minor optimizations. The 32bit version still
> clocks >120MHz while the 16bit version clocks at >150MHz. I am quite
> surprised that the improvement is so small going from the 32bit to the
> 16bit version. I spent a lot of time messing with this, adjusting the
> mapping and P&R to be more aggressive, but it only gets me to around
> 170MHz. _______________________________________________ Open-graphics
> mailing list [email protected]
> http://lists.duskglow.com/mailman/listinfo/open-graphics List service
> provided by Duskglow Consulting, LLC (www.duskglow.com)
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
