01-19-2016 08:45 AM
I am trying to understand what is and what is not possible with SDSoC.
It seems that ANY direct control from C generated RTL of any FPGA PL I/O pin is not possible when using SDSoC only?
Is this correct?
If we have say a LED connected to some PL I/O and we would like to implement say PWM using SDSoC then this would not be possible using SDSoC alone?
I am amazed a bit that SDSoC is an envirnoment that is not capable to blink a LED! I mean it is not possible to blink a LED using RTL generated by SDSoC if the LED does not exist in the SDSoC platform already.
01-19-2016 09:03 AM - edited 01-19-2016 09:04 AM
You are correct. Without a bitsream that instantiates an IOB, one has no control over an IOB in the programmable logic. One can load a partial bitstream at any time, and then one could have access from the PS side to the PL side. You do have control of the PS side IO however.
An empty bitstream is just that: the PL has nothing in it at all (and all IO are tristate).
What is it you are trying to do? Why is it not possible to have a bitstream for the PL which may be extended/modified once everything has booted (through re-configuration, or even loading a complete new bitstream)?
01-19-2016 10:15 AM
You can create an RTL that implements say PWM, and designate it to be in PL, that would work.
So you can generate a bitstream with SDSoC, that includes the PWM for the LED, and load it as complete bitstream, but.. the as missing part you can not connect from the SDSoC generated hardware to real world IO unless that was already there in the platform definition.
Partial Reconfiguration is still not availanble, not with SDSoC, as Partial Reconfiguration needs special license, or do you imply that the 995 $ price includes support for partial bitstreams???
SDaccel includes PR, yes, but SDSoC? at 995$ ? I doubt but I hope I am mistaken and Xilinx is giving green for partial configuration at SDSoC flat fee of 995 USD.
01-19-2016 10:26 AM - edited 01-19-2016 10:30 AM
You can indeed interface to the outside world with SDSoC (including LEDs or any other peripheral on a Xilinx or custom board). There are various examples that do this, several of which send video data out the HDMI chip on the board (which is, of course, connected to the PL pins).
There are two distinct sides to SDSoC development:
1) The platform definition - This is going to be where you define what board/chip you're working with and the various interfaces both to the outside world and to the SDSoC environment (via specially tagged AXI/AXIS interfaces). This is where you would define your LED/PWM pins. This part is going to be done by a hardware guy.
2) Application development - Once your platform is defined/decided on, the application developers can go to work, targeting your newly created custom platform. This is pure C with maybe some HLS work, so it is targeting software guys.
Now, to tie 1 and 2 together where you wish to interface to the outside world from an application that's targeting your custom platform, you can define what are called 'C-callable libraries' which essentially expose a software API to the 'specially tagged interface' in your hardware to SDSoC so that the tool can hook up datamovers and accelerators directly to that interface.
I think the piece you're missing is UG1146. Specifically, I'd go through the pf_axis and zc702_led tutorials. They explain this in greater detail (and probably more clarity :) )
01-19-2016 11:34 AM