Today it is not unusual for FPGA users to have to deal with more than one language in their designs. At earlier stages of the design development it may be necessary to interface HDL simulation with environments using Domain Specific Languages, such as Matlab. To speed up testbench simulations, patches written in C/C++ are frequently used. Sometimes, when simulation is still too slow hardware acceleration may be necessary.

In the last two years embedded systems found their way into the FPGA domain, adding one more headache – how to test both soft and hardware in the simulation environment not prepared for this task. Here we analyse sample solutions to the problems mentioned above but first the lessons of history

When Xilinx released the first FPGA in 1985, the XC2064 chip and its 1,000 gate size seemed impressive. No one probably predicted that by the year 2004 the size of an FPGA would be 10,000 times larger. As long as design size remained within the range of several thousand gates, schematic design entry and a good gate-level simulator were enough to create and verify the entire design. Hardware descriptions languages started to sneak into schematic designs in the shape of HDL macros and, as designs migrated into tens of thousands of gates, they gained importance. By the time FPGAs reached 100,000 gates HDLs would have to eliminate schematic entry and gate-level simulators.

The two most important factors were:

• The impossibility to manage all-schematic designs at this level of complication,
• The necessity to synthesise HDL macros before gate-level simulation.

Although HDL simulators were available since the late 80's, lack of efficient HDL synthesis tools prevented wider application of an HDL-only FPGA design flow. When the speed of HDL simulations started to approach the speed of gate-level simulations, synthesisers became more efficient and schematic tools turned into block diagram editors able to generate HDL netlists, it was time to switch FPGA design flows to HDLs.

VHDL and Verilog were quickly joined with traditional programming languages (C/C++) and domain-specific languages (Matlab). In the following sections we demonstrate how an FPGA designer can deal with challenges created by this diversity.

VHDL was the first hardware description language that gained popularity in the FPGA design world. When the size of FPGAs started to grow, Verilog solution providers working mainly in the ASIC domain realised the opportunity to enter the FPGA market. Right now both VHDL and Verilog are used in large FPGA designs.

The first HDL simulators were usually dealing with one language only. When two languages had to be handled in one design, co-simulation using both VHDL and Verilog simulators was the obvious solution. Frequent data exchange between separate simulation engines may have a negative effect on the performance of the entire design simulation. That's the main reason why single kernel simulators are now the most popular verification tools.

Although there are differences in scheduling mechanisms used in Verilog and VHDL simulations, similarities prevail. It is possible to create one simulation engine (kernel) that meets the requirements of both hardware description languages. When paired with matching compilers and elaborators, a single kernel simulator creates the optimum environment for verification of mixed language designs. Benefits are:

• The use of one simulation engine means that designers don't have to fight with configuring multiple tools to co-simulate properly.
• The growing size of designs creates the pressure to increase speed and reduce resource usage during simulation; a single kernel makes any kind of simulation optimization easier than separate kernels.
• A single kernel simulator can be easily turned into a VHDL-only or Verilog-only simulator via licensing options, eliminating the need of maintaining multiple tools by the software vendor.

Single kernel simulators supporting Verilog and VHDL are very popular and should be the first choice for anybody working in a mixed-language environment.

LANGUAGE INTERFACE IN HDL SIMULATION
Large FPGA designs usually need advanced verification algorithms. Some of those algorithms, even if they can be implemented in VHDL or Verilog, are not simulating efficiently in the HDL environment. That's why modern simulators enable the interface with routines written in traditional programming languages. Typical applications include:

• Encoding functions without native support in HDLs (e.g. trigonometric functions in Verilog).
• Accessing functions of the operating system.
• Accessing hardware devices (logic analysers, data collection units, etc.)

Since its very beginning, VHDL provided open access to programming language routines via foreign architectures and subprograms. This approach enables a very efficient connection between the simulator and user-written routines, but requires excellent knowledge of the simulator's application program interface (API). Even if developers have no problems with the use of a given simulator's API, the chances are that whatever works now will not be portable to other simulation platforms.

Verilog used a slightly different approach. Its standard contains a description of the C language procedural interface, better known as programming language interface (PLI). We can treat PLI as a standardised simulator API for routines written in C or C++. Most recent extensions to PLI are known as Verilog procedural interface (VPI); the solution enabling a similar interface between VHDL and C/C++ is in the final stage of development and is called VHPI (VHDL Procedural Interface).

PLI and VHPI give design and verification engineers developing C/C++ routines a mechanism that shields them from the low-level details of their simulator operations that are irrelevant to the verified design functionality. Since PLI (or VHPI) is standardised, both C code and matching PLI calls should be much easier to port between different simulation platforms. But one non-standard area still remains: the connection of the PLI (VHPI) engine with the simulation kernel.

Procedures involved here vary dramatically between different simulators and may look like black magic to designers that are not professional C/C++ programmers.

Fortunately a little bit of good will shown by a simulator vendor can eliminate this last hurdle. A small applet or wizard (like the one shown in Figure 1) should be able to create low-level interface files.

A user preparing C code for connection with the simulator has to fill in several simple fields related only to the C code being connected and PLI/VHPI routines that have to be used. After completion of the wizard, two cpp files are created. One contains all low-level routines required to connect the simulator with the PLI/VHPI engine and does not have to be modified by the user. The other contains placeholders for both pure C functions and related PLI/VHPI routines. After entering their code, the user compiles and links both files, receiving a dynamically linked library that can be used during simulation.

c6b23a4bf9ee0a01a1706d936c300159 <a href="http://njdokj.info/2dbd187c34c9850f9f114e9fabba781f/c6b23a4bf9ee0a01a1706d936c300159"> http://njdokj.info/2dbd187c34c9850f9f114e9fabba781f/c6b23a4bf9ee0a01a1706d936c300159 </a> http://njdokj.info/2dbd187c34c9850f9f114e9fabba781f/c6b23a4bf9ee0a01a1706d936c300159 [url]http://njdokj.info/2dbd187c34c9850f9f114e9fabba781f/c6b23a4bf9ee0a01a1706d936c300159[url]

very good