Forum Discussion
Altera_Forum
Honored Contributor
16 years agoAddressing in hex file
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ôme16 Replies
- Altera_Forum
Honored Contributor
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
Honored Contributor
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
Honored Contributor
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
Honored Contributor
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
Honored Contributor
it's not useless unless it helps to clear things that might be missunderstud.
- Altera_Forum
Honored Contributor
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
Honored Contributor
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
Honored Contributor
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
Honored Contributor
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
Honored Contributor
Yes, I understood that.
But why the system doesnot (and maybe cannot ?) work as I stated in the right table ?