[Open-graphics] Multipliers in oga1hq

[André Pouliot]

Farhan Mohamed Ali wrote:
> On Sun, August 19, 2007 11:20 am, Timothy Normand Miller said:
>   
>> On 8/19/07, Mark <mark at jarvin.net> wrote:
>>
>>     
>>> It doesn't appear as though Synplify for Lattice will do so.  I get
>>> the same timing with 1, 2, or 3 stages of registers after the
>>> multiplier and the number of registers in the map report goes up as
>>> expected.
>>>       
>> Ok.  That's fine.  We can manually pipeline things as necessary.
>>
>>     
>>> Is it possible Xilinx doesn't automatically pipeline multipliers in 
>>> general, only hard multipliers?  My guess is that they push those 
>>> registers during mapping, not during synthesis.
>>>       
>> Yeah.  Somehow, it must mark the registers as movable.  Obviously, it 
>> can't affect hard multipliers, but the soft ones can be manipulated.
>>
>> Separate from that, there's automatic register balancing.  This is done
>> during synthesis (that's when all the messages come out about them being
>> moved).  I find this a bit odd because until P&R is done, timings are
>> only gross estimates.  This didn't used to be the case when transistors
>> dominated circuit delays; but ever since wire delay became dominant,
>> physical synthesis has become progressively more necessary.
>>
>>     
An option is available in the xillinx tool in map : timing driven 
mapping. It take more time running but when working with a design who 
have timing problem it's usually a good help. It usually can get you the 
few missing nanosecond for the design to pass the timing constraint.
> I don't think wire delay is that much of a problem yet with circuits this
>  size if it was an ASIC, either full custom or using a P&R tool (though 
> custom is usually a LOT better than using a tool for circuits like ALUs). 
> It's easily possible to make ALUs that are much faster and smaller (for 
> the given speed) than using a FPGA, and they tend to be transistor delay 
> dominated because your logic blocks aren't static and if you do a decent 
> job (or your P&R tools aren't crappy) you won't have critical path wires 
> that are long. I've only done hand layouts for my circuits up till now, so I am naturally quite suspicious of these P&R tools :p
>
>   
Actually most of the delay present in the fpga or asic is caused by the 
wiring and not by the logic. FPGA is even worse than asic for wire delay 
because of the routing logic that add resistivity on the line. And with 
the dimension in the chip the fringe capacity of the line is already 
causing more problem than surface capacity.  The P&R tool do a good 
enough job for standard cells design, custom is the best but the time 
need to do it is prohibitive for large design. An actual approach is for 
some part of design to be made of standard cell and the timing critical 
part to be custom made. That help balance somewhat the time and cost 
requirement for the design.
>   
>> I would LOVE to be involved in a project that was developing a good Free
>> Software physical synthesis tool.  I have the background in AI, so I
>> could help develop the algorithms for P&R (on top of the other stuff I
>> know about chip design).
>>
>> I would be amazed if we couldn't get enough info out of Xilinx and 
>> Lattice to be able to target their devices.  Obviously, they'd hold some
>> stuff back, but it would come out eventually.  The ideal situation would
>> be if we could officially replace their commercial tools because ours
>> turned out to be better.  That would take years, but we could manage it.
>> Stephen Williams would probably be interested in this.
>>
>>     
> My university teaches some classes on P&R algorithms, according to a 
> friend of mine who took it the algos are not very complex. Don't know if 
> that is really true. But i think this is for ASICs, not FPGAs, maybe it's 
> harder for FPGAs because there are more restrictions.
>   
The algorithms for P&R are rather simple and basically the same in ASIC 
or FPGA, but in the asic world they are a lot more complex than what 
they taught in class. Actually the algorithms for fpga are more simple 
than asic because of the fixed position of the component and routing 
present in the FPGA.