ReconOS HLS

[Sebastian Meisner]

Hello Group, Hello Christoph!

Prof. Platzner assigned me the task of lifting the HLS implementation of
ReconOS into a new main version. This version will then be the official
current version on the website and code repo with up-to-date documentation and
it will be used in internal research projects and external projects with
industrial partners.

The current state seems to be (please correct me if you disagree):
https://github.com/ReconOS/reconos/ is the official github repository for
ReconOS. It has 5 branches:

v3.0_dev - the old version 3.0: ML605 boards and MicroBlaze CPU, ISE tools
shadowing - my own development branch, still based on version 3.0, ISE tools
master - current 3.1 version of ReconOS, compatible with ML605 and
zedboard, ISE tools
develop - HLS version, compatible with ML605 and zedboard, Vivado HLS tools
develop_ic - like before, but with direct communications between hw-threads


http://www.reconos.de/gettingstarted/tutorial/ is the official homepage. Its
"Getting Started" describes version 3.1


I suggest to give Reconos HLS the version number 4.0. A major version of 4
seems to be justified, because we use a complete different toolset. It is also
easier for new users: Vivado tools: Version 4 and up, old tools: version 3.

I suggest to first restructure the branches in the following way and then
update the website:

Old New Comment
v3.0_dev v3.0
shadowing v3.0_shadowing
master v3.1
develop v4.0 - New default branch
develop_ic v4.0_ic

This should make it very clear to the user which version they are getting. And
when checking out the code from the repo, they get the newest version by
default. I looked it up, this should be possible with git and github.

@Christoph: Is there a chanche to merge the develop_ic into the develop
branch? Or are the extensions to massive/complicated?

@Christoph: You got another mail from me!

I'm looking forward to any comment!

Kind regards,
Sebastian Meisner

--
Sebastian Meisner - Research Associate
Computer Engineering Group - www.upb.de/cs/ag-platzner
Paderborn University, Germany
Room: O3.128 Phone: +49 5251 60-4347

[Christian Plessl]

Hi Sebastian and others

I’m thrilled to hear that ReconOS development will continue. HLS support will surely be very attractive for users because it drastically simplifies the creation of HW threads.

I think the plan you are proposing makes sense.

What needs to be clarified though is what design tools and device families will be support. To my understanding Christoph’s HLS branch uses the HLS features of Vivado HLS but still relies on ISE for implementation instead of Vivado Design Suite.

Since ISE has reached the end of life and the Vivado Design Suite is the way going forward for Virtex 7 any beyond, I think the switch to Vivado Design Suite is inevitable in the long run. This redesign might be the right point in time to break with the past and support only Vivado and Virtex 7 and beyond.

Another area that requires consideration is the ReconOS-specific tooling. To my understanding, ReconOS is currently instantiated with a set of Python scripts dubbed as ReconOS Development Kit (RDK). The native way of scripting and extending Vivado is by means of TCL scripts. I also remember that Xilinx announced that TCL-based extensions to Vivado can be easily distributed and installed. Hence, I suggest to consider whether RDK could be ported to a Vivado TCL extension as well, to make it compatible with other extensions and simplify the installation process. Partial reconfiguration can also be controlled with TCL, so there may be additional synergies that are more difficult to exploit with Pyhton scripts running outside of Vivado.


Cheers
Christian

> --
> You received this message because you are subscribed to the Google Groups "ReconOS" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to reconos+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

--
Prof. Dr. Christian Plessl - Paderborn University, Germany, +49-5251-605399
High-Performance IT Systems group - http://homepages.uni-paderborn.de/plessl
Paderborn Center for Parallel Computing - http://pc2.uni-paderborn.de

[Christoph Rüthing]

Hi together,

I would agree with Christian, that the HLS support is very interesting for especially new users and might give ReconOS a good selling point. Furthermore, it is correct, that the all versions of ReconOS currently use the deprecated ISE toolchain. Therefore, lifting everything to the new Vivado tools would be a major progress. This includes converting the IP-Cores and, as said, adapting the toolchain. While I personally do not like TCL very much, it is the de-factor standard for Vivado and we should take a look into it, if it suffice our needs. A smooth integration into the Vivado tools would be great, but I'm not sure to what extend we can use it to generate our custom IP-Cores with varying number of ports, ... I simply do not know enough about the new Vivado tools right now to give any estimate. We should give it a try!

Regarding the documentation, there is also a develop branch for the Homepage-Repository in Github, which also includes an updated version of the Getting-Started tutorial using the RDK and a simplified process for building Linux and U-Boot. Of course, we would need to update the entire homepage and should also include some ready-to-run examples, users can simply copy onto its SD-Card. Maybe we can think of some interesting demonstrations here.

The develop_ic branch is, currently, most up-to-date, since it is the branch I worked on for my Master's Thesis, The interconnect developed there might be also integrated as an option into the master branch 4.0 then. So the user has still the option if he wants to use the regular communication via the processor or the new interconnect. However, the develop_ic branch lacks some features of the develop branch, like interrupting threads.

Yours,
Christoph

[Sebastian Meisner]

Hello Everyone!

Thanks Christian and Christoph for clarifying that the toolchain is still
based on ISE.

Lifting everything to Vivado would then be the first thing to do. I'm
currently introducing myself to Vivado and TCL. So far i'm quite optimistic,
since TCL is a general purpose language, so quite powerful, and every action
in Vivado corresponds to a command in TCL. Vivado even displays every TCL
command called in the TCL console, so we should easily get to know what and
how to call.

When everything is ready, we might even publish ReconOS in the Xilinx Tcl
Store. As there are only 19 Projects available at the moment, ReconOS would
have a very prominent position there. :-)

I'll continue my work with exploring Vivado and how to integrate the ReconOS
HLS version into it.

Yours,
Sebastian

[Enno Lübbers]

Hi .*,

I, too, am delighted to hear plans being made for continuing ReconOS development. In the (ancient) past, there were already thoughts towards designing an HLS front-end to ReconOS. Are you thinking of enabling people to write hardware threads using HLS, or do you want to generate even the ReconOS infrastructure itself using HLS?

If there are plans to support different front-ends or even different targets (back-ends?) within ReconOS, I would strongly recommend to support them all in a common source tree, instead of having different branches support different targets or feature sets. As long as these are sharing code or even only common concepts, maintenance will be a nightmare if changes have to be ported between branches (even with git). Also, this would avoid having to steer users towards different releases for their needs.

Integrating ReconOS into Vivado sure would make the experience more streamlined. I, personally, would also very much welcome if this were more of a choice, rather than a strict requirement, since it might impede portability to other FPGA vendors (brownie points if you can guess what I mean by „other“ :)). Possibilities would be an architecture that allows the user-facing APIs and tools to interface with an interchangeable back-end talking to specific vendor tools. I’d be happy to consult on any architecture discussions you want to share on that.

Excited to see the discussion unfold!

Kind regards
- Enno

[Christoph Rüthing]

Hi together,

exciting to also here something from the father of ReconOS ;)

Regarding the HLS support we already have developed a way to implement hardware threads using HLS, i.e. both the sequential OSFSM, as well as the processing part. Furthermore, for the new hardware resources connected to the hardware threads via the custom interconnect, we also used HLS to generate some of them.

I would agree that we should definetly not try to maintain different branches, but that is not the intentiony. We really want to remove the current development branches and only have the single master branch. However, since we had some major changes in the past, we just leave the older version in the v3.0 branch to not break old implementations completely.

I also thougt about the toolchain and had quick look into the Vivado TCL. I think it might be possible to integrate everything using TCL but I'm also not sure if we might get issues there because of tool limitations. In the past we already needed to circumvent limitations in the ISE tools, which was rather unpleasent. Furthermore, as you said, we would be somehow limited to the Vivado Tools and Xilinx FPGAs and could not support other FPGA vendor(s). The idea when introducing the RDK was to have a ReconOS toolchain which does not depend on any vendor's tools and only generates the necessary files based on the target to use. Maybe this still a good approach, although a neat integration into the Vivado world might be attractive.

To keep the discussion running, I will try to simply list some aspects we might want to think of:

- Since we have a heavily configurable system (different number of hardware threads, ...) we need to dynamically generate the VHDL code (different number of ports, ...) and, as I think, cannot stay with VHDL's generate and generic constructs.

- The current RDK not only generates VHDL but also automatically generates library code for easy access and initialization of resources, as well as convenience methods for creating hardware threads. I'm not sure if we can do this using Vivado TCL.

- Of course we should think of different FPGA vendors and if we want support them.

- We should keep everything as simple as possible, i.e. if someone wants to use ReconOS we might not want to burden him to learn corner features of Vivado or other tools.

- We should also think of simulating hardware threads in a convenient way. I also started with this in the RDK to automatically generate test benches and provide a simulation implementation of functions like mbox_get ...

Yours,
Christoph

[Sebastian Meisner]

Hi @ all!

About the Vivado integration I'm currently working on:
One can call Vivado on the command-line to execute TCL scripts in the Vivado
environment: vivado -mode batch -source your_tcl_script.tcl -tclargs your_arg

I'm currently using this to automatically convert hardware designs from the
old pcore format into the new IP Integrator format. Now i can use the ReconOS
Hardware from inside Vivado like any other pre-shipped IP.

Right now i'm wiring up a ReconOS system inside Vivado and copy-pasting the
tcl commands into a script. That script will then be reused to extend any
Zynq-Design with ReconOS components. Integration into the RDK should be easy
from there on.

The RDK is already sturctured to support different implementation styles of
hardware threads (VHDL, HLS, ..) as well as different implementation tools,
where "ise" is only supported one currently. I'd suggest to add "vivado" as a
supported tool and steer the vivado tools using TCL scripts. That way we can
keep all of the current infrastructure, support for the "old" ReconOS v3 and
add support for other tools too, like "quartus".

@Christoph: Just being curious: Why do you prefer generated VHDL code over
generate statements and generics?


Kind regards,
Sebastian