EDAboard.com | EDAboard.de | EDAboard.co.uk | WTWH Media

engineered data path versus inferred data path

Ask a question - edaboard.com

elektroda.net NewsGroups Forum Index - FPGA - engineered data path versus inferred data path


Guest

Sat Apr 21, 2018 2:45 pm   



Seem to get better results when using inferred data paths?

E.g. letting the synthesis tools insert the multiplexers where they see fit gives better Fmax than laying out the datapath in complete detail.
Also don't need to remember and code all the control signals for the muxes.
Still code intermediate adders and such to keep the number of inferred carry chains down.

Comments?

Jim Brakefield

Mike Field
Guest

Thu Apr 26, 2018 11:45 am   



It depends if you structure your design to allow it to be mapped to the features of the underlying hardware.

If you do this well you can get optimal performance. If you do this poorly (e.g have a reset on an internal register that can't be reset) then you will be left scratching your head trying to work out why performance is poor.


Guest

Fri Apr 27, 2018 4:45 pm   



On Thursday, April 26, 2018 at 5:27:19 AM UTC-5, Mike Field wrote:
Quote:
It depends if you structure your design to allow it to be mapped to the features of the underlying hardware.

If you do this well you can get optimal performance. If you do this poorly (e.g have a reset on an internal register that can't be reset) then you will be left scratching your head trying to work out why performance is poor.


Am thinking there are two issues:
Mapping to FPGA resources, which is always an issue.
(and particular FPGA families differ on things such as resets)

And best Fmax, where the packer and router have the interconnect delay info.
My thinking is that the location and ordering of the mux inputs makes a significant difference. And, unless you are a Jan Gray type, the tools (ISE, Quartus, etc) can do a better job?
(for the uninitiated, take a look at some real world routing on an FPGA)

Jim Brakefield

Mike Field
Guest

Sat Apr 28, 2018 10:45 am   



I'll ask Jan what his magic is and let you know :-)

I feel it is usually better to work at the highest level of abstraction you can, but always being sympathic to the lower levels.

That way you have to dive into the lower levels less frequently to resolve what in retrospect were trivial issues.

Of course you have to dive to the low levels or read and understand lots and lots of documentation to get an appreciation of what is sympathic to the lower levels. Experience has to be earned!

Sometimes it is the smallest changes that can matter - using active high vs active low signallimg, or registering a 'clear accumulator' flag so the register can be absorbed into a DSP block. If you are aware of tham you can save a lot of time. You see what patterns do or don't work, and only use the ones that do

But of course, at the sharp end where absolute performance is needed in complex designs then carefully engineered datapaths may be needed. The tools are good, but are only tools.

Mike.

Mike Field
Guest

Sat Apr 28, 2018 8:45 pm   



On Saturday, 28 April 2018 03:03:47 UTC+12, jim.bra...@ieee.org wrote:
Quote:
On Thursday, April 26, 2018 at 5:27:19 AM UTC-5, Mike Field wrote:
It depends if you structure your design to allow it to be mapped to the features of the underlying hardware.

If you do this well you can get optimal performance. If you do this poorly (e.g have a reset on an internal register that can't be reset) then you will be left scratching your head trying to work out why performance is poor.

Am thinking there are two issues:
Mapping to FPGA resources, which is always an issue.
(and particular FPGA families differ on things such as resets)

And best Fmax, where the packer and router have the interconnect delay info.
My thinking is that the location and ordering of the mux inputs makes a significant difference. And, unless you are a Jan Gray type, the tools (ISE, Quartus, etc) can do a better job?
(for the uninitiated, take a look at some real world routing on an FPGA)

Jim Brakefield


A asked:

"For a new moderately complex design, should I go for an engineered or inferred data path? (a.k.a. Should I initially trust the tools or not?)"

Jan's reply was....

"IMO you should have the technology mapped solution in mind before you start coding -- then do a min effort bottom up implementation to emit that, whether inferred or structurally instantiated. http://www.fpgacpu.org/log/aug02.html#artSmile"

Pragmatic as always!


Guest

Tue May 01, 2018 4:45 am   



On Saturday, April 28, 2018 at 2:26:22 PM UTC-5, Mike Field wrote:
Quote:
On Saturday, 28 April 2018 03:03:47 UTC+12, jim.bra...@ieee.org wrote:
On Thursday, April 26, 2018 at 5:27:19 AM UTC-5, Mike Field wrote:
It depends if you structure your design to allow it to be mapped to the features of the underlying hardware.

If you do this well you can get optimal performance. If you do this poorly (e.g have a reset on an internal register that can't be reset) then you will be left scratching your head trying to work out why performance is poor.

Am thinking there are two issues:
Mapping to FPGA resources, which is always an issue.
(and particular FPGA families differ on things such as resets)

And best Fmax, where the packer and router have the interconnect delay info.
My thinking is that the location and ordering of the mux inputs makes a significant difference. And, unless you are a Jan Gray type, the tools (ISE, Quartus, etc) can do a better job?
(for the uninitiated, take a look at some real world routing on an FPGA)

Jim Brakefield

A asked:

"For a new moderately complex design, should I go for an engineered or inferred data path? (a.k.a. Should I initially trust the tools or not?)"

Jan's reply was....

"IMO you should have the technology mapped solution in mind before you start coding -- then do a min effort bottom up implementation to emit that, whether inferred or structurally instantiated. http://www.fpgacpu.org/log/aug02.html#artSmile"

Pragmatic as always!


Better info than expected. Although it's from almost 16 years ago.

Would be good to hear from the IP vendors who offer customizable CPUs:
RPMs will presumably work for the CPU core.
What about, say, NIOS or microBlaze with their many configuration options?

Jim Brakefield

elektroda.net NewsGroups Forum Index - FPGA - engineered data path versus inferred data path

Ask a question - edaboard.com

Arabic version Bulgarian version Catalan version Czech version Danish version German version Greek version English version Spanish version Finnish version French version Hindi version Croatian version Indonesian version Italian version Hebrew version Japanese version Korean version Lithuanian version Latvian version Dutch version Norwegian version Polish version Portuguese version Romanian version Russian version Slovak version Slovenian version Serbian version Swedish version Tagalog version Ukrainian version Vietnamese version Chinese version Turkish version
EDAboard.com map