Zdenek Prikryl

Members
  • Content count

    6
  • Joined

  • Last visited

  1. Hello, I have two objects. One is a memory, and the second one is a generator. They are connected via a TLM socket. At the same time, both objects have a method that is sensitive on the clock. The method prepares data for write transactions and it should also pick-up data from reading transactions (and vice versa). It should also check the status of the transactions. I'd like to use a TLM socket for data passing instead of a pin-accurate model of memory interfaces. See the picture in the attachments. The issue is a synchronization because there is a clock (one source of events) and PEQ for sockets (second source of events). Is there any recommended/standard solution for this? For more detailed description of the issue, let's imagine the following scenario. Clock cycles a) Generator's clock cycle method issues a write request to the memory (data is not passed yet) b) The memory accepts the write request via the forward path, stores it to PEQ. a) Generator's clock cycle method prepared data and updates the payload for the write request (already in memory's PEQ). b) Generator's clock cycle method would like to check the status of the write (so it can mark the write transaction as finished ok or not). The memory should handle the write request in PEQ now and use the backward path to signalize a response to the generator. I don't know how to do this (is the standard PEQ capable of this? Should I write my own PEQ?). c) Generator's clock cycle method issues a read request to the memory. d) The memory accepts the read request via the forward path, stores it to PEQ. a) Generator's clock cycle method would like to check the status of the read request. The memory should handle the read request in PEQ now, update the payload with data, and use the backward path to signalize a response to the generator. I don't know how to do this (is the standard PEQ capable of this? Should I write my own PEQ?). b) If the response is ok, then generator's clock cycle method picks-up data and move on. ... Any help would be appreciated. Thanks and best regards. -- Zdenek
  2. Hi Alan, This is what I thought. Well, let's do some custom coding then :-).... Thanks.
  3. Hello, I'm trying to develop a memory that supports custom bytes/words. In the usual case, the byte is 8bit and word has 4 bytes (assuming 32bit data-path). Now, in embedded, it's possible that the byte is 12bit and word has 2 bytes (24bit data-path). For 12/24 integers, I can use sc_uint<12> or sc_uint<24>. So, my question is: Is there any helper function that stores/loads a custom int into the generic payload? If not, are there any rules to follow? Thanks.
  4. Hi, Recently I used the following Verilog code in my project: module dff8( input wire CLK, input wire RST, input wire [7:0] D0, output reg [7:0] Q0 ); always @( posedge CLK or negedge RST ) begin if ( RST == 1'b0 ) begin Q0 <= 8'b0; end else begin Q0 <= #10 D0; end end endmodule Is there any way how to model #<DELAY> in SystemC. The example of systemc register that I use is below. SC_MODULE(dff8) { // port declarations sc_in<bool> CLK; sc_in<bool> RST; sc_in<sc_uint<8> > D0; sc_out<sc_uint<8> > Q0; // process declaration void do_dff8() { if (RST.read() == 0) { Q0.write(0); } else { // HOW TO ADD DELAY HERE? Q0.write(D0.read()); } } SC_HAS_PROCESS(dff8); dff8(sc_module_name inst) : sc_module(inst) { SC_METHOD(do_dff8); sensitive << CLK.pos(); sensitive << RST.neg(); } }; Thanks for any help.
  5. Hi Alan, Thanks, one more question. LRM page 492 says: In summary, the approach to be taken with the hostendian conversion functions is to write the initiator code as if the endianness of the host computer matched the endianness of the component being modeled, while keeping the bytes within each data word in actual host-endian order. For data words wider than the host machine word length, use an array in host-endian order. Then if host endianness differs from modeled endianness, simply call the hostendian conversion functions. My understanding is that an initiator creates a payload (like described above) and then calls to_host_endianness() helper function to be able to send the payload in the hostendian form. When the payload arrives to a target then the target calls from_host_endianness() helper function and it obtains the payload in the correct form. In fact, using this approach, all communication outside of the initiators/targets is handled in the hostendian form, only internal parts of initiators and targets switches bytes in the payload when necessary.
  6. Hi Alan, Following Rahul's post, I have one more question. You mentioned that the interpretation lies in the initiators and targets. So, let's have two initiations (one big, one little) and a bus word has 4 bytes. The target (memory for instance) doesn't allow an unaligned access (address requests have to be: 0, 4, 8, ...). What should the initiations put into payloads when there is a half-word access at an unaligned address? For instance, an initiator wants to write 0xaabb to address 2 (address request goes to 0), Should the data and byte_enable fields of a payload be as follow? Little endian initiator data[0] == 0x00 (address offset +0) data[1] == 0x00 (address offset +1) data[2] == 0xbb (address offset +2) data[3] == 0xaa (address offset +3) byte_enable[0] = 0x00 byte_enable[1] = 0x00 byte_enable[2] = 0xff byte_enable[3] = 0xff Big Endian initiator data[0] == 0xbb (address offset +3) data[1] == 0xaa (address offset +2) data[2] == 0xaa (address offset +1) data[3] == 0xbb (address offset +0) byte_enable[0] = 0xff byte_enable[1] = 0xff byte_enable[2] = 0x00 byte_enable[3] = 0x00 Is this a correct interpretation of endianness in the little/big initiator (assuming little endian host)? Thanks.