Embedded Linux sobre FPGA -...

Embedded Linux sobre FPGA

Sistemas Embebidos – FIUBAPedro Ignacio Martos

Sistemas Embebidos - Embedded Linux sobre FPGA - Pedro Ignacio Martos

Temario

Descripción de la arquitectura del kernel de linux y de los controladores de dispositivoPresentación de un sistema linux embebido sobre FPGA utilizando un procesador softcoreDistribuciones de linux orientadas a linux embebidoImplementación de aplicacionesImplementación de un controlador de dispositivoImplementación del hardwareOpenCores y WishBone


¿Porqué usar linux embebido?

Interoperabilidad e infraestructura disponiblesConectividad a redes, distintos sistemas de archivos, soporte para dispositivos; gestión de interrupciones, etc.Gestión de memoria, procesos y threads.

PortabilidadCambio de plataforma de hardware con mínimos cambios en software (x86, PowerPC, Microblaze, ARM Cortex, etc)


¿Porqué usar linux embebido?

Entorno de desarrolloMismas herramientas que en linux “desktop”Las aplicaciones pueden ser prototipadas en linux desktop y después migradas a linux embebido con mínimos cambios.

EscalabilidadLinux embebido (ej. FPGA) - > Single Board Computers (ej. Beagleboard) - > desktop - > server - > Cluster (ej. Linux Rocks Distribution)


Estructura de un sistema linux

User ApplicationsTareas específicas, shells, etc.

LibreríasC Runtime (glibc), conectividad, gráficos, etc.

Kernel + System Call InterfaceHardware

CPU, controladores de interrupciones, controladores de memoria, etc


Arquitectura del kernelInterface de llamadas a sistema (SCI)Gestión de procesos (PM)Sistema de archivos virtual (VFS)Gestión de memoria (MM)Conectividad (Network Stack)Controladores de Dispositivos (DD)Ítems específicos de la arquitectura (Arch)


Interface de Llamadas a Sistema

Forma normalizada de acceder a código que debe correr en kernel spacePuede ser dependiente de la arquitectura de hardwareEs una forma indirecta de ejecutar código privilegiado


Sistema de Archivos Virtual (VFS)

Abstracción para la API de acceso a archivosCada tipo específico de sistema de archivos implementa su propia funcionalidadDesacopla el formato del sistema de archivos respecto de su soporte físico

Ext3 en disco SATAFAT32 en un disco USBReiserFS en un RAID


Arquitectura de los dispositivosPueden ser fundamentalmente de 3 tipos:

Orientados a caracteres (char)Secuencias (streams) de bytesSe utiliza open(), close(),read(),write(),seek(),etc.

Orientados a bloques (block)El sistema opera con grupos (bloques) de bytes en cada transacción.Suelen ser dispositivos direccionables, de almacenamiento o zonas de memoria.Las aplicaciones operan contra un buffer que cuando se llena el sistema realiza la transacción al dispositivo.

Orientados a ConectividadOrientados a paquetesasincrónicos


Acceso a los dispositivos

Los dispositivos char y block se ven como archivos del tipo “device node”

/dev/ttyS0 (puerto serie 0)/dev/sda (primer disco sata)

Los dispositivos de red no tienen una representación directa en el sistema de archivos


Clases de dispositivos

Se definen distintas clases de dispositivos y subsistemas

TTYUSBI2CSPI


Gestión de Procesos

Los procesos son la unidad de trabajo del scheduler; tienen su propio

Espacio de memoriaContexto del sistema de archivosContexto de seguridadContexto de conectividad

Cada thread de un proceso comparte el espacio de memoria del proceso

El cambio de contexto entre threads tiene poca sobrecargaLa escalabilidad es mas simple en sistemas multi CPU


Linux y uCLinuxLinux empezó en la arquitectura i386

Gestión de memoria por hardware (MMU)Memoria VirtualMemoria Paginada Mecanismos de protección

Otras arquitecturas son similaresPowerPC (IBM)SPARC (Sun)

uCLinux se emplea en arquitecturas sin MMUM68000 (Motorola / Freescale)BlackFin (Analog Devices)ARM7-TDMI


uCLinux

No tiene MMUNo hay protección de memoriaNo hay memoria virtualNo hay conversión de direcciones, modelo de memoria plano.Todos los procesos leen/escriben en todo el espacio de memoria

Para la gran mayoría de las aplicaciones no hay que realizar modificaciones al código.


Desarrollo para sistemas embebidos vs desarrollo para desktop

Compilación cruzada (cross compiling)Se compila en una plataforma distinta (host) de la que finalmente ejecutara el código (target).El runtime del host es distinto que el del target.

Usar linux simplifica esta situación

Se utilizan bootloadersEl proceso de arranque (bootloading) puede ser

Desde una memoria flashDesde red


Herramientas de generación de código (toolchain)

Las toolchains comprenden:Compilador (gcc, código de alto nivel a assembler)Ensamblador (as, assembler a código objeto)Enlazador (ld, código objeto a imagen ejecutable)Debugger (gdb)Otras herramientas (ej. Make, programadores jtag, etc.)

Hay toolchains para generar código en arquitecturas con y sin MMU

uCLinux: microblaze-uclinux-gcc / arm-elf-gccLinux: mb-linux-gcc / gcc target=xxx


Mas Información

http://www.ibm.com/developerworks/linuxhttp://www.ibm.com/developerworks/linux/library/l-linux-kernelhttp://www.ibm.com/developerworks/linux/library/l-system-calls


Distribuciones orientadas a linux embebido


Herramientas para linux embebido sobre FPGA (Xilinx)

ISESíntesis, mapping, place and route

EDKImplementación de procesadores hardblock y softcore; ip catalog (UART, ethernet, usb, pcie, etc).Toolchain para microblaze (softcore) y PowerPC (hardblock)

CoreGenLibrería/Catalogo de propiedad intelectual (controladores de memoria, filtros, bloques lógicos, etc.)


Herramientas para linux embebido sobre FPGA (Xilinx)

ChipScopeProAnalizador lógico dentro de la fpga, visualización de señales internas via jtag

iMPACT“Programación” de la fpga o de una PROM; compatibilidad jtag para otros dispositivos

PlanAheadPartición del diseño, Reconfiguración parcial

SysGenIntegración con matlab: “simulink a vhdl”


Uso de distribuciones orientadas a linux embebido

En general:Distintas partes se obtienen de distintos lugares.

Kernel / entorno de desarrolloToolchainHerramientas para configuración del hardware

Mantener todos los componentes de software sincronizados es muy difícilLa documentación esta distribuida y es especifica de cada componente de software

Genera un entry-level muy alto (se requiere mucha experiencia previa)Es difícil encontrar la información aún para usuarios experimentados


Uso de distribuciones orientadas a linux embebido

Utilizando una distribución orientada a linux embebido

Los componentes de software son compatibles entre si y están sincronizados.La documentación esta concentrada y es coherenteLa distribución esta probada sobre el hardware soportadoHay herramientas que simplifican la tarea de configurar la distribución para el hardware específico


Algunas distribuciones

Blue Cat Linuxhttp://www.lynuxworks.com/embedded-linux/embedded- linux.php

MontaVista Linuxhttp://www.mvista.com/product_detail_mvl6.php

Petalinuxhttp://www.petalogix.com/products/petalinux


Petalinux

Distribución fuertemente orientada a Xilinx.Código fuente del Kernel/librerías/aplicacionesToolchain orientada a microblazeSoporte de hardware para placas xilinxScripts desde línea de comandosHardware

Librerías para soporte de ip cores de xilinxReference designs de placas de xilinx


Workflow

Configuración del hardwareSe utiliza el workflow de EDK

Configuración de softwareSeleccionar la plataforma target (virtex, spartan, microblaze, powerpc)Configurar el kernel y aplicaciones (monolítico, módulos cargables, etc)Configurar el software de acuerdo a configuraciones especificas del hardware (direcciones de memoria, interrupciones, etc.)


Workflow (cont.)

Generación del sistema“build” del kernel y filesystemGeneración de la imagen final

ArranqueConfiguración del bootloaderCarga de la imagen


Algunas herramientas especificas

Petalinux-boot-prebuiltInicia el hardware con una imagen ya construida

Petalinux-jtag-bootTransfiere una imagen a la FPGA a través de JTAG

Petalinux-new-platformCrea una nueva plataforma (hardware) a partir de un template configurable (útil para nuevas placas)

Petalinux-new-appCrea e inicializa el entorno para desarrollar una aplicación, crea un makefile apto para compilar la aplicación

Petalinx-new-moduleCrea e inicializa el entorno para desarrollar un controlador de dispositivo. Crea un makefile apto para compilar el controlador (*.ko)


Compilación cruzada

Para linux desktop[user@host]$ gcc –o hello hello.c[user@host]$ ./helloHello, world![user@host]$_


Compilación cruzada (cont.)

Para linux embebido[user@host]$ microblaze- uclinux- gcc –o hello \hello.c[user@host]$ ./hello./hello: cannot execute binary file[user@host]$_

Compiladores:microblaze-uclinux-gcc (sin MMU)mb-linux-gcc (con MMU)


Compilación cruzada (cont.)

mb-gccGenera una imagen monolítica directamente ejecutable en microblaze.Enlaza con librerias de C reducidas.No se utiliza para desarrollo en linux embebido


Instalación de la aplicación compilada

Comando “make all install”En desktop; copia el binario generado a /usr/bin, /usr/local/bin, etc.En petalinux; copia el binario a la zona donde se tomaran las aplicaciones para generar la imagen del filesystem


AplicacionesAplicaciones standard

Shells, utilidades, webservers, conectividad, benchmarking, etc.Se guardan en petalinux- dist/userSe seleccionan mediante “menuconfig”Se compilan e instalan automáticamente durante el make de la distribución

Aplicaciones creadas por el usuarioSe pueden agregar directamente a petalinux- dist/userSe puede usar la herramienta petalinux- new- app y se crea en software/user- apps


Cross debugging

Host:$ microblaze-uclinux-gdb \/path/a/miaplicacion.gdb

(conexión remota a la ip del sistema con microblaze, puerto 1234)

Target$ gdbserver host:1234 /bin/miaplicacion

Microblaze-uclinux-gdb corre en el host, controla la aplicación en el target a través de tcp/ip y la aplicación gdbserver


Cross debugging

Archivo miaplicacion.gdbmiaplicacion es el binario ejecutable

Corre en el target bajo el control de gdbservermiaplicacion.gdb es una imagen en formato ELF que tiene los símbolos de debugging

Nombres de variables y funciones, etcSe utiliza en el host por la aplicación microblaze-uclinux- gdb


Controladores de Dispositivos


Introducción

Los controladores de dispositivo definen como se interactúa con un dispositivo físico:

Inicialización, control y apagado del dispositivo.Transferencias in/out, DMA, etc.Implementación de la API (open(),read(), write(), close(),etc)

Los controladores de dispositivo deben ser portablesEntre arquitecturas (i386, PPC, Cortex, etc.)Entre distintas configuraciones de sistema

Cantidad de dispositivos presentesRangos de direcciones del dispositivoTopología del bus al que esta conectado (pcie, usb)


Configuración¿Cómo saber qué dispositivos están presentes (cantidad, rango de direcciones/irq)?

Algunos buses son autodescriptivos (ej. usb)El bus asigna recursos al dispositivoEl S.O. le pregunta al bus los dispositivos y sus recursos asociados.El controlador de dispositivo usa esa información para acceder al dispositivo

En linux embebido sobre FPGA generalmente la configuración es estática

Los dispositivos y su rango de direcciones se definen en tiempo de síntesis.No se pueden averiguar en tiempo de ejecución

¿Cómo hace entonces un controlador de dispositivo en linux sobre FPGA para acceder a la información del dispositivo?


Configuración

Estructura “platform_device”Descriptor genérico para buses/dispositivosContiene información del rango de direcciones e IRQOpcionalmente puede tener información específica del dispositivo

Se puede inicializar en forma estática o dinámica (en tiempo de compilación del kernel o en tiempo de inicialización del sistema)El kernel provee un mecanismo para asociar el descriptor con el controlador


Estructura platform_deviceLa inicialización del sistema llama a platform_device_register() con una estructura platform_device como parámetroLa inicialización del controlador de dispositivo llama a platform_driver_register() con una estructura platform_driver como parámetroEl kernel asocia el platform_device con el platform_driver a través del campo “.name” e invoca a la función del campo “.probe” del platform_driverLa función .probe consulta la estructura platform_device para obtener información del hardware


Ejemplo de platform_device


Ejemplo de platform_device (cont.)


BSP

¿Cómo se obtienen los valores para inicializar la estructura platform_device?

Fijos (hard-coded)Forma tradicional para SoCs basados en microprocesadores / microcontroladores (ARM7, Blackfin, etc.)Inadecuado para FPGA / Softcores por lo dinámico de su desarrollo.


BSP

Mediante una herramienta de generación automática (en el caso de Petalinux es “autoconfig”)

El EDK permite el acceso a la base de diseño donde se fija el hardware del sistemaAutoconfig lee la configuración de hardwareAutoconfig genera la información de hardware en un formato comprensible por el kernel.


BSP (Ejemplo)Ip core Uartlite (linux-2.6-x/arch/microblaze/platform/common/xuartlite.c


Controladores de dispositivos como Módulos del kernel

Los controladores de dispositivos se integran al kernel en forma estática al momento de compilarlo (kernel monolítico) o en forma dinámica al cargarse como módulos independientes según se necesiten.Los módulos cargables son archivos con extensión .koSe cargan con el comando “insmod”Se descargan con el comando “rmmod”


Uso de módulos del kernel

“Used by” cuenta la cantidad de “clientes” del módulo

Procesos que tengan abiertos archivos asociados al hardware controlado por el móduloUso interno por parte del kernel

rmmod solo se puede invocar cuando la cuenta es cero


Uso de módulos del kernel

Casi todos los controladores de dispositivos se pueden implementar en forma estática o como módulo cargable.La capacidad de cargar módulos se configura en el kernel al momento de compilarlo


Módulos cargables en desktop y en embebido

Los módulos cargables se usan mucho en desktop

Se puede dar soporte a una gran variedad de hardware manteniendo el kernel de tamaño reducidoEl espacio en disco es mucho mas barato que el espacio de memoria, se tienen los módulos precompilados en el sistema de archivos.Solo se cargan los módulos de acuerdo al hardware presente


Módulos cargables en desktop y en embebido

En embebido tienen pros y contrasAl tener un kernel reducido en tamaño se reduce el tiempo de inicialización (boottime) En filesystems implementados en memoria generan un doble costo de espacio: una instancia como archivo .ko y una instancia como módulo cargado en el kernelSuele convenir utilizar módulos cargables durante el desarrollo y generar un kernel monolítico en el producto final.


I/O en userspace

Es común en el desarrollo de sistemas embebidos.En linux sin MMU es posible pero es una mala idea:

Dificil de mantenerNo es portableEs suceptible de errores: el kernel implementa mecanismos de serialización para el acceso al hardware que no están disponibles en userspaceNo hay gestión de interrupciones en userspace


I/O en userspace

Es posible mapear un dispositivo ubicado en “baseaddress” a una zona de memoria:

Sin MMU es casi lo mismo que:ptr=(void *) baseaddress

Con MMU el kernel remapea baseaddress, dando acceso directo al hardware

Portabilidad muy limitadaBaseaddress esta fija en el códigoNo hay gestión de interrupciones


I/O en userspace - UIO

Para soluciones estos inconvenientes se creo la API “UIO”

Linux- 2- 6-x/drivers/uioPermite una implementación portable para controladores de dispositivo en userspaceHay gestión de interrupciones (básica)Tiene asociado un pequeño controlador que se ejecuta en kernelspaceTodo el trabajo se realiza en userspace


UIO – Pros y Contras

Pros:Permite un prototipado rápido

No requiere recompilar o reinicializar el kernelLos errores no suelen afectar a otras partes del sistemaPermite trabajar con dispositivos sin tener profundos conocimientos del kernel

Muy útil cuando ningún controlador en kernelspace cumple la funcionalidad necesaria


UIO – Pros y Contras

ContrasLa gestión de interrupciones es muy básicaLa latencia de interrupción es alta y variableNo hay DMA desde/hacia userspacePermite la creación de controladores cerrados


Mas Información

Controladores de dispositivos“Linux Device Drivers 3rd.edition”

UIOwww.celinux.org/elc08_presentations/uio080417celfelc08.pdf


MMU en detalle

Sistemas con MMU en hardwareDirecciones virtuales

Mapeo automático entre direcciones físicas y virtualesEvita problemas de fragmentación de memoriaPermite el paginado y swapping a disco

Sistemas de protecciónSe generan excepciones cuando la aplicación trata de realizar I/O o acceso a zonas de memoria fuera de su rangoPermite al S.O. aislar las aplicaciones entre si y respecto de si mismo.Se controlan las zonas compartidas de memoria


MMU en detalle

Sistemas sin MMU – uCLinuxLos desarrolladores de sistemas embebidos están acostumbrados a acceder directamente al hardwareEn la medida de lo posible hay que utilizar controladores de dispositivos y prácticas standard

El kernel y los controladores implementan mecanismos de acceso serializado al hardware y gestión de interrupcionesEl código es mas mantenible y portableSe puede migrar a sistemas con MMU cuando sea necesario


MMU y microblaze

Microblaze puede sintetizarse con y sin MMULa MMU es muy similar a la del procesador PowerPC 405, para facilitar la migración a estos procesadoresHay 3 niveles de implementación

Usermode: controla el acceso a instrucciones privilegiadasProtección: Usermode + control del acceso a otras zonas de memoriaVirtual: Protección + direcciones virtuales


MMU: ¿si o no?

Criterios de selección:Tamaño: agregar la MMU duplica el footprint del microblazePerformance: MMU introduce los cambios de contexto y fallos de pagina, generando una sobrecarga al sistemaFuncionalidad: la MMU aporta la funcionalidad y seguridad ya mencionada


Implementación del Hardware


EDK El EDK esta compuesto por:

Xilinx Platform Studio (XPS): Herramienta para conectar Procesadores, buses y periféricos.Base System Builder (BSB): Configuración del sistemaIP Wizard: Permite crear o importar propiedad intelectual integrándola a los buses presentes.Debugger (XMD): Permite debuggear el procesador utilizado.Hardware Generator (PlatGen): Convierte el diseño en una netlist sintetizableLibrary Generator (LibGen): Configura el software necesario para el funcionamiento del sistema.Simulation Generator (SimGen): Genera modelos de comportamiento o de timing del sistema.GNU Toolchain: conjunto de herramientas para generar software ejecutado por el sistemaIP de procesadores, controladores de dispositivo, documentación, etc.

Se puede ejecutar mediante una interfase GUI o mediante línea decomandos


Propiedad Intelectual disponible

Hay un gran conjunto de ip cores$XILINX_EDK/hw/XilinxProcessorIP/pcores

Los mas utilizados:CPU Microblaze y PPCSystem Timer, Interrupt Controller, Memory Controller.Buses

PLB (Processor Local Bus): Bus de alta velocidad entre el procesador y memoria on-chipFSL: Bus tipo FIFO para comunicar coprocesadores y Hardware específico (aceleradores de hardware)


CPU Microblaze

Procesador de 32 bits similar al MIPS o al DLX32 Registros de 32 bits ortogonalesALU configurable

Mul/div de enteros, barrel shifter, comparadorOpcionalmente FPU, MMUOpcionalmente excepciones de hardware

Errores de bus, división por cero, accesos no alineados, fallos de paginación, etc.


CPU Microblaze

Cache de datos e instrucciones opcional y de tamaño variable

64 bytes a 64kbytes (dependiendo de la FPGA)Opcionalmente capacidad de debugging por hardware

Cantidad de breakpoints por hardware variableSoporte para watchpoint

OptimizacionesÁrea (pipeline de 3 etapas sin MMU)Performance (pipeline de 5 etapas)


CPU Microblaze

Se pueden crear instrucciones propias para la ALU

Aceleración para determinadas operaciones (ej. paridad)Los opcodes deben ser compatiblesUna mala implementación reduce la fmax del procesadorRequiere soporte en el compilador


Interfase de memoria

Multiport Memory Controller (MPMC)SDRAM, DDR, DDR2Hasta 8 puertos

Cache del CPUBus principalConexión directa a hardware dedicadoFramebuffers de video

Se puede configurar la prioridad de cada puertoControlador de memoria externo (xps_mch_emc)

SRAM y flashHasta 4 puertos


Otros cores

Controlador de interrupciones (XPS_INTC)Hasta 32 canales de interrupciónInterrupciones por nivel y por flanco

Timer de sistema (XPS_TIMER)Temporizador ascendente/descendenteUno o dos canalesAutorecarga, one- shot, PWM.


Otros Cores

I/O de propósito general (XPS_GPIO)Uno o dos canales de hasta 32 bitsFunción entrada/salida/tristate por cada bitGenera interrupciones si cambian los valores

EthernetMAC ethernet 10/100/1000

Otros busesSPI, I2C, USB, etc.


Buses – PLB

Generalmente Bus interno en la fpgaDirecciones de 32/64 bitsDatos de 32/64/128 bits (canales de lectura y escritura independientes)Bus de interfase de microblaze y PowerPC


Buses – FSL

Interfase tipo FIFO de 32 bitsCantidad de palabras configurable (1 a 32K)Versiones sincrónicas y asincrónicasPuertos maestro (escritura) y esclavo (lectura)Conexión directa a microblaze

Hasta 16 pares maestro/esclavoTransferencias en un solo cicloOpcionalmente operaciones bloqueantes

Útil para streamingDSP, video


Sistema microblaze típico


Base System Builder (BSB)Herramienta para generar sistemas

Se puede elegir de una librería de placas ya armadasCasi todas las placas de xilinx están soportadas y muchas de terceras partesSe pueden crear configuraciones propias

Se puede configurar periféricos a nivel placaGPIO para leds/switchesEthernetMemoria (SDRAM, DDR, flash, SRAM)System ACE (soporte para la configuración de la FPGA y memoria via jtag)

Genera autotests para la memoria y los periféricos


Hardware personalizado

Hardware fuertemente dependiente de la aplicación

Acelera procesos computacionalesPermite procesamiento en tiempo realPermite interfases específicas


Clases de hardware personalizado

CoprocesadoresFuertemente acoplados a la CPUTrabajan con datos muy específicosSensibles a la latencia

Periféricos personalizadosNo muy acoplados a la CPUTrabajan con bloques de datosSensibles al ancho de banda (transferencias)

Controladores de sistemaFPGA fundamentalmente llena con lógica digital específicaMicroblaze+linux provee funciones de control/gestión/interfase (ej. ethernet)


Ejemplo: Periféricos personalizados


Ejemplo: control/gestión/interfase


Buses – SimulaciónSe utilizan los modelos funcionales de bus (Bus Functional Models – BFM)

IBM CoreConnectLos BFM permiten implementar el protocolo del bus

Se pueden hacer scripts simulando transaccionesSe simula el comportamiento del bus y los periféricos conectados


OpenCores y Wishbone


OpenCores.org:Propiedad Intelectual sintetizable

AritméticaCordicDCTMatMult

ComunicacionesUSBEthernetSerial,I2C,SPI

CriptografíaAES,DES,SHA1

CPUsClones de z80, 8051, Microblaze, AVR

OtrosInterfaces de memoriaControladores de videoGeneradores de números aleatoriosPuentes entre buses


Bus WishBone

CaracterísticasBus de datos de 8/16/32/64 bits.Bus de direcciones de 32/64 bits.Sincrónico Transacciones simples o en ráfaga

Similar a PLBVersión simplificada, no tiene canales separados para lectura y escritura.

Porqué usarlo:Una gran librería de IP probada y sin pagos por licenciamiento disponible en OpenCores.org


WishBone y EDK

Se pueden agregar periféricos wishbone a un sistema con microblaze

Se utiliza el puente plbv_to_wishbone disponible en opencores.orgSe conecta un maestro PLB a wishboneLos dispositivos wishbone son esclavosNo hay transferencias en ráfaga


Wishbone y EDK


Mas Información

OpenCores.orghttp://www.opencores.org

Bus WishBonehttp://http://opencores.org/opencores,wishbone


El Futuro según Xilinx

Durante mucho tiempo Xilinx e IBM mantuvieron una alianza estratégica

PowerPC 405, PowerPC 440 en Virtex2, Virtex4 y Virtex5Microblaze compatible con PowerPCCoreConnect (PLB, OPB, BFMs)

Ahora (2010)Alianza con ARM

Virtex7 no tiene Processor HardblockSe avanza en un softcore Dual Cortex A9Se migra al bus AMBA 4 AXI de ARM


El Futuro según Xilinx


Mas Información

http://www.xilinx.com/technology/roadmap/processing-platform.htmhttp://www.xilinx.com/publications/prod_mktg/7-Series-Product-Brief.pdfhttp://www.xilinx.com/publications/prod_mktg/Virtex7-Product-Table.pdfhttp://www.xilinx.com/publications/prod_mktg/Artix7-Product-Table.pdfhttp://www.xilinx.com/publications/prod_mktg/Kintex7-Product-Table.pdf

Embedded Linux sobre FPGA -...

Documents

Transcript of Embedded Linux sobre FPGA -...