WO2019167081A1

WO2019167081A1 - System and method for emulation and simulation of rtl (design under test) using fpga

Info

Publication number: WO2019167081A1
Application number: PCT/IN2019/050176
Authority: WO
Inventors: Akash APASANGI; Vinay Kumar
Original assignee: Apasangi Akash; Vinay Kumar
Priority date: 2018-03-02
Filing date: 2019-03-01
Publication date: 2019-09-06

Abstract

The disclosure relates to a system and method for emulation and simulation of RTL (DUT) using FPGA. In one embodiment, a text based RTL design is converted into emulation capable RTL design which is then synthesized to generate a bit file using an EDA. The bit file is then loaded into the on-board FPGA and test cases are injected to the design under test (DUT) using a transactor, and at every clock cycle, the flip-flops states of the FPGA are recorded in a memory module. A simulation file is generated by mapping resultant states of the flip-flops with their naming nomenclature from the text based RTL design. The system provides a user friendly GUI using which a user/designer may choose debugging capabilities at modular level or for the complete IP core.

Description

SYSTEM AND METHOD FOR EMULATION AND SIMULATION OF RTL

(DESIGN UNDER TEST) USING FPGA

FIELD OF THE INVENTION:

[0001] The present disclosure relates to a system and method for emulating a design (design under test) and more particularly relates to a system and method for emulation and simulation of RTL (design under test) using Field Programmable Gate Arrays (FPGAs).

BACKGROUND TO THE INVENTION:

[0002] Generally, in integrated circuit design, hardware emulation is the process of imitating the behaviours of one or more pieces of the hardware (design under test) with another piece of hardware, typically a special purpose emulation system. The emulation model is usually based on a hardware description language source code, which is compiled into the format used by the emulation system. The emulation is performed for debugging and functional validation of the system being designed (design under test)

[0003] Typically, an integrated circuit (IC) designer creates a“register transfer logic” (RTL) design, which describes a digital electronic circuit in terms of flow of digital signals (data) between hardware registers and the logical operations performed on the digital signals. In other words, the RTL describes a digital electronic circuit as a hierarchy of logic modules that exchanges digital signals with one another or with other clocked devices that store information between clock cycles. Upon creating the RTL design, the designer uses computer-aided synthesis tool to convert the RTL design into a gate level design describing the integrated circuit (IC) as a set of interconnected instances of components (cells). Further, the designer uses computer-aided layout tools to generate an IC placement and routing plan for guiding IC fabrication. The routing plan generally comprises information pertaining to the position and orientation of each cell within the IC and further comprises the layout of the conductive nets that interconnects the cells. [0004] The design process often requires debugging and functional verification of the system (IC) being designed. Hence, at various stages of the IC design process, the designer uses verification tools such as emulators and simulators to determine whether the IC described by the RTL design or gate level design functions as expected. For the RTL verification and simulation, conventional methodology followed in the industry is to create a test bench environment, and to run the test cases using an industry standard Electronic Design Automation (EDA) tool. Hence, for RTL verification and simulation, the designer creates the test cases and inputs the test cases to the emulator or simulator along with the RTL or gate level design and signal specifications describing the time-varying behaviour of the IC input signals and specifying the particular IC signals that are to be monitored during the emulation or simulation. The emulator or the simulator produces a file comprising information pertaining to the time-varying behaviour of the particular IC signals selected by the designer. Then a debugger process the file and the RTL or gate level design to produce an output, wherein the output comprises waveforms indicating the behaviour of the monitored IC signals, schematic diagrams, information pertaining to the signal behaviour, etc.

[0005] However, inherent problem associated with the conventional system and method is that the emulator and the simulator runs on a general purpose computer and the process is a sequential execution process, and hence a very time consuming procedure. Further, gate level simulation takes more time than the simulation.

SUMMARY OF THE INVENTION:

[0006] This summary is provided to introduce a selection of concepts in a simple manner that are further described in the detailed description of the disclosure. This summary is not intended to identify key or essential inventive concepts of the subject matter nor is it intended for determining the scope of the disclosure

[0007] The present disclosure relates to a system and method for emulation and simulation

7 (simemulation) of RTL (design user test) using field programmable gate array (FPGA). The FPGA based emulation system/platform disclosed in the present disclosure provides a unique capability to verify and validate register-transfer level (RTL) design at faster rate, achieving prototyping of the RTL design at the same time. In one embodiment of the present disclosure, the RTL design is converted into emulation capable RTL design which is then processed to generate a bit file. The bit file is then loaded into the on board FPGA and test cases are injected to the design under test (DUT) using a transactor. In one embodiment of the present disclosure, the system provides a user friendly first graphical user interface (GUI) using which a user/designer may choose debugging capabilities at modular level or for the complete IP core. Further, the GUI provides various options using which the user may inject the test cases to the DUT.

[0008] To further clarify advantages and features of the present disclosure, a more particular description of the disclosure will be rendered by reference to specific embodiments thereof, which is illustrated in the appended figures. It is to be appreciated that these figures depict only typical embodiments of the disclosure and are therefore not to be considered limiting of its scope. The disclosure will be described and explained with additional specificity and detail with the accompanying figures.

BRIEF DESCRIPTION OF THE FIGURES:

[009] The disclosure will be described and explained with additional specificity and detail with the accompanying figures in which:

[0010] Figure 1 is a data flow diagram depicting emulation and simulation of a design under test using FPGA in accordance with an embodiment of the present disclosure,

[001 1] Figure 2a depicts a micro-architecture of the write-side scheme in accordance with an embodiment of the present disclosure; [0012] Figure 2b depicts a micro-architecture of the read-side scheme in accordance with an embodiment of the present disclosure;

[0013] Figure 3 illustrates a transactor based stimulus setup in accordance with an embodi m ent of the present disclosure,

[0014] Figure 4 illustrates an exemplary transactor packet format in accordance with an embodiment of the present disclosure;

[0015] Figure 5 illustrates an exemplars,_' GUI in accordance with an embodiment of the present disclosure; and

[0016] Figure 6 illustrates an exemplary user interface providing debugging capabilities in accordance with an embodiment of the present disclosure.

[0017] Further, persons skilled in the art to which this disclosure belongs will appreciate that elements in the figures are illustrated for simplicity and may not have necessarily been drawn to scale. Furthermore, in terms of the construction of the device, one or more components of the device may have been represented in the figures by conventional symbols, and the figures may show' only those specific details that are pertinent to understanding the embodiments of the present disclosure so as not to obscure the figures with details that will be readily apparent to those of ordinary' skill in the art having benefit of the description herein.

DESCRIPTION OF THE INVENTION:

[0018] For the purpose of promoting an understanding of the principles of the disclosure, reference will now be made to the embodiment illustrated in the figures and specific language will be used to describe them. It will nevertheless be understood that no limitation of the scope of the disclosure is thereby intended. Such alterations and further modifications to the disclosure, and such further applications of the principles of the disclosure as described herein being contemplated as would normally occur to one skilled in the art to which the disclosure relates are deemed to be a part of this disclosure. [0019] It will be understood by those skilled in the art that the foregoing general description and the following detailed description are exemplary and explanatory of the disclosure and are not intended to be restrictive thereof.

[0020] The terms "comprises", "comprising", or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a process or method that comprises a list of steps does not include only those steps but may include other steps not expressly listed or inherent to such a process or a method. Similarly, one or more devices or sub-systems or elements or structures or components preceded by "comprises... a" does not, without more constraints, preclude the existence of other devices, other sub-systems, other elements, other structures, other components, additional devices, additional sub-systems, additional elements, additional structures, or additional components. Appearances of the phrase“in an embodiment”,“in another embodiment” and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment.

[0021] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art. to which this disclosure belongs. The system, methods, and examples provided herein are illustrative only and not intended to be limiting.

[0022] Embodiments of the present disclosure will be described below in detail with reference to the accompanying figures.

[0023] The present disclosure relates to a system and method for emulation and simulation of RTL (design under test (DUT)) using field programmable gate array (FPGA). The FPGA based emulation system/platform disclosed in the present disclosure provides a unique capability to verify and validate register-transfer level (RTL) design at faster rate, achieving prototy ping of the RTL design at the same time. In one embodiment of the present disclosure. the RTL design is converted into emulation capable RTL design which is then processed to generate a bit file. The bit file is then loaded into the on board FPGA and test cases are injected to the design under test (DUT) using a transactor. In one embodiment of the present disclosure, the system provides a user friendly first graphical user interface (GUI) using which a user/designer may choose debugging capabilities at modular level or for the complete IP core. Further, the system provides a second graphical user interface (GUT) wherein the second GUI provides various options using which the user may inject the test cases to the

[0024] While the test eases are running, flip-flop states at every clock are captured and stored into an onboard DDR memory. A host machine reads the content of the DDR memory (flip- flop states) and maps the resultant states to the corresponding flip-flops along with flip-flop’s naming nomenclature from the RTL design input file and generates a waveform dump file which may be viewed using any known waveform viewer.

[0025] Figure 1 is a data flow diagram depicting emulation and simulation of a design under test using FPGA in accordance with an embodiment of the present disclosure. As shown, an integrated circuit (Ϊ C) designer initially generates a text based register transfer level (RTL) design 105 of an IC or IP core in a host machine 170, wherein the host machine 170 may be a general purpose computer. The designers typically use hardware description languages (for example, VHDL or Verilog) installed in the host machine 170 to create the RTL 105, and in HDLs the designer declares the registers and describes the combinational logic by using constructs that are familiar from programming languages. Thus created RTL 105 is fed to an inis^' software 1 10 (an application or a script installed in the host machine 170) which generates an emulation capable RTL 115. Generally, the RTL 105 is hierarchical, i.e., low level modules are organized to form higher level modules. In one embodiment of the present disclosure, the finif software 110 provides a first graphical user interface (GUI) that enables the designer to choose debugging capability at modular level or for the complete IP core. For example, a user may select one or multiple modules of the D!JT for debugging using a first graphical user interface (GUI) of the init software 110. Further, the‘init’ software/ application 110 adds requisite wrappers and glue logic to the IP core and generates the emulation capable RTL 115.

[0026] Thus generated emulation capable RTL 1 15 is synthesized to generate bit file 125 describing each module of the DUT. That is, an electronic design automation tool (EDA) 120 coverts the emulation capable RTL 115 into a gate level design (bit file) describing the IP core as a collection of instances of standard components (cells) such as logic gates, transistors, input/output ports and the like, each having a structure and behaviour described in a cell library. In other words, the emulation capable RTL 115 goes through a regular LPGA flow' to generate the bit file 125 and thus generated bit file 125 is loaded into the FPGA 130 as shown. Hence, the FPGA 130 serves as a virtual DUT and one or more test cases are injected to the FPGA 130 (virtual DUT) for debugging and validating the DUT, or the one or multiple modules of the DUT.

[0027] In one embodiment of the present disclosure, the‘init’ software 110 provides a second graphical user interface (GUI) using which the designer may create and add one or more test cases in any known formats such as C format, UVM test case format, etc. Typically, the test cases comprises clock, input data, error checking data, file input and output, conditional testing data, etc. for debugging and validating the design under test (DUT). In one embodiment of the present disclosure, the second GUI converts the created one or more test cases into native transactor format and passes the stimulus to the DUT, i.e., to the FPGA 130 through a transactor 135. In another embodiment of the present disclosure, a wrapper bridge inside the FPGA 130 deciphers this information and generates signal level transactions with the DUT bus interface protocol.

[0028] While the test cases are running, flip flop states (flip-flop data 140) of the FPGA emulating the one or multiple modules of DUT are captured and stored into an onboard DDR memory 145 at every clock (both the rising and falling edges). In one implementation, 10’ samples may be stored into the DDR memory 145 depending on the complexity of the DUT. Once the memory_' is full, the content of the DDR memory 145 is read using simulation software 150 installed in the host machine 170.

[0029] In one embodiment of the present disclosure, the simulation software 150 maps the resultant states to the corresponding flip-flops along with their naming nomenclature from the RTL 105 and generates a simulation file (waveform dump file) which may be viewed using any known waveform viewer. Typically during emulation, for every signal from the RTL design 105 there is a corresponding signal in the gate level design and the two signals may have different nomenclature and hierarchy. Hence, in one embodiment of the present disclosure, the simulation software 150 fetches flip-flops encoding details 155 from the RTL design 105 and the resultant states of the flip-flops from the DDR memory 145. Thus fetched flip-flops encoding details 155 and the resultant states of the flip-flops are mapped to generate the waveform dump file 160 which is generally in .vcd or .fsdb file format. Thus generated simulation file 160 may be viewed using any known waveform viewer 165 for further analysis by the designer. Hence the system/platform combines the capabilities of simulation by allowing designer to have software (C or UVM) based test cases to be run on a hardware which is emulated on the FPGA, thus providing both the emulation and simulation (simemulation) capabilities. The manner in which the Flip-Flop data 140 (output signal) are recorded in the DDR memory 145 is described in detail further below.

[0030] Figure 2a depicts a micro-architecture of the write-side scheme in accordance with an embodiment of the present disclosure. In one embodiment of the present disclosure, during emulation, the“init” software 110 taps the outputs of each of the Flip-Flops of the DUT and brings on top level. Further, the“init” software 110 segregates the output signals into groups wherein each group comprises of 512 output signals. In one example implementation,“50k” Flip-Flops form“100” groups each are having 512 output signals. In one embodiment of the present disclosure, the output signal data is written into a FIFO buffer 205 using a multiplexer 210 as shown and the output signal data is made available to a DDR controller 215. The DDR controller 215 is configured for managing the flow of output signal data to and from the DDR memory 145 and the DDR memory 145 may be a dedicated chip or integrated into FPGA board 130. In one implementation, the DDR controller 215 is interfaced with the FIFO buffer 205 using glue logic. The DDR controller 215 hence reads the output signal data from the FIFO buffer 205 and writes the same into the DDR memory 145. In one embodiment of the present disclosure, an on-board LED is provided to indicate the availability of the output signal data in the DDR memory 145. Once the DDR memory 145 is full, the on-board LED is lit to indicate the availability of the output signal data and the same information is visually displayed on the first GUI The manner in which the Flip-Flop data 140 (output signal) are read from the DDR memory 145 is described in detail further below. It is to be noted that the user may define the different clocks in the design, and preferably the clock ratios should be in multiples of‘2’ of the slowest clock. In one implementation, the sampling of the signals is done with the fastest clock defined by the user. On the other hand, for asynchronous clock designs, where the user wants to use the odd (not a multiple of 2) frequency, a different Mixed-Mode Clock Manager (MMCM) or Phase-Locked Loop (PLL) is instantiated to generate the required clocks and a separate DDR interface is defined to capture the samples on this clock. This enables the system to collect and record all data (flip-flop states) in the DDR memory 145

[0031] Figure 2b depicts a micro-architecture of the read-side scheme in accordance with an embodiment of the present disclosure. In one embodiment of the present disclosure, the DDR controller 215 reads the output signal data from the DDR memory 145 starting from a first location and communicates the output signal data to the host machine 170 using a host interface 220. The host interface may be any one of a host connectivity protocol such as but not limited to USB, PCIe, JTAG, etc. In one implementation, USB FTDI interface is used for connecting the FPGA board 130 to the host machine 170.

[0032] As described in the present disclosure, stimulus is passed to the DUT through the transactor 135 and C based test codes or UVM setup test cases may be used to pass the stimulus to the DUT using the transactor 135.

[0033] Figure 3 illustrates a transactor based stimulus setup in accordance with an embodiment of the present disclosure. As shown, in one embodiment of the present disclosure, FPGA board 130 is connected to the host machine 170 through a USB interface, USB FTDI interface 220. The second GUI running on the host machine 170 enables the designer to select the test case (code) and pass the test stimulus to the DUT through the transactor 135. In one implementation, the second GUI comprises all the requisite drivers and the software logic to convert the C code or UVM test cases into transactor understandable executable code.

[0034] In one embodiment of the present disclosure, the USB controller (USB FTDI chip 220) communicates the test codes from the host machine 170 (from the transactor 135) to the FPGA board 130, i.e., to the DUT. That is, once the test code is loaded, the test code is sequentially sent to the FPGA through a FIFO interface and a wrapper bridge 305 deciphers the test codes and converts the test codes into the bus transactions, which are then passed on to the DUT as shown.

[0035] In one embodiment of the present disclosure, the transactor 135 installed in the host machine 170 reads the‘C’ based test codes and compiles the same for syntax errors. On the other hand, In case of UVM test cases, glue logic is developed to emulate the DUT VIF and encapsulate that information into the transactor packet format. That is, the transactor 135 coverts the C based or UVM test codes into transactor packet format and which is then communicated to the DUT as described in the present disclosure. Figure 4 illustrates an exemplary transactor packet format in accordance with an embodiment of the present disclosure. Below table provides description of the transactor packet fields.

[0036] Referring back to Figure 1, in one embodiment of the present disclosure, the one or more system modules, such as the‘inifi Script/Software 110, the EDA 120, the transactor

135, the‘sim’ script/software 150 and the waveform viewer 165 may be implemented on a single host machine 170 as shown. Further, a common GUI may be provided for the ease of use by the designer and the common GUI provides links to various other GUIs such as to the first GUI and the second GUI for selecting debugging capabilities at modular level, for adding test cases, for viewing simulation results, etc.

[0037] Figure 5 illustrates an exemplary GUI in accordance with an embodiment of the present disclosure. The designer may initiate emulation and simulation (simemulation) on the DIJT using the GUI shown. Initially, the designer may add RTL design file (.f or .v format) using the“add file” option 505 and upon adding, the list of files added is displayed in the list of files 510. Then, the‘init’ software 110 processes the RTL design files and create hierarchy of the RTL, beginning with the top level module. As described in the present disclosure, the sy stem enables the designer to choose debugging capability at modular level (by selecting one or multiple modules of the DIJT) or for the complete IP core (DUT). Referring to Figure 5, the design may click on“Insert Debug” option 515 which enables the designer to choose debugging capability at modular level. Figure 6 illustrates an exemplary user interface providing debugging capabilities in accordance with an embodiment of the present disclosure. As shown, the designer may select a particular module’s signals to be seen in the waveform results for verification or lets the designer may select the complete design for verification. Referring back to Figure 5, the designer may define one or more parameters for emulation and simulation, for example, the designer may define clocks, add test cases, run the test cases, view results, etc., using the one or more options provided by the GUI.

[0038] An exemplary process flow for a 32-bit RISC processor to simulated and emulated using the proposed system and method is described in detail further below.

[0039] Example design of 32-bit RISC processor has 50K flip-flop count, and comprises the following sub-modules (simplified for ease of explanation) with rprocessor top as the top level module.

Above mentioned Verilog files path are listed in a rprocessor.f file

These files are then read through the GUI of Figure 5.

[0040] Referring back to Figure 5, the designer/user may add the project by clicking on“Add

File” option 505 and upon clicking, the application redirects the user to another window where the user may browse the“rprocessor.f” file to add the same. Then the all the fries will be listed in the“List of File” field 510. Then the user may compile the files and the application creates hierarchy, and any compile error will be displayed in the log.

[0041] The user may view the hierarchy of fries using the option“hierarchy” 520, and the application displays the files beginning with the top level module as shown below.

[0042] As described, the system disclosed in the present disclosure, enables the user to choose the debugging capabilities at modular level or for the complete IP core. Referring to Figure 5, the user may click on“Insert Debug” option 515 and the application provides the user with an option to select particular module’s signal to be observed in the waveform result.

[0043] Further, the user may define different clocks in the design using“Define Clocks” option 520. It is to be noted that the clock ratios should be in multiple of“2” of the slowest clock. Sampling of the signals is done with respect to the fastest clock defined by the user. Using the information on the clocks and the number of signals to be tapped out for debugging, the application determines the number of“512 size Muxs” required for the design, and also determines the values to configure the MMCM/PLL to generate the clocks. For example, Total_number_of_muxes ^:::: No_of_Debug_lines/512,

For rproseccor_top, Total_number_of_muxes = (50000/512) = 98.

[0044] Then the application taps out all the flip-flop outputs from the sub-modules and brings them as ports of the modified / processor top. Further, creates a“wrapper.v” file, in which the modified rprorcessor (DUT) is instantiated. In the“wrapper.v” file along with modified DUT, the application instantiates the required number of multiplexers to create a mux structure as shown in Figure 7. Then the application instantiates a DDR4 controller with 512 bits, as input as shown Figure 2a It is to be noted that the DDR4 will be working at a frequency of 400 MHz and number of signals to be tapped as 50,000. Then the fastest clock in the design shall be,

F = ~ (DDR4_CTRL_F *2*512/50,000) * 80%

i.e , ((400*(10^L6)*2*512)/50,000)*(80/100) ^{: =} 6.5 MHz At the read side of this, the controller will be glue logic to read the accumulated data, and the read request is initiated by the application.

[0045] With this wrapper as top, it is driven through the FPGA tool flow to create the bit file. By clicking on the“Generate Bit File” option 525 (referring to Figure 5), the application invokes the FPGA tool in the background to generate the bit file. Once the DUT bit file is generated with the hardware of Figure 7, the bit file may be loaded on the FPGA and user may send the stimulus through a“Send Stimulus” tab (not shown in Figure). Once the DDR4 memory is full, software reads the output from the DDR4 memory and dumps a project.vcd file along with states of each flip flop with corresponding names.

[0046] Hence, the FPGA based emulation system/platform disclosed in the present disclosure provides a unique capability to verify and validate register-transfer level (RTL) design at faster rate, achieving prototyping of the RTL design at the same time

[0047] Further, the system and method disclosed in the present disclosure provides a user friendly first graphical user interface (GUI) using which a user/designer may choose debugging capabilities at modular level or for the complete IP core. Furthermore, the GUI provides various options using which the user may inject the test cases to the one or multiple modules DUT.

[0048] Further, a DUT may be run at the near real time, and provides the debug capability of the traditional simulation methodology.

[0049] Furthermore, the platform combines the capabilities of simulation by allowing the designer to have software (C/UVM) based test cases to be run on a hardware which is emulated on an FPGA, thus providing both the emulation and simulation capabilities. As the debugging is hardware based, the debugging is close to the actual silicon debug with enhanced debug capabilities which helps in faster debug times.

[0050] While specific language has been used to describe the disclosure, any limitations arising on account of the same are not intended. As would be apparent to a person skilled in

5 the art, various working modifications may be made to the method in order to implement the inventive concept as taught herein.

[0051] The figures and the foregoing description give examples of embodiments. Those skilled in the art will appreciate that one or more of the described elements may well be combined into a single functional element. Alternatively, certain elements may be split into multiple functional elements. Elements from one embodiment may be added to another embodiment. For example, orders of processes described herein may be changed and are not limited to the manner described herein. Moreover, the actions of any flow diagram need not be implemented in the order shown; nor do all of the acts necessarily need to be performed. Also, those acts that are not dependent on other acts may be performed in parallel with the other acts. The scope of embodiments is by no means limited by these specific examples. Numerous variations, whether explicitly given in the specification or not, such as differences in structure, dimension, and use of material, are possible. The scope of embodiments is at least as broad as given by the following claims.

Claims

We Claim:

1. A method of simemulating a design under test (DUT), the method comprising:

converting a text based register transfer level (RTL) design of the DUT into an emulation capable RTL design;

synthesizing, by an electronic design automation tool (EDA), the emulation capable RTL for generating a bit fde, wherein the bit file describes the design under test as a collection of instances of standard components;

loading the bit file into a Field Programmable Gate Array (FPGA);

receiving and running one or more test cases for debugging and validating one or multiple modules of the DUT;

recording flip-flops states of the FPGA simulating the one or multiple modules at every clock cycle in a memory module; and

generating a simulation file by mapping resultant states of the flip-flops with their naming nomenclature from the text based RTL design.

2. The method as claimed in claim 1, wherein the method further comprises:

providing a first user interface for selecting the one or multiple modules for simulation; and

providing a second user interface for creating and selecting the one or more test cases for debugging and validating the design under test (DUT).

3. The method as claimed in claim 1 , wherein the one or more test cases are received through a transactor and deciphered using a wrapper bridge inside the FPGA.

4. The method as claimed in claim 1, wherein the flip-flops states of the FPGA simulating the one or multiple modules are recorded in the memory module at every clock cycle, wherein the clock cycle is derived based on fastest DUT clock defined by a user.

5. A system for si m emulation of a design under test (DUT), the system comprising: a host machine configured for:

synthesizing the emulation capable RTL for generating a bit file, wherein the bit file describes the design under test as a collection of instances of standard components;

loading the bit file into a Field Programmable Gate Array (FPGA) for emulating the DUT;

the FPGA being configured for:

receiving and running one or more test cases for debugging and validating one or multiple modules of the DUT,

a DDR controller configured for:

reading and recording flip-flops states of the FPGA simulating the one or multiple modules, at every clock in a memory module,

wherein, the host machine is further configured for generating a simulation file by mapping resultant states of the flip-flops with their naming nomenclature from the text based RTL design.