Skip to content

ESYNet User Manual : Simulation Engine

wangeddie67 edited this page May 2, 2019 · 34 revisions

ESYNet utilizes an event-driven simulation engine to perform the cycle-accurate simulation. In this chapter, we first introduce the conception of event-driven simulation. After that, we introduce how ESYNet implements the simulation engine.

Event-driven Simulation

The event-driven simulator consists of a simulation engine and simulation components. Simulation engine drives the simulation process forward while simulation components store the status and do the operations. In ESYNet, simulation components contain the components in the NoC.

The kernel of the simulation engine is the event queue which stores in the event in the order of increasing time. The event is an abstraction of simulation operations. The time determines when the simulation engine should respond to the specified event.

During the simulation, the simulation engine takes out the first event in the event queue and calls suitable simulation components to respond to the event. Simulation components receive the event and change their status and generate new events if necessary. The new events are inserted back to the event queue.

The simulation engine continues the iteration until all the events in the event queue have been responded. Thus, if the event queue is empty, the simulation is finished. When the simulation starts, the first event should be inserted to the event queue so that the simulation can start. If the event queue is empty, the simulation is finished.

The simulation time depends on the number of events. For example, if the NoC is not under heavy traffic, the simulation time can be very fast because there is not much event. On the other hand, the simulation accuracy depends on the fine-grain of event definitions.

Event Queue

ESYNet provides EsynetMessQueue as the event queue. The class is defined in esynet_mess_queue.h and esynet_mess_queue.cc. EsynetMessQueue inherts from multiset so that it can automatically sort items within the queue. The overload operator function of EsynetMessEvent is defined in esynet_mess_queue.cc.

class EsynetMessQueue : public multiset< EsynetMessEvent >;

The construction function inserts the first ROUTER event into the queue so that the simulation can start.

EsynetMessQueue provides two methods to insert events. addMessage should be provides the reference to an event and the event are inserted directly. insertMsg should be provides the necessary field and the event are created and inserted.

void addMessage(const EsynetMessEvent & x) { m_mess_counter++; insert(x); }
void insertMsg( int src, int dest, long long int sim_cycle, long packetSize, long int msgNo, long long addr, long vc );

EsynetMessQueue provides simulator to perform the simulation. All the events not later than sim_cycle (before and equal) are handled by the event queue.

void simulator( long long int sim_cycle );

EsynetMessQueue calls the simulation component through a pointer to NoC mp_sim_platform. In another word, EsynetMessQueue only recoganizes one simulation component which contains the entire NoC. See also Simulation platform.

Related topics
See also Event trace for more information about events used to record simulation, how to generate event trace.
See also Benchmark trace for more information about how to generate benchmark trace.

Simulation Components

ESYNet provides EsynetSimBaseUnit as the base-class for simulation components. The simulation components must inhert from EsynetSimBaseUnit, otherwise, they cannot be called by event queue.

Event queue calls the simulation components by eventHandler function.

virtual void eventHandler(double time, const EsynetMessEvent & mess);

It accepts the simulation time and the reference to the event. eventHandler is a virtual function which can be overloaded with different operations. By default, it uses update simulation time.

time is used to update the simulation cycle of each simulation component. Because there is no global time counter in ESYNet. The simulation cycle is stored within each simulation component. The simulation cycle are synchronized by eventHandler. In overloaded functions, it should not be forgot to update simulation time by setTime.

void setTime( double time );

The new events generated by eventHandler cannot be inserted into the event queue directly. The new events are stored in an event vector in EsynetSimBaseUnit. EsynetSimBaseUnit provides methods to operate on the event vector.

void addEvent(const EsynetMessEvent & event);
const vector< EsynetMessEvent > & eventQueue();
void clearEventQueue();

The event queue can get the new events after eventHandler.

The template to handle event should like follow. First, call eventHandler to handle the event. eventHandler does the correct operation, update status and generate new event. Then, call eventQueue to get the new event and insert them into the event queue. At lsat, call clearEventQueue to clear the events.

mp_sim_platform->eventHandler( m_current_time, current_message );
for ( size_t i = 0; i < mp_sim_platform->eventQueue().size(); i ++ )
{
    insert( mp_sim_platform->eventQueue()[ i ] );
}
mp_sim_platform->clearEventQueue();

Moreover, simulation components can be orgranized in a hierarchy way. The inner simulation components can be called by outer simulation components. The new event generates by the inner simulation components are inserted to the event vector of the outer simulation components. The event queue can get all new events from the event vector of outer simulation componnets.

Event Structure

ESYNet defines five events, includes: packet generation (EVG), router pipeline (ROUTER), link transmission (WIRE), credit transmission (CREDIT) and NI read (NIREAD).

ESYNet provides EsynetMessEvent to define the event structure. The class is defined in esynet_mess_event.h and esynet_mess_event.cc. m_event_time means the time when the simulation engine should respond to this event. The events are ordered by this field. m_mess_type means the event type. The group of m_src_id, m_src_pc and m_src_vc as well as the group of m_des_id, m_des_pc and m_des_vc specify which simulation component should be called to respond this event. Each event structure contains a field of flit structure to store more information. The flit structure is defined in esynet_flit.h and described in Flit structure.

Events in ESYNet

Packet generation event

Packet generation event (EVG) means a new packet should be injected into the network. EVG events are generated by the traffic generator or integration APIs.

EsynetMessEvent provides generateEvgMessage to generate a EVG event.

static EsynetMessEvent generateEvgMessage(double time, long src, long des, long pac_size, long msgno, double e2e_start, long flag = 0, long ack = -1 );

It should provides the following information.

Fields Data type NOTE
m_event_time double The injection time of the packet.
m_mess_type long EVG.
m_src_id long Source router id.
m_des_id long Destination router id.
m_flit EsynetFlit The head flit of new packet.
m_flit.m_flit_id long Packet id.
m_flit.m_flit_size long Packet size in flit.
m_flit.m_flit_type FlitType EsynetFlit::FLIT_HEAD.
m_flit.m_sor_addr long Source router id.
m_flit.m_des_addr long Destination router id.
m_flit.m_des_addr long Destination router id.
m_flit.m_flit_flag long Flit flags. Set FLIT_ACK if the packet is acknowledge packet.
m_flit.m_flit_start_time double The injection time of the packet.
m_flit.m_e2e_start_time double The end-to-end injection time of the packet. If the packet is an ACK packet, the end-to-end injection time is the injection time of the first packet; if the packet is retransmission packet, the end-to-end injection time should be the injection time of the first-time transmission.
m_flit.m_ack_packet long The id of the normal packet if this packet is a ACK packet.

The simulation engine calls the NI connected to the router specified by m_des_id to respond EVG event. NI will generate all the flits for the packets and stored flits in the injection queue. See also Traffic generation for more information.

Router pipeline

Router pipeline event (ROUTER) means one clock cycle for the pipeline in the router. ROUTER event provides the ability for ESYNet to perform the cycle-accuracy simulation. ROUTER events are generated by the simulation engine itself.

EsynetMessEvent provides generateRouterMessage to generate a ROUTER event.

static EsynetMessEvent generateRouterMessage(double time, double pipe, long id = -1 );

It should provide the following information.

Fields Data type NOTE
m_event_time double The simulation cycle.
m_pipe_time double The period of the pipeline in cycle.
m_mess_type long ROUTER.
m_src_id long Specified router to respond this event. Default value is -1.

ROUTER event is the first event in the event queue. It is inserted when the simulation starts. During the simulation, the simulation engine generates the next ROUTER event when it responds to one ROUTER event. The simulation cycle of the next ROUTER is calculated by added m_pipe_time to m_event_time. By default, the simulation engine calls all the routers and NIs to respond ROUTER event. Each router and NI does the pipeline once when they receive ROUTER event. See also Router pipeline and NI pipeline for more information.

ESYNet can support multi-clock-domains in NoC which means simulation components should not respond ROUTER event at the same time. ESYNet designs following rules to handle multi-clock-domains:

  • The basic clock period is 1.0 cycle. One ROUTER event with m_pipe_time as 1.0 can trigger all routers and NIs within the base clock domain.
  • Another clock period is measured by the basic clock period. One ROUTER event with m_pipe_time not as 1.0 can only trigger the router and NI specified by m_src_id.

Link transmission event

Link transmission event (WIRE) means a flit transmits through one link. WIRE events are generated by the link transmission stage in router pipeline.

EsynetMessEvent provides generateWireMessage to generate a WIRE event.

static EsynetMessEvent generateWireMessage(double time, long src, long src_pc, long src_vc, long des, long des_pc, long des_vc, const EsynetFlit & flit);

It should provides the following information. One WIRE event means m_flit transmits from m_src_vc of m_src_pc of m_src_id to m_des_vc of m_des_pc of m_des_id at m_event_time.

Fields Data type NOTE
m_event_time double The time when the flit should be received by destination router.
m_mess_type long WIRE.
m_src_id long Source router.
m_src_pc long Output physical port of source router.
m_src_vc long Output virtual channel of source router.
m_des_id long Destination router.
m_des_pc long Input physical port of destination router.
m_des_vc long Input virtual channel of destination router.
m_flit EsynetFlit The transmitted packet.

The simulation engine calls the router or NI specified by m_des_id to respond WIRE event. See also Receive flit in router and [Receive flit in NI] for more information.

Credit transmission event

Credit transmission event (CREDIT) means a credit information transmits through one link. The credit means the number of free-slots in the input channel/virtual channel connected with the output channel/virtual channel. In credit-based flow control, the credit is transmitted by the wires between routers as well. The WIRE events are generated by the router pipeline as well. See [flow control] for more information.

EsynetMessEvent provides generateCreditMessage to generate a CREDIT event.

static EsynetMessEvent generateCreditMessage(double time, long src, long src_pc, long src_vc, long des, long des_pc, long des_vc, long credit );

It should provides the following information.

Fields Data type NOTE
m_event_time double The time when the flit should be received by destination router.
m_mess_type long WIRE.
m_src_id long Source router.
m_src_pc long Input physical port of source router.
m_src_vc long Input virtual channel of source router.
m_des_id long Destination router.
m_des_pc long Output physical port of destination router.
m_des_vc long Output virtual channel of destination router.
m_flit.m_flit_id long Credit value.

The simulation engine calls the router or NI specified by m_des_id to respond CREDIT event. See also [flow control] for more information.

NI read event

NI read event (NIREAD) means a packet should be ejected from the network. NIREAD events are generated by the integration APIs.

EsynetMessEvent provides generateNIReadMessage to generate a NIREAD event.

static EsynetMessEvent generateNIReadMessage(double time, long ni);

It should provides the following information.

Fields Data type NOTE
m_event_time double The ejection time of the packet.
m_mess_type long NIREAD.
m_src_id long The NI id.

The simulation engine calls the NI by m_des_id to respond NIREAD event. NI will eject one packet out from the eject queue. See also NI pipeline for more information.

How to Add New Events

It is suggest to add new events by following flow:

  • Add the new event in EsynetMessEvent::EventType. The id of new event should be lower than 10 because the codes larger than 20 are used by the events to record the simulation.
  • Add a static method in EsynetMessEvent to generate the new event. The static method assigns value to the necessary fields for the new event.
  • (Optional) add the print string in the friend function EsynetMessEvent::operator<<.
  • Add the event handler function in EsynetFoundation. The event handle function accepts the reference to the event.
  • Add the event handler function into the switch-case structure in EsynetFoundation::eventHandler.