Tópicos em System-Level Design

Tópicos em System-Level Design Transaction Level Modeling Sandro Rigo sandro@ic.unicamp.br 2o Semestre de 2006

Integração de Componentes • Diversos padrões disponíveis • Foco em baixo nível • AMBA, CoreConnect, Avalon, OCP/IP • Úteis para descrição do modelo final • Baixo desempenho em simulação • Transaction Level Model (TLM) • Chamadas de funções • Interface dos módulos muito bem definida • Distribuída junto com o SystemC

Terminologia para Abstração

Exemplo

Comentários • É necessário expor tantos detalhes nessa fase? • Como simplificar o processo? • Que tal TLM? outport.write(A1, D1); outport.write(A2, D2); outport.write(A3, D3);

Tempo necessário para escrever o TLM Verificação do SW começa mais cedo Verificação do Sistema começa mais cedo Benefícios em Tempo de Projeto Tempo Total é reduzido !

TLM – Motivação • Adiantar a disponibilidade de uma plataforma para desenvolvimento de software; • Exploração do projeto como um todo • Fornecer um modelo completo do sistema para verificação • Será utlizado o padrão OSCI TLM 1.0

Conceitos usados pelo TLM • Comunicação é modelada separado da funcionalidade • Foco nas interfaces • Implementação apenas após a definição rígida das interfaces • Bloqueantes x Não bloqueantes • Métodos bloqueantes podem chamar a função wait() • SC_THREAD x SC_METHOD • Unidirecional x Bidirecional • Toda transação pode ser classificada de uma dessas formas ou quebrada para se enquadrar numa delas • Transferência de dados é feita através de chamadas de funções

Nomenclaturas • Para evitar conflito com outras nomenclaturas já existentes, novos nomes foram criados • Initiator (≠ Master) • Target (≠ Slave) • Put (≠ write) • Get (≠ read) • Peek

TLM Core Interfaces // uni-directional blocking interfaces template < typename T > class tlm_blocking_get_if : public virtual sc_interface { public: virtual T get( tlm_tag<T> *t = 0 ) = 0; virtual void get( T &t ) { t = get(); } };

TLM Core Interfaces // uni-directional blocking interfaces template < typename T > class tlm_blocking_put_if : public virtual sc_interface { public: virtual void put( const T &t ) = 0; };

TLM Core Interfaces // uni-directional non blocking interfaces template < typename T > class tlm_nonblocking_get_if : public virtual sc_interface { public: virtual bool nb_get( T &t ) = 0; virtual bool nb_can_get( tlm_tag<T> *t = 0 ) const = 0; virtual const sc_event &ok_to_get( tlm_tag<T> *t = 0 ) const = 0; };

TLM Core Interfaces // uni-directional non blocking interfaces template < typename T > class tlm_nonblocking_put_if : public virtual sc_interface { public: virtual bool nb_put( const T &t ) = 0; virtual bool nb_can_put( tlm_tag<T> *t = 0 ) const = 0; virtual const sc_event &ok_to_put( tlm_tag<T> *t = 0 ) const = 0; };

TLM Core Interfaces // bidirectional blocking interfaces template < typename REQ , typename RSP > class tlm_transport_if : public virtual sc_interface { public: virtual RSP transport( const REQ & ) = 0; }; OBS: Pode ser visto como uma união das interfaces bloqueantes de get e put.

Canais TLM • O pacote padrão inclui três canais: • tlm_fifo<T>: implementa todas as interfaces unidirecionais • tlm_req_resp_channel<REQ,RSP>: consiste de duas fifos • intiator-target (master_if): • fornece put para fila de REQ e get para fila de RSP • target-initiator(slave_if): • fornece put para fila de RSP e get para fila de REQ

Canais TLM • O pacote padrão inclui três canais: • tlm_transport_channel<REQ,RSP>: cada REQ ligado a uma RSP • exporta as mesmas interfaces que o tlm_req_rsp_channel • implementa a interface bidirecional de transporte

Canais TLM RSP transport( const REQ &req ) { mutex.lock(); master_port->put( req ); rsp = master_port->get(); mutex.unlock(); return rsp; }

Exemplo: O Protocolo TLM de ArchC • Possibilita a conexão dos simuladores gerados por ArchC a módulos externos • Totalmente baseado no padrão de SystemC v1.0 • Implementa a interface de transporte • bidirecional • bloqueante

Exemplo: O Protocolo TLM de ArchC • ac_tlm_protocol.H • ac_tlm_port.H • ac_tlm_port.cpp

Modelagem em três camadas • Usuário • API de conveniência, específica do protocolo • Protocolo • Código específico de protocolo • Faz a ponte entre as camadas de usuário e a de transporte • Transporte • Usa APIs e modelos genéricos de transporte de dados • Facilita a interoperabilidade dos modelos • Trabalho do TLM WG é definir código da camada de transporte

API ArchC – Modelo 3 camadas

Referências • SystemC from the Ground-up - David C. Black e Jack Donovan, Kluwer Academic Press, 2004 • Transaction Level Modeling in SystemC – Adam Rose, Stuart Swan, John Pierce, Jean-Michel Fernandez, OSCI TLM Working Group • SystemC Tutorial. Forte Design Systems. http://www.forteds.com

Tópicos em System-Level Design