tapasco issueshttps://git.esa.informatik.tu-darmstadt.de/tapasco/tapasco/-/issues2019-07-09T11:03:05Zhttps://git.esa.informatik.tu-darmstadt.de/tapasco/tapasco/-/issues/107[VC709] Seperate addresses of different memory regions2019-07-09T11:03:05ZJaco Hofmann[VC709] Seperate addresses of different memory regionsCurrently TPC has different devices at the same address depending on the viewpoint. For example the TPC configuration registers start at 0x0 which is visible from the host. The on-board DDR memory is also located at 0x0 but only visible ...Currently TPC has different devices at the same address depending on the viewpoint. For example the TPC configuration registers start at 0x0 which is visible from the host. The on-board DDR memory is also located at 0x0 but only visible by the DMA engine and the PEs. It might be advisable to split these memory regions. A new address map could look like
| Address | Device |
| --- | --- |
| 0x0001000000000000 | MIG |
| 0x0002000000000000 | Configuration |
| 0x0003000000000000 | PEs |
etc. Accordingly Configuration and PEs would be separated into different BARs.https://git.esa.informatik.tu-darmstadt.de/tapasco/tapasco/-/issues/127[ZCU102] Evaluate is very slow2019-10-16T13:46:04ZJaco Hofmann[ZCU102] Evaluate is very slowWhen running evaluate on a small core (~6000 LUTs) the process takes about 3 to 4 minutes for the 7-Series devices. When run on the ZCU102 Zynq Ultrascale+ device the same process requires over an hour.
For example Phase 3 Initial Routi...When running evaluate on a small core (~6000 LUTs) the process takes about 3 to 4 minutes for the 7-Series devices. When run on the ZCU102 Zynq Ultrascale+ device the same process requires over an hour.
For example Phase 3 Initial Routing requires more than 40 Minutes instead of about a minute for the other platforms.
Testing was done with Vivado 2016.4.https://git.esa.informatik.tu-darmstadt.de/tapasco/tapasco/-/issues/33Add "keep all runs" to `DesignSpaceExplorationJob`2019-01-22T12:27:35ZJens KorinthAdd "keep all runs" to `DesignSpaceExplorationJob`Might be useful for debugging.Might be useful for debugging.https://git.esa.informatik.tu-darmstadt.de/tapasco/tapasco/-/issues/166Add PE to interrupt mapping in Status Core2019-01-22T16:27:20ZJaco HofmannAdd PE to interrupt mapping in Status CoreInterrupts are currently mapped iterative to the corresponding interrupt line. To increase flexibility the status core can store the mapping used.
Advantages are flexible mappings that enable the use of more than one interrupt per PE.Interrupts are currently mapped iterative to the corresponding interrupt line. To increase flexibility the status core can store the mapping used.
Advantages are flexible mappings that enable the use of more than one interrupt per PE.https://git.esa.informatik.tu-darmstadt.de/tapasco/tapasco/-/issues/154Allow direct view of the device memory on PCIe2019-01-22T16:15:25ZJaco HofmannAllow direct view of the device memory on PCIeThis can be implemented by using a sliding window and a second BAR. The Xilinx Core does not support this feature directly, though. Will use a little Bluespec Module that has one configuration register for the address offset which forwar...This can be implemented by using a sliding window and a second BAR. The Xilinx Core does not support this feature directly, though. Will use a little Bluespec Module that has one configuration register for the address offset which forwards the requests accordingly.Jaco HofmannJaco Hofmannhttps://git.esa.informatik.tu-darmstadt.de/tapasco/tapasco/-/issues/161Allow PE Masters to have any valid AXI Data Width2019-01-22T16:23:47ZJaco HofmannAllow PE Masters to have any valid AXI Data WidthThe data width of PE masters is currently limited to either 32 or 64 bit. Considering that most platforms outside of Zynq have much broader memory controllers it is beneficial to support all valid AXI Data Widths up to 1024 bits. This mi...The data width of PE masters is currently limited to either 32 or 64 bit. Considering that most platforms outside of Zynq have much broader memory controllers it is beneficial to support all valid AXI Data Widths up to 1024 bits. This might also be relevant for Zynq platforms if the designer of a PE wants to keep their logic simple and rely on data width converters to interface with the memories correctly.Jens KorinthJens Korinthhttps://git.esa.informatik.tu-darmstadt.de/tapasco/tapasco/-/issues/37Architecture per ThreadUnit2017-05-10T10:56:13ZJens KorinthArchitecture per ThreadUnitExtend TPC to use one Architecture per ThreadUnit; allows to combine different Architectures in one bitstream.Extend TPC to use one Architecture per ThreadUnit; allows to combine different Architectures in one bitstream.https://git.esa.informatik.tu-darmstadt.de/tapasco/tapasco/-/issues/28Asynchronous Memory Transfers2019-01-15T16:51:39ZJens KorinthAsynchronous Memory TransfersSimilar to asynchronous job launches: Check if asynchronous memory transfers could be useful. I guess probably not so much, because we need to wait for the transfers to finish, before we can launch the job in anycase - worst/ideal case w...Similar to asynchronous job launches: Check if asynchronous memory transfers could be useful. I guess probably not so much, because we need to wait for the transfers to finish, before we can launch the job in anycase - worst/ideal case would be that the job starts immediately and data must be available. It would be possible to add mem barriers based on the job struct, but I do not think this would be worth the effort.https://git.esa.informatik.tu-darmstadt.de/tapasco/tapasco/-/issues/84Automate installation2017-06-01T12:20:38ZJens KorinthAutomate installationPlatform requires some additional bring-up, e.g., customization and installation of udev rules. Should have a script that automates the process and can be run once as `sudo`.Platform requires some additional bring-up, e.g., customization and installation of udev rules. Should have a script that automates the process and can be run once as `sudo`.https://git.esa.informatik.tu-darmstadt.de/tapasco/tapasco/-/issues/165AXI Interconnect does not handle AXI4 -> AXI4 Lite properly for small transfers2020-03-18T17:12:05ZJaco HofmannAXI Interconnect does not handle AXI4 -> AXI4 Lite properly for small transfersIt seems like the AXI interconnect does not handle protocol conversion from AXI4 to AXI4-Lite properly and ignores the strb signal on reads. Accordingly, whenever a request comes e.g. through PCIe that is larger than the AXI4-Lite slave ...It seems like the AXI interconnect does not handle protocol conversion from AXI4 to AXI4-Lite properly and ignores the strb signal on reads. Accordingly, whenever a request comes e.g. through PCIe that is larger than the AXI4-Lite slave data width it will result in superfluous transactions. That's not a big deal for writes as the strb signal is set properly. However, for reads there is no such signal in AXI4-Lite and if the read has some effect on the state of the device it will result in hard to debug problems. This is known to Xilinx but seems to be wont-fix: https://forums.xilinx.com/t5/Embedded-Development-Tools/AXI4-gt-AXI-Lite-wstrb-behavior/td-p/645535https://git.esa.informatik.tu-darmstadt.de/tapasco/tapasco/-/issues/93BlueDMA support in ZC7062019-06-26T06:28:06ZJens KorinthBlueDMA support in ZC706ZC706 could benefit from an DMA engine feature, which allows to use the on-board DDR banks. Port BlueDMA to Zynq and implement a Platform `Feature` for it.ZC706 could benefit from an DMA engine feature, which allows to use the on-board DDR banks. Port BlueDMA to Zynq and implement a Platform `Feature` for it.https://git.esa.informatik.tu-darmstadt.de/tapasco/tapasco/-/issues/83Boot: Replace Xilinx Root FS2019-01-22T15:57:40ZJens KorinthBoot: Replace Xilinx Root FSThe rootfs is currently repurposed from the official PyNQ image (publicly available). This has been convenient, but in the long term it would be preferable to build a custom rootfs from scratch with less baggage. Replace it with an Ubunt...The rootfs is currently repurposed from the official PyNQ image (publicly available). This has been convenient, but in the long term it would be preferable to build a custom rootfs from scratch with less baggage. Replace it with an Ubuntu rootfs, or buildroot.https://git.esa.informatik.tu-darmstadt.de/tapasco/tapasco/-/issues/19Cleanup: Kernels, Examples2018-07-01T15:08:25ZJens KorinthCleanup: Kernels, Examples* [x] remove broken kernels
* [x] check that all kernels work in HLS
* [ ] check that all kernels have example programs
* [ ] check that example programs *actually work*
* [x] move through all directories, sift files* [x] remove broken kernels
* [x] check that all kernels work in HLS
* [ ] check that all kernels have example programs
* [ ] check that example programs *actually work*
* [x] move through all directories, sift files2018.2https://git.esa.informatik.tu-darmstadt.de/tapasco/tapasco/-/issues/174Compose fails after HLS runs2019-01-22T16:31:55ZJaco HofmannCompose fails after HLS runsSometimes a compose job fails after successful HLS runs with the following error:
```bash
[16:22:41 <pool-1-thread-2: ImportTask> INFO] Import of 'arrayinit_axi4mm.zip' with target axi4mm@vc709
[16:22:41 <pool-1-thread-2: Import$> INFO]...Sometimes a compose job fails after successful HLS runs with the following error:
```bash
[16:22:41 <pool-1-thread-2: ImportTask> INFO] Import of 'arrayinit_axi4mm.zip' with target axi4mm@vc709
[16:22:41 <pool-1-thread-2: Import$> INFO] SynthesisReport for arrayinit not found, starting evaluation ...
[16:22:41 <pool-1-thread-2: EvaluateIP$> INFO] starting evaluation of /home/wimi/jah/projects/tapasco/tapasco_2018.2/core/arrayinit/axi4mm/vc709/ipcore/arrayinit_axi4mm.zip for xc7vx690tffg1761-2@1000,000 MHz, output in /tmp/372075065893313964/evaluate.log
[16:30:38 <pool-1-thread-2: EvaluateIP$> INFO] evaluation of /home/wimi/jah/projects/tapasco/tapasco_2018.2/core/arrayinit/axi4mm/vc709/ipcore/arrayinit_axi4mm.zip for xc7vx690tffg1761-2@1000,000 MHz finished successfully, report in /home/wimi/jah/projects/tapasco/tapasco_2018.2/core/arrayinit/axi4mm/vc709/ipcore/arrayinit_export.xml
[16:30:38 <pool-1-thread-3: VivadoHighLevelSynthesis$> INFO] starting run 'arraysum' for axi4mm@vc709: output in /home/wimi/jah/projects/tapasco/tapasco_2018.2/core/arraysum/axi4mm/vc709/hls/axi4mm.log
[16:31:16 <pool-1-thread-3: VivadoHighLevelSynthesis$> INFO] Vivado HLS finished successfully for 'arraysum' for axi4mm@vc709
[16:31:16 <main: HighLevelSynthesis$> INFO] all HLS tasks have finished.
[16:31:16 <main: HighLevelSynthesis$> WARN] executed HLS with co-sim for [Kernel @/home/wimi/jah/projects/tapasco/tapasco_2018.2/kernel/arraysum/kernel.json]
Name = arraysum
TopFunction = arraysum
Version = 1.0
Files = /home/wimi/jah/projects/tapasco/tapasco_2018.2/kernel/arraysum/arraysum.c
TestbenchFiles = /home/wimi/jah/projects/tapasco/tapasco_2018.2/kernel/arraysum/arraysum-tb.c
CompilerFlags =
TestbenchCompilerFlags =
Args = arr by reference
OtherDirectives = None, but no co-simulation report was found
[16:31:16 <pool-1-thread-2: ImportTask> INFO] Import of 'arraysum_axi4mm.zip' with target axi4mm@vc709
[16:31:16 <pool-1-thread-2: Import$> INFO] SynthesisReport for arraysum not found, starting evaluation ...
[16:31:16 <pool-1-thread-2: EvaluateIP$> INFO] starting evaluation of /home/wimi/jah/projects/tapasco/tapasco_2018.2/core/arraysum/axi4mm/vc709/ipcore/arraysum_axi4mm.zip for xc7vx690tffg1761-2@1000,000 MHz, output in /tmp/9791558545089762559/evaluate.log
[16:39:08 <pool-1-thread-2: EvaluateIP$> INFO] evaluation of /home/wimi/jah/projects/tapasco/tapasco_2018.2/core/arraysum/axi4mm/vc709/ipcore/arraysum_axi4mm.zip for xc7vx690tffg1761-2@1000,000 MHz finished successfully, report in /home/wimi/jah/projects/tapasco/tapasco_2018.2/core/arraysum/axi4mm/vc709/ipcore/arraysum_export.xml
[16:39:08 <main: Compose$> INFO] all HLS tasks finished successfully, beginning compose run...
[16:39:08 <pool-1-thread-4: ComposeTask> ERROR] java.lang.Exception: could not find all required cores for target axi4mm@vc709, missing: arrayinit, arraysum
```Lukas SommerLukas Sommerhttps://git.esa.informatik.tu-darmstadt.de/tapasco/tapasco/-/issues/98Core Import: Add Synthesis and PnR parameters2019-01-22T16:00:31ZJens KorinthCore Import: Add Synthesis and PnR parametersIt would be useful to be able to control the parameters of synthesis and implementation directly from TaPaSCo. Maybe we should define modes, e.g.,
* **fastest** - lowest effort, minimal runtime
* **fast** - slightly slower, but stil...It would be useful to be able to control the parameters of synthesis and implementation directly from TaPaSCo. Maybe we should define modes, e.g.,
* **fastest** - lowest effort, minimal runtime
* **fast** - slightly slower, but still short runtime
* **normal** - default options
* **optimal** - slower, get as close to _real_ values as possible
* **aggressive_performance** - maximal optimization to performance
* **aggressive_area** - maximal optimization areahttps://git.esa.informatik.tu-darmstadt.de/tapasco/tapasco/-/issues/64DSE: Abort runs after PlacerErrors2019-01-22T15:54:09ZJens KorinthDSE: Abort runs after PlacerErrorsWhen a run results in a `PlacerError` it is extremely unlikely that any run with the same (or a larger) `Composition` will succeed. Runs are already pruned after the batch finishes, but it could be useful to be even more aggressive and a...When a run results in a `PlacerError` it is extremely unlikely that any run with the same (or a larger) `Composition` will succeed. Runs are already pruned after the batch finishes, but it could be useful to be even more aggressive and abort runs in the current batch, if they would be pruned. This could speed up batches and increase convergence speed.https://git.esa.informatik.tu-darmstadt.de/tapasco/tapasco/-/issues/124Evaluate 64 bit for platform_addr_t2020-04-03T17:49:05ZJaco HofmannEvaluate 64 bit for platform_addr_tAll platforms except for legacy Zynq, such as the PCIe based systems or MPSoC, use larger than 32 bit addresses. While we currently get by with smaller addresses this might change in the future and we should consider a move to 64 bit add...All platforms except for legacy Zynq, such as the PCIe based systems or MPSoC, use larger than 32 bit addresses. While we currently get by with smaller addresses this might change in the future and we should consider a move to 64 bit addresses.
I currently don't see any problem just changing the address width. The Zynq platform should continue to work with the required casts and all other platforms currently cast to 64 bit addresses anyway.https://git.esa.informatik.tu-darmstadt.de/tapasco/tapasco/-/issues/18Example code: Remove globals2017-12-28T14:41:22ZJens KorinthExample code: Remove globalsTPC Examples contain global TPC objects, which inspires bad code (see EVO use cases). Remove and introduce proper handling.TPC Examples contain global TPC objects, which inspires bad code (see EVO use cases). Remove and introduce proper handling.Jens KorinthJens Korinthhttps://git.esa.informatik.tu-darmstadt.de/tapasco/tapasco/-/issues/129Fallback option of requested amount of MSI-X interrupts is not available2019-10-23T11:56:06ZJaco HofmannFallback option of requested amount of MSI-X interrupts is not availableThe driver currently simply fails if the OS is not able/willing to provide the requested number of interrupts.
There should be a fall back option that gets enabled automatically if the requested amount of interrupts can not be provided.The driver currently simply fails if the OS is not able/willing to provide the requested number of interrupts.
There should be a fall back option that gets enabled automatically if the requested amount of interrupts can not be provided.Jaco HofmannJaco Hofmannhttps://git.esa.informatik.tu-darmstadt.de/tapasco/tapasco/-/issues/40Feature: BRAM2019-01-22T15:51:13ZJens KorinthFeature: BRAMImplement a `Feature` to generate a chunk of BRAM and map it into address space for small allocations. Parameters: size + offsetImplement a `Feature` to generate a chunk of BRAM and map it into address space for small allocations. Parameters: size + offset