The ORCA project hereby announces its second Open Call for Extensions which focuses on the development of missing functionalities to extend the ORCA software and hardware platforms. In particular, this second call targets four topics:
- EXT1 – Partial reprogramming of FPGA on SDR at runtime
- EXT2 – Polar Codes for FPGA
- EXT3 – Interfaces for 5G and LTE interworking
- EXT4 – Dynamic runtime composition of mmWave transceiver chains consisting of processing functions that are split between FPGA and CPU
|Project full name||ORCA – Orchestration and Reconfiguration Control Architecture|
|Project grant agreement number||732174|
|Call title||Second ORCA Open Call for Extension|
Extended Wednesday, 13th June 2018, at 17:00 Brussels local time
|Feasibility and Relevance check deadline|
Extended Monday the 4th June 2018 by the end of the day
A technical feasibility and relevance check is required before submission. This feasibility and relevance check will be carried out by the ORCA members responsible for the facilities, radio hardware platforms, and software platforms involved.
It is essential that the proposing party gets in contact with the ORCA partner in charge of the testbed which are intended to be used for the proposed Extension, to discuss its feasibility and relevance within the ORCA federation and the related specific requirements. Each proposing party must therefore identify a possible Patron either by contacting an appropriate ORCA partner (see section 4 of the Open Call document) or through , in case support is required for selecting an appropriate partner.Please check the FAQ section below before contacting us.
The proposing party must submit its draft proposal to the Patron by Wednesday the 21st of May by the end of the day using the submission portal. In this draft proposal at least sections A, B and C needs to be fully completed. The feedback will be provided by the Patron at the latest by Tuesday the 29th of May 2018, and must be copied into section D of the proposal template
- Total budget for Open Call 2 for Extension: 300 000 €
- Maximum budget per Extension: 75 000 €
- Expected number of Extensions to be funded: 4
- Guaranteed support: 18 000 € (An extra budget of typically € 4500 per Extension will be allocated to the ORCA consortium partner acting as Patron for guaranteed support)
Requirements related to the proposer
- Proposers must be eligible for funding in H2020 projects.
- Proposals will only be accepted from a single party.
- Parties that having been selected in previous ORCA Open Calls are not eligible to participate again.
A proposer can only be selected for funding for one proposal, even if the proposer submitted multiple proposals that are ranked high enough to be selected for funding. In the latter case, the proposer may be given the opportunity to choose the one to be retained for funding.
- Language in which the proposal must be submitted: English
- Proposals must follow the provided template (see Section 5.1 Open Call and Appendix A to the same document)
- Proposals (draft as well as final proposals) must be submitted through the online submission form at the bottom of this page
FREQUENTLY ASKED QUESTIONS (FAQs)
SDR hardware can be remotely accessed in the wireless test facilities supported in ORCA (see https://www.orca-project.eu/testbeds/). The costs for equipment should be a minor contribution of the requested funding.
ORCA targets to offer open and modular software and hardware platforms to the wireless community for experimental validation of networked SDR solutions. The results achieved during the implementation of the Extension by the proposer will be owned by the proposer (further referred to as the Provider). But the Provider is expected to grant to the coordinator (IMEC) non-exclusive, non-transferable, royalty-free and fully paid-up right, with the right to grant sub-licenses to third parties (e.g. ORCA partners or successful proposers in future Open Calls), to use, improve and/or modify the source code. See also article 2.1.1 in Agreement for the integration of an Extension to the ORCA Platform for Experimentation.
A successful proposer will enter the ORCA project as a third party. This implies that a third party does not have to fill in NEF or any other forms from the Commission for financial claims. The only thing that is needed is an invoice, and then depending on the report and the outcome of the review, the Third Party will be paid. However, for a good and better review of your proposal it is best to list the costs related to the proposed experiment or extension as would be done for any European Project:
- number of PM
- personnel costs
- other direct costs (with a very rough split into the different major categories)
- indirect costs
This information will be used to evaluate the “value for money” of your proposal which is one of the criteria in the proposal review process.
So, there will be no audit, no formal accounting required, but any information, as close as possible to what you would do for a EU project, is advisable to get a proper review of the proposal.
Both draft and final proposals have to be submitted via the submission portal. The latest submission before the submission deadline will be considered for evaluation.
The full process is as follows:
- A first draft proposal is submitted by the Proposer via the submission portal before the feasibility and relevance check deadline.
- The Patron provides feedback via email to proposer
- The Proposer includes the feedback in the proposal, finalises its proposal and submits the final proposal again via the submission portal before the submission deadline
The Patron will NOT review draft proposals or propose any changes to the proposal. The Patron will only give feedback on the feasibility of the proposed experiment based on the completed sections A, B and C. The feedback of the Patron needs to be included in section D of the proposal. The feasibility check does not provide a commitment that the proposal will be selected.
The Patron will be your main contact and support during the time of your extension but in the general based on the platforms considered and your needs, other contact partners can be contacted. The full list of contact people and related platforms can be found in section 6.1 of the Open Call document linked as Detail Call information in the Call documents section in this page.
The maximum duration for an extension is 9 months.
For the integration of the extension with the SDR platform the provider will get support from skilled ORCA consortium partner (the Patron). Details about roles in this OC etc. are listed under the following link: https://www.orca-project.eu/open-calls/1st-orca-open-call-extension/#1505718330823-22bd4d57-e712
More details are listed within the call information document: https://orca-project.eu/wp-content/uploads/sites/4/2017/09/ORCA_OC1_for_Extension.pdf
- Page 35 -> 6.1. Support of Extension and role of Patron
- Page 44 -> Section C
For the extension, it is targeted to select one main Patron, but the proposer/provider can also interact with other ORCA contact persons as well, depend which platforms are considered. The degree of platform independence is also a high weighted evaluation criteria for this extension. More information on this topic you will found under https://orca-project.eu/wp-content/uploads/sites/4/2017/09/ORCA_OC1_for_Extension.pdf
- Page 32 -> point 6. Degree of platform independence
Unfortunately it is not possible to borrow hardware from ORCA, because it’s integrated fix into the testbeds, but several options are possible to make the integration successful:
- simulator only tests
- loop back modes to tests without SDR hardware
- remote access to SDR hardware through the testbeds
- physical integration session together with the patron (e.g. meet together for 2-3 days with direct access to the SDR hardware), the travel expenses for this can be foresee in the proposal
- buy SDR hardware for integration purposes (not funded by ORCA)
FAQs - Extension 1: Partial reprogramming of FPGA on SDR at runtime
The “cloud” refers to any remote infrastructure (eg, servers) that can offer storage accessible via the internet, http and ftp are sufficient for this purpose.
A partial bitstream corresponds to a predefined Partial Reconfigurable Region (PRR), it is up to the proposer to define exactly what can be contained in a PRR, it may contain a single or multiple IP cores.
The basic configuration of firmware can be single or multiple functions compiled into object files. A function may be used by drivers for multiple IP cores, though it should allow proper input parameters to be applied for each IP core in case differentiation is needed.
Readily available Xilinx IP cores are acceptable as BPU for this extension, as the focus is not to develop new IP cores. Many users or institutes have Vivado license, hence will have access to Xilinx cores.
The 50 ms time constraint is an estimation of total reconfiguration time from user perspective. It is correct that the configuration will take longer when larger partial bitstream is loaded, it is appreciated if the proposer can give analytical results for what can be configured within the 50 ms time spam.
The use of GITAR is optional and should only come into play at the end of the open call, as the focus lays on enabling partial updates of the bitstream on the FPGA. Using GITAR or not will have no impact on the assessment of the proposal. You should consider it as a possible tool that can be used to integrate your work in a fully functional software stack (e.g. with IPv6 support, etc.). There are also alternatives that can be considered depending on the preferred OS running on the processors.
FAQs - Extension 4: Dynamic runtime composition of mmWave transceiver chains consisting of processing functions that are split between FPGA and CPU
The use of RFNoC is highly recommended as it is the ORCA goal to eventually wrap up everything in RFNoC. However, the scope of this EXT4 is quite wide, and it is an option to focus on mmWave VHDL code development, and we can wrap up the functionality in RFNoC later.
Compliance with the 802.11ad standard is not a hard requirement. This is actually not even possible, as most of the ORCA hardware is not high performance enough to meet 802.11ad specifications. We just focus on the 802.11ad preamble as an example preamble for channel estimation and analog beam forming.
This is definitely interesting, but not obligated for this extension. An partial or full transceiver chain (not all on FPGA) is recommended, and a strategy to enable partial offloading of the most demanding functional blocks to the FPGA makes sense.
Currently, the ORCA project does not offer a phased array, so analog beam forming is not yet supported. Digital beam forming is however supported already. By focusing on the channel estimation functionality, hybrid beam forming should be possible once the phased array becomes available.
mmWave systems should outperform the state of the art in terms of throughput, so an efficient implementation that can deliver a high throughput is interesting. However, most ORCA platforms don’t support a large bandwidth yet, and it is unlikely that cost-effective solutions covering a bandwidth of more than 2 GHz will become available in the future. As a result, when trade-ing off speed with functionality, it is at short term more relevant for ORCA and the research community to offer more lower throughput functionality.