Просмотр полной версии : Вектор-06Ц: Altera DE1
Ты видимо слушал через обычный разъем наушников на DE1? Я уже подзабыл, как там сделан звук, но по-моему он идет через какой-то хитрый аудиокодек, который наверняка работает на чем-нибудь типа 48кГц. То есть картина получается очень похожей на то, что имеем в эмуляторах. Чтобы не было эффектов стычки ШИМа с кодеком можно было бы попробовать вывести ШИМ на ножку и послушать ее напрямую (через резистор и конденсатор).
А чтобы правильно вывести через кодек, получается надо делать настоящий ресемплер, как в v06x.
Чтобы поддержать марку DE1 напомню результаты разгона с кэшем (я их где-то выкладывал, но уже и сам забыл).
Максимальная попробованная частота проца - 81 МГц. Больше не пробовал только из-за того, что хотел поддерживать частоту SDRAM как минимум x2 (в данном случае 162 МГц).
Скорость при этом выросла в 13.5 раз, можно сказать, что "эквивалентная частота вектора" была чуть больше 40 МГц. Уверен, что это не предел, если увеличить эффективность кэширования.
Приведенная ранее оценка для DE1
Скорость при этом выросла в 13.5 раз
была заниженной, т.к. получена при демонстрационном прогоне Ambal3Dp8, и там очень сильно влияет ожидание прерывания.
Взял для теста время распаковки теста устройств запакованного шринклером. И решил не брать рекордную частоту проца, т.к. там была нестандартная развертка и надо твикать все что можно и я уже забыл часть того, что нужно твикать. Частота проца 72 МГц, SDRAM 144 МГц.
Без кэша быстрее чем стандартный вектор в 12.87 раз.
С кэшем 256 байт быстрее в 17.07 раза.
С кэшем 512 байт быстрее в 17.54 раза.
С кэшем 2 Кб быстрее в 18.12 раза ("эквивалентная частота" вектора 54 МГц).
Дальнейшее увеличение кэша в данном тесте не привело к заметному ускорению (измерял с точностью 1/50 секунды, возможно небольшой выигрыш <1/50 все же был). Отмечу, что в других программах выигрыш от кэша может быть меньше, т.к. у шринклера перекос в сторону чтения, а кэш у меня write through.
Пора уже сделать 8080 с конвейером, спекулятивным исполнением , meltdown и spectre.
Если серьезно, то при текущей организации работы с памятью на DE1 конвейерный 8080 не очень нужен, тормозит в основном память. Вот на DE2-115 (и других девбордах с жирными плисинами), где вектору достаточно внутренней памяти, конвейер дал бы заметный эффект.
Надо бы сделать какой-то тест/демку, который будет очень сильно тормозить на стандартном векторе. Когда шринклер распаковывает за 3.5 секунды вместо минуты или jpeg 224x224 выводится за примерно 8 секунд вместо 2 с лишним минут, хочется чего-то более тяжелого и продолжительного. И я даже не пробовал и не очень хочу пробовать эти тесты на DE2-115, там будет слишком быстро.
тормозит в основном память
Память ведь сделана SDRAM как SRAM, за каждым байтом лезет с отдельной командой? Кеш тоже сделать, хотя бы на чтение.
Кэш, к сожалению, все же медленнее, чем просто внутриплисовый sram. И дополнительная проверка на совпадение тэга, и некэширование записи (т.к. сейчас write through) и кэш-промахи и еще кое-что. Улучшить можно, например все же сделать write back и оптимизировать арбитраж, но хотелось бы побольше адекватных тестов, чтобы было чем проверять эффект животворящих улучшений.
Добавил в тесты мандельброта и сделал Write Back кэш. Несмотря на неэффективную выгрузку из кэша, write back дал прирост скорости 2-3%.
Отмечу, что в шринклерном тесте из-за постоянных перезаписей 1 Кб wb уступает 1 Кб wt. Но с 2 Кб выходит вперед и увеличение с 2 до 4 для wb еще ускоряет (пусть и микроскопически), в отличие от wt.
Эффективной выборке в кэш (и записи из кэша для write back) на векторе мешает организация видео. Приходится выбирать, что важнее, и на данный момент в приоритете скорость выборки видеоданных.
А нельзя сделать, чтобы видеосистема хотя бы для тестов игнорировала кеш? Или даже просто ее временно отключить, чтобы сравнить.
Совсем малой кровью тут не отделаешься. В идеале линию кэша нужно заполнять (и выгружать в случае wb) пакетом, а сейчас пакетом читается видео. Т.е. нужно 1) сделать пакетное чтение/запись кэша; 2) как-то переделать чтение видео, чтобы не очень тормозило. Для "чистого" теста проще всего уйти с DE1 и взять DE2-115 (или DE1-SoC), все видео переместить во внутренний sram и баловаться с кэшем и SDRAMом. Но мне это академическое направление на данный момент не очень интересно, хотелось бы придумать что-то ускорительное именно для DE1.
Интересно, как на HDMIном выходе MISTer выглядят векторовские демки с мультиколором, у zx next некоторые проблемы с этим делом.
Немного подтюнил SDRAM, все стало чуть быстрее, максимальное ускорение все ближе к x19. Добавил третий бенчмарк - 3d крутилку без vsync, и в ней wt быстрее, чем wb.
ivagor, а исходниками не поделитесь? Хочу на такую плату попробовать: https://github.com/ChinaQMTECH/CYCLONE_IV_EP4CE15
Проект на github (https://github.com/svofski/vector06cc) (svofski). Там, кстати, есть "мультиверсия" (https://github.com/svofski/vector06cc/tree/multipulti), возможно ее будет проще портировать.
Проект на github (svofski).
Это версия с sdram и кэшем?
С этой платой я не знаком, но предположительно проще всего портировать будет с версии для wxeda (project/wxeda). Там похожей версии Циклон 4 и SDRAM.
Что-то меня в свое время остановило от полного мержа версии multipulti, сейчас уже не могу вспомнить. Может быть просто я оказался внезапно занят чем-то еще, а потом забыл.
С этой платой я не знаком, но предположительно проще всего портировать будет с версии для wxeda
На самом деле вариант с гитхаба я уже давно перенес на эту плату, хотелось бы вариант с кэшем глянуть, я только учусь верилогу, многое для меня загадка.
На самом деле вариант с гитхаба я уже давно перенес на эту плату
Респект!
Респект!
Да особо не за что.. вы очень аккуратно пишете, очень понятно, переносить легко.
Эх я бы пообщался на тему верилога, но боюсь отпугну.. я назойлив. :(
Если это более-менее в рамках этой темы, то здесь это вполне удобно. Есть еще тема "ПЛИС и все, что с ними связано (https://zx-pk.ru/threads/9342-plis-i-vsjo-chto-s-nimi-svyazano.html)", в которой тематика вопросов не ограничена Векторостроением и круг заглядывающих туда шире.
Есть еще тема "ПЛИС и все, что с ними связано",
О, спасибо!!! Я как-то не обратил внимание на эту тему. Я сейчас пытаюсь сделать Орион на верилог, у меня есть уже штук 10 работающих вариантов, но все не нравятся..
Эмуляция 2хпортовой памяти на сдрам - тот еще геморрой..
Это версия с sdram и кэшем?
По этой теме выкладывал (https://zx-pk.ru/threads/8635-vektor-06ts-altera-de1.html?p=681968&viewfull=1#post681968) кэширующий контроллер SDRAM. Несомненно, его можно улучшить, чем и пытаюсь заниматься.
у меня есть уже штук 10 работающих вариантов
Ого, я столько не видел. Если не секрет, чем, например мой (https://zx-pk.ru/threads/28980-orion-na-de1.html) не нравится?
- - - Добавлено - - -
Если нужен полный проект с sdram и кэшем, то как вариант можно глянуть ts conf для какой-нибудь sdramной девборды.
Если не секрет, чем, например мой не нравится?
Исходника не нашел, ссылка битая. А вообще, Орион это очень хороший объект для изучения верилога, поэтому и пытаюсь написать сам.
По этой теме выкладывал кэширующий контроллер SDRAM.
Залип... :)
Отмечу один из самых серьезных тормозов SDRAM_Controller144_w_cache2.v - не стоит параллельно начинать читать sdram и кэш, последовательный (сначала проверяем кэш и только если там нет, читаем sdram) вариант лучше.
Отмечу один из самых серьезных тормозов SDRAM_Controller144_w_cache2.v - не стоит параллельно начинать читать sdram и кэш, последовательный (сначала проверяем кэш и только если там нет, читаем sdram) вариант лучше.
А если мы попали в кеш и стартанули чтение SDRAM, то что будет если следующий цикл тоже попадание в кеш? Будет ждать окончания цикла SDRAM?
если мы попали в кеш и стартанули чтение SDRAM, то что будет если следующий цикл тоже попадание в кеш? Будет ждать окончания цикла SDRAM?
Если речь про SDRAM_Controller144_w_cache2.v, то там все очень дубово, снаружи видно только процесс обращения к памяти (без разделения на кэш и sdram) и процессор должен ждать, пока не окончится текущее обращение. В идеале процессы обращения к кэшу и sdramу стоит разделить.
Попробовал разогнать версию "all in internal sram" для DE1-SoC. Получилось 120 МГц, выше программирование палитры портится. 135 МГц на DE2-115 остается локальным рекордом. Уверенность, что палитру можно доработать и для более высоких частот только окрепла, там иногда получается.
После оптимизации арбитража доступа проца/видео к памяти шринклер на DE1 преодолел рубеж ускорения в 19 раз, что (для меня) довольно приятно.
Менее приятными оказались последствия задействования полного объема квазидиска в варианте "все внутре" для DE2-115. Рекорд 135 МГц был получен при использовании 64 КБ озу и 64 КБ кваза, все работало стабильно. Но когда началось переключение страниц квазидиска, DE2-115 перестал успевать. Все работает, кроме нормального доступа ко всем страницам кваза. Попытки оптимизировать этот момент не окончились успехом и если нужно >64 Кб кваза приходится замедлять DE2-115 до 75 МГц. К счастью DE1-SoC нормально работает с квазом >64 на 120 МГц.
Все же нашелся и положительный момент связанный с быстрыми версиями. Если в Emu поднять соответственно в конфиге частоту и отключить торможение (adjust=4), то результаты бенчей полностью совпадают с девбордами, т.е. их можно вполне адекватно эмулировать в таком режиме. Возможно не всякий старый процессор потянет рилтаймовую эмуляцию 120 или 135 МГц, я на слабосильном компе еще не пробовал.
Оценил вклад чтения видео в торможение. На примере распаковки теста устройств шринклером.
Все чтение видео включено - ускорение (по сравнению со стандартным вектором) в 19.0765 раз
Отключаем чтение видео по бокам - ускорение в 19.5361 раз
Отключаем чтение видео по бокам и сверху/снизу - ускорение в 19.7744 раз
Отключить вобще все чтение видео затруднительно, не только потому, что ничего не будет видно, но и потому, что не будет регенерации и sdram рассосется. Но по приведенным данным можно прикинуть, что без чтения видео ускорение составило бы примерно 20.3-20.4 раз.
- - - Добавлено - - -
Т.е. когда все видео-чтение включено, оно тормозит проц примерно на 6%.
Лучше поздно, чем никогда - сообразил, как сократить чтение/запись кэша на такт. Это дало резкий скачек быстродействия:
Распаковка теста устройств шринклером: 23.3309
Мандельброт: 23.1079
Вращение 3D объектов: 20.0755
Комментарий по поводу третьего теста. Основной тормоз там в том, что этот тест очень много пишет в видеопамять, а для видеопамяти у меня wb кэш работает в режиме wt. Но тут вариантов нет, запись в видеопамять нельзя откладывать.
В итоге получилось преодолеть даже в тяжелом случае планку ускорения в 20 раз. "Эквивалентная частота" вектора 60-69 МГц, думаю на этом можно успокоиться.
Возможно кому-нибудь будет интересно не только максимальное ускорение, но и оценка вклада кэша и сравнение WT c WB. Кэш увеличил до максимума 8 Кб (в предыдущем посте было 4 Кб WB), но в данном наборе тестов это влияет только на крутилку3D.
без кэша 8 Кб WT 8 Кб WB
Шринклер 13.7415 22.5208 23.3309
Мандельброт 13.1249 21.9532 23.1079
Крутилка3D 13.6595 20.4937 20.8033
Цифры в таблице - ускорение в разах при Fcpu=72 МГц; Fsdram=144 МГц по сравнению со стандартным вектором.
8 Кб WT ускоряет в 1.50-1.67 раза
8 Кб WB ускоряет в 1.52-1.76 раза
Проект на github (https://github.com/svofski/vector06cc) (svofski). Там, кстати, есть "мультиверсия" (https://github.com/svofski/vector06cc/tree/multipulti), возможно ее будет проще портировать.
Интересно, а возможно-ли, малой кровью, заменить ядро Т80 на vm80a ?
А то терзаю реал с переходником между ним и ПЛИСиной, когда тут весь комплект на одной плате.
Пробовал в v06cc три ядра - T80, vm80a Vslava, и вариант b2mа, все работали. Чуть сложнее было с вариантом b2mа, т.к. там нет READY, поэтому тормозил клоком. vm80a с v06cc похоже пробовал только на DE2-115, особых проблем не помню, вроде все было нормально.
На DE1 делал версию специалиста с выбором одного из прох процов, работало нормально.
...
vm80a с v06cc похоже пробовал только на DE2-115, особых проблем не помню, вроде все было нормально.
...
Что-то в интерфейсе Т80 не вижу F1 и F2.
На F1 похож cpu_se/CSE, видимо Т80 без F2 обходится.
У меня взгляд с другой стороны и для меня наоборот vm80a "особенный" с двумя фазами, тем более он появился последним. И у T80 и у k580wm80a b2ma одна фаза.
У меня взгляд с другой стороны и для меня наоборот vm80a "особенный" с двумя фазами, тем более он появился последним. И у T80 и у k580wm80a b2ma одна фаза.
Что-то с наскоку не получилось подменить Т80 на vm80a :(
Добился появления загрузочной сетки. Не стабильно, но появляется.
Перестал видеть SD-карту, загрузчик переходит на кассету, а не на дискету как с Т80.
Очень чувствителен к положению F2. Малейший сдвиг фронта или спада сигнала F2 и начинает рвать загрузочную сетку или просто перестает работать.
Меня ещё смущает сигнал cpu_se (се3) - я принял его за F1, но по логике его формирования, он почему-то не совпадает по фазе с несущей 6МГц (се6).
На сканах шин которые я снимал с реального Вектора, F1 совпадали по фазе с несущей 6МГц.
Добился появления загрузочной сетки.
Это уже хорошо, есть свет в конце тоннеля.
Очень чувствителен к положению F2.
Тут я не понял, в какое место T80 ты подаешь F2? В v06cc на CLKEN подается cpu_ce, ты туда F2 подал? Про несовпадение фазы СLKEN с фазой чего-либо еще я бы пока сильно не переживал. Можно попробовать поменять фазу и длительность (скважность) сигнала подаваемого на CLKEN и добиться нормальной работы.
- - - Добавлено - - -
Уточню, я про изменение фазы и длительности CLKEN формируемого внутри плис на основании приходящих снаружи сигналов.
...
Тут я не понял, в какое место T80 ты подаешь F2? В v06cc на CLKEN подается cpu_ce, ты туда F2 подал?
...
Не.
В v06cc родным ядром является Т80.
Я пытаюсь заменить ядро на vm80a.
В Т80 нет входного F2, но у vm80a на вход должен подаваться F2.
Я его (F2) сгенерировал (для vm80a) сразу за спадом CLKEN (он-же cpu_ce и ce3).
Если речь о замене проца в v06cc (сначала подумал, что пробуешь T80 в реале), то для vm80a я просто делал cpu_ce2 инверсным относительно cpu_ce, там близкое совпадение с требованиями к реальному F2 не нужно.
Если речь о замене проца в v06cc (сначала подумал, что пробуешь T80 в реале), то для vm80a я просто делал cpu_ce2 инверсным относительно cpu_ce, там близкое совпадение с требованиями к реальному F2 не нужно.
Подал на вход F2 инверсный cpu_ce - ничего принципиально не изменилось, продолжал рвать загрузочную сетку и не работало меню выбора дискеты.
На pin_clk, вместо clk24 (который подавался на Т80) подал clk60 - и взлетело...
На Альтеровской отладочной плате модифицированный vm80a стабильно заработал.
Интересно, а у ПЛИС-эмулятора Вектора есть функционал "скриншот" ?
SD-карта ведь подключена, есть куда писать образы экрана.
Интересно, а у ПЛИС-эмулятора Вектора есть функционал "скриншот" ?
SD-карта ведь подключена, есть куда писать образы экрана.
У моего нету. Идея для фичи хорошая, но лучше когда такие высокоуровневые вещи реализованы платформой. В MiSTer, например, это часть общей функциональности.
У моего нету. ...
Ясно.
Я пробовал запустить на нём свои тесты AY и ВИ53, и про скриншоты задумался.
Кстати о результатах тестов:
AY - читает из 15 порта.
ВИ53 - в отличии от реала, фиксирует значение счётчиков таймера при подаче каждой команды "защёлка" (чтение на лету), в принципе так-же как и все эмуляторы.
Ясно.
Я пробовал запустить на нём свои тесты AY и ВИ53, и про скриншоты задумался.
Кстати о результатах тестов:
AY - читает из 15 порта.
ВИ53 - в отличии от реала, фиксирует значение счётчиков таймера при подаче каждой команды "защёлка" (чтение на лету), в принципе так-же как и все эмуляторы.
Можешь поправить =)
Я сейчас очень далек от этого проекта. У меня есть мысли к нему вернуться, потому что я заглядываюсь на вот такую симпотную платку: Tang Nano 9K (https://wiki.sipeed.com/hardware/en/tang/Tang-Nano-9K/Nano-9K.html). А так вообще наверняка сейчас можно найти реализацию 8253 поточнее моей и просто вставить.
AY - читает из 15 порта.
Не знаю, о какой ревизии идет речь, но чтение из 14 и 15 я делал и определенно эта версия была доступна (в проекте есть папка .svn).
А так вообще наверняка сейчас можно найти реализацию 8253 поточнее моей и просто вставить.
8253 Saara звучит получше (https://zx-pk.ru/threads/8635-vektor-06ts-altera-de1.html?p=861805&viewfull=1#post861805) если хочется ШИМа.
always portmap_device = address_bus_r[7:2];
...
wire ay_sel = portmap_device == 3'b101 && address_bus_r[1] == 0; // only ports $14 and $15
wire ay_rden = io_read & ay_sel;
Вроде должны быть оба, но я никогда не проверял как чтение из AY работает.
- - - Добавлено - - -
8253 Saara звучит получше если хочется ШИМа.
Это ведь тот же проект, или другой?
https://github.com/sorgelig/Vector06_MIST
Это ведь тот же проект
Да
- - - Добавлено - - -
Нашел (1 (https://zx-pk.ru/threads/8635-vektor-06ts-altera-de1.html?p=1133778&viewfull=1#post1133778), 2 (https://zx-pk.ru/threads/8635-vektor-06ts-altera-de1.html?p=1133867&viewfull=1#post1133867))
Да
- - - Добавлено - - -
Нашел (1 (https://zx-pk.ru/threads/8635-vektor-06ts-altera-de1.html?p=1133778&viewfull=1#post1133778), 2 (https://zx-pk.ru/threads/8635-vektor-06ts-altera-de1.html?p=1133867&viewfull=1#post1133867))
Обязательно надо будет его тоже попробовать. При случае, конечно.
- - - Добавлено - - -
Вот текущая версия https://github.com/MiSTer-devel/Vector-06C_MiSTer/tree/master
Смутно припоминаю, что в отдельных загрузчиках (кажется coman и омское пзу-8) есть возможность сохранения видеопамяти (рестарт с нажатием определенных клавиш). Coman не подходит, а пзу-8 (если я про него правильно вспомнил) теоретичски можно прикрутить.
camister
23.04.2024, 16:38
5 лет назад уехал в США. Вектор естественно пришлось отдать в добрые руки, Сейчас пришла пора "отдавать долги". Т.е. мне нужен Вектор-06Ц реализованый на ПЛИС, только вот незаю что брать Altera DE1 или Altera DE10? мне нужен только вектор, ничем другим пользоваться не буду. Если что цена не имеет большого значения. Главное видеть оригинальный экран загрузки и иметь возможность загрузаться с кассеты (Смартфона) и чтобы звуки были :) И еще хочу программы на бейсике писать и сохранять их на ленту.
Не уверен, что это точно, но возможно что DE1 и Вектор отделяют меньше лет, чем прошло с появления DE1 до сегодняшнего дня.
Я прямо сейчас портирую vector06cc на Tang Nano 9K + 5" LCD 800x480. Пока еще рано праздновать, но шансы на успех есть. Сейчас работает процессор + память и квазы на PSRAM + video на LCD (с обрезанием). Следующий шаг это масштабирование, потом периферия. HDMI тоже надеюсь прикрутить, благо на плате он есть.
Проект под MiSTer тоже интересный, но ему нужен MiSTer и железо описано на вики MiSTer-а (https://github.com/MiSTer-devel/Wiki_MiSTer/wiki). DE10-Nano основная плата.
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot