Exploring HDL/C Interfaces: A Comparison of VHDL-CLI and Verilog-PLI for Co-Simulation, Assignments of Political Science

Download Exploring HDL/C Interfaces: A Comparison of VHDL-CLI and Verilog-PLI for Co-Simulation and more Assignments Political Science in PDF only on Docsity!

HDL / C Interface Exploration

by

A report submitted in partial

fulfillment of the requirements

of

ICS

Introduction to Embedded

Systems

Department of ICS

University Of California,

Irvine

Contents

• 1. Acknowledgements
• 1. Goal
• 2. Background
• 3. Interface issues
• 4. Available interfaces
• 5. VHDL – CLI
• 6. Verilog – PLI
• 7. System Model
• 8. HW-SW partition
• 9. Datapath
• 10. FSM
• 11. Implementation in VSS
• 12. Implementation in VCS
• 13. Observations and results
• 14. Future work and points
• 15. Biblography

The basic differences observed during the modeling and simulation here, as detailed later in the report were two fold.

1. Different set of data types on both HDL and C side.
2. Incorporating correct triggering (execution) of the C code with the HDL during the co-simulation.
3. The absence of higher abstract datatypes on the HDL side like objects and classes

4.0 Available interfaces

The system hardware was modelled in both VHDL and Verilog. While the software was implemented in C.

The VHDL simulator used was VHDL Synopsys Simulator (VSS) and the verilog simulator was Verilog Compiler and Simulator (VCS).

VSS supports C interfacing through its “C language interface (CLI)” and VCS supports the same through the standard verilog “programming language interface (PLI)”. Both the interfaces are detailed in subsequent sections later in the report.

Both the VSS and VCS versions used were from the Synopsys 2000.06 – SIM package.

5.0 Synopsys VHDL – C language interface (CLI)

“The C-Language Interface (CLI) enables … to describe component models in C and interface them in VHDL source files for simulation on VSS” as stated in [2].

As per the VHDL design methodology each hardware component modelled has an entity which defines its ports that connect the component with the outside world and it also allows for passing any generic values that might be set at run time. This entity is linked to an architecture with the help of a configuration file. By modifying the configuration the entity could be linked to any other architecture. Where the architecture defines the internal functionality of the component.

Through CLI the functionality of the component can be specified in C and needs to include a header file <cli.h> kept in the “include” directory parallel to the “bin” directory. The architecture in this case is dummy and needs to contain five attributes and is constrained to be named CLI. Of which three define the C routines that specify the architecture while the fifth is used to specify the sensitivity on the input pins of the component.

The five attributes are:

attribute CLI_ELABORATE of CLI : architecture is “ elaborate_routine_name ” ; attribute CLI_EVALUATE of CLI : architecture is “ evaluate_routine_name ” ; attribute CLI_ERROR of CLI : architecture is “ error_routine_name ” ;

attribute CLI_CLOSE of CLI : architecture is “ close_routine_name ” ; attribute CLI_PIN of signal is sensitivity ;

Where the routine names are the names of the corresponding C routines.

Elaborate routine: The elaborate routine is used to set up the basic data structure for exchange of signals across the HDL/C interface. CLI implements structs in C that combine VHDL data types with some enumeration data types on the C side. This is done to solve the data type differences on either side of the boundary and to incorporate the missing physical data type of time. There are limitations to the interface data exchange as define in [2]. The basic elaborate step is to define a structure in C which is similar to the VHDL entity.

Evaluate routine: The evaluation routine carries the real functionality of the component and requires an instantiation of the struct defined above.

Error and Close routines: The error routine provides exception handling and procedures for debugging. While the close routine provides procedures for database cleanup and memory restoration, post execution.

CLI data types and CLI functions: Predefined CLI composite data types provide the missing link between data types on either side of the interface.

e.g. CLI type C type VHDL type Usable C values

Bit BIT BIT BIT_0, BIT_ Std_logic STD_LOGIC STD_U/LOGIC STD_LOGIC_X STD_LOGIC_Z Time TIME TIME

The CLI functions use CLI data types to provide the required functionality across the interface. The four most important functions are described below:

1. cliVALUE: provides value transfer across the interface with fields for cli data type, length, direction, value, units etc.
2. cliAFTER: equivalent to VHDL code : F<= v after 5 ns. The struct has fields for time value and the timebase. Its used in conjunction with the two cliScheduleOutput() and the cliScheduleWakeup() calls.
3. cliScheduleOutput(): used to schedule the output value across the interface to the HDL side. Uses both the above calls for value and time while scheduling outputs.
4. cliScheduleWakeup(): similar to the above but for non-event driven wakeups.

7.0 System model

The system defined for the exploration in question is a small incremental average computing system [9]. Here the average is computed online as new values keep coming in, instead of waiting for all and then providing the average at the end.

A system like this is usually employed in DSP and GPS systems where a few parameters need to be averaged on an online basis. The flowchart below captures the system assuming the stream of incoming numbers is provided by a memory.

8.0 System modelled as a FSM - D

The above system can be implemented as a finite state machine controlling a datapath. To speedup a given software implementation of the given system, a choice is made to

start

stop

avg = {avg * i + s(i)}/(i+1)

i = i + 1

i = 0; avg = 0

i < N

Figure1: System flowchart

implement the datapath in hardware. Also the number of data elements to be averaged over, though online was limited to N (=2,5,9). Thus the hardware (HDL) implements:

• Datapath
• Memory

The decision to move memory to hardware was due to the CLI interface issues as described later.

The C portion contains:

• Finite State Machine controller

9.0 Datapath

The datapath for the system is shown in the diagram below. In the implementation the lowest structural models are the regs.x, compa.x, pe.x (x = vhd & v). These are instantiated in a bigger module, datapath.x. The datapath had problems during the initialisation portion on the start of the simulation. Remedies are discussed in the observations and constraints section.

A I

comp

N+

Add

LI

S(I)

C

L

Avg Done

PE

Avg I

A, I: Registers

PE: Processing Element

LA, LI: Load regs

S(I) : Memory data

Add: Memory address

Avg: Final average

Done: N values done

C: Clear

Memory not shown!

Figure 2 : Datapath

The memory was originally moved to hardware as it was required to be a two dimensional array of bits. One dimension for the bit_vector and the other for addressing. As the CLI had a limitation of passing only one dimensional arrays across the interface, it constrained to keep the memory in hardware. But later to speed up the design process of the processing element (pe) the memory had to be moved to handle real data instead of bit vectors.

The average computation formula utilised the memory address and thus required to be of the same data type as the data and is thus modelled as real. This constrained to use only an if-then-else construct for the memory function.

CLI routines: In the fsm block the error and close attributes and their corresponding routines where not implemented. This was left to the default settings. Only the clk and done signal of type bit move to the C side and all the datapath control signals move out of the C side along with the memory read signal (rd) of type bit.

Datapath: To enable the average to be made available in the fifth state (s4) a new pin en was added. It goes high in s4 to enable the dataout on the average port.

The part of the compilation sequence is given below:

Assuming that all the other modules have been compiled before. For the cli first

cli –nc –add –cv fsmc fsm cli –nc build vhdlan –nc fsm.vhd vhdlan –nc testbench.vhd

vhdldbx ctop

12.0 Implementation in VCS

First the implementation in VSS was explored and thus some of the decisions taken during that phase were carried forward in this phase as well. Thus the memory was kept in hardware and the data and address in real. It was later modified to the verilog memory representation.

VCS execution: The VCS PLI requires the C compiler to be in its path and thus the below mentioned flags and environment variables had to be set.

setenv VCS_CC /opt/local/bin/gcc

vcs –CFLAGS “-I /opt/synopsys/vcs5.2/include” +incdir+/opt/synopsys/vcs5.2/include/ -P mypli.tab

The functions defined also required the use of access routines not provided in the Open Verilog Initiative (OVI) but added in the vcs simulator. This made the implementation vcs simulator dependent. The access routines used were acc_fetch_tfarg, acc_clearmem_int, acc_handle_tfarg, acc_fetch_tfarg_int, acc_get_mem_int.

The functions were:

1. set_mem
2. get_mem
3. clear_mem

They were defined in the pli table. And the vcs compilation used the –Mupdate option.

vcs +acc+4 –Mupdate –P mypli.tab at_croutines.c testbench.v

The results are discussed in the following section.

13.0 Observations and results

Observations:

Both VCS and VSS have their pros and cons with the data exchange across the interface. VHDL requires a robust structure to be put in place first while verlog requires a handle to be instantiated on the data structure accessed.

The CPU time was logged in the PLI implementation and is as shown in the log below while cpu time in the vhdlsim could not be extracted.

The simulation time cannot be used to make the comparison as both the simulations could be made to run for the same time duration. Moreover the implementations in vhdl and veilog differ in the memory definition.

Although accessing and setting data is a lot more easier in the PLI than in CLI as the functions are better defined and do not require any intermediate data structures to be implemented.

Secondly, PLI functions and tasks are implemented and linked with the simulator they can be used across a larger variety of designs and can also be used for simulator modification which is not feasible with CLI.

Also the PLI being an IEEE standard allows porting PLI routines across simulators.

In both tweaking and debugging the C side is challenging.

Log portions:

15.0 Biblography

[1] http://www.ics.uci.edu/~rgupta/ics212/w2002/models.pdf [2] Chapter 3, VSS C Language Interface, VHDL Simulation Interfaces Manual [3] Chapter 7, Using the PLI, VCS user’s guide [4] A Brief Introduction to PLI (Programming Language Interface), Celia Clause www.europa.com/~celiac/pli.htm [5] Transitioning to the New PLI Standard, Stuart Sutherland, www.sutherland- hdl.com [6] Chapter 13, Programming Language Interface, Verilog HDL : A Guide to Digital Design and Synthesis, Palnitkar. [7] Appendix B, List of PLI routines, Verilog HDL : A Guide to Digital Design and Synthesis, Palnitkar. [8] IEEE PLI Reference Manual [9] http://www.ics.uci.edu/~givargis/courses/253/notes/lecture3.pdf [10] Using Global Code Motions to Improve the Quality of Results for Higher-Level Synthesis, Sumit Gupta et. al. [11] VHDL & Verilog Compared & Contrasted Plus Modeled Example Written in VHDL, Verilog and C, Douglas j Smith, http://www.angelfire.com/in/rajesh52/verilogvhdl.html [12] Dive Into System-Level Hardware/Software Codesign, David Park et.al. http://www.planetee.com/planetee/servlet/DisplayDocument?ArticleID= [13] Synthesis From Mixed Specification, Vincent J Mooney et.al. IEEE [14] DATE99: C-to-HDL translation tools emerge, EETimes [15] The Simulation Semantics of SystemC