Скачать презентацию System C and Levels of System Abstraction Part Скачать презентацию System C and Levels of System Abstraction Part

d4bb885ff35b9f865e0e21e86aec2b0d.ppt

  • Количество слайдов: 22

System. C and Levels of System Abstraction: Part I System. C and Levels of System Abstraction: Part I

Levels of System Abstraction Ø Executable specification l l l Ø Translation of design Levels of System Abstraction Ø Executable specification l l l Ø Translation of design specification into System. C Independent of the proposed implementation Time delays if present denote timing constraints Untimed functional model (CP) l l l Separation of the specification into modules Communication between modules is point to point Communication usually via bounded FIFO • blocking read, blocking write l No time delays present in the model

Levels of System Abstraction Ø Timed functional model (CP + T) l l Processes Levels of System Abstraction Ø Timed functional model (CP + T) l l Processes communicate via point-to-point links Timing delays added to processes to reflect • Timing constraints • Latency of a particular implementation l l Timing delays added to FIFOs to model communication latencies Initial model for hardware/software trade-off analysis

Levels of System Abstraction Ø Transaction level model or Programmers view (PV) l Communication Levels of System Abstraction Ø Transaction level model or Programmers view (PV) l Communication modeled by function calls • • l Similar to transport level specification Bus burst mode of read/write FIFOs replaced by actual communication protocol Bus contention modeled but not with realistic timing Instruction set simulator for SW code (HW in timed process) • Register accurate l l Ø Memory map is defined Timing defined in terms of instruction set cycles Platform transaction model (or PV + T) l Interconnection architecture fully defined • Multiple clock cycles for bus communication • Can model bus arbitration overhead l l SW on ISS, HW in timed process Model is not pin accurate

Levels of System Abstraction Ø Behavioral hardware model (mainly for ASIC cores) l l Levels of System Abstraction Ø Behavioral hardware model (mainly for ASIC cores) l l Ø Pin accurate and functionally accurate at its boundaries Not clock accurate No internal structure Input to behavioral synthesis tool Pin accurate cycle accurate model (CA) l l l In addition to pin accurate it is also cycle accurate Does not necessarily have the internal structure SW ISS replaced by model that includes cache

Levels of System Abstraction Ø Register transfer level model l Pin accurate Cycle accurate Levels of System Abstraction Ø Register transfer level model l Pin accurate Cycle accurate Internal structure is defined

System Design Styles Ø Application specific standard product (ASSP) l l Intel IXP series System Design Styles Ø Application specific standard product (ASSP) l l Intel IXP series network processors TI OMAP platform

System Design Styles Ø Programming for application specific standard product (ASSP) l Architecture is System Design Styles Ø Programming for application specific standard product (ASSP) l Architecture is fixed • Multiple programmable units • Multiple application specific cores • Multiple memory interfaces l Objective : Map application on target platform • Maximize performance l Design proceeds from CP, CP+T, PV to final implementation

System Design Styles Ø Structured ASIC: IP based design style l Xilinx platform FPGA System Design Styles Ø Structured ASIC: IP based design style l Xilinx platform FPGA • Power. PC hardcores • Microblaze softcores • 18 bit Multipliers • Block RAMS • Rocket I/O transceivers

System Design Styles Ø Structured ASIC: IP based design style l Architecture is fixed System Design Styles Ø Structured ASIC: IP based design style l Architecture is fixed to a large extent • Flexibility in introducing HW cores l l IP blocks provided by vendor Designer generates new cores • Programmable units are fixed • Memory interfaces are fixed l Objective : Refine micro-architecture with an objective of • Maximize: performance • Minimize: cost, power l Design proceeds from CP, CP+T, PV+T, CA to final implementation

System Design Styles Ø Generic multiprocessor So. C design l Architecture is yet to System Design Styles Ø Generic multiprocessor So. C design l Architecture is yet to be defined • HW cores can consist of l l IP blocks provided by vendor Designer generates new cores • Multiple programmable units • Multiple memory interfaces l Objective : Design micro-architecture with an objective of • Maximize: performance • Minimize: cost, power l Design proceeds from CP, CP+T, PV+T, CA to final implementation

Executable Specification Any code in C or C++ can act as the executable specification Executable Specification Any code in C or C++ can act as the executable specification Ø The code is implementation agnostic Ø The code acts a functional benchmark for verification Ø Timing specified at input/output boundaries Ø l l Specified as design directive Code might be specified as one System. C process with timing

Untimed Functional Model Ø Design is specified in terms of its functional components Ø Untimed Functional Model Ø Design is specified in terms of its functional components Ø Functional components specify possible structural boundaries of final implementation Ø Some functional components might be merged while other might become discrete cores

Untimed Functional Model Ø Dataflow Mo. C is the most common form of specification Untimed Functional Model Ø Dataflow Mo. C is the most common form of specification l Alternatively Kahn process networks, Multi-rate dataflow Communication between components is through directed point-to-point FIFO Ø FIFO are bounded Ø l Ø Blocking read, blocking write Time delays might exist in the model at the boundaries l l Processes in which the model interacts with the environment Time delays denote constraints for the system

System. C Untimed Functional Model Modules contain SC_THREAD process Ø Modules communicate through sc_fifo System. C Untimed Functional Model Modules contain SC_THREAD process Ø Modules communicate through sc_fifo channels Ø l Ø Initial values in FIFOs should be specified Stop simulation when l Finite time has elapsed • Requires atleast one module with time delay l Terminate processes through data backlog • Thread returns when input FIFO is empty l Call sc_stop() when termination condition is reached • Easiest to implement • For example, consumption of finite set of input stimuli

System. C Untimed Functional Model Z-1 constant adder fork printer template <class T> SC_MODULE(DF_Const){ System. C Untimed Functional Model Z-1 constant adder fork printer template SC_MODULE(DF_Const){ sc_fifo_out output; T constant_; void process() { while(1) output. write(constant_); } SC_HAS_PROCESS(DF_Const); DF_Const(sc_module_name N, const T& C): sc_module(N), constant_(C) { SC_THREAD(process); } };

System. C Untimed Functional Model template <class T> SC_MODULE(DF_Adder){ sc_fifo_in<T> input 1, input 2; System. C Untimed Functional Model template SC_MODULE(DF_Adder){ sc_fifo_in input 1, input 2; sc_fifo_out output 2; void process() { while(1) { output. write(input 1. read() + input 2. read()); } } SC_CTOR(DF_Fork) { SC_THREAD(process); } }; template SC_MODULE(DF_Fork){ sc_fifo_in input; sc_fifo_out output 1; sc_fifo_out output 2; void process() { while(1) { T value = input. read(); output 1. write(value); output 2. write(value); } } SC_CTOR(DF_Fork) { SC_THREAD(process); } };

System. C Untimed Functional Model template <class T> SC_MODULE(DF_Printer){ sc_fifo_in<T> input; unsigned n_iterations_; bool System. C Untimed Functional Model template SC_MODULE(DF_Printer){ sc_fifo_in input; unsigned n_iterations_; bool done_; void process() { while(1) { For (unsigned i = 0; i < n_iterations_; i++) { T value = input. read(); cout << name() << “ “ << value << endl; } done = true; return; } SC_HAS_PROCESS(DF_printer); DF_Printer(sc_module_name NAME, unsigned N_ITER) : sc_module(NAME), n_interations_(N_ITER), done_(false); { SC_THREAD(process); } ~DF_Printer() { If (!done_) cout << name() << “ not done yet “ << endl; } };

System. C Untimed Functional Model int sc_main(int argc, char** argv) { DF_Const<int> constant(“constant”, 1); System. C Untimed Functional Model int sc_main(int argc, char** argv) { DF_Const constant(“constant”, 1); DF_Adder adder(“adder”); DF_Fork fork(“fork”); DF_Printer printer(“printer”, 10); sc_fifo const_out(“const_out”, 5); sc_fifo adder_out(“adder_out”, 1); sc_fifo feedback(“feedback”, 1); sc_fifo to_printer(“to_printer”, 1); feedback. write(42); constant. output(const_out); adder. input 1(feedback); adder. input 2(const_out); fork. input(adder_out); fork. outpu 1(feedback); fork. outpu 2(to_printer); printer. input(to_printer); sc_start(-1); return(0); } • Start simulation without time limit. • Simulation stops when no more events. • When printer thread exits simulation will stop. • All FIFOs will become full

System. C Timed Functional Model template <class T> SC_MODULE(DF_Const){ sc_fifo_out<T> output; T constant_; void System. C Timed Functional Model template SC_MODULE(DF_Const){ sc_fifo_out output; T constant_; void process() { while(1) { wait(200, SC_NS); output. write(constant_); } } SC_HAS_PROCESS(DF_Const); DF_Const(sc_module_name N, const T& C): sc_module(N), constant_(C) { SC_THREAD(process); } }; template SC_MODULE(DF_Adder){ sc_fifo_in input 1, input 2; sc_fifo_out output 2; void process() { while(1) { output. write(input 1. read() + input 2. read()); wait(200, SC_NS); } } SC_CTOR(DF_Fork) { SC_THREAD(process); } };

Stopping Dataflow Simulation Ø Simulate with fixed number of input stimuli and return l Stopping Dataflow Simulation Ø Simulate with fixed number of input stimuli and return l If a method thread is blocked due to a bug then simulation will not stop Ø Each process consumes a fixed amount of stimuli and sets a “done” signal l A “terminator” process issues “sc_stop()” when all processes have issued “done”

Levels of System Abstraction Ø To be continued Ø Detour into l l Hardware Levels of System Abstraction Ø To be continued Ø Detour into l l Hardware performance estimation System-level performance estimation