ЛР 8 для ИВТ. Vivado не распознает адрес в *.mem файле

[BROsandr]

При инициализации памяти .mem файлом, полученном из main.c, vivado 2019.2 не распознает второй указатель адреса( первый распознает и загружает по указанным в нем адресу, если его менять ). vivado просто не загружает все, что располагается после второго адреса.

mem image

vivado image

mem файл

@00000000
...
00EE8EB3 000EAF83 00000793 00078513
00C12083 00812403 01010113 00008067
FE010113 00812E23 02010413 FEA42623
00000793 00078513 01C12403 02010113
00008067
@000002B4
00000003 00000005 00000010 00000001
00000004 00000008 00000006 00000009
FFFFFFFD 00000000

Можно пофиксить удалением строки адреса, тем самым склеив с предыдущей секцией, если в дизассемблированном коде эти секции идут последовательно.

Дизассембл

...
 264:	02400713          	li	a4,36
 268:	00078e93          	mv	t4,a5
 26c:	000eaf03          	lw	t5,0(t4)
 270:	00ee8eb3          	add	t4,t4,a4
 274:	000eaf83          	lw	t6,0(t4)
 278:	00000793          	li	a5,0
 27c:	00078513          	mv	a0,a5
 280:	00c12083          	lw	ra,12(sp)
 284:	00812403          	lw	s0,8(sp)
 288:	01010113          	addi	sp,sp,16
 28c:	00008067          	ret

00000290 <int_handler>:
 290:	fe010113          	addi	sp,sp,-32
 294:	00812e23          	sw	s0,28(sp)
 298:	02010413          	addi	s0,sp,32
 29c:	fea42623          	sw	a0,-20(s0)
 2a0:	00000793          	li	a5,0
 2a4:	00078513          	mv	a0,a5
 2a8:	01c12403          	lw	s0,28(sp)
 2ac:	02010113          	addi	sp,sp,32
 2b0:	00008067          	ret

Disassembly of section .data:

000002b4 <array_to_sort>:
 2b4:	00000003          	lb	zero,0(zero) # 0 <_start>
 2b8:	0005                	c.nop	1
 2ba:	0000                	unimp
 2bc:	0010                	0x10
 2be:	0000                	unimp
 2c0:	0001                	nop
 2c2:	0000                	unimp
 2c4:	0004                	0x4
...

mem после фикса

...
03010413 FCA42E23 FCB42C23 FE042623 
09C0006F FE042423 0700006F FE842783 
00279793 FDC42703 00F707B3 0007A703 
FE842783 00178793 00279793 FDC42683 
00F687B3 0007A783 02E7DA63 FE842783 
00279793 FDC42703 00F706B3 FE842783 
00178793 00279793 FDC42703 00F707B3 
00078593 00068513 F31FF0EF FE842783 
00178793 FEF42423 FEC42783 FD842703 
40F707B3 FFF78713 FE842783 F8E7E0E3 
FEC42783 00178793 FEF42623 FD842783 
FFF78713 FEC42783 F4E7EEE3 00000013 
00000013 02C12083 02812403 03010113 
00008067 FF010113 00112623 00812423 
01010413 00A00593 2B400513 F09FF0EF 
2B400793 02400713 00078E93 000EAF03 
00EE8EB3 000EAF83 00000793 00078513 
00C12083 00812403 01010113 00008067 
FE010113 00812E23 02010413 FEA42623 
00000793 00078513 01C12403 02010113 
00008067 
00000003 00000005 00000010 00000001 
00000004 00000008 00000006 00000009 
FFFFFFFD 00000000 

vivado после фикса

[HepoH3]

В tcl-консоли есть какие-нибудь варнинги об этом?

[gr33nka]

0x00002B4 это же 692-ой адрес. Посмотри в первом (не исправленном) варианте, что лежит по адресу 692, возможно твои данные таки там

[gr33nka]

Но если он записывает в 692-ую ячейку, то адресовывать код будет 692ой байт, а не 692ую ячейку.

Если ошибусь, то Андрей Павлович поправит, на сколько помню загрузка в память использует пословную адресацию, а процессором используется (в инструкциях) побайтовая. Отсюда и неразбериха с этими адресами.

[gr33nka]

Увидел коммент с задержкой, тогда @HepoH3 разбирайся) а я пошел работать, извиняюсь за флуд

[BROsandr]

У меня, как я понимаю, из-за этого регистровый файл повреждается(иксами) и прога не работает

[HepoH3]

Блин, это тоже косяк, который надо унифицировать и исправить, чтобы конфигурирование памяти происходило понятно и везде одинаково. Через эти файлы памяти тянутся то слова, то байты. Превращу этот коммент в issue

Подожди пока, я это проверяю по месту. Это косяк в компиляторе кажется, поскольку он должен был по ключу --verilog-data-width=4 автоматом менять адрес в hex-файле

Короче я попробую связаться с разработчиками binutils, но даже если баг подтвердится, пройдут месяцы, прежде чем фикс доползет до кросскомпиляторов riscv, пока надо в методичку варнинг написать.

[HepoH3]

Блин, это тоже косяк, который надо унифицировать и исправить, чтобы конфигурирование памяти происходило понятно и везде одинаково. Через эти файлы памяти тянутся то слова, то байты. Превращу этот коммент в issue

Подожди пока, я это проверяю по месту. Это косяк в компиляторе кажется, поскольку он должен был по ключу --verilog-data-width=4 автоматом менять адрес в hex-файле

Короче я попробую связаться с разработчиками binutils, но даже если баг подтвердится, пройдут месяцы, прежде чем фикс доползет до кросскомпиляторов riscv, пока надо в методичку варнинг написать.

Баг уже зарегистрирован: https://sourceware.org/bugzilla/show_bug.cgi?id=27214