Embedded systems 1/5

(1)

systems 1/5 J.-M Friedt & al.

Heterogeneous Multi-Processing CPU-FPGA co-design OscIMP Digital Getting started...

Module generatory

Embedded systems 1/5

J.-M Friedt, G. Goavec-Merou FEMTO-ST/time & frequency department

jmfriedt@femto-st.fr slides atjmfriedt.free.fr

January 13, 2020

(2)

Module generatory

HMP co-design

Heterogeneous Multi-Processing (HMP6= SMP !):

• heterogeneous digital processing systems sharing one main general purpose CPU with dedicated co-processors (ASIC, CPU, GPU, FPGA)

• complexity of the various abstraction layers, especially communications

• IPC¹/RPC²over network

• Linux/Zephyr ; Linux/FreeRTOS (RPMSG & remoteproc³)

→OpenAMP⁴

• consistent development environment

wiki.st.com/stm32mpu/nsfr_img_auth.php/e/ef/Remoteproc_overview.png

1InterProcess Communication: pipes, sockets, shared memory

2Remote Procedure Call

3https://www.kernel.org/doc/Documentation/remoteproc.txt

4Asymetric Multi Processing @https://github.com/OpenAMP/open-amp

2 / 13

(3)

Heterogeneous Multi-Processing CPU-FPGA co-design

OscIMP Digital Getting started...

Module generatory

CPU-FPGA context

Redpitaya: baseband dual ADC &

DAC 14/16 bits @ 125MHz

PlutoSDR: AD9363 RF frontend 70 MHz→6 GHz

⇒Perfect for acquisition and Digital Signal Processing with co-design CPU/FPGA:

• FPGA (Real-time) for fast task

• data acquisition;

• frequency transposition;

• filtering;

• decimation.

• CPU (General Purpose OS) for slow task after decimation

• post-processing;

• display;

• transmission;

• configuration

(4)

Module generatory

Example

ad9767_0

ad9767_v1_0 dataA_in dataB_in cplxToReal

convertComplexToReal_v1_0 data_in dataI_out

dataQ_out dataComplex_to_ram_v1_0

dataCplx_to_ram

s00_axi data1_in

dupplCplx

dupplComplex_1_to_2_v1_0 data1_out data_in

data2_out ltc2145_0

ltc2145_v1_0 dataA_out dataB_out

realToCplx

convertRealToComplex_v1_0 dataI_in dataQ_in data_out

AXI

DAC ADC

PL->PS

A (DUT)

CLK

B (REF) P2*

P1 unwrap

unwrap reglin

reglin mixer

nco

mixer fir+decim fir+decim atan

atan FFT

FFT

nB+nclk+nADC2

nA+nclk+nADC1

nA−nB

4 / 13

(5)

Module generatory

Consequence

• one algorithm⇒one or more flavor (data type, performance vs. resources, ...): fpga ipdirectory

• need to communicate between FPGA and CPU:

linux driverdirectory

• some IPs are widely used or complex to configure⇒ need to provide library with CPU code (reduce redundance, simplify application): liboscimpinlib directory.

drivers lib

dtbo app

IP FPGA

CPU

(6)

Module generatory

OscIMP EcoSystem

Purpose : provide a coherent environment to create design (FPGA), and application:

• blocks (IP) with algorithm level of implementation (FPGA);

• GNU/Linux hierarchy compliance (driver/library/application);

• tools to generate some files and scripts/Makefile to factorize most common part;

• consistent addressing & bitstream loading under supervision of Device Tree Binary Overlay (dtbo).

drivers lib

dtbo app

IP FPGA

CPU

...

setenv.sh nco_conf

fir_conf ...

Makefile lib

app1 ... app1 app2

fir nco ...

xilinx.mk setenv.sh fpga_ip

setenv.sh nco_core fir_core

Makefile.inc linux_driver

...

redpitaya

settings.sh oscImpDigital

plutosdr doc/tutorials

6 / 13

(7)

Module generatory

FPGA

Algorithms or utilities functions.

Developer aspect:

• normalize interfaces between blocks

• isolation between implementation and communication

End user aspect:

• 0, 1 or more interface to connect;

• AXI interface automatically connected.

... ...

IP.vhd

IP_comm IP_top

IP_protocol

(8)

Module generatory

FPGA

Algorithms or utilities functions.

Developer aspect:

• normalize interfaces between blocks

• isolation between implementation and communication

End user aspect:

• 0, 1 or more interface to connect;

• AXI interface automatically connected.

... ...

IP.vhd

IP_comm IP_top

IP_protocol

converters

redpitaya_converters_v1_0 phys_interface

dataA_out data_a_o[13:0]

data_a_en_o data_a_clk_o data_a_rst_o dataB_out dataA_in

dataB_in adc_rst_i

clk_o rst_o rstn_o

interface

signal

8 / 13

(9)

Module generatory

CPU: environment

Char device driversto add abstraction, GNU/Linux hierarchy compliance and communication improvement:

• 1 IP with communication⇒1 (or more) driver(s);

• acoredriver knows how to communicate with an IP but not where;

• device tree overlayused to provide which drivers must be probed and base address for each of them;

librariesto simplify some common and long (number of line) tasks.

TODO⇒IIO integration

(10)

Module generatory

CPU: application

Application structure:

• dts to provides which driver must be used and base address;

• Makefile to cross-compile application and generate thedtbofrom dts

• applicationName us.sh a shell script used to flash FPGA, load devicetree and drivers;

• main.c: user application

user defined

automatically created by module_generator (based on XML file)

myApp.dts myApp_us.sh

design

tcl + Makefile xpr or

Makefile main.c

myApp

app myApp.xml

10 / 13

(11)

Module generatory

CPU: module generator

• Used to generate some files in app directory.

• use an XML file for design’s informations.

module_generator -dts myApp.xml

<?xml version="1.0" encoding="utf-8"?>

</options>

<ips>

<instance name="data1600" id = "0"

base_addr="0x43c00000" addr_size="0xffff" />

</ip>

<instance name="nco" id = "0"

</ip>

(12)

Module generatory

Play with repositories

1 Assumption: functionalbuildrootframework

2 Clone repository and submodules:

git clone --recursive https://github.com/oscimp/oscimpDigital.git 3 Configure: fill variables insettings.shand source configuration

file

4 Discover:

In oscimpDigital/doc/tutorials/redpitaya

See firstoscimpDigital/README.mdto configure your shell environment.

Cheat-Sheet for Redpitaya available at

jmfriedt.free.fr/redpitaya_cheat-sheet.pdf

12 / 13

(13)

Module generatory

CPU: module generator

• Used to generate some files in app directory.

• use an XML file for design’s informations.

module_generator -dts myApp.xml

myApp.xml

<?xml version="1.0" encoding="utf-8"?>

<ips>

<instance name="data1600" id = "0"

</ip>

<instance name="datanco0" id = "0"

</ip>

<ips>

</project>

tutorial5 us.sh

cp ../bitstreams/tutorial5_wrapper.bit.bin /lib/firmware rmdir /sys/kernel/config/device-tree/overlays/fpga mkdir /sys/kernel/config/device-tree/overlays/fpga cat tutorial5.dtbo > $DTB_DIR/dtbo

insmod ../../modules/data_to_ram_core.ko

tutorial5.dts

/dts-v1/;

/plugin/;

/ {

compatible = "xlnx,zynq-7000";

fragment0 {

target = <&fpga_full>;

#address-cells = <1>;

#size-cells = <1>;

__overlay__ {

#address-cells = <1>;

#size-cells = <1>;

firmware-name = "tutorial5_wrapper.bit.bin";

data1600: data1600@43c00000{

compatible = "ggm,dataToRam";

reg = <0x43c00000 0xffff>;

};

datanco0: datanco0@43c10000{

compatible = "ggm,nco_counter";

reg = <0x43c10000 0xffff>;

};

(14)

Module generatory

Outline of the lab sessions

1 ADC→DAC (PL standalone application)

2 ADC→DAC & PS (DataToRAM): add kernel driver for reading

3 ADC→DAC & PS after processing (FIR filter): add kernel driver for configuring

4 ADC→DAC & PS after processing (frequency transposition by NCO)

5 TCL programming instead of graphical user interface

14 / 13