JOP-Java Optimized

Processor
História do Java em Real-Time
1992 Oak for *7
1995 Java for the Internet
1996 Nilsen: First Paper on Real-Time Java
1997 picoJava, PersonalJava
1998 EmbeddedJava, RTSJ Start

2000 J2EE: Server Applications

2000 J2ME: Java for Mobile Phones
2002 RTSJ Final Release

2003 JTime

Java for Desktop Applications Embedded Systems

Características:
• O JOP é de código aberto sob a
GNU General Public License,
versão 3.
• A linguagem são: VHDL, Java,
Microcode, C, (Verilog);
• Processor pipeline;
• Microcode;
Características da linguagem que trariam problemas para
se tentar desenvolver sistemas de tempo-real

• Garbage collector: Esta funcionalidade do Java a princípio pode parecer ser uma boa
ferramenta para um sistema em tempo-real. Afinal, liberaria recursos de memória – muitas
vezes escassos – para o sistema. Porém se, por exemplo, sua custosa execução entrasse
em ação no momento em que uma tarefa crítica do sistema tivesse que ser realizada. Esses
tipo de comportamento é inaceitável.
• Threads : Java tem um modelo inserido para concorrência, que simplifica a programação
concorrente porém a definição destas funcionalidades são muito vagas para sistemas de
tempo-real. O comportamento das threads é definido de forma muito fraca, permitindo por
exemplo, que processos de menor prioridade preemptem outros de maior prioridade ou
mesmo uma implementação sem preempção é permitida. Isto protege as threads de
problemas como starvation mas não é aceitável em sistemas de tempo real.
• Controle e acesso de memória: Java traz restrições no acesso a memória. E certo
desperdício quando por exemplo, faz alocação dinâmica de classes, a resolução e verificação
de classes é uma função complexa, consome memória e seu tempo de execução é
praticamente impossível de prever.
• Outros problemas: sincronização de recursos, tamanho das bibliotecas, etc.
ESPECIFICAÇÃO JAVA PARA TEMPO REAL
O sucesso e aceitação da linguagem e a proposta inicial do Java que era para sistemas
embarcados, foi criado um grupo de peritos para estudar o melhoramento de Java para
sistemas de tempo real. O RTJEG (Real-Time for Java Expert Group) publicou em
novembro de 2001 a especificação de Java para Tempo Real – Real Time Specification
for Java (RTSJ).
A Sun deixou a implementação desta especificação a cargo da empresa americana
TimeSys. Em 2003 saiu a primeira implementação comercial, com uma implementação
de referência (Reference Implementation – RI) e um Technology Compatibility Kit
(TCK). Em 2005 a versão 1.0.1 e a versão atual é a 1.0.2. A JSR-282 (Java
specification request) que implementa melhorias foi aceita para uma versão 1.1 da
especificação.
A RSSJ traz algumas modificações para tempo
real:
• Threads e escalonamento: Um escalonador preemptivo básico, é definido, com 28
prioridades. Podendo outros escalonadores (como EDF) serem carregados
dinamicamente. Novas classes de threads são definidas: RealtimeThread acessa
todas as regiões de memória e é afetada pelo coletor de lixo;
NoHeapRealtimeThread só acessa a memória do escopo e pode sempre preemptar
o coletor de lixo(nunca é atrasada por ele); AsyncEventHandlers para tratar eventos,
pode ter prioridade maior que o coletor. Todas elas acabam sendo eventos
escalonáveis.
• Memória: Como o Garbage collector é problemático em aplicações de tempo real, a
RSTJ define novas regiões de memória. Immortal memory é a memória
compartilhada por todas as threads, sem coletor de lixo e permanece até o término
do programa. Scooped memory memória onde os objetos são alocados até que a
última thread a “deixe”. Phisycal memory usada para controlar a alocação em
memórias com tempo de acesso diferentes. Raw memory para acesso de memória a
nível de byte e mapeamentos de I/O.
A RSSJ traz algumas modificações para tempo
real:
• Sincronização: Herança de prioridade para controlar inversão de prioridades
• Eventos assíncronos: para conectar com os Asynchronous Event Handlers. Os
eventos podem ser disparados arbitrariamente por um método fire(), por
temporizadores, por sinais ou por ocorrências.
• Transferência de controle assíncrona: exceções de interrupção podem ser lançadas
por cada thread em uma thread específica. É segura, pode ser desabilitada (por
default) ou ativada em determinada thread.
Java virtual machine (JVM);
• Java virtual machine (JVM);
• Um conjunto de instruções - os
bytecodes;
• Um formato binário - o arquivo de
classe;
• Um algoritmo para verificar o
arquivo de classe;
O JOP foi conduzido com sucesso
para vários FPGAs e placas
diferentes. As principais placas
FPGAs utilizadas são:
• Altera Cyclone EP1C6 ou
EP1C12;
• Xilinx Spartan-3;
• Altera Cyclone-II (placa Altera
DE2);
• Xilinx Virtex-4 (placa ML40x);
• Xilinx Spartan-3E (placa
Digilent Nexys 2);
Outros Sistemas em tempo real que utiliza o
JVM
• picoJava
• SUN, never released

• aJile JEMCore
• Available, RTSJ, two versions

• Komodo
• Multithreaded Java processor

• FemtoJava
• Application specific processor
Performance
picoJava aJile Komodo FemtoJava JOP

Predictability -- . - . ++

Size -- - + - ++

Performance ++ + - -- +

JVM conf. ++ + - -- .

Flexibility -- -- + ++ ++
Processadores FPGA
Processor Resources Memory fmax
[LC] [KB] [MHz]
JOP min. 1077 3.25 98
JOP typ. 1831 3.25 101
Lightfoot 3400 1 40
Komodo 2600 - 33/4
FemtoJava 2000 - 4
NIOS 2923 5.5 119
SPEAR 1700 8 80
Microcode

JOP tem um único conjunto instrução

nativa, o chamado microcódigo.
Durante a execução, cada bytecode
Java é traduzido para uma ou uma
sequência de instruções de
microcódigo. Essa tradução apenas
adiciona uma pipeline para o
processador central e não resulta em
despesas gerais de execução
 Microcode
dup: dup nxt // 1 to 1 mapping
 Stack-oriented;
// a and b are scratch variables
 Compacto; // for the JVM code.

 Tamanho Constante ; dup_x1: stm a // save TOS

stm b // and TOS−1
 Ciclo de máquina simples;
ldm a // duplicate TOS
 Acesso as funções Low-level ; ldm b // restore TOS−1
ldm a nxt // restore TOS
// and fetch next bytecode
Processor Pipeline
 Interrupção public class InterruptHandler
implements Runnable {
public static void main(String[] args) {
 Interrupt logic at bytecode translation // get factory
InterruptHandler ih = new
 Bytecode especiais InterruptHandler();
fact . registerInterruptHandler (1, ih );
 Transparencia para o núcleo pipeline
// enable interrupt 1
 Interrupção e escalonamento: fact .enableInterrupt (1);
// start normal work
 Prioridade para o dipostivo no drivers }
public void run() {
 Não adicionais blocos de tempo;
// do the first level interrupt handler
 Integração de analise de escalonamento work
}
 Jitter free timer events; }
 Limite para a thread
 Escalonamento
• Três tipo de classes:
public class RtThread {
public RtThread(int priority, int period)
...
public RtThread(int priority, int period,
int offset, Memory mem)

• RtThread, HwEvent and public void enterMemory()

public void exitMemory()
SwEvent public void run()
public boolean waitForNextPeriod()
• periódicos e esporádicos public static void startMission()
threads; }

public class HwEvent extends RtThread {

• Preemptive; public HwEvent(int priority, int minTime,

Memory mem, int number)
public void handle()

• Prioridade fixa; }

public class SwEvent extends RtThread {

public SwEvent(int priority, int minTime,
Memory mem)
public final void fire()
public void handle()
}
Escalonamento
• Prioridade fixa com estrita ordem monotónica;
• Protocolo de emulação de teto prioritário;
• Prioridade máxima para objetos não atribuídos;

• Interrompe sob o controle do Escalonador

• Prioridade para drivers de dispositivo
• Sem tempo de bloqueio adicional;
• Integração na análise de planejamento;
Protocolo Herança de Prioridade (PHP)

• Protocolo de herança prioritária:

• As Tarefas são escalonadas pela sua prioridade estática enquanto não
existir recurso bloqueado.
• Quando existe recurso bloqueado, a tarefa em sessão crítica herda
prioridade das tarefas mais prioritárias.
Protocolo Herança de Prioridade (PHP)
Pedido de entrada em SC

Entrada em SC

Herda Prioridade P1
Fim de Execução da Sessão
Crítica

Executando em
SC
Inversão de prioridade
• Protocolo de emulação de teto prioritário:
• Cada recurso possui uma prioridade teto (prioridade igual a da tarefa mais prioritária
que pode alocar o recurso).
• Se nenhum recurso compartilhado está bloqueado, quem requisita é atendido.
• Se alguma tarefa bloqueia outra mais prioritária, a menos prioritária herda sua
prioridade.
• No caso de haver recurso em uso:
• A tarefa que solicita só consegue acesso ao recurso solicitado se sua prioridade for maior
que a prioridade teto de todos os recursos em uso alocados por outras tarefas.
Protocolo de Prioridade Teto
Seja P1 > P2 > P3
P1
Legenda para os recursos
RC1 (Prioridade Teto = P1)
RC2 (Prioridade Teto = P1)
RC3 (Prioridade Teto = P2)
Tempo de término

P2

P3 P2 P3
Garbage Collection para JOP
• O coletor pode operar em dois modos:
• (1) como coletor de stop-the-world disparado na alocação quando o
heap está cheio, ou
• (2) como colecionador concorrente em tempo real executando no
seu próprio thread.
• O coletor em tempo real é programado periodicamente na menor
prioridade e dentro de cada período
Collector para JOP
•Flip -troca as synchronized (mutex) {
useA = !useA;
if (useA) {
funções de copyPtr = heapStartA;
fromSpace = heapStartB;
tospace e toSpace = heapStartA;
} else {
fromspace. copyPtr = heapStartB;
fromSpace = heapStartA;
toSpace = heapStartB;
}
allocPtr = copyPtr+semi size;
}
Collector para JOP
Root Marking -Todas as
referências estáticas são
empurradas para a pilha. Apenas
uma única operação push
precisa ser atômico. À medida
que as pilhas do thread estão
vazias, não precisamos de uma
varredura de pilhas de threads.
int addr =
Native.rdMem(addrStaticRefs);
int cnt =
Native.rdMem(addrStaticRefs+1);
for ( i=0; i<cnt; ++i) {
push(Native.rdMem(addr+i));
} if (Native.rdMem(ref+OFF GREY)!=0) {
return;
}
if (Native.rdMem(ref+OFF GREY)==0) {
// pointer to former gray list head
Native.wrMem(grayList, ref+OFF
GREY);
grayList = ref ;
}
 } else if (flags==IS OBJ){
// its a plain object
// get pointer to method table
for (;;) {
Collector para JOP // pop one object from the gray list
synchronized (mutex) {
flags = Native.rdMem(ref+OFF MTAB ALEN);
// get real flags
flags = Native.rdMem(flags+MTAB2GC INFO);
ref = grayList ; for ( i=0; flags!=0; ++i) {
if ( ref==GREY END) { if (( flags&1)!=0) {
Mark and Copy-Um break;
}
push(Native.rdMem(addr+i));
}
objeto é exibido da pilha, grayList = Native.rdMem(ref+OFF GREY);
// mark as not in list
flags >>>= 1;
}
todos os objetos Native.wrMem(0, ref+OFF GREY);
}
}
// now copy it − color it BLACK
// push all childs
referenciados, que // get pointer to object
int addr = Native.rdMem(ref);
int size = Native.rdMem(ref+OFF SIZE);
synchronized (mutex) {

ainda estão brancos, são int flags = Native.rdMem(ref+OFF TYPE);

if (flags==IS REFARR) {
// update object pointer to the new location
Native.wrMem(copyPtr, ref+OFF PTR);

empurrados para a pilha, // is an array of references

int size = Native.rdMem(ref+OFF MTAB ALEN);
// set it BLACK
Native.wrMem(toSpace, ref+OFF SPACE);

o objeto é copiado para o for ( i=0; i<size; ++i) {

156 7 REAL-TIME GARBAGE COLLECTION
// copy it
for ( i=0; i<size; ++i) {
Native.wrMem(Native.rdMem(addr+i), copyPtr+i);
espaço, push(Native.rdMem(addr+i)); }
} copyPtr += size;
o ponteiro é atualizado }
}

Collector para JOP
Sweep handles-Todas as listas
de uso são verificadas se ainda
apontarem para o Tospace (ou
podem ser adicionados à lista
livre.
synchronized (mutex) {
ref = useList; // get start of the list
useList = 0; // new uselist starts empty
}
while ( ref !=0) {
7.4 IMPLEMENTATION 157
int next = Native.rdMem(ref+OFF NEXT);
// a BLACK one
if (Native.rdMem(ref+OFF SPACE)==toSpace) {
// add to used list
synchronized (mutex) {
Native.wrMem(useList, ref+OFF NEXT);
useList = ref ;
}
// a WHITE one
} else {
// add to free list
synchronized (mutex) {
Native.wrMem(freeList, ref+OFF NEXT);
freeList = ref ;
Native.wrMem(0, ref+OFF PTR);
}
}
ref = next;
}
Collector para JOP
Clear Fromspace-Ao final do for ( int i=fromSpace;
trabalho do coletor, o espaço que i<fromSpace+semi size; ++i) {
contém apenas branco
Os objetos são inicializados com Native.wrMem(0, i);
zero. Os objetos alocados nesse
espaço (após o próximo flip) são
já inicializado e a alocação pode ser }
realizada em tempo constante.
Para reduzir o tempo de bloqueio,
uma unidade de hardware executa
cópias de objetos e arrays em um
interruptible a e registra a posição
de cópia em uma interrupção
Worst-case execution time (WCET)
• As estimativas de tarefas do tempo de execução do pior caso (WCET)
são essenciais para projetar e verificar sistemas em tempo real. JOP
foi projetado para ser fácil alvo para a análise WCET. O WCET de cada
bytecode pode ser previsto em termos de número de ciclos que
requer. Não há dependências de tempo entre bytecodes.
• A análise WCET deve ser feita em dois níveis: no nível do microcódigo
e no bytecode. A análise do microcódigo WCET é realizada apenas
uma vez para uma configuração do processador. O resultado dessa
análise de microcódigo é o tempo modelo do processador. O modelo
de tempo é a entrada para a análise do WCET no bytecode
nível (ou seja, o aplicativo Java)
SimpCon
• é uma especificação para uma conexão simples e eficiente de sistema em
chip (SoC). O SimpCon fornece comandos e provisões de ciclo único para
pipelining de conexões de leitura e gravação.
• O SimpCon é um padrão totalmente síncrono para interconexões no chip. É
uma conexão ponto-a-ponto entre um mestre e um escravo. O mestre
inicia uma leitura ou escrita transação. Os comandos mestres são de ciclo
único para liberar o mestre para continuar no interno operações durante
uma transação pendente. O escravo deve registrar o endereço quando
necessário para mais de um ciclo. O escravo também registra os dados em
uma leitura e fornece para o mestre por mais de um único ciclo. Esta
propriedade permite ao mestre atrasar o leitura real se estiver ocupada com
operações internas. O escravo sinaliza o fim da transação através de um
novo contador pronto para fornecer
 entity sc test slave is generic (addr bits : integer );
port (
clk : in std logic ;
reset : in std logic ;
−− SimpCon interface
SimpCon wr data : in std logic vector (31 downto 0);
rd, wr : in std logic ;
rd data : out std logic vector (31 downto 0);
• Conexão ponto-a-ponto mestre / escravo; rdy cnt : out unsigned(1 downto 0);
−− input/output ports
in data : in std logic vector (31 downto 0)
• Operação síncrona; out data : out std logic vector (31 downto 0)
); end sc test slave;
• Leia e escreva transações; architecture rtl of sc test slave is
begin
• Rápido lançamento do pipeline para o rdy cnt <= ”00”; −− no wait states
process(clk, reset) begin
mestre; if (reset=’1’ ) then
rd data <= (others => ’0’);
• Transações com pipeline; out data <= (others => ’0’);
elsif rising edge(clk ) then
• Especificação de fonte aberta; if rd=’1’ then
rd data <= in data;
end if ;
• Custos de implementação baixos; if wr=’1’ then
out data <= wr data;
end if ;
end if ;
end process;
end rtl ;
 Os seguintes arquivos VHDL devem ser compilados na
seguinte ordem:

Simulação simulação / sim_jop_types_100.vhd

simulação / sim_ram.vhd
simulação / sim_pll.vhd

• VHDL com ModelSim

simulação / sim_jbc.vhd
simulação / sim_rom.vhd
simulação / sim_memory.vhd
simulação / sim_uart.vhd
• Alto Nivel com JopSim jtbl.vhd
bcfetbl.vhd
offtbl.vhd
core / cache.vhd
core / mem32.vhd
core / mul.vhd
core / extension.vhd
core / bcfetch.vhd
core / fetch.vhd
core / decode.vhd
core / shift.vhd
core / stack.vhd
core / core.vhd
io / cnt.vhd
io / iomin.vhd
top / jopcyc.vhd
simulação / tb_jop.vhd
Aplicações
• Kippfahrleitung
• Distributed motor control
• ÖBB
• Vereinfachtes Zugleitsystem
• GPS, GPRS, supervision
• TeleAlarm
• Remote tele-control
• Data logging
• Automation

VSIS
 Aplicações
• Kippfahrleitung
• Na carga ferroviária, uma grande quantidade de tempo é
gasto no carregamento e descarga de vagões de mercadorias.

• O fio de contato acima dos vagões é o principal obstáculo.

Balfour Beatty Austria desenvolveu e patenteou uma solução
técnica, a chamada Kippfahrleitung, para inclinar o contato
fio.

• O sistema de inclinação mecânica conduzido por um sistema

assíncrono motor (logo abaixo do tubo preto). A pequena caixa
montada no mastro contém o sistema de controle. O cabo
preto é a interligação de rede de todos os sistemas de
controle.

• O fio de contato está inclinado em uma distância de até um

quilômetro. Para uma distância máxima de 1 km, todo o
sistema é composto por 12 mastros. Cada mastro é inclinado
por um assíncrono motor.
 Aplicações
• A principal tarefa do programa é medir a posição usando o
sensor giratório e para comunique-se com a estação base em
restrições em tempo real.

• O sistema é composto por sensores de extremidade e

rodação, tensão e alimentação dos motores.

• A ferramenta de análise WCET para Java estava disponível

• Não há interrupções ou dispositivos de acesso directo à

memória (DMA) que possam influenciar a execução

• A comunicação é baseada em um modelo mestre / escravo.

Somente a estação base (o mestre) é Permitiu enviar um
pedido para uma única estação de mastro. Esta estação é
então obrigada a responder dentro do tempo limite.

• Se ocorrer um erro irrecuperável, a estação base desliga a

energia para todas as estações de mastro, incluindo as fontes
de alimentação para os motores.
 TeleAlarm

TeleAlarm (TAL) é uma unidade terminal típica remota de

um controle de supervisão e aquisição de dados
(SCADA). É utilizado pelo fornecedor de energia da
Áustria EVN (eletricidade, gás e aquecimento) para
monitorar a planta de distribuição. O TeleAlarm também
inclui portas de saída para controle remoto de válvulas de
gás.
 TeleAlarm

Hardware
O dispositivo TAL consiste em um módulo CPU FPGA e
uma placa de E / S. O módulo FPGA contém um
dispositivo Altera Cyclone, 1 MB de memória estática, 512
KB Flash e 32 MB NAND Instantâneo. A placa de E / S
contém várias portas de entrada e saída digitais
protegidas EMC, duas 20 portas de entrada mA, conexão
Ethernet e uma interface serial. Além disso, o dispositivo
executa o carregamento de uma bateria recarregável para
sobreviver a falhas de desligamento. Ao desligar,
um evento importante para um fornecedor de energia, um
alarme é enviado. A bateria recarregável também é
monitorado e o dispositivo se desliga quando o limite de
tensão mínimo é alcançado.
Este evento é enviado para o sistema SCADA antes que
o poder seja desligado.
 TeleAlarm

A comunicação entre o TAL e o sistema principal de

controle de supervisão é realizada
com um protocolo proprietário. Em uma mudança de
valor, o TAL envia os novos dados para a central
sistema. Além disso, as unidades remotas são
consultadas pelo sistema central em uma base regular. o
O próprio TAL também envia o estado atual regularmente.
TAL pode se comunicar via Internet / Ethernet,
um modem e via SMS para um telefone celular.
O mesmo hardware também é usado para um projeto
diferente: um controle de elevação em uma automação
fábrica na Turquia. O software de controle de elevação
simples agora é usado como uma caixa de teste para a
ferramenta WCET
 Apoio ao controle ferroviário de via
única
Outra aplicação do JOP está em um dispositivo de
comunicação com propriedades em tempo real macias -
Austrian Railways '(O¨ BB) novo sistema de suporte para
linhas de pista única. O sistema ajuda a
superintendente na estação ferroviária para acompanhar
todos os trens na pista. Ele pode enviar
comandos aos motoristas dos trens individuais. Além
disso, o dispositivo verifica o
posição atual do trem e gera um alarme quando o trem
entra em um segmento de trilha
sem uma autorização.
 Apoio ao controle ferroviário de via
única
Outra aplicação do JOP está em um dispositivo de
comunicação com propriedades em tempo real macias -
Austrian Railways '(O¨ BB) novo sistema de suporte para
linhas de pista única. O sistema ajuda a
superintendente na estação ferroviária para acompanhar
todos os trens na pista. Ele pode enviar
comandos aos motoristas dos trens individuais. Além
disso, o dispositivo verifica a posição atual do trem e
gera um alarme quando o trem entra em um segmento
de trilha sem uma autorização.
Quando um trem entra em um segmento não permitido
todos os trens nas proximidades são
avisados ​automaticamente. Este aviso gera um alarme
na locomotiva e o motorista tem que realizar uma parada
emergêncial.
 Apoio ao controle ferroviário de via
única
A estação ferroviária está ligada à Intranet da empresa
ferroviária., no qual está conectado à Internet via GPRS
e a um GPS. Cada locomotiva que entra na pista está
equipada com uma ou duas desses terminais.
Deve-se notar que este sistema não é um sistema de
segurança crítica. A comunicação sobre uma rede
pública de telefonia móvel não é confiável e o sistema
não está certificado para segurança.
 Apoio ao controle ferroviário de via
única
Hardware
Cada locomotiva está equipada com um receptor GPS,
um modem GPRS e a comunicação
dispositivo (terminal). O terminal é um dispositivo
personalizado. O módulo FPGA é o mesmo que
Na TAL, somente a placa de E / S é adaptada para esta
aplicação. A placa de E / S contém vários
interfaces de linha serial para o receptor GPS, o modem
GPRS, depuração e download, e
exibir conexão. As portas de E / S auxiliares conectadas
a relés são reservadas para uso futuro. UMA
A extensão possível é parar o trem automaticamente
 Apoio ao controle ferroviário de via
única
Comunicação
A posição atual do trem é medida com GPS e o
segmento de trilha atual é calculado. O número deste
segmento é regularmente enviado para a estação
central. Para aumentar a precisão da posição, os dados
diferenciais de correção GPS são transmitidos ao
terminal.
Os dados do GPS diferencial são gerados por uma
referência de base localizada na central
estação.
A troca de posições, comandos e mensagens de alarme
é realizada através de rede de telefone (via GPRS). A
conexão é protegida através de uma rede privada virtual
que é encaminhado pelo provedor da rede móvel para a
Intranet da empresa ferroviária.
 Apoio ao controle ferroviário de via
única
Comunicação
O prazo para a comunicação de mensagens importantes
estão no intervalo de vários segundos. Após várias
tentativas não-bem-sucedidas o operador é informado
sobre o erro de comunicação. Ele é o responsável pelo
desempenho as ações necessárias.
Além do protocolo específico da aplicação, um servidor
TFTP é implementado no terminal.
Referências bibliograficas

http://www.jopdesign.com/thesis/index.jsp
http://www.jopdesign.com/download.jsp
http://www.jopdesign.com/docu.jsp