Jump to content

Giuli0

Members
  • Content Count

    8
  • Joined

  • Last visited

  • Days Won

    1

Giuli0 last won the day on August 12 2014

Giuli0 had the most liked content!

About Giuli0

  • Rank
    Member

Profile Information

  • Gender
    Not Telling
  • Location
    Italy
  1. Hi Ralph, thanks for your reply. Actually, I fixed the problem using a delay module. I agree with what you said, but in my case, I am integrating a pre existing project with no clock, and i preferred to keep everything as close as possible to the initial interface. Now it works.
  2. So, I am still working on this memory code, and I am still having troubles... The memory module has some submodules: a decoder, and a sc_vector containing mem_cell modules. The mem_cell has two input ports: datain, and address_enable. Address_enable is connected to the output port of the decoder, while datain is directly connected to the datain port of the memory upper level module. According to my design, mem_cell is sensitive to both address_enable and datain. My problem is that this signals have different path lengths: address_enable, receiving its value from the decoder, needs an extra d
  3. Hello Ralph, I was trying and answering to Karthick and I didn't see your answer. After reading it, I guess I was right. ThreadA and threadB are connected through a signal. ThreadA writes on the signal during its delta numb1, and this value will be seen by threadB only during its delta number2. Right? Thanks you both Karthick and Ralph!
  4. Thanks Karthick, now it works, but I am not sure why! Using you suggestion, generally speaking I think that the mechanism works like this: If I write something in threadA during delta number 1, it will only be available in threadB during delta num2. And if deltaB writes something during its delta num2, threadA has to wait delta num3 in order to read it. This is why the stimulus thread needs 2 wait(SC_ZERO_TIME) statements in order to read the correct output from the memory, because it has to forward its delta value. Am I right? And if all of this is right, what could be a more recco
  5. Hello everybody, While working on a systemC project, I discovered that probably I have some confused ideas about signals and ports. Let's say I have something like this: //cell.hpp SC_MODULE(Cell) { sc_in<sc_uint<16> > datain; sc_in<sc_uint<1> > addr_en; sc_in<sc_uint<1> > enable; sc_out<sc_uint<16> > dataout; SC_CTOR(Cell) { SC_THREAD(memory_cell); sensitive << enable << datain << addr_en; } private: void memory_cell(); }; //cell.cpp void Cell::memory_cell() { unsign
  6. So, do you think that one solution could be for the memory_thread to notify another process waiting for it, and this one to notify back to the memory_thread, after the delay? Or maybe doing something better without using a third process, but still using these commands: event_name.notify(mem_delay) and wait(event_name)?
  7. So, do you think that one solution could be for the memory_thread to notify another process waiting for it, and this one to notify back to the memory_thread, after the delay? Or maybe doing something better without using a third process, but still using these commands: event_name.notify(mem_delay) and wait(event_name)?
  8. Hello! I am working on a SystemC project which has 2 different modules interacting through ports and channels. Both modules are running SC_THREADS. Now, I am having problems using the wait(sc_time) statement. What I want to do is simply to let the time flow (simulated systemC time) while I am inside one thread, without removing the process from the runnable set and without allowing another thread to resume (which happens if I use wait(sc_time)). I want to stay inside the thread, and I want the thread to "take some time" to execute. i need to to this because I am simulating a ram memory, and I
×
×
  • Create New...