Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Altera_Forum
Honored Contributor I
1,361 Views

Efficiency improvements after switching to 17.1 from 17.0

Just as an FYI: I noticed significant resource savings on the same code when switching to version 17,1 of the tool from version 17.0. I'm not sure if this is common for new releases of this tool but thought I should mention it. If you're getting tight on resources it may be worthwhile to install 17.1 alongside whatever version you're using and try it out. (Note: don't forget to use a BSP that supports 17.1).

0 Kudos
15 Replies
Altera_Forum
Honored Contributor I
67 Views

Are you talking about actual resource utilization after placement and routing, or resource estimation provided by the compiler? 

 

I am facing significant perfomance degradation (30%) and higher area utilization going from 16.1.2 to 17.0/17.1.
Altera_Forum
Honored Contributor I
67 Views

 

--- Quote Start ---  

Are you talking about actual resource utilization after placement and routing, or resource estimation provided by the compiler? 

 

I am facing significant perfomance degradation (30%) and higher area utilization going from 16.1.2 to 17.0/17.1. 

--- Quote End ---  

 

 

Good question; I was referring to the resource estimation provided by the compiler. When I get the time (it will take a few days) I'll do some full build comparisons with 17.0 and 17.1.  

 

I've typically been working under the assumption that Quartus will perform more advanced optimizations during synthesis. Admittedly I've only been periodically comparing resource estimate vs actual but it's been pretty consistent. I'd be curious to know if anyone has seen the opposite. 

 

I don't even attempt to build if my resource utilization is too high; so even if all they've done is improve the estimator tool that would be a worthwhile upgrade in my opinion.
Altera_Forum
Honored Contributor I
67 Views

In my case I have seen up to 50% overestimation on logic and memory, and v17.0/17.1 have gotten worse compared to v16.1.2. I would recommend not relying much on the estimated area utilization and go ahead with compilation either way if you have the resources to spare and only assume your kernel is not going to fit if the actual fitting fails.

Altera_Forum
Honored Contributor I
67 Views

I've seen the estimates usually as an overestimate depending on how the kernel is structured. In 16.1/17.0 I've had estimates ~110% and the actual build around 60% particularly for memory blocks. DSPs aren't as quite wide as a gap, but I've found them to not be all that reliable for estimates until a full build is made so I have something to scale it against.

Altera_Forum
Honored Contributor I
67 Views

Hi guys,  

A bit of topic but I need some help: 

I recently updated to 17.1 from 17.0, and now the configuration is using JTAG instead of PR via PCIe. 

Can't find documentation about this in the update, and "ACL_PCIE_USE_JTAG_PROGRAMMING=0" doesn't work. 

Anyone know what's going on? Configuration via JTAG is so much slower than PCIe...
Altera_Forum
Honored Contributor I
67 Views

 

--- Quote Start ---  

Hi guys,  

A bit of topic but I need some help: 

I recently updated to 17.1 from 17.0, and now the configuration is using JTAG instead of PR via PCIe. 

Can't find documentation about this in the update, and "ACL_PCIE_USE_JTAG_PROGRAMMING=0" doesn't work. 

Anyone know what's going on? Configuration via JTAG is so much slower than PCIe... 

--- Quote End ---  

 

 

Check the project folder that the OpenCL compiler creates and see if you have a "top.done" file in it or a "flat.done" file. There was another thread in the forum before that seemed to suggest that people are being defaulted to the flat flow in v17.0. If you compile with the flat flow, reconfiguration can only be done using JTAG.
Altera_Forum
Honored Contributor I
67 Views

 

--- Quote Start ---  

Check the project folder that the OpenCL compiler creates and see if you have a "top.done" file in it or a "flat.done" file. There was another thread in the forum before that seemed to suggest that people are being defaulted to the flat flow in v17.0. If you compile with the flat flow, reconfiguration can only be done using JTAG. 

--- Quote End ---  

 

Hi 

There is a "top.done", but no "flat.done". 

Would you know how to avoid this? Deleting it doesn't help. 

Thanks.
Altera_Forum
Honored Contributor I
67 Views

If you have a "top.done" then everything should be fine and configuration should happen through PCI-E. You are using Arria 10, right? What is your board?

Altera_Forum
Honored Contributor I
67 Views

 

--- Quote Start ---  

If you have a "top.done" then everything should be fine and configuration should happen through PCI-E. You are using Arria 10, right? What is your board? 

--- Quote End ---  

 

Arria 10 GX
Altera_Forum
Honored Contributor I
67 Views

Try "unset ACL_PCIE_USE_JTAG_PROGRAMMING" instead of "ACL_PCIE_USE_JTAG_PROGRAMMING=0". Also check your bashrc to make sure ACL_PCIE_USE_JTAG_PROGRAMMING is not being overridden. 

 

Note that when you switch from one version of Quartus to another and change your BSP alongside with it, the first time you try to run a kernel compiled by the new version, the programming will be done via JTAG since the static region of the new BSP is different from the previous one and hence, the static region will need to be updated. However, this should only happen once and every configuration after that should go through PCI-E.
Altera_Forum
Honored Contributor I
67 Views

I have same question about difference between 17.1 and 17.0 

When I emulating a kernel and get the event time, in 17.0 the time will be equal to system clock time like: 

event time: 95xxx ms 

sys time: 95xxx ms 

 

But in 17.1, it will be different, like: 

event time: 3xx ms 

sys time: 95xxx ms 

 

Is this because that event time in 17.1 only count simulated execution time ?
Altera_Forum
Honored Contributor I
67 Views

If you are experiencing that behavior on the exact same kernel, you should consider reporting it to Altera since it might be a bug. However, execution time or event time during simulation do not represent anything meaningful; i.e. lower emulation time on a kernel does not mean it will also be faster on the FPGA. Hence, you should avoid drawing any conclusions based on simulation time.

Altera_Forum
Honored Contributor I
67 Views

Anyone tried the new "host channels" feature?

Altera_Forum
Honored Contributor I
67 Views

 

--- Quote Start ---  

Anyone tried the new "host channels" feature? 

--- Quote End ---  

 

 

I'd like to, but it is only available in the BSP of Altera's reference board, while I use a different board. I don't think any other board supports it right now.
Altera_Forum
Honored Contributor I
67 Views

I believe that host channels are only used for supporting emulating io channels from fpga to fpga via Linux named pipes or files on the host. This way, emulating io channels and host channels are essentially the same thing (except named pipes is a Linux only feature). This is supported at least since 17.0 I believe and works well for emulating a multi fpga solution using io channels in my experience. 

 

The new thing that's been added in 17.1 is the "host pipes" which allow for communication between the host and kernel directly, outside of emulation. One of the boards I'm using has 17.1 bsp support from Nallatech which hopefully I can find some time to work on soon.
Reply