Zdenek Prikryl

  • Content count

  • Joined

  • Last visited

  1. Hi Alan, This is what I thought. Well, let's do some custom coding then :-).... Thanks.
  2. 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.
  3. 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.
  4. 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.
  5. 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.