A
Allan Herriman
Guest
On Tue, 06 Oct 2015 23:02:27 -0400, rickman wrote:
[snip]
You seemed to have misinterpreted my earlier post in this thread in which
I had two implementations of *exactly* the same function that were giving
very different speed and area results after synthesis.
I think what you say (about the coding not mattering and the tools doing
a good job) is true for "small" functions.
Once you get past a certain level of complexity, the tools (at least the
Xilinx ones) seem to do a poor job if the function has been coded the
canonical way. Recoding as a tree of XORs can give better results.
This is a fault in the synthesiser and is independent of the speed vs
area optimisation setting.
Regards,
Allan
[snip]
Ok, I'm not at all familiar with GFs. I see now a bit of what you are
saying. But to be honest, I don't know the tools would have any trouble
with the example you give. The tools are pretty durn good at
optimizing... *but*... there are two things to optimize for, size and
performance. They are sometimes mutually exclusive, sometimes not. If
you ask the tool to give you the optimum size, I don't think you will do
better if you code it differently, while describing *exactly* the same
behavior.
You seemed to have misinterpreted my earlier post in this thread in which
I had two implementations of *exactly* the same function that were giving
very different speed and area results after synthesis.
I think what you say (about the coding not mattering and the tools doing
a good job) is true for "small" functions.
Once you get past a certain level of complexity, the tools (at least the
Xilinx ones) seem to do a poor job if the function has been coded the
canonical way. Recoding as a tree of XORs can give better results.
This is a fault in the synthesiser and is independent of the speed vs
area optimisation setting.
Regards,
Allan