-
Notifications
You must be signed in to change notification settings - Fork 13
ESYNet User Manual : Simulation Engine
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
- Event Queue
- Simulation Components
- Event Structure
- Events in ESYNet
- How to Add New Events
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.
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. |
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.
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.
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 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 withm_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 withm_pipe_time
not as 1.0 can only trigger the router and NI specified bym_src_id
.
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
) 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 (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.
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
.
Copyright @ Junshi Wang