The current approach for designing an integrated circuit in the form of a System-on-Chip (SoC) is based on reusing the models for modules with a well-defined functionality. For easier interconnection, these intellectual property (IP) cores should have an interface that obeys the rules of a standard socket.
The Open Core Protocol (OCP) is a common standard for IP core interfaces, or sockets, which facilitates the concept of "plug and play" design for SoCs. This paper presents the use of the OCP with regard to implementing a multi-port access memory with a single port SRAM. The study case is a digital sampling oscilloscope (DSO) implemented on a FlexASIC device from eASIC. The general capabilities of the chip include a two-channel digital sampling 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 SRAM blocks. The on-chip SRAM is shared between the DSO and the AWG. Furthermore, the CPU also requires access to the memory; thus, a time-multiplexed memory access subsystem was designed. The OCP protocol was chosen to provide access and arbitration of the SRAM access on a 96 bit wide data bus.
Introduction: How we used the OCP
Designed for implementation on the FlexASIC FA600 device, eASIC's DSO chip (project name "eScope") uses all of the available block SRAM (bRAM) memory to store the samples for both the data acquisition channels and the waveform generator channel. Due to the fact that the bRAM memory has a single port and the memory must be accessed by three clients, a time-multiplexing scheme was implemented.
In the case of this design, all of the available memory blocks on the FA600 are configured as a 4k × 96 memory, which was formed from 12 bRAMs (4 rows × 3cols × [1k × 32bit]) (Fig 1). The memory is directly connected to a bus converter (ocp2mem), which provides OCP access to the bRAM module.
1. Memory module map for the eScope.
The 96-bit wide memory module can store up to eight 12-bit data samples. In the case of a double-sampled channel mode, the data is composed from interleaved samples from both channels.
Configuring the block memory as a 96-bit wide data bus and clocking it with a high-frequency internal clock (up to 210 MHz) assures eight time slots of 12 × 210 Mbps, where these eight time slots are assigned to three different types of actions as follows:
- Two time slots are used by the trigger generator logic to store the data samples into the memory.
- One time slot is used by the waveform generator logic to retrieve the waveform generation samples from the memory.
- Six time slots can be used by the USB host to read/write data samples.
One constraint associated with the project was to make the memory access technology independent. This meant providing memory access using a standard bus that was not tied to the memory implementation and interface. It was for this reason that the OCP solution was selected to provide the memory access arbitration and standard core interconnection.
Using this approach means that the time-multiplexed usage of the block memory can be easily enhanced to support larger memory sizes or A/D converters with a larger number of mega-samples-per-second (MSPS) in future versions of the eScope.
The DSO architecture
The eScope is designed around nine sub-modules and uses the OCP as the standard mechanism for interconnecting the memory with three possible clients. These nine sub-modules are as follows:
- clkGen: Clock/reset generator for the eScope.
- adcInput: Synchronizers for the data samples from the ADC.
- dacOutput: FIFO synchronizers for the waveform data to the 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 three OCP initiator ports and one OCP target port.
- ocp2mem: OCP to memory interface converter (includes an OCP target port).
The internal architecture of the eScope and the interconnection of its sub-modules is illustrated in Fig 2. Note that the ocpMerge module implements a fixed-priority arbitration with a priority ordering as follows:
- trigGen (highest priority)
- waveGen (lowest priority)
Also note that the trigGen (trigger generator) module initiates OCP write transactions to the sample memory; the waveGen (wave generator) module initiates OCP read transactions; and the hostIf (host interface) module initiates both read and write OCP transactions.
Testing the OCP busses
The eScope was tested using different scenarios randomly selecting configuration parameters from sets that include all corner cases. The ModelSim-MATLAB-CoreCreator test environment, which is illustrated in Fig 3, includes a MATLAB-Verilog simulation. The OCP busses were tested using OCP monitors and checkers. The OCP monitors were added in the top-level testbench 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.
The external ADC, DAC, and CPU models read/write the sample data from external files. The validation of a selected scenario was performed using MATLAB scripts with the same functionality and parameter set as the HDL code. Any errors were displayed graphically, where error were computed as the difference between the expected signals generated by MATLAB and the signals written to file by the external Verilog models. A 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 performed in the Verilog test environment using a custom version of the $random task.
eASIC technology specific implementation
The eTool design flow is illustrated in Fig 4. This flow, which is based on a typical standard cell design flow, is designed to leverage existing ASIC design methodology and infrastructure as much as possible.
Logic synthesis was performed with the Synopsys Design Compiler synthesis tool using an eASIC-provided Liberty-format synthesis library. This library contained all of the 2-, 3-, 4-, and 5-input functions that can be implemented with combinations of LUT configurations in the eCell, and also 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 an eASIC-developed technology mapping and packing tool called eMap. This tool replaces slower LUT-based functions with faster NAND and MUX functions where possible; it 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.
Tables 1 and 2 present the results of the eScope implementation on eASIC Structured ASIC fabric using the Synopsys flow:
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 were created that were 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 blocks and coupled with time-multiplexing was a key factor that allowed the eScope project to be developed in a short period of time.
Also, designing the eScope was made easier by the reuse of the OCP switch and ocp2mem converter from a previous design, while the testing phase was enriched by the OCP monitors and checkers.
About the authors
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 and Computers, in 2000 with MSc degree in Electronics and Computers. His graduation thesis was entitled: "EDA tools for eASIC technology." His research interests are in the area of VLSI design, HDL modelling, C/C++ programming, and synthesis. Traian can be reached at firstname.lastname@example.org.
Dan Nicula is a professor at Transilvania University in Brasov, Romania, in the Department of Electronics and Computers. He graduated the Polytechnic Institute of Bucharest, Romania, in 1990 with a MSc degree in Electronics. In 1997, he was awarded a PhD in Computer Sciences by Transilvania University. His research interests are mainly in the area of VLSI design and HDL RTL-level modelling; his teaching duties include HDLs, microprocessors, and digital electronics. Dan is the author of books regarding VHDL/Verilog and he is also the site manager of the eASIC subsidiary located in Brasov, Romania. Dan can be reached at email@example.com.