06-02-2016 02:26 AM
I want to generate a simple project which is using c-callable library. In SDSOC2016.1, They have given a sample project files in FIR_LIB folder for the same. But I dont know how to use and where to start with these files(since my previous experience lies only on RTL coding and design). I was referring 3rd chapter in UG1146. But I am feeling there explanation is inadequate. If anybody can help me on this, It will be greatly appreciated.
Thanks In advance.
06-07-2016 05:08 AM
Users can create a "wrapper" around an IP so that it can be used in the SDSoC tool. However, there are a few things that the user may need to take care of. If the IP is parameterised, and the user wants to set these, then this is done via the params.xml file. To see a list of these, you can create a simple Vivado project, and add the IP to the block design and right click on the IP to see the configuration. Here, I have applied the config from the param.xml file for the fir_lib:
If you dont specify a param, then the default will be used.
In the fcnmap.xml we can set the interface(s). You also tell the SDSoC the expected latency, and the resources used on the interface.
Once this information is obtained, then the user can create the library, with the sdslib. This is pretty well described in the docs.
07-04-2016 09:08 PM
Hi, Thank you very much for your reply. Please help in the following queries too.
How can I create fncmap.xml and params.xml?, We have to manually create this or any tool for this?
I have one more doubt on control signals for the ip core. In user guide it is mentioning that we should use the following control signals. Where should I use this?
// 0x00 : Control signals
// bit 0 - ap_start (Read/Write/COH)
// bit 1 - ap_done (Read/COR)
// bit 2 - ap_idle (Read)
// bit 3 - ap_ready (Read)
// bit 7 - auto_restart (Read/Write)
// others - reserved
// (COR = Clear on Read, COH = Clear on Handshake)
Thanks in advance.
07-05-2016 09:05 AM
Unfortunately there is not yet a tools which helps you create these xml files yet. In the meantime, you can look at the <sdsoc_install>\samples\fir_lib\build directory to see the fcnmap and params sample files for the FIR lib example.
It may look confusing and arbitrary, but its really just mapping the function name <--to--> IP name, and the function argument <--to--> port name, etc.
As for the control signals, what that part of the UG1027 is saying is that if you write an RTL core with an AXI-Lite control interface, you need to match the VivadoHLS specification. SDSoC assumes that all cores come from VivadoHLS. So you need to make your core be controlled exactly like it would be if generated from VivadoHLS. For example, at offset 0x0 in the AXI-Lite slave interface must be the control register with the bits defined as you posted (for start, done, etc.).
07-06-2016 09:35 PM
Thanks for your reply. I have few more queries. Please
1)Where should I use these control signals?
2)I have a locally generated RTL core which is using axi stream interface, After IP core packing I could to generate library through SDSLib and using xml files. My target is to use this RTL ip core inside the SDSoc function call. So in this scenario what all things I should take care?. Should I consider ap_ctrl_hs bus registers or not? Please clarify this in detail.
Thanks in advance.
07-18-2016 08:24 AM
1. You will only use the control signals explicitly within your IP (e.g., as I/O to its internal state controller). The SDSoC runtime will use the control register to manage accelerator tasks (i.e., function calls to your IP) according to program function calls into the entry points you define for your C-callable library.
2. You will not target this IP within a hardware function call, but instead through a software function (or functions) that may call other hardware functions in conjunction with your library functions that target RTL IPs. The dataflow between calls to hardware functions within this software function (or functions) will define the system connectivity between different the hardware functions. Streaming data interfaces between hardware functions will typically lead to concurrent (pipelined) task execution, with hardware direct connections implemented using AXI4 streams. Sometimes you need to use #pragma SDS data access_pattern(A:SEQUENTIAL) on a hardware function argument as a hint to the system compiler that data is streaming.