Licencias Open Hardware

Hace pocos días el CERN presentó su licencia Open Hardware (pdf). Esta licencia se incluye en el proyecto de repositorio Open Hardware Repository del mismo CERN.

Para empezar, expliquemos qué es Open Hardware (OSHW). Por OSHW entendemos cualquier diseño HW (un dispositivo, una pieza de HW, un módulo para ser usado por otros diseños, etc.) en que todo el proceso de diseño (esquemáticos, elecció de componentes, firmware i SW asociado, documentación, código para circuitos integrados, etc.) está disponible de forma libre.

Esto tiene unas cuantas implicaciones, ya que toda la información necesaria para poder replicar un diseño hardware es muy variado.

PCB arduino, ejemplo de Open HW

Por ejemplo, para poder hacerse una copia de una módulo Arduino, con tener disponibles el diseño de la PCB (en sus distintas fases y formatos), la lista de componentes a obtener y el SW necesario (Sistema Operativo, drivers, etc.) hay suficiente.

Por otro lado, para el caso de un módulo con una funcionalidad concreta para lógica reconfigurable (FPGA) para usarlo en un diseño propio, nos basta con una buena documentación y el código VHDL o Verilog.

En todo caso, y a diferencia de open source SW, nos harán falta herramientas y/o fabricantes: a diferencia del SW, HW seran dospositivos físicos que habrá queconseguir/comprar o fabricar de una forma o otra, siendo así su costo distinto de cero.

Parece claro que una sola licencia que abarque los distintos aspectos de un sistema HW no puede ser sencilla, y de hecho hasta la actualidad se han usado distintas licencias para las distintas partes; así, hasta la fecha tenemos:

    • Código modelado/simulación (SystemC o parecidos): GPL (GreenSocs)
    • Código SW: GPL/LGPL (Arduino, Linux EnCaja),
    • Documentación general: Creative Commons, FDL, etc.

Con esta retahíla de licencias se cubre, a mi entender, perfectamente la propiedad, como la distribución libre de cualquier proyecto HW.

Entonces, por qué el CERN saca una licencia nueva para HW abierto? En principio, y sin ser un experto en leyes ni textos jurídicos, esta licencia cubre estos aspectos:

    • Permite modificar la Documentación (entendiendo documentación como toda la información necesaria para el proyecto), debiendo
      publicarse los cambios y manteniendo el copyright del autor original (Sección 3)
    • Cualquiera puede fabricar el dispositivo y distribuirlo (venderlo?) pero siempre ofreciendo la licencia y la Documentación. (Sección 4)

El resto de puntos (secciones 5 y 6) son detalles “de abogados” como el copyright de la propia licencia, el uso de marcas registradas, la posibilidad de actualizar el texto de la licencia y cosas así.

Como se ve, está nueva licencia es parecida a la GPL en el aspecto que también es viral: esto es, que un producto con esta licencia provoca que cualquier trabajo derivado deba ser también licenciado con la misma licencia. Esto obliga a que todo el mundo que use el trabajo original debe publicar el código derivado (Documentación según la licencia CERN OHL) y permita trabajos derivados.

Qué diferencia esta licencia de otras como TAPR? Sinceramente, no lo se, y no veo ninguna explicación sobre las diferencias o mejoras en la web del OHWR.

Para un proyecto nuevo que implique un diseño HW que queramos ofrecer libre, qué licencia usar? Pues tampoco se si vale la pena esta nueva licencia. Mi opinión: un mix de GPL para el código, CC-BY-SA para esquemáticos y FDL para la documentación es suficiente y todo el mundo conoce (o debería) estas licencias.

Hay algo que se escape con esta combinación? Quizás con el tema de las patentes no está claro, porque qué ocurre si alguien patenta un dispositivo derivado? O se deriva un dispositivo de un diseño patentado? O se usa una parte patentada en un diseño?

Posted in Divulgació | Comentarios desactivados en Licencias Open Hardware

Una clase para Loggearlos a todos

Una buena forma de sacar información de lo que está pasando en nuestras simulaciones SystemC es generar un archivo de log con la distinta información que necesitemos (nombre del módulo, tiempo de simulación, qué se está enviado o recibiendo, etc.).

Para ello la forma más elegante y sencilla de hacerlo es crearse una clase especial para la tarea, que los demás módulos puedan usar para enviar sus información y ésta los grabe en un fichero. Esto se consigue diseñando una clase de tipo singleton. Este patrón de diseño restringe la creación de un solo objecto de una clase dada. En nuestro caso, hará que todos los módulos usen el mismo objecto.

Continue reading »

Posted in General | Tagged , , , | Comentarios desactivados en Una clase para Loggearlos a todos

Configurando Eclipse para desarrollar proyectos TLM-2.0

Hoy os explico cómo crear un proyecto en eclipse para desarrollar un proyecto en TLM-2 y SystemC, es muy fácil! Continue reading »

Posted in General | Tagged , , | Comentarios desactivados en Configurando Eclipse para desarrollar proyectos TLM-2.0

Ejemplo de Loosely-timed

Primero recordemos qué significa el estilo loosely-timed: en este estilo usamos la función bloqueante b_transport y por tanto tenemos dos puntos de sincronización asociados a cada transacción, que corresponden al inicio y al fin de la misma. Estos dos puntos pueden estar en el mismo tiempo de simulación o estar separados (en el caso de tener los dos puntos de sincronización en el mismo instante de simulación, estaríamos en el caso untimed). Continue reading »

Posted in Ejemplos | Tagged , , , , , | Comentarios desactivados en Ejemplo de Loosely-timed

Ejemplo DMI

Vamos con el Direct Memory Interface (DMI) que tenemos definido en TLM-2.0. DMI viene a ser «pasar» de transacciones, protocolos y todo eso. Es decir, el Target pasa un puntero de su región de memoria (o parte de ella) al Initiator para que acceda directamente sin usar transacciones. Así ganamos en velocidad de simulación, ya que todo es mucho más sencillo. Esto del DMI está enfocado a dispositivos tipo memoria (de ahi lo de Direct Memory Interface 😉 ) conectados a módulos que accedan muchísimas veces a esos dispositivos de memoria, como por ejemplo CPUs o DMAs. Pero no eso no quita que lo podamos usar en cualquiera de nuestros módulos :-).
Continue reading »

Posted in Ejemplos | Tagged , , | Comentarios desactivados en Ejemplo DMI

Loosely time y temporal decoupling

Este estilo de codificación permite tan sólo 2 puntos de tiempo en cada transacción, correspondientes a la llamada y al retorno de la función b_transport. (usando el protocolo base, esto se correspondo con el inicio de la petición y el inicio de la respuesta de la transacción).Podemos elegir que estos dos puntos sean el mismo (y la transacción ocurre en tiempo 0)
El tiempo que se pasa como parámetro en la función b_transport indica el tiempo de inicio (y de respuesta) de la transacción respecto al tiempo actual de simulación. En el uso normal (sin usar temporal decoupling), este valor será siempre 0. El target de la transacción puede usar wait() dentro de la función b_transport para simular su tiempo de respuesta, etc.

Continue reading »

Posted in General | Tagged | Comentarios desactivados en Loosely time y temporal decoupling

Ejemplo de Untimed

Vamos con el primer ejemplo…

Initiator

Empezamos con los includes de las cabeceras necesarias

#include 

using namespace sc_core;

#include "tlm.h"

#include "tlm_utils/simple_initiator_socket.h"

Primero incluimos systemc (previsible, eh?) y luego tlm.h (también previsible).

Por último incluimos el socket mas sencillo de todos para este ejemplo.

A continuación declaramos la classe Initiator

class Initiator: sc_module

{

public:

tlm_utils::simple_initiator_socket initiator_socket;

SC_HAS_PROCESS(Initiator);

Initiator(sc_module_name name_);

private:

void initiator_thread();

};

Continue reading »

Posted in Ejemplos | Tagged , , , , , | 1 Comment

Interfaces, sockets, DMI y demás

Interfaces

Cuando usamos el canal normal para comunicar un Initiator con un Target usamos los interfaces que se definen en TLM2.0. De hecho, un Initiator crea una transacción y la pasa como argumento al método del interface (ya sea bloqueante o no). Este método lo implementa el Target que recibe la transacción y hace con ella lo que deba (la ejecuta). Este camino se conoce como forward path. Una vez el Target ha ejecutado la transacción, debe retornar al Initiator, y puede hacerse de dos formas distintas: a través de llamadas a métodos desde el Target al Initiator (a este camino se le llama el backward path; o usando el retorno del método del interface (se conoce como return path).

Continue reading »

Posted in General | Tagged , , , | Comentarios desactivados en Interfaces, sockets, DMI y demás

Estilos de codificación (Coding Styles)

En TLM-2 se contemplan 3 modos distintos de modelado (llamados Coding Styles en los documentos oficiales) : Untimed, Loosely-timed y Approximately.timed. Cada uno de ellos sirve para un propósito determinado, y para modelar distintos tipos de sistemas. También debemos tener en cuenta el coste de simulación de cada modo (menos costoso Untimed, más costoso el Approximatelly-timed).

Continue reading »

Posted in General | Tagged , , , , | Comentarios desactivados en Estilos de codificación (Coding Styles)

Bienvenido

Empiezo este blog con la intención de hablar, comentar, informar, aprender sobre el mundo SystemC-TLM.

Posted in General | Tagged , | 1 Comment
Newer »