MpSoC Forum « gmgPuBlog

MpSoC Forum

Julio 14, 2008 de yerart

A la hora de poder innovar o avanzar en la investigación del diseño de circuitos integrados con varios cores (MpSoC) es bueno tener información de primera mano sobre las líneas de investigación más importantes y los avances que se van produciendo en dichas líneas. Para ello hay que buscar en las fuentes adecuadas.

Una de esas fuentes es un foro europeo, el MpSoC Forum, que se reúne desde comienzos de este siglo en Francia para dar a conocer y debatir los últimos avances en ese campo, en donde participan los principales grupos de investigación de la academia y la industria.

Según aparece reflejado en su página:

MPSoC is a pluridisciplinary forum bringing together key R&D actors from the different fields required to design heterogeneous multiprocessor SoC (MPSoC). The full week format and the quality of both attendees and speakers make of MPSOC a unique occasion for executives and senior managers to explore new ideas and refine strategic thinking. The program brings together key actors from IP, fabless, semiconductor, system houses and design industry to build a vision of the next step in integrated system design.

Una particularidad que tiene este foro es que publica online todos los papers y comunicaciones que se presentan. La última reunión de este año 2008, celebrada como siempre a finales de junio ya tiene disponibles las transparencias de las comunicaciones realizadas. En la página principal del MpSoC fórum se tienen en sendos enlaces a las reuniones celebradas desde 2001 a 2007.

Escrito en multicube | Etiquetado congresos, EETimes, MpSoC, multicube, Tensilica | 2 comentarios

2 comentarios

en Julio 14, 2008 a 9:30 pm | Responder yerart

El hecho de encontrar el foro anterior vino como consecuencia de una búsqueda en Google sobre MpSoC Conferences. Otras de las cosas que encontré fue una serie de artículos en el blog de Steve Leibson, un ejecutivo de la empresa Tensilica, que es un fabricante de IP Cores para Systems-on-a-Chip (SoCs), especialmente de microprocesadores que son utilizados en muchos productos de electrónica de consumo. En algunos de los artículos pongo extractos que son de interés para el proyecto en el que estoy trabajando (y por extensión los artículos de los que los he sacado son de especial interés y deben ser leídos)

La serie de artículos trata de las conferencias dadas en el MpSoC Forum 2008 y son las siguientes:

> MPSOC ’08, Live from Maastricht: Where We Are and Where We’re Going

> MPSOC ’08, Live from Maastricht: Real Men (and Women) Simulate!

… MPSOC ’08 on the explosive needs of system simulation in the MPSOC era.

… Many such techniques have been developed including synchronous data-flow (SDF) graphs, stochastic automata networks (SAN), event adaptation functions, and real-time calculus (RTC). Of these, Ienne advocates a form of real-time calculus called network calculus, which is a mathematical model based on min-plus algebra. Network calculus is based on deterministic queuing theory and provides worst-case bounds on system behavior. …

> MPSOC ’08, Live from Maastricht: Quad-HD Displays—33 Mpixels and Counting

> MPSOC ’08, Live from Maastricht: 3D Chips

> MPSOC ’08, Live from Maastricht: MP and the Symbian OS

> MPSOC ’08, Live from Maastricht: Dismal SOC Project Stats and TLM 2.0 as the Way Out of the Mess

… CoWare’s solution is the use of virtual platforms, which allow early software prototyping, development, and testing on a network of simulators. CoWare’s chosen vehicle is SystemC simulation, which provides very high system simulation speed and near-real-time debugging.

… TLM 2.0 the new transaction-level modeling API permits the development of compatible peripheral models, making the SystemC environment start to look a lot more like a box of Lego bricks and a lot less like a crate of Hasbro’s Play-Doh.

… The loosely timed APIs are for software development. Synchronization between processes occurs over groups of instructions, not on a per-instruction basis. Instruction groups might even be as large as 100,000 instructions said Kogel. The approximately timed APIs are for architectural and performance analysis. These are the hardware-development use cases and are synchronized on a per-instruction basis. As you might expect, simulations using the approximately timed APIs produce more accurate timing results and run slower than simulations that use the loosely timed APIs. It seems to me that a key element of TLM 2.0 is that neither type of API is optional. TLM 2.0-compatible models must support both.

… at 7/6/2008 10:01:39 PM, Grant Martin said:
This last point is an interesting point of discussion and some controversy. I agree with Steve that two levels of accuracy-speed tradeoff are required, but unless “approximately timed” is modelled to be very close to cycle accurate (or better, if models support both loosely timed and cycle accurate modelling through run-time choices), then certain aspects of system functional correctness may not be simulatable using TLM 2.0. In particular, some systems use time and order dependent synchronisation, and a simulation using the loosely timed approach may indicate functional correctness but the system itself may not work properly. Use of cycle-accurate modelling for proving system correctness (and some aspects of system performance), in conjunction with loosely-timed modelling for fast functional simulation, is the best system modelling strategy. TLM 2.0 or a future derivative of TLM may need evolution in order to provide validated cycle accurate modelling. But its a good start.

> MPSOC ’08, Live from Maastricht: Got SMP? Need Auto Parallelization? Just add Multigrain OSCAR

> MPSOC ’08, Live from Maastricht: OSCI’s TLM 2.0 and the Arrow of Time

… Synopsys’ Joachim Kunkel spoke at MPSOC ’08 about system simulation and the impact of the new OSCI TLM 2.0 API standard.

> MPSOC ’08, Live from Maastricht: Imitation is the Sincerest Form of Flattery

> MPSOC ’08, Live from Maastricht: From 1 to 1000 Cores: How do We Get There?

> MPSOC ’08, Live from Maastricht: Green Systems and MPSOC Design

… If you’ve already decided to meet your performance requirements by distributing the work over a number of processors, why would you then choose a bottleneck like a global bus or bus hierarchy to move data and instructions to and from these processors?” There are much better interconnection schemes for on-chip processors that exploit the massive interconnect routability on nanometer silicon. Such methods include point-to-point connections with or without dual-ported RAM or FIFO queue buffers and on-chip networks (NoCs).
en Julio 15, 2008 a 9:31 pm | Responder yerart

Otra referencia que he encontrado relacionada con la búsqueda de Google que he comentado y que puede aclarar un poco más la complejidad que se encuentra en el diseño de sistemas con MpSoCs, es un artículo de Richard Goering en EETimes:

EE Times: Multiple processors mean multiple challenges

While a performance boost can be achieved by adding many processors to a system-on-chip, designers must be prepared to tackle the related speed bumps of software and hardware design

(09/19/2005 10:00 AM EDT)

RSS de los Comentarios

L	M	X	J	V	S	D
« Jun				Ago »
	1	2	3	4	5	6
7	8	9	10	11	12	13
14	15	16	17	18	19	20
21	22	23	24	25	26	27
28	29	30	31

gmgPuBlog

Diario Digital de Gerardo de Miguel González. La pasión por aprender.

MpSoC Forum

2 comentarios

Escribe un comentario

Etiquetas

categorías

Archivo

Lo más visto

Admin