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 not read and understood your code properly yet. I'll look at this
and see if it can be combined. I think one of the problems could be
signed number support, but we'll see. The carry chain is a problem,
although i think it could be the IO buffers messing timing estimates too.
However this is not necessarily a bad thing, as it was pointed out that
once other logic comes into the picture, things may slow down.
> 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.
Thank you for your comments, i will look into it. I've just trying to
optimize for what the synthesizer likes best, so it doesn't always look
as nice or as intuitive as i would like either.
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
