Usage of OCP in Memory Access Arbitration for a by fzk93926

VIEWS: 14 PAGES: 8

									           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 (traian@easic.ro)
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 (dan@easic.ro)
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.

								
To top