- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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).
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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...- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 ?- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Anyone tried the new "host channels" feature?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page