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 A model that is cycle-timing accurate for communication and for functionality is usually referred to as a register-transfer level (RTL) model. We refer to models with un-timed communication and functionality as a SAM. The RTL model is traditionally used for automatic synthesis to gates. Many times the SAM is used for algorithmic refinement and can be refined to approximately-timed communication and/or functionality. The other four points plotted on the graph are usually collectively referred to as TLMs, and rely on approximately-timed functionality or communication. Approximately-timed models can rely on statistical timing, estimated timing, or sub-system timing requirements (or budgets) derived from system requirements. A model with cycle-timed communication and approximately-timed functionality has been referred to as a Bus Functional Model(BFM) in older methodologies and the label is retained here. The three remaining TLMs have not yet developed commonly accepted names. For now, we will use the names developed by Gajski and Cai. All of these models are not necessary for most systems. In reality, most systems only need to progress through two or three points on the graph in Figure 2-1. With a language that supports refinement concepts, the transformation can be quite efficient.

Exemplo The timing diagram in Figure 2-2 illustrates one possible design outcome of a bus implementation. When first defining and modeling the system application, the exact bus-timing details do not affect the design decisions, and all the important information contained within the illustration is transferred between the bus devices as one event or transaction (componentassembly model). Further into the development cycle, the number of bus cycles may become important (to define bus cycle-time requirements, etc.) and the information for each clock cycle of the bus is transferred as one transaction or event (bus-arbitration or cycle-accurate computation models). When the bus specification is fully chosen and defined, the bus is modeled with a transaction or event per signal transition (bus functional or RTL model). Of course, as more details are added, more events occur and the speed of the model execution decreases. In this diagram, the component assembly model takes 1 “event,” the bus arbitration model takes approximately 5 “events,” and the RTL model takes roughly 75 “events” (the exact number depends on the number of transitioning signals and the exact simulator algorithm). This simple example illustrates the magnitude of computation required and why more system design teams are employing a TLM-based methodology.

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);

Benefícios em Tempo de Projeto Tempo necessário para escrever o TLM Verificação do SW começa mais cedo Verificação do Sistema começa mais cedo 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