Licenses 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?

A class to Log them all

A good way to retrieve information of what is happening in our SystemC simulations is to generate a log file with the information that we need (module name, simulation time, what phase is going on, etc.).

The most elegant and easy way to do that is to create a special class for that task, that the other modules in the simulation can use to send their information and to be stores in disk. This can be achieved designing a singleton type class. This design pattern restricts the instantiation of a class to one single object. In our case, it will cause that all modules use the same object and log file.

Continue reading A class to Log them all

Ejemplo de Loosely-timed example

First of all, I should remember you what means loosely-timed: we use the blocking function b_transport and therefore we have two synchronization points per transaction, that corresponds to the beginning and the end of the transaction. These two points  can be in the same simulation time or in different simulation time. In case we have the two synchronization points in the same simulation time, we are using untimed).

Continue reading Ejemplo de Loosely-timed example

A DMI example

Let’s go with the Direct Memory Inteface (DMI) defined in TLM-2.0. DMI mechanism in roughly speaking is to pass over transactions, protocols and so on. In short, the Target sends a pointer to its memory region (o part of it) to the Initiator to allow him to that memory region directly, without using transaction. This way, we speed up the simulation, because everything is more easy.  DMI is focsed on memory type devices connected to modules that are accessing very frequently to that memory devices, like CPUs or DMAs. But the mechanism is there, and we can use it in any of our modules.
Continue reading A DMI example

Loosely time and temporal decoupling

This coding style works with 2 timing points in each transaction, one in the function call and the other in the return for the b_transport function (using the base protocol these points corresponds to the start of the petition and the start of the response). We can put these two points in the same time to mark that the transaction is not using time.

Continue reading Loosely time and temporal decoupling

Untimed example

Let’s start with the first example…

Initiator

We shall start with the include’s

#include 

using namespace sc_core;

#include "tlm.h"
#include "tlm_utils/simple_initiator_socket.h"

Firstly we include systemc and then tlm.h
Then we include the easiest socket for that example.
Now it’s time to declare the Initiator class

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 Untimed example

Blog Màrius Montón