Open-source Framework and Practical Considerations for Translating RTL VHDL to SystemC

By Syed Saif Abrar ^1,2, Maksim Jenihhin², Jaan Raik²
¹ IBM, Bangalore, INDIA
² Tallinn University of Technology, Tallinn, ESTONIA

Abstract

SystemC has gained wide acceptance in the design of new digital IPs. However, there are numerous IPs already designed in VHDL. With the advances in SystemC ecosystem, like IEEE standardization, TLM-2 standard, SystemC high-level-synthesis, many IP design-houses are interested in developing SystemC models of their portfolio VHDL IPs. However, there is a lack of any standard approach in this regard. This paper aims to fill this gap by describing practical tips and pitfalls to be considered while translating VHDL to SystemC. These decisions affect the correctness, quality as well as maintainability of the translated code. The described approaches have been implemented in zamiaCAD, an open-source RTL framework for VHDL. The zamiaCAD implementation has been successfully used to translate various VHDL benchmark designs.

I. Introduction

Model development time is of utmost importance to IP design houses. Code translation tools speed up the model development time as well as guaranty consistency between original and translated models. Both top-down approaches and VHDL IP-reuse approaches are used for deriving SystemC models. High-level synthesis tools, like [1], [2] and [3] are an example of top-down approach. Bottom up approaches, like [4] and [5] are examples of IP reuse. However, readability and efficiency of the translated code are two major problems of the current code translators.

II. VHDL Front-end: zamiaCAD

zamiaCAD [6] is a scalable model based open-source framework [7] that addresses RTL design, verification and analysis [8]. Currently the front-end fully supports VHDL-2002 standard. On the back-end side zamiaCAD supports design entry, navigation and analysis and has an Eclipse IDE plug-in based user interface. It also contains a built-in VHDL simulator supporting verification and debug flows and it has stubs for synthesis and for visualization of the design structure. Figure 1 demonstrates a simplified flow of the framework. An object database ZDB (zamiaCAD Data Base), which has been custom-designed and highly optimized for scalability and performance is used for zamiaCAD applications. The database is HDL independent and is able to accommodate extremely large designs. Full elaboration in zamiaCAD semantically resolves the Abstract Syntax Tree (AST) generated by the parser and results in a set of scalable Instantiation Graph (IG) data structures, stored in ZDB. Instantiation Graph is a data structure represented by a densely connected graph of semantically resolved objects representing elements of the hardware design. As demonstrated in [7] the framework is capable of handling very large industrial multi-core designs, e.g. a SoC made of more than 3500 Leon3 [9] processor cores.

Figure 1. Simplified zamiaCAD flow

III. VHDL to SystemC Translation Considerations

This section provides tips and pitfalls to be considered while converting VHDL to SystemC. A designer needs to take various decisions to achieve efficient and correct translation and such a list of good practices to follow, and pitfalls to avoid, is helpful and practical to use.

1.Human readability

First and the foremost is the consideration about the usage of the generated SystemC code. Whether the SystemC code is only to be directly fed to the compiler or is it going to be maintained by human developers. Many VHDL-to-SystemC converters lack this feature and generate an obscure code which is not fit for human consumption. It goes a long way to decide the human relationship with the generated SystemC code.

2. Similarity of the translated SystemC to VHDL

This guideline is related to the earlier consideration about readability. If a team of designers needs to maintain both the VHDL and SystemC code-bases, then it is appropriate to have a consistent view between the two. The translation mechanism must decide about this early on and take care of. Usage of the same module-names, variables, constructs, etc. must be adhered too, unless SystemC does not support a feature inherently.

3. SystemC module constructor on-the-fly

SystemC module needs a constructor, unlike a VHDL model. Some information, like sensitivity-list, is part of the SystemC constructor that is only available in VHDL process declaration, as shown in Table 1. Hence, SystemC constructor can only be written once complete VHDL code has been parsed. This demands that the information for the SystemC constructor be gathered while parsing the VHDL module, accumulated on-the-fly and finally written to the SystemC file.

Table 1. SystemC module constructor

4. Multiple architecture definitions

VHDL enables definition of multiple architectures for a single entity. However, SystemC is limited in this regards that there is only a single SystemC class available for each representation. A practical approach in this regard is to derive the name of each SystemC module from a combination of the VHDL entity and architecture names, e.g. by concatenating VHDL entity and architecture names. Table 2 shows this approach.

Table 2. SystemC model naming

5. Using constructors rather than SC_CTOR

VHDL allows model parameterization using generics. In order to achieve the same in SystemC, it is recommended to use the class constructors instead of SC_CTOR. This enables the VHDL generics to be used as constructor parameters, as shown in Table 3.

Table 3. SystemC parametrizable constructors

6.Virtual destructor

As it is also discussed in the guideline 7 in Effective C++ [10], if the SystemC model has any virtual function then it should have a virtual destructor. Additionally, the classes not designed to be base classes or not designed to be used polymorphically should not declare virtual destructors.

7. Native C++ data-types for faster simulation

This is conventional wisdom to use C++ datatypes. Using lesser state types might suffice instead of higher state types. Take an example of VHDL std_logic type. If only values '0'/'1' are relevant, and not the 'X'/'Z' states, then C++ bool type is recommended instead of exact replacement by SystemC sc_logic type. However, this approach must be used with care. The entire code needs to be analyzed to make sure that the left-out values (e.g. 'X'/'Z' in this case) are not used anywhere in the code. Also, this restricts the SystemC model for later design updates when we might need to use the dropped values.

8. Operator precedence differences between VHDL and SystemC

This consideration is extremely important to keep up with. VHDL and SystemC have different precedence for certain operators. Table 4 compares the operator precedence for both VHDL and SystemC. As is common, use parenthesis for clarity and overwriting precedence.

Table 4. VHDL and SystemC operator precedence

9. Using port-methods for clarity

SystemC uses the same operator '=' for reading the variables as well as the ports. To remove ambiguity, use methods for read/write on ports and to reserve '=' for variable assignments, as shown in Table 5.

Table 5. SystemC port method

10.VHDL and SystemC port types

Both VHDL and SystemC have similar types of ports and can be mapped uniquely from VHDL to SystemC. Table 6 shows the similar port mapping between VHDL and SystemC. VHDL has a unique 'buffer' port type, that indicates that the port is out type, but its value can be read inside the entity. For all practical purposes this can be mapped to SystemC 'sc_inout' port.

Table 6. VHDL and SystemC port types

11.Translating VHDL process

VHDL process is used to implement sequential behavior. SystemC allows either SC_METHOD or SC_THREAD for such purpose. Sensitivity of the VHDL-process becomes the sensitivity of SystemC translation. Whether to choose SC_METHOD or SC_THREAD depends on the usage of wait within VHDL process. Since an SC_METHOD cannot have wait statement, any VHDL process with a wait statement should be implemented as SC_THREAD, otherwise SC_METHOD might be preferred. Table 7 shows this approach.

Table 7. SystemC process declarations

12.Concurrent statements in VHDL

Sequential statements within a VHDL process goes inside a similar SC_METHOD or SC_THREAD in SystemC. But what about the concurrent statements outside of any VHDL process? There are 2 ways to handle such statements in SystemC.

a) Use single SC_METHOD for all concurrent statements, and sensitive to all the source (right-handside) variables in these statements, as shown in Table 8. This approach is easy to implement but has a drawback that the SC_METHOD executes whenever any variable changes. This affects the performance.

Table 8. Single SC_METHOD

b) Separate SC_METHOD for each statement, being sensitive to only this statement's source variable, as shown in Table 9. The approach adds to the translation effort as well as increases the code-size but only single statement is executed each time, reducing the simulation overhead.

Table 9. Separate SC_METHOD's

13.Handling clock-edge sensitivity

VHDL and SystemC uses varying notations to describe clock-edge sensitivity. Table 10 shows the translation for positive-edge clock sensitivity. But the process P1 is invoked on both the edges of clock. Efficient and recommended, but elaborate, approach is to analyze the VHDL implementation of the process P1 to determine the clock-sensitivity of interest, and then use it in SystemC, as shown in the Table 11. Such scheme is better for an event-based simulator like SystemC.

Table 10. Double clock-edge sensitivity

Table 11. Single clock-edge sensitivity

14.Switch-case translation

VHDL allows variables, logic-types as well ports in the switch-case construct, whereas SystemC allows only integer variables. Hence, VHDL switch literal must be converted to an integer, as shown in Table 12. Another possibility is to use if-then-else constructs, as shown in Table 13. This is particularly useful where the VHDL switch literal

uses a range of values
cannot be converted to an integer, e.g. Stringtypes.

Table 12. SystemC switch-case

Table 13. SystemC if-then-else

15.SystemC process at start-up

SystemC scheduler has an interesting feature that each process (SC_METHOD or SC_THREAD) is always invoked once at the start-of-simulation. This happens even in absence of any event! Use dont_initialize() to stop this default invocation, as shown in Table 14. 16.Executing the SystemC model constructor SystemC has a unique requirement to execute the constructor of each module instance. This is unlike VHDL as there is no constructor for a VHDL design. Table 15 shows the structure of a 4-bit adder from 4 instances of 1-bit adder.

Table 14. SystemC process as start-up

Table 15. SystemC model constructor

IV. Results

The approach for VHDL to SytemC translation following the guidelines was implemented in zamiaCAD framework. As a proof of concept a set of VHDL RTL designs have been successfully translated to SystemC using zamiaCAD. The translated SystemC code is cycle-accurate, pin-accurate and bit-accurate as in the source VHDL. E.g. the designs include b01, b04, b06 and b09 benchmarks from ITC99 benchmarks family and a set of proprietary designs following structural RTL (separate FSM and detailed datapath) and functional RTL (datapath embedded to FSM) implementations.

V. Conclusions and future work

This paper presented practical guidelines and considerations for translating VHDL RTL designs to RTL SystemC. These guidelines are useful for manual translations as well as for developing translation tools. Open-source zamiaCAD framework has been used for implementing the discussed approaches. Various benchmarks have been successfully translated from VHDL to SystemC as a proof of concept. Future work aims at developing a methodology to automatically raise the abstraction-level from SystemC RTL to TLM and verification issues.

VI. References

[1] Cynthesizer, Forte, http://www.forteds.com/

[2] Catapult C, Calypto, http://www.calypto.com/

[3] C-to-Silicon compiler, Cadence, http://www.cadence.com/

[4] HIFSuite: Tools for HDL code conversion and manipulation, Bombieri, N., IEEE HLDVT Workshop, 2010

[5] SAVANT: VHDL Analysis Tools, University of Cincinnati, http://www.ece.uc.edu/~paw/savant

[6] zamiaCAD Framework website. http://zamiacad.sf.net/, 2012.

[7] A. Chepurov, G. Bartsch, R. Dorsch, M. Jenihhin, J. Raik, V. Tihhomirov, A Scalable Model Based RTL Framework zamiaCAD for Static Analysis, Proc. IEEE VLSI-SOC, October 7-10, 2012. Santa Cruz, USA.

[8] A. Chepurov, V. Tihhomirov, S.A. Syed, M. Jenihhin, J. Raik, Applications of the Open Source HW Design Framework zamiaCAD. DATE 2012 University Booth: Design Automation and Test in Europe, Dresden, Germany, March 12-16, 2012.

[9] Aeroflex Gaisler AB. LEON3 SPARC V8 Processor IP core, GRLIB IP library, v.1.1.0-b4108. http://www.gaisler.com/

[10] Effective C++, Scott Meyers, Amazon.com