Addressing in hex file

[Altera_Forum]

Hello, 

 I currently design a system with SOPC based on the Nios II processor. I checked the hex file generated by the Nios II IDE after compilation. At the beginning I have the following :  :020000020000FC  Which means that the address will not be on 16 bits but on 20 bits (four 0 are added at the end) (cf http://en.wikipedia.org/wiki/intel_hex) (http://en.wikipedia.org/wiki/intel_hex%29).    --- Quote Start ---   02, extended segment address record, segment-base address. Used when 16 bits are not enough, identical to 80x86 real mode addressing. The address specified by the 02 record is multiplied by 16 (shifted 4 bits left) and added to the subsequent 00 record addresses. This allows addressing of up to a megabyte of address space. The address field of this record has to be 0000, the byte count is 02 (the segment is 16-bit). The least significant hex digit of the segment address is always 0.   --- Quote End ---  The next lines of the hex file are :  :20000000008400141001483A10BFF80400BFFD1600400034087008140800683A0000000066 :20000800008400141000003310BFF80400BFFD1606C00074DEC0001406800074D690B1144F :200010000080003410B0B41400C0003418F0B41410C00326100000151080010410FFFD36DB :20001800000C0880000C16C0003FFF06DEFFFF04DF000015D839883A0005883ADF000017AA ...  The first address is 0x00000, the second is 0x00080, the third 0x00100, ..., so there are 128 addresses between each address . However, there are only 32 bytes of data on each line.  So I don't understand very well the organisation, and what are the data between addresses 0x00020 and 0x00080 for example. Does someone have a explanation for that ?  Thanks in advance.  Jérôme

[Altera_Forum]

lets have a look at this line 

:20000800008400141000003310BFF80400BFFD1606C00074D EC0001406800074D690B1144F  :20 means 32 Bytes length 0008 means 8 bytes(words) but it is 32bit data format so 4byte per word x8=32 00 record type data record  now you have 64 hex digits what give you the 32 bytes 008400141000003310BFF80400BFFD1606C00074DEC0001406800074D690B114  4F 2's complement of the checksum  as the data width is 32 bit the adr needs to be incremented by 8 with each line  hope it's clear otherwise ask

[Altera_Forum]

I agree with your reasoning if there is not the firt line (:020000020000FC). 

 Because, with this first line, the address 0x0008 is interpreted as 0x00080 ("The address specified by the 02 record is multiplied by 16 (shifted 4 bits left) and added to the subsequent 00 record addresses").  At least, it is like that that I understand it.

[Altera_Forum]

Ah ok, I misunderstood the way the first line work. 

The shifting is not applied on the others address but only on the one given by record 02. In this case, it is 0, so it does not change anything. So suppress the first line in this case would give the same result since the total memory don't exceed 65 Kio. Thanks for your help. Sorry for this useless thread. :-(

[Altera_Forum]

thats what i tries to explain. 

 the adr field is always only 16bit so you must take these 16 bit and shift them to get the correct address. 32bit data means you have to shift twice. the adr is a 32bit asdr and not a 8 bit adr. 0008 will be 0x00020 in 8 bit adr mode.   i guess your mistake is that you shift the complete information and not only the 16 bit adr field.  lets have a look at your line (:020000020000FC). :02 Extended Segment Address Record  0000 adr 02 type 0000 segment FC checksum  this means take the adr 0000 multiply by 16 and add that result to all adr. you get from the data records to calculate the target adr.

[Altera_Forum]

it's not useless unless it helps to clear things that might be missunderstud.

[Altera_Forum]

Ok. There is still something not very clear. I have two questions, I think the answer are linked. 

 So, the address bus is on 32 bits. But in the hex file the maximum we can reach is FFFF (max address with 00 record) + FFFF0 (max address we can add with 02 record) = 10FFEF. So we are far from FFFFFFFF.  Secondly, in SOPC Builder, if I put a memory of 16 Kio, I have for example a span from 0x0000C000 to 0x0000FFFF, which means 16384 addresses. Does that means that at one address, we store 1 bytes and not 4 ? In this case, why not to store data directly in 4 bytes since it is the depth of the bus ?

[Altera_Forum]

if you talk about bytes and byteadr. you still think of an 8 bit cpu 

nios is a 32bit cpu, so when accessing 32bit = 4bytes then the lowest 2 adr bit are 00  nios has an adr alignment of 4 means in bytes it uses byte adr 0 4 8 c 10 14 18 1c 20 ... to store 32bit so your 16kByte memory from 0xc000 up to 0xFFFF hast 16384 byte what is 4096 memory locations of 32bit you can't store 4 byte in 1 byte adr, but you can in 1 32bit wide memory  about your first question, if you have FFFF in the adr field of the 02 record, then multiplyed by 16 you get 0xFFFF0 but you can't add 0xFFFF from the data record to it as this adr. mode will be maximum um 0xFFFFF what gives 20 Bit adr space. resp. 1MByte maximum  So have a look at Type 05 Start Linear Address Record (used by epcs controler) that enables you to gain access to the full 32bit memory in linear mode  Here again it starts with :020000020000fc and is followed by :040000000001703a51 :0400010004c00074c3 again :04 means 4 data bytes 0000 adr 00 type 0001703a data 51 checksum next line :04000100:04 means 4 data bytes 0001 adr (pay attention we are in 32 bit mode !) 00 type 04c00074 data c3 checksum

[Altera_Forum]

Ok, about the hex file, I think I understand well know the different modes (16, 20, 32) now. 

 For the general addressing question, I understand what you say. But my question is why the memory location is not 32 bits instead of 8 bits ?  I made a schematic with both mode to be sure that we be well understood. The table on the left is what is done, i.e. a memory location is 8-bit depth, The table on the right is what I think about, i.e. the memory location is 32-bit depth.

[Altera_Forum]

it seems that you haven't realy understood the difference between 8 and 32 bit 

your pictures are a bit wrong in 8 bit mode you will get correctly 0x00000000 0x35 0x00000001 0x56 0x00000002 0xF6 but in 32 bit mode there is no adr at 0x00000001 as the lowest 2 bits are always 0 in 32 bit you will have  0x00000000 0x3556.... but the next possible adr is 0x00000004 0x.....  in 16 bit mode you will memory adr. 0x00000000 0x???? 0x00000002 0x???? 0x00000004 0x???? 0x00000006 0x????  it didn't look after bigendian stuff here

[Altera_Forum]

Yes, I understood that. 

 But why the system doesnot (and maybe cannot ?) work as I stated in the right table ?

[Altera_Forum]

a byte is a byte and has 8 bit 

if you address bytewide then you get access to 8 bit per access only if you want to access a word (16bit) then your address must be aglined to 16bit boundaries so possible adr is 0x0 0x1 0x2 (from 16bit point of view) what is 0x0 0x2 0x4 in bytewide view same in 32bit. the lsb of the 32bit data is the lsb of 8bit data but the msb of your 32bit is the msb of the 4. data byte think of an array and let the contect be {0,1,2,3,4,5,6,7,8,9,....} accessing this memory bytewide you will see at  adr[0] 0x0 adr[1] 0x1 adr[2] 0x2 adr[3] 0x3 adr[4] 0x4 but now in 16 bit access mode adr[0] 0x0100 adr[2] 0x0302 adr[4] 0x0504 and in 32 bit adr[0] 0x03020100 adr[4] 0x07060504 if you write down the possible addresses in binary maybe this helps you  8 bit 00000 00001 00010 00011 00100 00101 16 bit 00000 00010 00100 00110 01000 32 bit 00000 00100 01000 01100 10000 showing only the lowest 5 adr bits

[Altera_Forum]

Argh. We don't arrive to understand each other. Maybe is because my question has no sense when we know how it is done physically. 

 My idea of a memory (imagine it as a town) is, we have an address bus that permit to access a memory element (imagine it is as a building). The size of the address bus will simply indicate how many memory element we can access (bus of N bits => access to 2^N elements (2^N building in the town)).  You have a first type of memory where the size of an element is 8 bits (your building has 8 floors). So the data bus is 8-bit length.  Why can we not imagine a memory where the size of an element is 32 bits (your building has 32 floors), or 24 or even 15 if we want ?  I hope this metaphor will help to be understood.

[Altera_Forum]

the addressbus is adressing bytes if you look at it with all bits. 

nios is normaly looking at your memory from a 32bit view thus it doesn't know the lower 2 bits  if you access parts of 32 bit = 4 byte within a 4 byte alignment then nios / avalon uses the byteenables to tell the switchfabric what part of the complete 32bit is accessed.  i understand what you want to ask, but the thing is a 8 bit dus width master has N addresbits, an 16bit master has N-1 and a 32bit Master has N-2 bit wide address bus. all of them have the same addressspan in bytes. if your memory is 1MByte (8bit) then it is 0,5MWord (16Bit) or 0,25MLongWords (32bit)  they all have the same complete memory size, but different bit width.

[Altera_Forum]

This way of working is not the one of the Nios only because I think it is the same for processor inside PC for example (and probably other processors). 

But, would it not be more simple if the depth of the memory was the same than the depth of the bus ?

[Altera_Forum]

from nios side of view there is no difference if the target memory is 8 16 or 32 bit wide. 

the translation is handled by the avalon switch fabric. even if you copy from an 8 bit target to a 16 bit target. a 32 bit master is capable of fetching 4x the data as an 8 bit master in 1 clock cycle. thus does not need to address the memory 4 times.  they other way round, if you connect an external 8 bit memory and an 32 bit memory to your fpga, then you must connect the 8bit slaves lowest addressignal to the fpga lowest addressignal lets call this call tristate_bus_a[..] where the lowest signal is tristate_bus_a[0] and is connected to 8bitmemory_a[0]. but the 32bit memory ist connected differently 32bitmemory_a[0] goes to tristate_bus_a[2]

[Altera_Forum]

Ok. Thanks for the explanations.