Jump to content

bobo.drugo

Members
  • Posts

    2
  • Joined

  • Last visited

Profile Information

  • Gender
    Not Telling

bobo.drugo's Achievements

Member

Member (1/2)

0

Reputation

  1. Hi Philipp, thanks for your quick reply. I have a wait statement on each control path, it was not reported in the code snippet above. My ISS consumes simulation time, the pipeline model is stepped every clock cycle. When I say that the signal can be "kept high" I mean that the ISS can issue two or more consectuive memory accesses without setting the request signal to '0' in between (similar to a burst access). This is why I have this: if(!request.read()) wait(request.posedge_event()); Let me put the question this way. Below a simple example of ISS-memory interaction: -------------------------------------------------------------- void ISS::working() { while(true) { IO_data.write(_data); request.write(true); wait(); request.write(false); ... } } void memory::working() { while (true) { wait(request.posedge_event()); data = IO_data.read(); ... } } -------------------------------------------------------------- Am I sure that the data read by the memory is _data written by the ISS? Thanks, Daniele
  2. Hi everybody, I have a question regarding wait(SC_ZERO_TIME) statements. I am working on a virtual platform for embedded systems with several ISSs, interconnections and memory modules. The memory thread has to be triggered on the positive edge of the request signal and keep on serving subsequent requests if the signal is kept high by the initiator after the first request. The code below shows the memory module implementation. ----------------------------------------------------------------------------- void memory::working() { while (true) { wait(SC_ZERO_TIME); wait(SC_ZERO_TIME); if(!request.read()) wait(request.posedge_event()); data = IO_data.read(); /* ... */ } } ----------------------------------------------------------------------------- My problem is that without the 2 wait(SC_ZERO_TIME) statements, a quick fix made some time ago, the data read is wrong (not current cycle). Since I checked that every master is filling first the data field then raising the request signal, I don't understand the need of two delta cycles to avoid reading the old value. Any idea/suggestion? Ciao, Daniele
×
×
  • Create New...