Patent Application
20230421477
Generally, the invention relates to analysis of pre-silicon simulation results. More specifically, the invention relates to method, system, and a Graphical User Interface (GUI) client for generating a simulation timeline encoded packets view.
Pre-Silicon simulation is a process of execution of a model, represented by a computer program that provides information about the system under investigation. As opposed to an analytical approach for analyzing the model that is purely theoretical, the analysis of the model via the simulation technique is more reliable as it is more flexible and convenient. In order to analyze the system via the simulation technique multiple simulation testbench components are used.
In a scenario, when a Device Under Test (DUT) (or a System Under Test (SUT)) has multiple input and output interfaces and uses multiple streams that enter or exit the DUT via a single interface, in such a scenario getting a bigger picture of a stimuli, scoreboard expectations, and outputs might become time consuming with the usage of traditional logs, transcripts, or waveforms. Similarly, in order to perform analysis of simulation results, simulation failures, and simulation testbench components (testbench components) activities by using traditional logs, transcripts or waveform might not be always efficient.
Therefore, there is a need of implementing an efficient and reliable technique for generating a simulation timeline encoded packets view for analyzing simulation results.
In one embodiment, a method for generating a simulation timeline encoded packets view is disclosed. The method may include receiving a type string from each of a plurality of simulation testbench components. It should be noted that, the type string corresponds to a simulation testbench component from a plurality of simulation testbench components and a packet type from a plurality of packet types. The method may include assigning one or more unique type codes to each of the plurality of simulation testbench components based on one or more type strings received from the respective simulation testbench component. The method may include iteratively receiving from at least one of the plurality of simulation testbench components, a plurality of data strings along with the corresponding assigned unique type code. It should be noted that, each of the plurality of data strings correspond to a packet and a packet type from the plurality of packet types. The method may include storing each of the plurality of data strings marked with an associated receipt timestamp. The method may include contemporaneously generating at each iteration a simulation timeline encoded packets view for each of the plurality of simulation testbench components based on the plurality of data strings, the marked receipt timestamps, and the assigned unique type codes. The method may include contemporaneously rendering at each iteration the simulation timeline encoded packets view via a Graphical User Interface (GUI).
In another embodiment, a graphical user interface (GUI) client for generating a simulation timeline encoded packets view is disclosed. The disclosed GUI client may be configured to receive a request from a user to render the simulation timeline encoded packets view for a simulation. It should be noted that, the simulation timeline encoded packet view may include each of a plurality of simulation testbench components, a plurality of data strings received from each of the plurality of simulation testbench components, a marked receipt timestamp, and an assigned unique type code. The GUI client may be configured to process the received request for generating the simulation timeline encoded packets view for the simulation. The GUI client may be configured to contemporaneously render at each iteration to the user, the generated simulation timeline encoded packets view for the simulation.
In yet another embodiment, a system for generating a simulation timeline encoded packets view is disclosed. The system includes a processor and a memory communicatively coupled to the processor. The memory may store processor-executable instructions, which, on execution, may cause the processor to receive a type string from each of a plurality of simulation testbench components. It should be noted that, the type string corresponds to a simulation testbench component from a plurality of simulation testbench components and a packet type from a plurality of packet types. The processor-executable instructions, on execution, may further cause the processor to assign one or more unique type codes to each of the plurality of simulation testbench components based on one or more type strings received from the respective simulation testbench component. The processor-executable instructions, on execution, may further cause the processor to iteratively receive from at least one of the plurality of simulation testbench components, a plurality of data strings along with the corresponding assigned unique type code. It should be noted that, each of the plurality of data strings corresponds to a packet and a packet type from the plurality of packet types. The processor-executable instructions, on execution, may further cause the processor to store each of the plurality of data strings marked with an associated receipt timestamp. The processor-executable instructions, on execution, may further cause the processor to contemporaneously generate at each iteration, a simulation timeline encoded packets view for each of the plurality of simulation testbench components based on the plurality of data strings, the marked receipt timestamps, and the assigned unique type codes. The processor-executable instructions, on execution, may further cause the processor to contemporaneously render at each iteration, the simulation timeline encoded packets view via a Graphical User Interface (GUI).
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed.
The present application can be best understood by reference to the following description taken in conjunction with the accompanying drawing figures, in which like parts may be referred to by like numerals.
The following description is presented to enable a person of ordinary skill in the art to make and use the invention and is provided in the context of particular applications and their requirements. Various modifications to the embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the invention. Moreover, in the following description, numerous details are set forth for the purpose of explanation. However, one of ordinary skill in the art will realize that the invention might be practiced without the use of these specific details. In other instances, well-known structures and devices are shown in block diagram form in order not to obscure the description of the invention with unnecessary detail. Thus, the invention is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features disclosed herein.
While the invention is described in terms of particular examples and illustrative figures, those of ordinary skill in the art will recognize that the invention is not limited to the examples or figures described. Those skilled in the art will recognize that the operations of the various embodiments may be implemented using hardware, software, firmware, or combinations thereof, as appropriate. For example, some processes can be carried out using processors or other digital circuitry under the control of software, firmware, or hard-wired logic. (The term “logic” herein refers to fixed hardware, programmable logic and/or an appropriate combination thereof, as would be recognized by one skilled in the art to carry out the recited functions.) Software and firmware can be stored on computer-readable storage media. Some other processes can be implemented using analog circuitry, as is well known to one of ordinary skill in the art. Additionally, memory or other storage, as well as communication components, may be employed in embodiments of the invention.
A functional diagram of a system 100 configured for generating a simulation timeline encoded packets view is illustrated in
In an embodiment, a first data string sent by each of the plurality of simulation testbench components to the packets plotter 102 may be the type string. In other words, each of the plurality of simulation testbench components may send the type string only when a data string is to be sent to the packets plotter 102 for the first time. The reception module 106 may further send the type string received from each of the plurality of simulation testbench components to the code assigning module 108.
Upon receiving the type string, the code assigning module 108 may assign a unique type code for each of the at least one type string received from each of the plurality of simulation testbench components based on the type string thereof. In an embodiment, the unique type code may correspond to at least one of one of the plurality of simulation testbench components and one of the plurality of packet types. Thereafter, the code assigning module 108 may send the at least one assigned unique type code back to each of the plurality of simulation testbench components and to the mapping module 110. The mapping module 110 may be configured to map the at least one assigned unique type code to the associated simulation testbench component from the plurality of simulation testbench components and the corresponding packet type from the plurality of packet types. Once the mapping is done, it may be stored in a database 118. In an embodiment, the at least one assigned unique type code may be stored in an array labeled as ‘unique type code per type’ by indexing each of the plurality of simulation testbench components using the associated type string. In other words, the ‘unique type code per type’ array may be used for storing the at least one unique type code for each of the plurality of simulation testbench components using the associated type string.
As will be appreciated, any simulation testbench component from the plurality of simulation testbench components present in a pre-silicon simulation environment (also referred as verification environment/or testbench/or test environment) may send data strings for one or more of the plurality of packet types to the packets plotter 102. Thus, once the unique type codes are assigned and also mapped to each of the plurality of simulation testbench components and packet types, the reception module 106 may iteratively receive a plurality of data strings each with the corresponding assigned unique type code, from at least one of the plurality of simulation testbench components. As with the type string, each of the plurality of data strings may correspond to a packet and a packet type from the plurality of packet types. It may be noted that each of the plurality of data strings may include at least one of a string representation of the associated packet, register address, register data, along with one of the unique type codes assigned to the simulation testbench component that generated the data string from the plurality of data strings.
In addition to iteratively receiving the plurality of data strings each with the corresponding assigned unique type code from the at least one simulation testbench component, the reception module 106 may be configured to receive a critical message from one or more of the plurality of simulation testbench components. In an embodiment, the critical message does not include any unique type code. The critical message may include, but is not limited to at least one of a reset event message, an error event message, a user-defined event message, or an end of simulation event message.
At each iteration, once the reception module 106 receives one or more data strings each with the corresponding assigned unique type code. As discussed before, in addition to the data strings, the reception module 106 may also receive critical messages at one of the iterations. At each such iteration, the identification module 112 fetches each of the one or more data strings to identify the at least one unique type code included therein. The unique type code thus identified enables the identification module 112 to determine the simulation testbench component that generated that data string. Upon identifying the at least one assigned unique type code included in each of the plurality of data strings, the identification module 112 may extract a receipt timestamp associated with each of the plurality of data strings corresponding to each of the at least one unique type code. In an embodiment, the receipt timestamp for a data string from the plurality of data strings may be a timestamp of receiving the data string by the packets plotter 102. In addition to extraction of the receipt timestamp for each of the plurality of data strings, the identification module 112 may fetch each of the critical message from the reception module 106 to identify the receipt timestamp of each critical message. Once all the above stated information is extracted, the mapping module 110 may be configured to create a mapping between each of the plurality of data strings, the associated receipt timestamps, and the one of the unique type codes assigned to a simulation testbench component generating the data string. Upon creating the mapping, the mapping module 110 may store the created mapping and each of the received critical message along with the corresponding receipt timestamp in the database 118. In an embodiment, each of the set of critical messages received from one or more of the plurality of simulation testbench components may be stored using an array labeled as ‘critical messages’. The array ‘critical messages’ may be used for storing each of the set of critical messages received from one or more of the plurality of simulation testbench components. The timestamp of receiving each of the set of critical messages may be stored using an array labeled as ‘message time’. The array ‘message time’ may be used for storing the timestamp of receiving each of the set of critical messages from one or more of the plurality of simulation testbench components. With reference to
Further, the view generation module 114 may fetch details (i.e., the data string, the associated receipt timestamp, and the at least one unique type code assigned) associated with the simulation testbench components and details of each of the received critical message (i.e., the corresponding receipt timestamp) from the database 118. Based on the fetched details, the view generation module 114 may plot a timeline of transactions corresponding to each of the plurality of simulation testbench components in the simulation timeline encoded packets view, based on the plurality of data strings, the identified unique type codes, and the extracted receipt timestamps. Further, the view generation module 114 may also plot each of the critical message received from one or more of the plurality of simulation testbench components in the simulation timeline encoded packets view.
As discussed before, the simulation timeline encoded packets view may be generated corresponding to at least one of the plurality of simulation testbench components from which the plurality of data strings has been received, and each of the critical message received from one or more of the plurality of simulation testbench components. In an embodiment, at each iteration, i.e., at each time instant when one or more data strings are received, the view generation module 114 may generate the simulation timeline encoded packets view for each of the plurality of simulation testbench components based on the one or more data strings, the marked receipt timestamp for each of these data strings, and the unique type codes assigned to each of the plurality of simulation testbench components. Upon generating the simulation timeline encoded packets view, the view generation module 114 may share the generated simulation timeline encoded packets view to the rendering module 116.
The rendering module 116 may then render the generated simulation timeline encoded packets view to a user via at least one of a plurality of user devices 122. In an embodiment, the rendering module 116 may be configured to contemporaneously rendering at each iteration, i.e., at each time instant when one or more data strings are received, the simulation timeline encoded packets view via a Graphical User Interface (GUI) (also referred as GUI client) of the plurality of user devices 122. Examples of the plurality of user devices 122 may include, but is not limited to, computer, laptop, mobile, and tablet.
As will be appreciated the user may communicate via each of the plurality of user devices 122 with the view generation module 114 of the packets plotter 102 via a network 120. The network 120, for example, may be any wired or wireless communication network and the examples may include, but may be not limited to, the Internet, Wireless Local Area Network (WLAN), Wi-Fi, Long Term Evolution (LTE), Worldwide Interoperability for Microwave Access (WiMAX), and General Packet Radio Service (GPRS). Further, the database 118 may be periodically updated based on new data strings received from one or more of the plurality of simulation testbench components. The database 118 may also be updated based on at least one type string received from a new simulation testbench component that may be added to the simulation. The complete process followed by the system 100 is further explained in detail in conjunction with
Referring now to
Once the unique type code is assigned to each of the plurality of simulation testbench components, at step 206, a plurality of data strings each with the corresponding assigned unique type code may be received from one or more of the plurality of simulation testbench components. It may be noted that data strings may be received at each iteration, i.e., at each time instance, one or more data strings may be received. In other words, receiving data strings is an iterative process till the simulation is completed. Each of the plurality of data strings may correspond to a packet and a packet type from the plurality of packet types. Further, each of the plurality of data strings may include at least one of a string representation of the associated packet data, register address, register data along with one of the unique type codes assigned to a simulation testbench component from the plurality of simulation testbench components generating the data string from the plurality of data strings.
Upon iteratively receiving the plurality of data strings each with the corresponding assigned unique type code, at step 208, each of the plurality of data strings may be stored. In an embodiment, in order to store each of the plurality of data strings, each of the plurality of data strings may be marked with an associated receipt timestamp and stored thereafter. The associated receipt timestamp for a data string from the plurality of additional data strings may correspond to a timestamp of receiving the data string by a packets plotter. In addition, in order to store a data string, at step 210, a mapping may be created between the data string, the associated receipt timestamp, and one of the unique type code assigned to a simulation testbench component that generated the data string. It will be apparent to a person skilled in the art that the mapping may be performed for each of the plurality of data strings in a similar manner. With reference to
Once the plurality of data strings are stored, at step 212, at each iteration, a simulation timeline encoded packets view may be contemporaneously generated for each of the plurality of simulation testbench components. In an embodiment, the simulation timeline encoded packets view may be contemporaneously generated based on the plurality of data strings, the marked receipt timestamp, and the assigned unique type codes. In other words, the simulation timeline encoded packets view may be generated on a data string in real-time, as and when the data string is received. Upon generating the simulation timeline encoded packets view, at step 214, at each iteration the simulation timeline encoded packets view may be rendered to a user via a Graphical User Interface (GUI). In other words, the simulation timeline encoded packets view may be rendered to the user via the GUI, as and when the data string is received, in real-time. Thus, the user would be able to ascertain the progress of a simulation in real-time. Additionally, once the simulation has completed, the simulation timeline encoded packets view for all the data strings received from the plurality of simulation testbench components is rendered to the user via the GUI.
With reference to
Referring now to
Referring now to
Once the at least one unique type codes assigned to each of the plurality of simulation testbench components and receipt timestamps for each of the received data strings have been identified, at step 408, a timeline of transactions corresponding to each of the plurality of simulation testbench components may be plotted in the simulation timeline encoded packets view. In an embodiment, the plotting of the timeline of transactions corresponding to the plurality of simulation testbench components may be done based on the plurality of data strings, the identified unique type codes, and the extracted receipt timestamps. This has been further explained in detail in conjunction with
Referring now to
At step 502, a critical message may be received from the one or more of the plurality of simulation testbench components. Upon receiving the critical message, at step 504, the critical message may be presented on the GUI corresponding to the receipt timestamp of the critical message. The presented critical message, for example, may clearly indicate on the GUI that an error has occurred during the simulation. It should be noted that, the critical message along with the corresponding receipt timestamp may be rendered via the simulation timeline encoded packets view generated for the simulation.
Referring now to
Once each of these simulation testbench components and packet types have been assigned a unique type code, one or more of the simulation testbench components may send data strings that include unique type codes to the packets plotter 102. The data strings may be received at various time instances and may be plotted in the GUI based on the receipt timestamps, unique type codes and the type strings used by the simulation testbench component sending these data strings respectively. Specifically, with reference to
As depicted via the GUI 600, one or more cells in the column 604, i.e., the column for the register write, may depict unique type code included within the data strings received from the respective simulation testbench component and the data string counts/numbering at various time instances. By way of an example, data strings ‘RA0’, ‘RA1’, up to ‘RA117’ are received at different time instances from the associated simulation testbench component. Based on the receipt timestamp for each of these data strings, unique type code and the data string counts/numbering, these are depicted on the GUI 600. In other words, the data strings are represented on the GUI for a given simulation testbench component using merely the unique type code, the data string counts/numbering, and the receipt timestamps. For example, a data string that includes the unique type code ‘RA’ may be received at ‘100 nanoseconds (ns)’ represented as ‘RA0’ (first packet), the data string that includes the unique type code ‘RA’ may be received at ‘150 ns represented as ‘RA1’, and another data string that includes the unique type code ‘RA’ may be received at 202400 ns represented as ‘RA117’. Thus, these data strings may be represented on the GUI 600 using the unique type codes RA0, RA1, and RA117 mapped respectively to the times 100 ns, 150 ns, and 202400 ns. In a similar manner, all other data strings received from the respective simulation testbench component are represented on the GUI 600.
Further, one or more cells in the column 606, i.e., the column for the interface 1 driver, may depict unique type code included within the data strings received from respective simulation testbench component and the data string counts/numbering at various time instances. By way of an example, data strings ‘DA0’, ‘DA1’, up to ‘DA605’ are received at different time instances from the interface 1 driver simulation testbench component. Based on the receipt timestamp for each of these data strings, unique type codes, and the data string counts/numbering, these are depicted on the GUI 600. In other words, the data strings are represented on the GUI for a given simulation testbench component using merely the unique type code, the data string counts/numbering, and the receipt timestamps. For example, a data string that includes the unique type code ‘DA’ may be received at ‘500 ns’ represented as ‘DA0’, the data string that includes the unique type code ‘DA’ may be received at ‘900 ns’ represented as ‘DA1’, and another data string that includes the unique type code ‘DA’ may be received at ‘201350 ns’ represented as ‘DA605’. Thus, these data strings may be represented on the GUI 600 using the unique type codes DA0, DA1, up to DA605 mapped respectively to the times 500 ns, 900 ns, and 201350 ns. In a similar manner, all other data strings received from the respective simulation testbench component are represented on the GUI 600.
In a similar manner, one or more cells in the column 608, i.e., the column for interface 1 monitor may depict unique type code included within the data strings received from respective simulation testbench component and the data string counts/numbering at various time instances, one or more cells in the column 610, i.e., the column for interface 2 driver may depict unique type code included within the data strings received from the respective simulation testbench component and the data string counts/numbering at various time instances, and one or more cells in the column 612, i.e., the column for interface 2 monitor may depict unique type code included within the data strings received from the respective simulation testbench component and the data string counts/numbering at various time instances.
As depicted via the GUI 600, the cells mapped to time instances at which no data string is received from any of the simulation testbench components remain empty. In addition to providing the representation of the plurality of data strings received from the simulation testbench components, the GUI 600 may also provide representation of a set of critical messages based on a timestamp of receiving each of the set of critical messages for the simulation.
In the GUI 600, the set of critical messages are depicted adjacent to time instance when these critical messages were received, based on the respective receipt timestamps. For example, a reset message is received at a time instance of ‘50 ns’, a message of detection of parity error by the interface 1 monitor simulation testbench component is received at a time instance of ‘2075 ns’, a message on running out of credits from the interface 1 driver is received at a time instance of ‘200810 ns’, and a message on simulation ending is received at a time instance of ‘202500 ns’.
As depicted via the GUI 600, the simulation timeline encoded packets view may provide representation of each of the plurality of simulation testbench components, the plurality of data strings received from each of the plurality of simulation testbench components, the set of critical messages in a chronological order along with the associated timestamps. This simulation timeline encoded packets view provided to the user may enable user to understand activities of the simulation testbench components in a testbench/test environment, reasonably faster. Moreover, the simulation timeline encoded packets view might be used by the user in conjunction with a codes look-up file (also referred as a code 2 packet mapper log files), while locating a packet of interest. Therefore, the simulation timeline encoded packets view may save considerable amount of simulation results analysis time. In reference to
Referring now to
In
In
In
In
Referring now to
In order to plot the set of packets, initially, the scoreboard may send a type string. The type string may represent a packet type associated with each of the set of packets that the scoreboard wants to plot. In the GUI 1200, a first column, i.e., ‘time 1202’ may represent pre-defined time intervals. At one of these time intervals, one or more critical messages and one or more packets may be received. Further, in the GUI 1200, subsequent columns represent various packet types and their representation in the form of unique type code corresponding to the time instances at which these are received. A column 1204 is for expected drop packet, a column 1206 is for expected stream 8 output packet, a column 1208 is for actual stream 8 output packet, a column 1210 is for expected stream 9 output packet, and a column 1212 is for actual stream 9 output packet.
Once each packet type has been assigned a unique type code, these unique type codes may be used by the scoreboard (simulation testbench component) to populate the GUI 1200 via the packets plotter 102. The one or more packets may be received at various time instances and may be plotted in the GUI 1200 based on the receipt timestamps, unique type codes, and the packet type that they respectively correspond to. Specifically, with reference to
As depicted via the GUI 1200, one or more cells in the column 1204, i.e., the column for the expected drop packet, may depict unique type code representing packets of the relevant type and packet count/numbering received at various time instances. By way of an example, ‘ZA0’ and ‘ZA1’ represent expected drop packets that are received at different time instances. Thus, expected drop packets are represented on the GUI 1200 using merely the unique type code and the packet count/numbering allocated therein. For example, the packet (first packet) that includes the unique type code ‘ZA’ may be received at 280 microsecond (us) represented as ‘ZA’, while the packet that includes the unique type code ‘ZA’ may be received at 400 us represented as ‘ZA1’. Thus, these packets ‘ZA0’ and ‘ZA1’ are represented on the GUI 1200 using the unique type code and the packet count/numbering mapped respectively to the times 280 us and 400 us.
Further, one or more cells in the column 1206, i.e., the column for the expected stream 8 output packet, may depict unique type code representing packets of the relevant type and packet count/numbering received at various time instances. By way of an example, EA0, EA1, and EA2 represent expected stream 8 output packets that are received at different time instances. For example, the packet that includes the unique type code ‘CEA’ may be received at 100 us represented as ‘EA0’, the packet that includes the unique type code ‘EA’ may be received at 120 us represented as ‘EA1’, and the packet that includes the unique type code ‘EA’ may be received at 350 us represented as ‘EA5’. Thus, these packets EA0, EA1, EA5 may be represented on the GUI 1200 using the unique type code and the packet count/numbering mapped respectively to the time instances 100 us, 120 us, and 350 us.
In a similar manner, one or more cells in the column 1208, i.e., the column for the actual stream 8 output packet, may depict unique type code representing packets of the relevant type and packet count/numbering received at various time instances, one or more cells in the column 1210, i.e., the column for the expected stream 9 output packet, may depict unique type code representing packets of the relevant type and packet count/numbering received at various time instances, and one or more cells in the column 1212, i.e., the column for the actual stream 9 output packet, may depict unique type code representing packets of the relevant type and packet count/numbering received at various time instances.
As depicted via the GUI 1200, the cells mapped to time instances at which no packets are received, remain empty. In addition to providing the representation of the packets, the GUI 1200 may also provide representation of a set of critical messages based on a timestamp of receiving each of the set of critical messages during the simulation.
In the GUI 1200, the set of critical messages are depicted adjacent to time instance when these critical messages were received, based on the respective receipt timestamps. For example, a reset de-assertion message is received at a time instance of ‘50 ns’, and a message of detecting actual stream 9 output data error is received at a time instance of 350 us.
As depicted via the GUI1200, the simulation timeline encoded packets view may provide representation of various packets and each of the set of critical message in a chronological order along with the associated receipt timestamp. The simulation timeline encoded packets view rendered to the user via the GUI 1200 may enable the user to understand activities of the simulation reasonably faster. Additionally, the simulation timeline encoded packets view may save considerable amount of simulation results analysis time. Moreover, the simulation timeline encoded packets view might be used by the user in conjunction with a codes look-up file (also referred as a code 2 packet mapper log files), while locating a packet of interest. The code look-up file associated with each of the set of packets has been depicted via
Referring now to
In
In
In
In
Referring now to
Various embodiments provide method and system for generating a simulation timeline encoded packets view. The disclosed method and system may receive a type string from each of a plurality of simulation testbench components. The type string may correspond to a packet type from a plurality of packet types. Further, the disclosed method and system may assign a unique type code to each of the plurality of simulation testbench components based on the type string received from each of the set of packets. Moreover, the disclosed method and system may iteratively receive from at least one of the plurality of simulation testbench components, a plurality of data strings along with the corresponding assigned unique type code. Each of the plurality of data strings may correspond to a packet and a packet type from the plurality of packet types. Further, the disclosed method and system may store each of the plurality of data strings marked with an associated receipt timestamp. Thereafter, the disclosed method and system may contemporaneously generate at each iteration a simulation timeline encoded packets view for each of the plurality of simulation testbench components based on the plurality of data strings, the marked receipt timestamps, and the assigned unique type codes. Lastly, the disclosed method and the system may contemporaneously render at each iteration, the simulation timeline encoded packets view via a Graphical User Interface (GUI).
The disclosed method and system may provide some advantages like, the disclosed method and the system may be methodology independent and hence may be used across any of an existing industry standard verification methodology. Further, the disclosed method and the system may provide user an ability to identify each of a set of packets and position of each of the set of packets in a sequence of packets corresponding to each of a plurality of simulation testbench components represented in the simulation timeline encoded packets view. In addition, the disclosed method and the system may provide pictorial representation to the user in order to enable the user to view an error occurred in the simulation and relate timing of the error (if there is an error) with transaction timing of each of the plurality of simulation testbench components (also referred as testbench components). Moreover, the disclosed method and the system may provide pictorial representation to the user in order to enable the user to view critical event (i.e., the critical message) and relate timing of the critical event (for example: reset, driver waiting for credits, Scoreboard (SB) flagging the error, SB dropping the packet) with transactions timing of each of the plurality of simulation testbench components.
It will be appreciated that, for clarity purposes, the above description has described embodiments of the invention with reference to different functional units and processors. However, it will be apparent that any suitable distribution of functionality between different functional units, processors or domains may be used without detracting from the invention. For example, functionality illustrated to be performed by separate processors or controllers may be performed by the same processor or controller. Hence, references to specific functional units are only to be seen as references to suitable means for providing the described functionality, rather than indicative of a strict logical or physical structure or organization.
Although the present invention has been described in connection with some embodiments, it is not intended to be limited to the specific form set forth herein. Rather, the scope of the present invention is limited only by the claims. Additionally, although a feature may appear to be described in connection with particular embodiments, one skilled in the art would recognize that various features of the described embodiments may be combined in accordance with the invention.
Furthermore, although individually listed, a plurality of means, elements or process steps may be implemented by, for example, a single unit or processor. Additionally, although individual features may be included in different claims, these may possibly be advantageously combined, and the inclusion in different claims does not imply that a combination of features is not feasible and/or advantageous. Also, the inclusion of a feature in one category of claims does not imply a limitation to this category, but rather the feature may be equally applicable to other claim categories, as appropriate.
