Usage of OCP in Memory Access Arbitration for a Digital Sampling Oscilloscope Traian TULBURE lecturer and Ph.D. candidate at Transilvania University of Brasov Dan NICULA professor at Transilvania University in Brasov, Romania site manager of eASIC subsidiary in Brasov, Romania 2 Paper Title Usage of OCP in Memory Access Arbitration for a Digital Sampling Oscilloscope Authors Traian TULBURE (email@example.com) Traian TULBURE is a lecturer and Ph.D. candidate at Transilvania University of Brasov. He graduated from Transilvania University in Brasov, Romania, Department of Electronics & Computers, in 2000 with MSc degree in Electronics & Computers. Graduation thesis “EDA tools for eASIC technology”. His research interests are in the area of VLSI design, HDL modelling, C/C++ programming, synthesis. Dan NICULA (firstname.lastname@example.org) Dr. Dan NICULA is a professor at Transilvania University in Brasov, Romania, Department of Electronics & Computers. He graduated the Polytechnic Institute of Bucharest, Romania, in 1990 with a MSc degree in Electronics. In 1997 he was awarded the PhD in Computer Sciences by Transilvania University. His research interests are mainly in the area of VLSI design and HDL RTL level modelling. Teaching duties include HDLs, microprocessors and digital electronics. He is an author of books regarding VHDL/Verilog. He is site manager of eASIC subsidiary located in Brasov, Romania Overview The current approach for designing an integrated circuit as SoC (System-on-Chip) is based on reusing the models for modules with a well-defined functionality. For easier interconnection, these IP cores should have an interface that obeys the rules of a standard socket. Open Core Protocol (OCP) is a common standard for intellectual property (IP) core interfaces, or sockets, which facilitate “plug and play” System-on-Chip (SoC) design. The paper presents the usage of OCP protocol for implementing a multi-port access memory with a single port SRAM. The study case is a Digital Sampling Oscilloscope (DSO) implemented on eASIC FlexASIC device. The general capabilities of the chip include a two-channel digital sampling oscilloscope (DSO) and an arbitrary waveform generator (AWG) in a single USB-powered module. The chip is implemented on structured eASIC fabric that includes single port SRAMs. The on-chip SRAM is shared between DSO and AWG. CPU access to the memory is necessary too. A timing multiplexing access to the memory was designed. The OCP protocol was chosen to provide access and arbitration of the SRAM access on a 96 bit wide data bus. 3 Introduction how we used OCP? Designed for FlexASIC FA600 device, eASIC’s DSO chip (project name “eScope”) uses all block SRAM (bRAM) memory available on the FlexASIC device to store the samples for both acquisition channels and the waveform generator channel. Because the bRAM memory has a single port and the memory must be accessed by three clients, a time multiplexing scheme was implemented. All available memory blocks on FA600 are configured as a 4kx96 memory, build from 12 bRAMs (4 rows x 3cols x 1kx32bit). The memory is directly connected to a bus converter (ocp2mem). The bus converter provides OCP access to the bRAM module. Figure 1: eScope memory module map The memory module is 96 bits wide and can store up to 8 data samples, 12 bit each. For double sampled channel mode, the data is composed from interleaved samples from both channels. Configuring the block memory as a wide data bus memory (96 bits) and clocked it at a high frequency internal clock (up to 210 MHz) assures 8 time slots of 12*210 Mbps. The 8 time slots are assigned to 3 types of actions: • 2 time slots are used by the trigger generator logic to store the data samples into the memory; • 1 time slot is used by the waveform generator logic to retrieve the waveform generation samples from the memory; • 6 time slots can be used by the USB host to read/write data samples. A project constraint was to make the memory access technology independent. This meant to provide memory access using a standard bus, not related with the memory implementation and interface. To achieve the memory access arbitration and a standard core interconnection the OCP solution was selected. This way, the time multiplexed usage of block memory can be easily improved to support larger memory size or A/D converters with a larger number of MSPS, in the future eScope versions. 4 The architecture DSO architecture and OCP position The eScope is designed around 9 modules and uses Open Core Protocol (OCP) as a standard for interconnecting the memory with three possible clients. The submodules are: • clkGen: clock/reset generator for eScope • adcInput: synchronizers for the data samples from ADC • dacOutput: FIFO synchronizers for the waveform data to DAC • trigGen: trigger generator includes an OCP initiator port • waveGen: waveform generator logic includes an OCP initiator port • hostIf: USB module host interface includes an OCP initiator port • sampleMem: block memory shared for storing data samples and wave generator data • ocpMerge: 3:1 combinatorial OCP merge with 3 OCP initiator ports and 1 OCP target port • ocp2mem: OCP to memory interface converter, includes an OCP target port The sub-modules interconnection is presented in figure 2: Figure 2: eScope internal architecture. OCP position. ocpMerge module implements a fixed-priority arbitration with a priority ordering of: • trigGen (highest priority); • hostIf; • waveGen (lowest priority). trigGen (trigger generator) initiates OCP write transactions to the sample memory. waveGen (wave generator) initiates OCP read transactions. hostIf (host interface) initiates both read and write OCP transactions. 5 Testing testing OCP busses eScope was tested using different scenarios randomly selecting all configuration parameters from sets that include all corner cases. The test environment, presented in Figure 2, includes a Matlab-Verilog simulation. The OCP busses were tested using OCP monitors and checkers. The OCP monitors were added in the top level test- bench and were used to check the OCP transactions. All internal OCP 96 bit wide busses are checked during RTL simulation. Also the dump files are checked and disassembled offline after the simulation has ended. Figure 3 presents the eScope test environment: Figure 3: ModelSim/Matlab/CoreCreator test environment The external ADC, DAC and CPU models read/write the sample data from external files. The validation of a selected scenario was done using MatLab scripts with same functionality as the HDL code, which use the same set of parameters and graphical display of the error. The error was computed as difference between the expected signal generated by MatLab and the signal wrote to file by the external Verilog models. The zero error defined the successful run of a scenario. Various testing scenarios are defined by eScope parameters controlled by a dummy model of the CPU and by the waveforms selected for ADC and HFIF input files. The values of eScope parameters and test waveforms are randomly selected from a set of predefined values. This selection is done in the Verilog test environment using a custom version of $random task. 6 Implementation eASIC technology specific The eTool design flow is illustrated in Figure 4. This design flow is based on the normal ASIC design flow for Standard-Cell design. This approach is designed to leverage existing ASIC design methodology and infrastructure as much as possible. Figure 4: eTool design flow Logic synthesis was performed with the Synopsys Design Compiler synthesis tool using an eASIC-provided Liberty-format synthesis library containing all of the two, three, four, and five input functions that can be implemented with combinations of LUT configurations in the eCell, as well as the inverting buffer models and a number of DesignWare components that have been optimally implemented in the eCell logic. The netlist produced by Design Compiler was passed through the eASIC-developed ‘technology mapping and packing’ tool (called eMap) that replaces the slower LUT-based functions with the faster nand and mux functions where possible, and then packs multiple functions into single eCells where possible. The netlist created by eMap was characterized with standard wire-load modelling before place and route for use with the Synopsys Primetime static timing analysis. Table 5 and table 6 presents the implantation of eScope on structured ASIC using the Synopsys flow: Clocks Synthesis (ns) Mapping (ns) Place &Route (ns) scClk 3.95 4.72 7.53 wgClk 3 4.43 5.42 hfClk 26.37 28.97 35.62 Table 5: eScope timing results Synthesis Mapping Place &Route (cells) (cells) (cells) 5945 3923 3923 Table 6: eScope area results The back-end design flow uses the eASIC-developed eMap and eVrouter tools to implement the final place and route. Parasitic extraction was performed to annotate the final netlist for back-end (signoff) static timing analysis using Primetime. In parallel, logicBIST vectors are created that are embedded in the final bitstream and Via Mask database. The bitstream assembly and the configuration via mask generation steps are performed using the eDK tools. Conclusions OCP usage benefits The usage of OCP standard busses in modelling a three port memory using only single port SRAM and time multiplexing was a factor that allowed developing of the eScope project in a short period of time. Designing of eScope was made easier also by reusing of OCP switch and ocp2mem converter from a previous design while the testing phase was enriched by the OCP monitors and checkers. References www.easic.com Covered by the following patents: US Patents: US 6,194,912; US 6,236,229; US 6,245,634; US 6,331,733; US 6,331,789; US 6,331,790; US 6,476,493; US 6,642,744; US 6,686,253; US 6,756,811; US 6,819,136; US 6,930,511; US 6,953,956; US 6,985,012. European Patents: EP 1 161 797 B1; EP 1 533 904 A1. eASIC, FlexASIC, eASICore and “The Configurable Logic Company” are registered trademarks of eASIC Corporation in the United States. eCore is an abbreviation of eASICore. Structured eASIC, eI/O, eCell, eUnit, eRAM, eTool, eGenPLD, eDebug, eMacroWare, eGenSim, eGenMem, eGenModule, eMµ are trademarks of eASIC Corporation in the United States. Other company and product names may be trademarks or registered trademarks of the respective owners with which they are associated. eASIC Corp. 2001 Walsh Avenue U.S. GOVERNMENT RESTRICTED RIGHTS Santa Clara Tel: 408-855-9200 info@eASIC.com Use, duplication, or disclosure by the United States Government is subject to the restrictions set forth in CA 95050, USA Fax: 408-855-9201 www.eASIC.com DFARS 252.227-7013 (c)(1)(ii) and FAR 52.227-19.
Pages to are hidden for
"Usage of OCP in Memory Access Arbitration for a"Please download to view full document