Farhan Mohamed Ali wrote:
On Sun, August 19, 2007 11:20 am, Timothy Normand Miller said:
On 8/19/07, Mark <[EMAIL PROTECTED]> 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.
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
