Торжественно заявляю: Ура! Вчера я получил первые существенные результаты: мой процессор на ПЛИС успешно выполнил программу самотестирования. Процессор полностью бинарно совместим с виртуальным процессором, который я симулировал в Logisim, вплоть до того, что использовал абсолютно тот же микрокод.
Основые параметры системы:
Ширина машинного слова: 16 бит.
Ширина адреса: 16 бит, максимально адресуемая память — 128К (65536 двухбайтовых слов). Отдельные байты не адресуются.
Ввод-вывод с отображением на адресное пространство.
ОЗУ на чипе ПЛИС — 16К (8192 двухбайтовых слова).
Ввод: PS/2 клавиатура.
Вывод: текстовый VGA-терминал, матрица 80х30 символов. Знакогенератор использует прошивку от CGA-адаптера с шрифтом 8х8 точек (эх, ностальгия!).
Потребленные ресурсы ПЛИС: 2147 логических модуля (примерно 15% от ресурсов чипа).
К чему я это всё?
Ну, во-первых, просто похвастаться и поделиться радостью!
Во-вторых, найти таких же гиканутых товарищей, кому было бы интересно на эти темы пообщаться
Готов поделиться техническими подробностями или зачерпнуть мудрости у более опытных товарищей.
P.S. Немного подробнее написал у себя в бложике: тут. Там и картинки есть
Здравствуйте, 0x7be, Вы писали:
0>Торжественно заявляю: Ура! Вчера я получил первые существенные результаты: мой процессор на ПЛИС успешно выполнил программу самотестирования. Процессор полностью бинарно совместим с виртуальным процессором, который я симулировал в Logisim, вплоть до того, что использовал абсолютно тот же микрокод.
Поздравляю)
0>К чему я это всё? 0>Ну, во-первых, просто похвастаться и поделиться радостью! 0>Во-вторых, найти таких же гиканутых товарищей, кому было бы интересно на эти темы пообщаться 0>Готов поделиться техническими подробностями или зачерпнуть мудрости у более опытных товарищей.
Нуу подозреваю, что тут скорее вопросы будут, чем советы. Всё же тема довольно специфическая) Хотя кто его знает... )))
От меня пока основные вопросы такие:
— какие языки применялись для проектирования? ) VHDL, Verilog или может вообще C++ (SystemC)? И почему именно они?
— какие инструменты применялись для разработки (редакторы, симуляторы и т.п.)? И почему именно они? )
— это всё только для самообучения и фана или есть идеи это использовать в дальнейшем для чего практического? )
Здравствуйте, alex_public, Вы писали:
_>Поздравляю)
Спасибо
_>От меня пока основные вопросы такие: _>- какие языки применялись для проектирования? ) VHDL, Verilog или может вообще C++ (SystemC)? И почему именно они?
VHDL. Где-то нашёл статейку, где автор шибко хвалил его и ругал Verilog.
По опыту написания столкнулся с его тяжеловесным синтаксисом. Есть мысль пощупать Verilog, тем более, что инструментарий позволяет смешивать в одном проекте модули на разных языках.
_>- какие инструменты применялись для разработки (редакторы, симуляторы и т.п.)? И почему именно они? )
Altera Quartus II v13.1. Использовался просто потому, что чип от этого же вендора, соответственно, инструментарий адаптирован. Я даже сомневаюсь, что чужой инструментарий подошёл бы к нему.
Само устройство взял по совокупности трех параметров: функциональных возможностей, цены и доступности в РФ.
Симулятор, если честно, так и не освоил, какой-то он замороченный. Для отладки применял кнопки/переключатели/светодиоды на самой плате, а так же зонды (встраиваемые в схему компоненты + спец. программа, которая умеет вычитывать значения с их входов). Пробовал так же использовать SignalTap (позволяет записывать сигналы в разных точках схемы), но он почему-то безбожно врал. В итоге, комбинируя простейшие средства отладки и модульный подход "снизу вверх", постепенно собрал и отладил схему.
_>- это всё только для самообучения и фана или есть идеи это использовать в дальнейшем для чего практического? )
Пока это чистый фан, продиктованный профессиональными комплексами (двадцать лет был программистом, а как оно работает на уровне схем не знал). Каких-то конкретных перспектив практического применения пока не вижу, но может что-то нарисуется в будущем. Зато теперь могу сыну толково объяснить, как компьютер работает
Присоединяюсь к поздравлениям!
0>VHDL. Где-то нашёл статейку, где автор шибко хвалил его и ругал Verilog. 0>По опыту написания столкнулся с его тяжеловесным синтаксисом. Есть мысль пощупать Verilog, тем более, что инструментарий позволяет смешивать в одном проекте модули на разных языках.
Я в универе изучал оба языка, и субъективно мне Verilog больше нравится, но в данном случае самый лучший язык — это тот, который знаешь
0>Пока это чистый фан, продиктованный профессиональными комплексами (двадцать лет был программистом, а как оно работает на уровне схем не знал). Каких-то конкретных перспектив практического применения пока не вижу, но может что-то нарисуется в будущем. Зато теперь могу сыну толково объяснить, как компьютер работает
Побольше бы программистов имело такие же "комплексы"!
У меня вот есть идея сварганить LCD Display Driver — то есть чип, который будет "рисовать" картинку в своей памяти по командам от внешнего MCU, и рулить собственно матрицей (в смысле выдавать сигналы развёртки, и "зажигать" нужные точки). Но пока руки до этого не доходят — даже ещё с чипом не определился. Но по смыслу это будет в целом аналог твоего проца — просто он будет более специализированным.
Здравствуйте, koandrew, Вы писали:
0>>По опыту написания столкнулся с его тяжеловесным синтаксисом. Есть мысль пощупать Verilog, тем более, что инструментарий позволяет смешивать в одном проекте модули на разных языках. K>Я в универе изучал оба языка, и субъективно мне Verilog больше нравится, но в данном случае самый лучший язык — это тот, который знаешь
А чем он лучше с твоей субъективной точки зрения?
Есть ли в VHDL какие-то возможности, которых нет в Verilog?
K>У меня вот есть идея сварганить LCD Display Driver — то есть чип, который будет "рисовать" картинку в своей памяти по командам от внешнего MCU, и рулить собственно матрицей (в смысле выдавать сигналы развёртки, и "зажигать" нужные точки). Но пока руки до этого не доходят — даже ещё с чипом не определился. Но по смыслу это будет в целом аналог твоего проца — просто он будет более специализированным.
Т.е. он будет исполнять что-то вроде Windows Metafile, рисуя в видеобуфере растровую графику?
UPDATE: Кстати, видел, что народ при создании спец. устройств на ПЛИСах при наличии ресурсов проступает просто — засовывает в ПЛИС софтовый процессор (например, знаменитый Z80) и окружает его предметно-специфичной системой.
Здравствуйте, alpha21264, Вы писали:
0>>P.S. Немного подробнее написал у себя в бложике: тут. Там и картинки есть A>А ты не хочешь его заопенсоурсить? Может в тебе дремлет второй (третий?) Линус Торвальдс?
Я подумываю о том, чтобы выложить его куда-нибудь, когда он достигнет некоторой зрелости. Я много примеров на opencores.org смотрел, туда можно поместить.
Хотя, они никак не хотят меня регистрирвоать Практической и научной ценности в моём проекте нет, но как некий простой пример системы, которая может быть интересна таким же начинающим людям, это сгодится.
Как-то так.
Здравствуйте, 0x7be, Вы писали:
0>А чем он лучше с твоей субъективной точки зрения? 0>Есть ли в VHDL какие-то возможности, которых нет в Verilog?
Я вот видел такую картинку:
Причём насколько я понимаю, все твои цели укладываются в пункт RTL-описание (раз ты не пользуешься всякими симуляторами и т.п.), так что тебе подходит любой из 4-ёх инструментов — можно выбирать по вкусу. )
0>UPDATE: Кстати, видел, что народ при создании спец. устройств на ПЛИСах при наличии ресурсов проступает просто — засовывает в ПЛИС софтовый процессор (например, знаменитый Z80) и окружает его предметно-специфичной системой.
Здравствуйте, alex_public, Вы писали:
_>Я вот видел такую картинку: ... _>Причём насколько я понимаю, все твои цели укладываются в пункт RTL-описание (раз ты не пользуешься всякими симуляторами и т.п.), так что тебе подходит любой из 4-ёх инструментов — можно выбирать по вкусу. )
Интересная картинка. Надо будет для пробы небольшой кусочек на verilog попытаться исполнить.
_>Ага. Кстати, ты такое http://vlsicad.eecs.umich.edu/BK/Slots/cache/www.gaisler.com/products/leon2/leon.html наверняка видел при разработке своего? ) Это вроде как один из самых продвинутый доступных нахаляву. )))
Не, как-то мимо него прошёл. Я больше искал софтовые реализации старых процессоров. В частности, нашёл Intel 8080 и изучил код.
Здравствуйте, 0x7be, Вы писали:
0>А чем он лучше с твоей субъективной точки зрения?
Меньше букав 0>Есть ли в VHDL какие-то возможности, которых нет в Verilog?
Насколько я помню, нет.
0>Т.е. он будет исполнять что-то вроде Windows Metafile, рисуя в видеобуфере растровую графику?
Типа того, только система команд будет ориентированна на композицию — то есть операции со спрайтами, альфа-блендинг, и т.п. Плюс ещё будет блок формирования управляющих сигналов для матрицы LCD.
0>UPDATE: Кстати, видел, что народ при создании спец. устройств на ПЛИСах при наличии ресурсов проступает просто — засовывает в ПЛИС софтовый процессор (например, знаменитый Z80) и окружает его предметно-специфичной системой.
В моём случае при использовании МК от него потребуется очень неслабая производительность, т.к. только для выдачи сигналов на матрицу нужно до сотни мегагерц частоты (частота развёртки зависит от разрешения панели)- и это не считая собственно графического сопроцессора. Это как раз тот случай, где использование FPGA позволит добиться лучшего результатаф.
Здравствуйте, koandrew, Вы писали:
0>>UPDATE: Кстати, видел, что народ при создании спец. устройств на ПЛИСах при наличии ресурсов проступает просто — засовывает в ПЛИС софтовый процессор (например, знаменитый Z80) и окружает его предметно-специфичной системой. K>В моём случае при использовании МК от него потребуется очень неслабая производительность, т.к. только для выдачи сигналов на матрицу нужно до сотни мегагерц частоты (частота развёртки зависит от разрешения панели)- и это не считая собственно графического сопроцессора. Это как раз тот случай, где использование FPGA позволит добиться лучшего результатаф.
А у тебя что, не будет видеопамяти? Будешь на каждом цикле обновления экрана пересчитывать картинку из вектора в растры?
Здравствуйте, 0x7be, Вы писали:
0>А у тебя что, не будет видеопамяти? Будешь на каждом цикле обновления экрана пересчитывать картинку из вектора в растры?
Пока ещё не знаю — проект ещё в стадии идеи Впрочем я знаю пример такого решения — чипы серий FT80x/FT81x от FTDI. В общем посмотрим — в крайнем случае можно реализовать память в самом FPGA, ну или распаять готовый модуль SRAM — они копейки стоят.
Здравствуйте, 0x7be, Вы писали:
0>P.S. Немного подробнее написал у себя в бложике: тут. Там и картинки есть
Почитал статью. По поводу SD-карты настоятельно рекомендую использовать протокол SPI (он проще, чем SDIO, и его по спецификации обязаны поддерживать все SD/MMC карты). Соответственно, тебе придётся реализовать SPI Master контроллер в железе — но я не думаю, что это очень сложно, и наверняка есть готовые. Сам протокол проще реализовать в софте. Описание его гуглится по словам sd card spi
Здравствуйте, koandrew, Вы писали:
K>Почитал статью. По поводу SD-карты настоятельно рекомендую использовать протокол SPI (он проще, чем SDIO, и его по спецификации обязаны поддерживать все SD/MMC карты). Соответственно, тебе придётся реализовать SPI Master контроллер в железе — но я не думаю, что это очень сложно, и наверняка есть готовые. Сам протокол проще реализовать в софте. Описание его гуглится по словам sd card spi
В ту часть мануала ещё не залезал ещё в более простых вещах есть что сделать. Как минимум нормальный скроллинг к терминалу прикрутить. Но когда дойдут руки, совет обязательно вспомню
Здравствуйте, 0x7be, Вы писали:
0>В ту часть мануала ещё не залезал ещё в более простых вещах есть что сделать.
Если контроллер найдёшь готовый, то остальное там — дело техники. Работа с SD/MicroSD очень популярна среди любителей, потому в инете полно кода под любые платформы, а уж с портированием я думаю у тебя проблем не будет
0>Как минимум нормальный скроллинг к терминалу прикрутить.
В смысле чтобы текст вверх уходил, когда кончаются строки? Если у тебя есть видеобуфер, то rep mov — наше всё Ставишь указатель источника на начало второй строки, указатель получателя — на начало первой, и копируешь ширина * (высота — 1) * байт_в_символе байт, каждый раз инкрементируя оба указателя. На x86 это три строчки на ассемблере Если твой проц не умеет делать операции типа "память-память", то тогда через аккумулятор.
Здравствуйте, 0x7be, Вы писали:
0> Но когда дойдут руки, совет обязательно вспомню
А, и ещё один heads up — карточка при чтении/записи может кушать до 300 мА тока, так что если ты питаешь плату от USB, то учти, что USB может дать максимум 500 мА (а так как карте нужно 3.3 В, то преобразователь напряжения выдаст и того меньше). Игнорирование этого факта ведёт к неадекватному поведению чипа — мне это стоило почти трёх дней чесания репы, ударов лбом от стену и стол, и многоэтажного мата в попытках понять, почему МК вдруг начал жить своей жизнью , пока я не вспомнил про эту "тонкость" (видел это в одном из видео по Ардуино), и соорудил более мощный внешний источник питания. После этого всё сразу взлетело, а я от радости заорал матом так, что ко мне соседи прибежали выяснить, не убивают ли тут кого
0>>В ту часть мануала ещё не залезал ещё в более простых вещах есть что сделать. K>Если контроллер найдёшь готовый, то остальное там — дело техники. Работа с SD/MicroSD очень популярна среди любителей, потому в инете полно кода под любые платформы, а уж с портированием я думаю у тебя проблем не будет
В смысле, код контроллера или железо? Сам-то считыватель уже интегрирован в плату, так что мне надо только код написать, чтобы его подцепить.
K>В смысле чтобы текст вверх уходил, когда кончаются строки? Если у тебя есть видеобуфер, то rep mov — наше всё Ставишь указатель источника на начало второй строки, указатель получателя — на начало первой, и копируешь ширина * (высота — 1) * байт_в_символе байт, каждый раз инкрементируя оба указателя. На x86 это три строчки на ассемблере Если твой проц не умеет делать операции типа "память-память", то тогда через аккумулятор.
У меня пока терминал — это настоящий терминал, то есть у процессора нет произволльного доступа к видеобуферу. Через системную шину можно побайтно посылать символы в ASCII-коде, а реализация контроллера сама их выводит и всё делает. Вообщем, скроллинг пока делаю аппаратно. Вообщем, ничего особенного, если бы не глюки. Для видеобуфера я использую двухпортовый вариант altsyncram (обёртка для интегрированных блоков ОЗУ на чипе). Соответственно, в режиме скроллинга пробегаюсь по буферу и переношу каждый символ на 80 позиций назад, а потом зачищаю последнюю строку.
В теории всё просто. Но вчера реализовал эту схему, она глючит. Во-первых, работает, почему-то не со значением сдвига "80", а "82". Если 80, то текст едет по диагонали. Во-вторых, при скроллинге текст в некоторых строках размазывается по горизонтали Успел вчера нагуглить на каком-то форуме утверждение, что эта реализация ОЗУ даёт задержку в такт при чтении, видимо я это не учитываю. Сегодня попробую замедлить процесс в два раза, если руки дойдут
Здравствуйте, koandrew, Вы писали:
0>> Но когда дойдут руки, совет обязательно вспомню K>А, и ещё один heads up — карточка при чтении/записи может кушать до 300 мА тока, так что если ты питаешь плату от USB, то учти, что USB может дать максимум 500 мА (а так как карте нужно 3.3 В, то преобразователь напряжения выдаст и того меньше). Игнорирование этого факта ведёт к неадекватному поведению чипа — мне это стоило почти трёх дней чесания репы, ударов лбом от стену и стол, и многоэтажного мата в попытках понять, почему МК вдруг начал жить своей жизнью , пока я не вспомнил про эту "тонкость" (видел это в одном из видео по Ардуино), и соорудил более мощный внешний источник питания. После этого всё сразу взлетело, а я от радости заорал матом так, что ко мне соседи прибежали выяснить, не убивают ли тут кого
То есть надо для надёжности БП подключать К моей платке поставляется БП, но мне пока хватало питания от УСБ.
Спасибо, буду иметь в виду.
Здравствуйте, 0x7be, Вы писали:
0>Торжественно заявляю: Ура! Вчера я получил первые существенные результаты: мой процессор на ПЛИС успешно выполнил программу самотестирования.
А какая в нем система команд? Команды и данные в одной памяти или в разных?
0>Ширина адреса: 16 бит, максимально адресуемая память — 128К (65536 двухбайтовых слов). Отдельные байты не адресуются.
Смелое решение. Я тоже как-то думал, что сейчас байты не нужны, в USB используется UTF-16 поэтому работать нужно в ней. А во многих сигнальных процессорах байтов нет уже давно.
Я отвечаю за свои слова, а не за то как вы их интерпретируете!
Q>А какая в нем система команд?
RISC-подобная система команд, в общей сложности 60 команд.
Юзеру доступно восемь регистров общего назначения (R0-R7), плюс несколько специальных: SP (stack pointer), OP (object pointer), BP (base pointer).
Вся арифметика/логика только над регистрами. Загрузка/выгрузка регистров осуществляется в следующих режимах: UPDATE: Арифметика/логика так же есть в режме "регистр и константа".
0. Инициализация регистра константой.
1. По константному адресу.
2. Косвенная адресация через регистр (любой из доступных).
4. Косвенная адресация со смещением от указателя OP или BP (смещение — либо константа, либо из регистра).
(Без)условные переходы либо константному адресу, либо через регистр.
Поддерживается работа со стеком: CALL/RET, PUSH/POP. В стек кладётся не только адрес возврата, но и адрес указателя на начало стекового фрейма. Благодаря этому можно не заботиться о выталкивании из стека лишнего при вызове RET — стек автоматически восстановится в нужное состояние.
Прерывания, обработка ошибок и т.п. пока не реализованы, работа на будущее.
Как-то так, вроде основные моменты осветил.
UPDATE: Код "Hello world":
Label Command Arg1 Arg2
TTY const 0FC00h
nop
init R0 msg
loop ldi R1 R0
cmpc R1 0
je exit
str R1 TTY
inc R0
jmp loop
exit jmp exit
msg string Hello, World!
dw 10
stringz Have a nice day.
END PROGRAM
Q>Команды и данные в одной памяти или в разных?
В одной.
0>>Ширина адреса: 16 бит, максимально адресуемая память — 128К (65536 двухбайтовых слов). Отдельные байты не адресуются. Q>Смелое решение. Я тоже как-то думал, что сейчас байты не нужны, в USB используется UTF-16 поэтому работать нужно в ней. А во многих сигнальных процессорах байтов нет уже давно.
Это решение исключительно для упрощения схемы процессора. Поскольку я ориентируюсь на систему уровня Intel 80080/Zilog Z80, в ней байтовая адресация всё ещё актуальна.
У меня в планах стоит разработать третью версию процессора, в которой я реализую ещё ряд фич, в т.ч. и байтовую адресацию.
Здравствуйте, 0x7be, Вы писали:
0>В смысле, код контроллера или железо? Сам-то считыватель уже интегрирован в плату, так что мне надо только код написать, чтобы его подцепить.
Я имею в виду протокол, т.е. код драйвера.
0>У меня пока терминал — это настоящий терминал, то есть у процессора нет произволльного доступа к видеобуферу. Через системную шину можно побайтно посылать символы в ASCII-коде, а реализация контроллера сама их выводит и всё делает.
То есть типа порта чтоли (x86 аналог команд in/out)?
0>В теории всё просто. Но вчера реализовал эту схему, она глючит. Во-первых, работает, почему-то не со значением сдвига "80", а "82". Если 80, то текст едет по диагонали. Во-вторых, при скроллинге текст в некоторых строках размазывается по горизонтали Успел вчера нагуглить на каком-то форуме утверждение, что эта реализация ОЗУ даёт задержку в такт при чтении, видимо я это не учитываю. Сегодня попробую замедлить процесс в два раза, если руки дойдут
Может выравнивание какое? Видеобуферы часто имеют такую "особенность", когда в конце каждой строки есть несколько байт для выравнивания, которые не отображаются на экране.
Здравствуйте, koandrew, Вы писали:
K>То есть типа порта чтоли (x86 аналог команд in/out)?
Memory-mapped IO. Ячейка с адресом FC00 зарезевирована под терминал. Запись в неё посылает символ в терминал, считывание читает символ с клавиатуры.
Это временное решение, в будущем более тесно интегрирую видеоконтроллер с шиной, а логику терминала перенесу в BIOS, которого пока нет.
0>>В теории всё просто. Но вчера реализовал эту схему, она глючит. Во-первых, работает, почему-то не со значением сдвига "80", а "82". Если 80, то текст едет по диагонали. Во-вторых, при скроллинге текст в некоторых строках размазывается по горизонтали Успел вчера нагуглить на каком-то форуме утверждение, что эта реализация ОЗУ даёт задержку в такт при чтении, видимо я это не учитываю. Сегодня попробую замедлить процесс в два раза, если руки дойдут K>Может выравнивание какое? Видеобуферы часто имеют такую "особенность", когда в конце каждой строки есть несколько байт для выравнивания, которые не отображаются на экране.
Не, буфер я сделал без выравнивания. Полагаю, что проблемы исключительно с таймингом при работе с памятью.
Здравствуйте, koandrew, Вы писали:
K>А можно тебя попросить выложить вот эту схему в бОльшем разрешении, чтобы её можно было прочитать?
Может быть проще сделать: я вышлю тебе файл от Logism с этой схемой? Сам симулятор есть в свободном доступе, весит всего-ничего.
Скинь е-мейл, куда послать.
Здравствуйте, 0x7be, Вы писали:
0>Может быть проще сделать: я вышлю тебе файл от Logism с этой схемой? Сам симулятор есть в свободном доступе, весит всего-ничего. 0>Скинь е-мейл, куда послать.
Здравствуйте, qwertyuiop, Вы писали:
0>>Just4lulz. Q>Но все равно в нем должна быть какая-то суперность-пуперность. В чем она?
В том что его с нуля придумал я
Разве это не круто?
Здравствуйте, 0x7be, Вы писали:
Q>>Но все равно в нем должна быть какая-то суперность-пуперность. В чем она? 0>В том что его с нуля придумал я 0>Разве это не круто?
Не очень. Для крутости могу подкинуть идею. Я давно думал, что среди различных типов операндов не мешало бы ввести "сокращенные константы". Обычные константы занимают целое слово и требуют для чтения отдельного цикла, а сокращенные можно вставить в код команды. Наиболее часто используемые константы — это "единица, остальные нули", "N единиц, 16-N нулей", а также их инверсии. Их можно закодировать 6-ю разрядами: 4 разряда — номер бита (например единицы, при остальных нулях), 1 разряд — тип константы (один из двух описанных), третий — инверсия полученного числа.
Наличие таких операндов позволило бы сократить систему команд, удалив такие как инкремент/декремент, проверка бита в слове, установка/очистка бита и т.п.
Я отвечаю за свои слова, а не за то как вы их интерпретируете!
Здравствуйте, qwertyuiop, Вы писали:
Q>Не очень. Для крутости могу подкинуть идею. Я давно думал, что среди различных типов операндов не мешало бы ввести "сокращенные константы". Обычные константы занимают целое слово и требуют для чтения отдельного цикла, а сокращенные можно вставить в код команды. Наиболее часто используемые константы — это "единица, остальные нули", "N единиц, 16-N нулей", а также их инверсии. Их можно закодировать 6-ю разрядами: 4 разряда — номер бита (например единицы, при остальных нулях), 1 разряд — тип константы (один из двух описанных), третий — инверсия полученного числа. Q>Наличие таких операндов позволило бы сократить систему команд, удалив такие как инкремент/декремент, проверка бита в слове, установка/очистка бита и т.п.
А оно точно даст выгоду хоть в чем-то? Мне пока это не очевидно. Сокращение системы команд самоцелью не является. Из того, что я понял о философии RISC, её плюс в том, что схема управляющего устройства для такого набора команд существенно проще и быстрее за счет того, что набор команд становится меньше и проще. Ты же предлагаешь идею, которая с одной стороны пытается сократить набор команд, но достичь этого за счёт усложнения логики декодирования команды, т.е. комбинируем худшее из RISC и CISC. Где я ошибаюсь?
UPS>КРУТЬ! UPS>А змейку под этот проц можно сделать?
Для змейки надо доделать в терминале функцию переноса курсора в произвольное положение (или произвольный доступ к видеобуферу).
В остальном всё можно.
Кстати, спасибо за хорошую идею, надо будет написать такую программу чисто для проверки
Здравствуйте, 0x7be, Вы писали:
0>Отправил.
Спасибо! А можно ещё ликбезглоссарий по акронимам? А то я что-то плаваю во всех этих BGU, BGR, EOM, TJC и т.д.
Здравствуйте, koandrew, Вы писали:
K>Здравствуйте, 0x7be, Вы писали:
0>>Отправил. K>Спасибо! А можно ещё ликбезглоссарий по акронимам? А то я что-то плаваю во всех этих BGU, BGR, EOM, TJC и т.д.
Поля микрокода:
BMS — Bus Master Selector. Идентификатор устройства, которое на данном такте вещает на шину процессора своё значение.
BSS — Bus Slave Selector. Идентификатор устройства, которое на данном такте читает из шины процессора значение в себя.
Коды BMS/BSS:
0-31 — согласно таблице "ЦПУ Блоки".
32 — номер устройства берется из поля машинного слова команды Register 1
64 — номер устройства берется из поля машинного слова команды Register 2
ALUOP — код операции АЛУ. См. лист "АЛУ".
TJC — флаг Test Jump Condition. Если == 1, то включается логика условного перехода, использующая поле JM.
JM — Jump Mask. Трех-битовая маска, которая при TJC == 1 накладывается на значение регистра CF. Принцип такой: если операция (JM and CF) даёт нулевое значение, то генерируется сигнал EOM, т.е. выполнение микрокода для данной команды обрывается и вычитывается следующая команда. Если ненулевое, то выполнение микрокода команды продолжается.
FETCH — вычитать следующее слово из памяти по регистру IP и поместить его в внутренний регистр управляющего устройства DATA (адрес на шине — 1E). Применяется двухсловными командами, которые во втором слове содержат аргумент (константа или адрес).
EOM — End Of Microcode. Бит, которые генерирует сигнал на выборку следующей команды и сброс счётчика микрокода.
Схемы:
BGU — Bus Gate Unit. Схема, которая управляет подключением устройства к внутренней шине процессора. На вход получает свой идентификатор и управляющие сигналы шины. Пропускает сигналы от/к шине в соответсвии с тем, как шина обращается к устройствам (т.е. если BMS = идентификатор, то выводит на шину значение, если BSS = идентификатор, то читает из шины).
BGR — BGU + 16-битный регистр.
CR-8/16 — регистр-счётчик (8 и 16 бит, соответственно).
Лист "Система команд", расшифровка аргументов:
R1, R2 — обобщённое название регистра. Тут терминологическая путаница, т.к. есть конкретные регистры R1 и R2, но тут подразумевается "первый аргумент-регистр в команде" и "второй аргумент-регистр в команде"
const — слово-константа.
addr — слово-константа, которая трактуется как адрес.
Здравствуйте, 0x7be, Вы писали:
0>Вроде всё осветил. Если что ещё — спрашивай
Ещё раз спасибо! И ещё пара вопросов:
1. Я правильно понимаю, что весь этот огород с отдельными входами-выходами в подмодулях нужен из-за необходимости обхода ограничения Logisim?
2. Я заметил, что у тебя АЛУ выполняет все операции сразу. Мне это кажется неэффективным с точки зрения расхода электричества, тем более, что эта проблема легко устраняется добавлением демультиплексора на вход первого операнда. Или у тебя есть какие-то веские причины так не делать?
Здравствуйте, koandrew, Вы писали:
K>Ещё раз спасибо! И ещё пара вопросов: K>1. Я правильно понимаю, что весь этот огород с отдельными входами-выходами в подмодулях нужен из-за необходимости обхода ограничения Logisim?
Да. Logisim не позволяет в подсхеме иметь контакты "ввод-вывод". Либо ввод, либо вывод. Пришлось обходить.
В версии 2.2 я заменил большинство этих схем парой демультиплексор-мультиплесор. Оно не так наглядно, зато симуляция быстрее работает.
В VHDL-версии процессора я тоже реализовал схему с (де)мультиплексором.
K>2. Я заметил, что у тебя АЛУ выполняет все операции сразу. Мне это кажется неэффективным с точки зрения расхода электричества, тем более, что эта проблема легко устраняется добавлением демультиплексора на вход первого операнда. Или у
тебя есть какие-то веские причины так не делать?
Так сделано ради простоты. Расход электричества — последнее, что меня волнует
Здравствуйте, 0x7be, Вы писали:
0>Да. Logisim не позволяет в подсхеме иметь контакты "ввод-вывод". Либо ввод, либо вывод. Пришлось обходить. 0>В версии 2.2 я заменил большинство этих схем парой демультиплексор-мультиплесор. Оно не так наглядно, зато симуляция быстрее работает. 0>В VHDL-версии процессора я тоже реализовал схему с (де)мультиплексором.
Ясно
0>Так сделано ради простоты. Расход электричества — последнее, что меня волнует
Понятно Мне просто сразу в глаза бросилось — я тут недавно только воевал за энергопотребление, потому у меня теперь нюх на такие штуки
Здравствуйте, 0x7be, Вы писали:
Q>>Наличие таких операндов позволило бы сократить систему команд, удалив такие как инкремент/декремент, проверка бита в слове, установка/очистка бита и т.п.
0>А оно точно даст выгоду хоть в чем-то? Мне пока это не очевидно.
Как минимум, оно дает выгоду в быстродействии: для считывания константы не требуется еще раз обращаться к памяти.
0>Сокращение системы команд самоцелью не является.
...после чего ты начинаешь рассказывать о преимуществах RISC
0>Из того, что я понял о философии RISC, её плюс в том, что схема управляющего устройства для такого набора команд существенно проще и быстрее за счет того, что набор команд становится меньше и проще. Ты же предлагаешь идею, которая с одной стороны пытается сократить набор команд, но достичь этого за счёт усложнения логики декодирования команды, т.е. комбинируем худшее из RISC и CISC. Где я ошибаюсь?
RISC понятие относительное и используется часто лишь в рекламных целях, в слове ARM буква R тоже означает RISC, однако система команд там отнюдь не простая. Кстати, там тоже есть сокращенные константы, причем более сложные: там в качестве константы может быть набор единиц и нулей, у которых "расстояние" между крайними единицами не превышающей 8 бит, этот набор может быть помещен в любое место в 32-разрядном слове.
Что же касается декодирования, то декодировать придется не команду, а операнд, самих же команд будет меньше, например не потребуются инкремент и декремент — они заменяются на сложение с единицей. А операнд все равно надо декодировать, у тебя же наверное есть поле где указывается номер регистра, а также находятся ли данные в самом регистре или к ним надо обращаться косвенно через адрес. Просто в тип операнда добавится еще одна возможность: он может быть сокращенной константой.
Я отвечаю за свои слова, а не за то как вы их интерпретируете!
0>>А оно точно даст выгоду хоть в чем-то? Мне пока это не очевидно. Q>Как минимум, оно дает выгоду в быстродействии: для считывания константы не требуется еще раз обращаться к памяти. 0>>Сокращение системы команд самоцелью не является. Q>...после чего ты начинаешь рассказывать о преимуществах RISC
Дяденька, я же не настоящий сварщик В меру своего понимания пытаюсь в этом разобраться.
Q>Что же касается декодирования, то декодировать придется не команду, а операнд, самих же команд будет меньше, например не потребуются инкремент и декремент — они заменяются на сложение с единицей. А операнд все равно надо декодировать, у тебя же наверное есть поле где указывается номер регистра, а также находятся ли данные в самом регистре или к ним надо обращаться косвенно через адрес. Просто в тип операнда добавится еще одна возможность: он может быть сокращенной константой.
Сказать по правде, у меня сейчас нет чёткого понимания, как правильно организовывать машинное слово с командой. На данный момент у меня крайне примитивная схема: первое обязательное слово (16 бит) состоит из 8-битового поля опкода и двух 4-битовых селекторов регистров. Если команда содержит константу/адрес, то оно помещается во второе слово. Схема простая для понимания и декодирования, но неэффективная с точки зрения расходования бит памяти. На будущее есть мысль переработать систему команд и формат их упаковки, но это оптимизация. Пока у меня с функциональными возможностями не всё закрыто
Здравствуйте, 0x7be, Вы писали:
0>Дяденька, я же не настоящий сварщик
Ну так надо стремиться стать настоящим
0>Сказать по правде, у меня сейчас нет чёткого понимания, как правильно организовывать машинное слово с командой. На данный момент у меня крайне примитивная схема: первое обязательное слово (16 бит) состоит из 8-битового поля опкода и двух 4-битовых селекторов регистров.
Понятно, то есть код команды и тип операнда не разделяются.
0>На будущее есть мысль переработать систему команд и формат их упаковки, но это оптимизация.
Я бы не назвал это оптимизацией. Это архитектура.
А слабо сделать выполнение операций не только между регистрами, но и между памятью и регистром (с помещением результата в регистр)?
Я отвечаю за свои слова, а не за то как вы их интерпретируете!
Здравствуйте, qwertyuiop, Вы писали:
0>>Дяденька, я же не настоящий сварщик Q>Ну так надо стремиться стать настоящим
Потихоньку стремлюсь
0>>Сказать по правде, у меня сейчас нет чёткого понимания, как правильно организовывать машинное слово с командой. На данный момент у меня крайне примитивная схема: первое обязательное слово (16 бит) состоит из 8-битового поля опкода и двух 4-битовых селекторов регистров. Q>Понятно, то есть код команды и тип операнда не разделяются.
Да. Конкретная команда однозначно трактует селекторы регистров и слово данных, эта трактовка прошита в её микрокоде.
Из-за этого, кстати. в микрокоде хватает копипасты
Q>А слабо сделать выполнение операций не только между регистрами, но и между памятью и регистром (с помещением результата в регистр)?
Уже есть похожие команды, которые в качестве одного операнда используют регистр, а второго — слово данных из команды. Например:
addc R1, 10 ; Прибавить к значению в регистре R1 константу 10.
Схема управляющего устройства уже сейчас позволит поддержать следующие варианты команды:
addci R1, 10 ; Прибавить к значению в регистре R1 значение по адресу 10.
addri R1, R2 ; Прибавить к значению в регистре R1 значение по адресу, хранящемуся в R2
Надо только микрокод написать. Но при таком подходе возникает проблема с комбинаторным взрывом количества кодов операций, поэтому я решил этого не делать. Персективным вижу разделение кода операции и кодов, указывающих на операны.
Здравствуйте, qwertyuiop, Вы писали:
Q>Здравствуйте, 0x7be, Вы писали:
0>>Дяденька, я же не настоящий сварщик
Q>Ну так надо стремиться стать настоящим
0>>Сказать по правде, у меня сейчас нет чёткого понимания, как правильно организовывать машинное слово с командой. На данный момент у меня крайне примитивная схема: первое обязательное слово (16 бит) состоит из 8-битового поля опкода и двух 4-битовых селекторов регистров.
Q>Понятно, то есть код команды и тип операнда не разделяются.
Не поясните, что имеется в виду? Т.е. тип операнда -- регистр либо константа. Здесь одни регистры, это имеется в виду?
0>>На будущее есть мысль переработать систему команд и формат их упаковки, но это оптимизация.
Q>Я бы не назвал это оптимизацией. Это архитектура.
Q>А слабо сделать выполнение операций не только между регистрами, но и между памятью и регистром (с помещением результата в регистр)?
Это кмк, не очень тривиально, тут сразу можно в интел идти инженером. Вот на какой-нибудь DM кэш замахнуться можно.
Здравствуйте, 0x7be, Вы писали:
Q>>Понятно, то есть код команды и тип операнда не разделяются. 0>Да. Конкретная команда однозначно трактует селекторы регистров и слово данных, эта трактовка прошита в её микрокоде. 0>Из-за этого, кстати. в микрокоде хватает копипасты
Ну так взять и разделить всю команды на три поля:
1 код собственно команды (5 или 6 бит)
2 описание первого операнда: регистр, память по адресу в регистре, (еще что-то — ты писал что у тебя есть относительная адресация), ..., сокращенная константа (7 или 8 бит)
3 второй операнд — всегда регистр (3 бита)
Такую архитектуру и реализовать было бы легче кмк
0>Уже есть похожие команды, которые в качестве одного операнда используют регистр, а второго — слово данных из команды. Например: 0>
0> addc R1, 10 ; Прибавить к значению в регистре R1 константу 10.
0>
Это-то понятно, но ведь константа хранится в следующем слове, значит на ее извлечение потребуется цикл чтения из памяти.
А сокращенные константы делают ненужными большинство однопрерандных команд:
CLR == 0 & R
SET == ffff | R
INC == 1 + R
DEC == ffff + R
BITSET == bit | R
BITCLR == ~bit & R
COM == ffff ^ R
NEG == 0 — R
TST == 0 | R или ffff & R
Останутся только сдвиги, и те можно ликвидировать когда в твоем проце появятся умножение и деление.
Я отвечаю за свои слова, а не за то как вы их интерпретируете!
Привет ещё раз. Я вот тоже решил купить себе какую-нить FPGA'шку "на поиграться", но что-то никак не могу определиться с конкретной моделью. Посему можно поинтересоваться, почему именно ты выбрал ту модель, какую ты выбрал?
Я тут поигрался с софтом от производителей, и софт Альтеры мне понравился больше — там я почти сходу разобрался, как делать тест-бенчи и гонять симуляции с вейвформами для верификации, потому и железяки интересуют на их чипах.
Поскольку мне важно, чтобы чипы были "вручнуюпаябельные" (читай — НЕ *BGA), то из имеющегося на рынке мне подходят только серии Cyclone IV (пятая серия только в BGA) и MAX10. Серия MAX10 мне нравится тем, что там "всё включено" — то есть и преобразователь напряжения для ядра, и память битстрима интегрирована в чип, и потому их очень удобно использовать в своих проектах — программатор (от Terasic стоит 70 каксов) подключается непосредственно к чипу и битстрим "заливается" туда. То есть не нужно отдельной микросхемы для программирования FPGA. Но серия Cyclone IV помощнее будет. В общем в раздумьях я...
Здравствуйте, koandrew, Вы писали:
K>Привет ещё раз. Я вот тоже решил купить себе какую-нить FPGA'шку "на поиграться", но что-то никак не могу определиться с конкретной моделью. Посему можно поинтересоваться, почему именно ты выбрал ту модель, какую ты выбрал? K>Я тут поигрался с софтом от производителей, и софт Альтеры мне понравился больше — там я почти сходу разобрался, как делать тест-бенчи и гонять симуляции с вейвформами для верификации, потому и железяки интересуют на их чипах. K>Поскольку мне важно, чтобы чипы были "вручнуюпаябельные" (читай — НЕ *BGA), то из имеющегося на рынке мне подходят только серии Cyclone IV (пятая серия только в BGA) и MAX10. Серия MAX10 мне нравится тем, что там "всё включено" — то есть и преобразователь напряжения для ядра, и память битстрима интегрирована в чип, и потому их очень удобно использовать в своих проектах — программатор (от Terasic стоит 70 каксов) подключается непосредственно к чипу и битстрим "заливается" туда. То есть не нужно отдельной микросхемы для программирования FPGA. Но серия Cyclone IV помощнее будет. В общем в раздумьях я...
Я плясал от трёх вещей: от своей цели, стоимости и доступности. Поскольку я делаю компьютер, мне нужна была плата на которой будет достаточно мощная микросхема, память, порты. Я погуглил проекты на opencores.org, посмотрел модели, на которых люди делали свои компьютеры, взял этот список за основу. Дальше просто выбирал по цене и доступности в Москве.
Здравствуйте, 0x7be, Вы писали: 0>Я плясал от трёх вещей: от своей цели, стоимости и доступности. Поскольку я делаю компьютер, мне нужна была плата на которой будет достаточно мощная микросхема, память, порты. Я погуглил проекты на opencores.org, посмотрел модели, на которых люди делали свои компьютеры, взял этот список за основу. Дальше просто выбирал по цене и доступности в Москве.
Ок, продолжаем серию тупых вопросов
Я заметил, что у тебя GPR'ы (General Purpose Register) недоступны напрямую ALU, и значения из них нужно переместить в O1/O2 перед выполнением операции. Мне кажется, куда эффективнее было бы организовать прямой доступ к ним ALU примерно так:
Картинко
Плюс это дало бы возможность выполнять операции типа "Rr <- Rx [ALUOP] Ry", при этом x,y и r могут быть любыми (в том числе и одинаковыми). А если добавить в эту адресацию ещё и MAR, то можно выполнять операции вида "память-регистр" за один такт, и, немного поднапрягшись, даже "память-память" за два такта (тут надо будет немного добавить логики для сетапа операции записи в память).
Вопрос как и прежде — у тебя были какие-то причины так не делать, или просто "так вышло"?
K>Ок, продолжаем серию тупых вопросов K>Я заметил, что у тебя GPR'ы (General Purpose Register) недоступны напрямую ALU, и значения из них нужно переместить в O1/O2 перед выполнением операции. Мне кажется, куда эффективнее было бы организовать прямой доступ к ним ALU примерно так:
Да, ты прав. Это следствие того, что для меня простота на первом этапе важнее эффективности. Поэтому я выбрал простейшую одношинную архитектуру по типу описанного тут: http://www.cdf.toronto.edu/~ajr/258/notes/micro/one-bus.html
По-хорошему надо иметь минимум три шины, чтобы одновременно коммутировать на АЛУ два операнда и результат в регистр. Можно четыре шины, чтобы попутно можно было коммутировать из регистра значение на шину адреса и выводить результат в память. Тогда арифметика за один такт решаться будет.
Впрочем, я пока решил дальше одношинной схемы не идти, а заниматься проблемами исполнения. При переходе от Logsim к VHDL и реальному железу выскочило много граблей Например, в симуляторе ОЗУ данные на выход подаёт мгновенно, а в реале это не так. Пока я выкрутился из этого чудовищным костылём (сам даже не понимаю, как это работает). Плюс, проц описан на VHDL в структурном стиле, что делает его трудносопровождаемым. Я решил переписать его как конечный автомат, попутно решив эти проблемы. Микрокод будет другим, а на уровне команд хочу сохранить совместимость.
K>Плюс это дало бы возможность выполнять операции типа "Rr <- Rx [ALUOP] Ry", при этом x,y и r могут быть любыми (в том числе и одинаковыми). А если добавить в эту адресацию ещё и MAR, то можно выполнять операции вида "память-регистр" за один такт, и, немного поднапрягшись, даже "память-память" за два такта (тут надо будет немного добавить логики для сетапа операции записи в память).
Я вот в твоей схеме не понял, как делать пересылку между регистрами. Разве что спец. командой в АЛУ, которая на тупо выход коммутирует один из операндов. Или это пока ещё не сделано?
K>Вопрос как и прежде — у тебя были какие-то причины так не делать, или просто "так вышло"?
Простота — страшная сила
K>P.S. Ты если что звиняй за тупые вопросы — я пока тока вникаю в эту тему
Это ничего. Отвечая на твои вопросы я сам начинаю лучше понимать тему, так что задавай ещё и побольше
K>P.P.S. Нашёл тут интересный цикл лекций по цифровой схемоте: https://www.utdallas.edu/~dodge/EE2310/ И ещё сайт www.fpga4fun.com тоже интересный.
Спасибо, засмотрим
Здравствуйте, 0x7be, Вы писали: 0>По-хорошему надо иметь минимум три шины, чтобы одновременно коммутировать на АЛУ два операнда и результат в регистр. Можно четыре шины, чтобы попутно можно было коммутировать из регистра значение на шину адреса и выводить результат в память. Тогда арифметика за один такт решаться будет.
Дык в моём примере как раз три шины и есть 0>Впрочем, я пока решил дальше одношинной схемы не идти, а заниматься проблемами исполнения. При переходе от Logsim к VHDL и реальному железу выскочило много граблей Например, в симуляторе ОЗУ данные на выход подаёт мгновенно, а в реале это не так. Пока я выкрутился из этого чудовищным костылём (сам даже не понимаю, как это работает).
Ну вот теперь ты понял, зачем в процы ставят кэши Вообще после "запуска" операции чтения/записи нужно ждать сигнала READY от чипа (у разных чипов/контроллеров он по-разному называется, но смысл его одинаков). ну либо закладываться на тайминги памяти (в принципе ничего себе подход, если заранее известны тайминги памяти), и напедалить нужное количество NOP'ов в микрокод, ну или реализовать микрокоманду NOP x с тем же смыслом). Так поступают реальные процы, и называется это cpu stall кажись. Собственно все свистопляски с prefetch'ем, предсказанием переходов и конвейером как раз и придумали, чтобы уменьшить вероятность этого простоя. 0>Плюс, проц описан на VHDL в структурном стиле, что делает его трудносопровождаемым. Я решил переписать его как конечный автомат, попутно решив эти проблемы. Микрокод будет другим, а на уровне команд хочу сохранить совместимость.
А ты пользуйся графической формой. IDE умеет генерить символьные файлы для компонентов, описанных на HDL (правый клик на HDL-файле в "Project Navigator (Files)" -> "Create Symbol Files for Current File"), после чего описанные в этом файле модули становятся доступными в графическом редакторе. В этом случае всё будет выглядеть, как в Logisim'е — в виде схемы, что ИМХО намного нагляднее, чем в коде. Вот тут в главе 6 есть небольшой туториал по тому, как это организовать.
Пример описания(Verilog) и его символа
Лично я предпочитаю графическую форму для всего, кроме совсем уж низкоуровневых вещей типа счётчиков. В Quartus Prime довольно мощный графический редактор, правда, как это часто бывает в "железячном" деле, без поллитра временами тяжеловато разобраться, куда жать 0>Я вот в твоей схеме не понял, как делать пересылку между регистрами. Разве что спец. командой в АЛУ, которая на тупо выход коммутирует один из операндов. Или это пока ещё не сделано?
Это просто схема, которую я наваял за пару минут для демонстрации своей идеи, т.к. мне показалось, что картинка намного лучше словесного описания продемонстрирует суть того, что я предлагаю. 0>Это ничего. Отвечая на твои вопросы я сам начинаю лучше понимать тему, так что задавай ещё и побольше
Здравствуйте, koandrew, Вы писали:
K>Дык в моём примере как раз три шины и есть
Да, я заметил
K>Ну вот теперь ты понял, зачем в процы ставят кэши Вообще после "запуска" операции чтения/записи нужно ждать сигнала READY от чипа (у разных чипов/контроллеров он по-разному называется, но смысл его одинаков). ну либо закладываться на тайминги памяти (в принципе ничего себе подход, если заранее известны тайминги памяти), и напедалить нужное количество NOP'ов в микрокод, ну или реализовать микрокоманду NOP x с тем же смыслом). Так поступают реальные процы, и называется это cpu stall кажись. Собственно все свистопляски с prefetch'ем, предсказанием переходов и конвейером как раз и придумали, чтобы уменьшить вероятность этого простоя.
Я хочу абстрагировать микрокод от этих ужасающих подробностей. Сейчас в микрокоде обращение к шине не отличается от пересылки между регистрами. Я хочу ввести специальные микрокоманды для ввода/вывода на шину и в схеме предусмотреть сигналы готовности.
K>А ты пользуйся графической формой. K>... K>Лично я предпочитаю графическую форму для всего, кроме совсем уж низкоуровневых вещей типа счётчиков. В Quartus Prime довольно мощный графический редактор, правда, как это часто бывает в "железячном" деле, без поллитра временами тяжеловато разобраться, куда жать
Нет, я как раз хочу от этого отойти. Я хочу переписать процессор как конечный автомат, применив для этого рекомендуемую в VHDL идиоматику. В таком описании логика схемы намного прозрачнее выражена, чем в структурном описании, её будет проще развивать и сопровождать.
0>>Я вот в твоей схеме не понял, как делать пересылку между регистрами. Разве что спец. командой в АЛУ, которая на тупо выход коммутирует один из операндов. Или это пока ещё не сделано? K>Это просто схема, которую я наваял за пару минут для демонстрации своей идеи, т.к. мне показалось, что картинка намного лучше словесного описания продемонстрирует суть того, что я предлагаю.
Это факт, лучше
Здравствуйте, 0x7be, Вы писали:
0>Да, я заметил
Кстати я ради интереса почитал про архитектуру AVR, MIPS — в обоих АЛУ имеет прямой доступ ко всем GPR'ам. Из интересного — у MIPS регистр IP является обычным регистром, как и все остальные, при этом его инкрементирование выполняется на АЛУ
0>Я хочу абстрагировать микрокод от этих ужасающих подробностей. Сейчас в микрокоде обращение к шине не отличается от пересылки между регистрами. Я хочу ввести специальные микрокоманды для ввода/вывода на шину и в схеме предусмотреть сигналы готовности.
Ты полегче с абстракциями — это тебе не С++ В железе абстракции могут оказаться дороже, чем ты думаешь
0>Нет, я как раз хочу от этого отойти. Я хочу переписать процессор как конечный автомат, применив для этого рекомендуемую в VHDL идиоматику. В таком описании логика схемы намного прозрачнее выражена, чем в структурном описании, её будет проще развивать и сопровождать.
Ну дело хозяйское. Лично мне схема кажется более наглядной — всё же это железяка, а не какая-то там программа
Кстати — тебя ещё не достало писать простыни бойлерплейта на VHDL? PROCESS, ARCHITECTURE, COMPONENT.... бррр! Ещё с универа помню На верилоге тот же функционал требует раза в два меньше букав
Я тут нашёл неплохое описание драйвера LCD-панели: http://www.fpga4fun.com/GraphicLCDpanel.html Как раз то, что мне нужно. Оказывается всё гораздо проще, чем я думал — вывести графику из видеобуфера на панель занимает всего несколько десятков строчек кода. Осталось разобраться, как с RAM/ROM работать — и дело в шляпе будет Ну и ещё само собой видеопроцессор реализовать надо будет — но это уже совсем отдельная история.
Ещё на ютубе нашёл неплохие видеогайды по FPGA: https://www.youtube.com/user/AntoniusSimplus/videos Из интересного — описание драйвера VGA и использование SRAM. Кстати товарищ этот — русский, по акценту сразу слышно
Здравствуйте, koandrew, Вы писали:
K>Кстати я ради интереса почитал про архитектуру AVR, MIPS — в обоих АЛУ имеет прямой доступ ко всем GPR'ам. Из интересного — у MIPS регистр IP является обычным регистром, как и все остальные, при этом его инкрементирование выполняется на АЛУ
Странное решение. Разве это не должно приводить к тому, что команда, использующая АЛУ, будет выполняться дольше, т.к. нельзя будет одновременно считать арифметику для команды и сдвигать IP?
K>Ты полегче с абстракциями — это тебе не С++ В железе абстракции могут оказаться дороже, чем ты думаешь
Не, ну писать сортировку массива в один такт я не буду (читал про такое извращение на хабре
0>>Нет, я как раз хочу от этого отойти. Я хочу переписать процессор как конечный автомат, применив для этого рекомендуемую в VHDL идиоматику. В таком описании логика схемы намного прозрачнее выражена, чем в структурном описании, её будет проще развивать и сопровождать. K>Ну дело хозяйское. Лично мне схема кажется более наглядной — всё же это железяка, а не какая-то там программа
Её сложнее проектировать и эволюционировать. Насколько я знаю, как только методы синтеза схем стали выдавать нормальные результаты, с ручной разводкой схем быстро завязали.
Не хватает ещё синтаксического сахару для поддержки конечных автоматов (по типу как это сделано в методах-итераторах в C#).
K>Кстати — тебя ещё не достало писать простыни бойлерплейта на VHDL? PROCESS, ARCHITECTURE, COMPONENT.... бррр! Ещё с универа помню На верилоге тот же функционал требует раза в два меньше букав
Есть немного, но у меня пока такая ситуация, что я больше думаю, чем пишу
K>Я тут нашёл неплохое описание драйвера LCD-панели: http://www.fpga4fun.com/GraphicLCDpanel.html Как раз то, что мне нужно. Оказывается всё гораздо проще, чем я думал — вывести графику из видеобуфера на панель занимает всего несколько десятков строчек кода. Осталось разобраться, как с RAM/ROM работать — и дело в шляпе будет Ну и ещё само собой видеопроцессор реализовать надо будет — но это уже совсем отдельная история.
Там интерфейс попроще будет, чем VGA. Впрочем, у меня VGA-адаптер со знакогенерацией занимает две страницы на VHDL. Правда, там есть какие-то особенности реализации, которые я так и не понял.
Это вообще пока моя беда — некоторые вещи у меня работают вот так, а не иначе, и я не понимаю, почему вот так оно работает, а иначе — нет.
K>Ещё на ютубе нашёл неплохие видеогайды по FPGA: https://www.youtube.com/user/AntoniusSimplus/videos Из интересного — описание драйвера VGA и использование SRAM. Кстати товарищ этот — русский, по акценту сразу слышно
SRAM-фигня, SDRAM веселее Разница в сложности между прямолинейной и оптимизированной реализациями раз в десять
P.S. А вообще я сейчас занят переписыванием ассемблера с VBA на C# Думаю, что надо будет подумать о портировании какого-нибудь простенького С-компилятора на свою архитектуру.
Здравствуйте, 0x7be, Вы писали:
0>Странное решение. Разве это не должно приводить к тому, что команда, использующая АЛУ, будет выполняться дольше, т.к. нельзя будет одновременно считать арифметику для команды и сдвигать IP?
Перечитал доку — нет, там отдельный сумматор для инкремента. "Общий" АЛУ был только на прототипе.
0>Её сложнее проектировать и эволюционировать. Насколько я знаю, как только методы синтеза схем стали выдавать нормальные результаты, с ручной разводкой схем быстро завязали.
ЕМНИП Интел только в P-4 перешла на синтез. Просто железки обычно не разрабатывают по принципу "а давайте-ка мы как-нить сбоку вот эту фичу прикрутим". Если сразу сделать структурную схему девайса, то всё остальное будет проще.
0>Не хватает ещё синтаксического сахару для поддержки конечных автоматов (по типу как это сделано в методах-итераторах в C#). Железячники вообще товарищи консервативные — ну типа как жабники
0>Есть немного, но у меня пока такая ситуация, что я больше думаю, чем пишу
На самом деле писать-то в ИДЕ почти пофигу, а вот читать лично мне сложнее, потому что содержательная часть кода теряется в куче бойлерплейта. Особенно бесит COMPONENT->PORT MAP — чистое дублирование кода, и часть COMPONENT вообще можно выбросить, т.к. в PORT MAP можно использовать синтаксис pin => signal. В верилоге это намного более элегантно сделано (синтаксически почти как в С++/С#). Ну и тест-бенчи ИМХО в верилоге проще (==быстрее) писать, что важно, т.к. мало кому нравится писать юнит-тесты
0>Там интерфейс попроще будет, чем VGA. Впрочем, у меня VGA-адаптер со знакогенерацией занимает две страницы на VHDL. Правда, там есть какие-то особенности реализации, которые я так и не понял.
Абсолютно то же самое один-в-один — только частота у LCD-панели у каждой своя (впрочем, многие панели не очень разборчивы, и будут работать в широком диапазоне частот развёртки). Ибо все современные видеопротоколы фундаментально одинаковы (из-за обратной совместимости — это ещё один "пунктик" у железячников )
Правда в твоём случае ещё нужен знакогенератор (т.к. ты пишешь в текстовом режиме как я понял), что несколько усложняет дело. Если бы использовал графический режим — то было бы то же самое с точностью до разрешения, размеров внеэкранных областей и частоты развёртки.
0>Это вообще пока моя беда — некоторые вещи у меня работают вот так, а не иначе, и я не понимаю, почему вот так оно работает, а иначе — нет.
Ну дык выкладывай код и спрашивай — чем смогу, помогу. Как оказалось, я весьма неплохо всё помню с универа несмотря на то, что прошло 10 лет
0>SRAM-фигня, SDRAM веселее Разница в сложности между прямолинейной и оптимизированной реализациями раз в десять
Там SDRAM и демонстрируется — я не так написал. Товарищ авалоноский контроллер юзает. На моей девплате тоже SDRAM стоит, но в конечном девайсе мне нужно нечто побыстрее 100 МГц, так что думаю использовать DDR2/3 (тут рядом как раз тема об этом).
0>P.S. А вообще я сейчас занят переписыванием ассемблера с VBA на C# Думаю, что надо будет подумать о портировании какого-нибудь простенького С-компилятора на свою архитектуру.
Возьми какой-нить flex/bison/yacc ну или что там сейчас модно юзать для создания парсеров. Мы в универе за две пары на лабах успевали полнофункциональный парсер С сделать Кодогенератор тоже относительно просто сделать, если забить на оптимизацию. Основная сложность там — это портирование/написание crt. Вот с ней возни будет много.
P.S. Ты бы кстати в блог почаще писал о прогрессе — интересно же, как там у тебя процесс идёт, какие грабли попадаются, ну и т. д.
0>>Её сложнее проектировать и эволюционировать. Насколько я знаю, как только методы синтеза схем стали выдавать нормальные результаты, с ручной разводкой схем быстро завязали. K>ЕМНИП Интел только в P-4 перешла на синтез. Просто железки обычно не разрабатывают по принципу "а давайте-ка мы как-нить сбоку вот эту фичу прикрутим". Если сразу сделать структурную схему девайса, то всё остальное будет проще.
Возможность развивать дизайн эволюционно — это функция мягкости материала. Раньше и программы начинали делать со структурной схемы, потому что рефакторить было слишком накладно. Как появились адекватные инструменты, эволюционный дизайн вошёл в моду. С появлением ПЛИСов в железе тоже стала появляться такая возможность.
0>>Там интерфейс попроще будет, чем VGA. Впрочем, у меня VGA-адаптер со знакогенерацией занимает две страницы на VHDL. Правда, там есть какие-то особенности реализации, которые я так и не понял. K>Абсолютно то же самое один-в-один — только частота у LCD-панели у каждой своя (впрочем, многие панели не очень разборчивы, и будут работать в широком диапазоне частот развёртки). Ибо все современные видеопротоколы фундаментально одинаковы (из-за обратной совместимости — это ещё один "пунктик" у железячников ) K>Правда в твоём случае ещё нужен знакогенератор (т.к. ты пишешь в текстовом режиме как я понял), что несколько усложняет дело. Если бы использовал графический режим — то было бы то же самое с точностью до разрешения, размеров внеэкранных областей и частоты развёртки.
А там тоже есть "порожки" до/после сигнала синхронизации, когда отрисовка не происходит?
0>>Это вообще пока моя беда — некоторые вещи у меня работают вот так, а не иначе, и я не понимаю, почему вот так оно работает, а иначе — нет. K>Ну дык выкладывай код и спрашивай — чем смогу, помогу. Как оказалось, я весьма неплохо всё помню с универа несмотря на то, что прошло 10 лет
Я думаю на codeplex проектик завести и поместить туда всё, что есть.
0>>SRAM-фигня, SDRAM веселее Разница в сложности между прямолинейной и оптимизированной реализациями раз в десять K>Там SDRAM и демонстрируется — я не так написал. Товарищ авалоноский контроллер юзает. На моей девплате тоже SDRAM стоит, но в конечном девайсе мне нужно нечто побыстрее 100 МГц, так что думаю использовать DDR2/3 (тут рядом как раз тема об этом).
Авалоновский — это который в системе NIOS идёт? Я нашёл простейший контроллер в интернетах. Он тупой и неэффективный, зато я понимаю, как он работает
0>>P.S. А вообще я сейчас занят переписыванием ассемблера с VBA на C# Думаю, что надо будет подумать о портировании какого-нибудь простенького С-компилятора на свою архитектуру. K>Возьми какой-нить flex/bison/yacc ну или что там сейчас модно юзать для создания парсеров. Мы в универе за две пары на лабах успевали полнофункциональный парсер С сделать
Я взял пока sprache. Простой монадический парсер, который позволяет правила грамматические прямо в коде писать. Вчерась я добил ассемблер до функциональности, идентичной прототипу на VBA, но внутри пока ужас-ужас
К тому же я хочу сделать ассемблер, который можно легко перенастроить на сборку другого ассемблера, т.к. мне следующим шагом надо будет новый микрокод реализовывать.
K>Кодогенератор тоже относительно просто сделать, если забить на оптимизацию. Основная сложность там — это портирование/написание crt. Вот с ней возни будет много.
Ну, если не браться за всю библиотеку разом, а писать функции по необходимости, то не так страшно будет, я думаю
Слона надо есть по частям
K>P.S. Ты бы кстати в блог почаще писал о прогрессе — интересно же, как там у тебя процесс идёт, какие грабли попадаются, ну и т. д.
Дык, прогресса почти что и нет пока Времени мало, к тому же я сейчас не делаю новые вещи, а довожу до ума уже сделанные. Я же до сих пор по сути прототипировал.
Я вот щас сделаю новую микроархитектуру, которая позволит эволюционировать процессор дальше, и займусь новыми вещами: байтовую адресацию прикручу, прерывания, более рациональную систему и формат команд, монитор напишу.
Вот после этого можно новую публикацию делать.
Здравствуйте, 0x7be, Вы писали:
0>Возможность развивать дизайн эволюционно — это функция мягкости материала. Раньше и программы начинали делать со структурной схемы, потому что рефакторить было слишком накладно. Как появились адекватные инструменты, эволюционный дизайн вошёл в моду. С появлением ПЛИСов в железе тоже стала появляться такая возможность.
Ну хозяин-барин как говорится Видимо тут сказывается разный бэкграунд — мне проще думать о железке в "железных" терминах. Плюс когда "схема" перед глазами, проще разобраться с таймингами.
0>А там тоже есть "порожки" до/после сигнала синхронизации, когда отрисовка не происходит?
Да. Вот даташит панели, которую я планирую использовать — там в разделе таймингов есть их описание (blanking). Только в цифровом интерфейсе нет DAC само собой. Я же говорю — железячники повёрнуты на обратной совместимости
0>Я думаю на codeplex проектик завести и поместить туда всё, что есть.
Да всё равно куда — лишь бы доступно было. Что именно непонятно-то?
0>Авалоновский — это который в системе NIOS идёт?
Смотри тут Он через qsys настраивается (по крайней мере в Quartus Prime 15.1, которую я юзаю). В их University Program вообще много какие полезные IP имеются — правда они все заточены под периферию, которая есть на девайсах этой программы (девайсы серии DEх от Terasic тоже к ней относятся), но для тебя это не должно быть проблемой, ибо как я понял ты не собираешься делать свои кастомные платы.
0>Я нашёл простейший контроллер в интернетах. Он тупой и неэффективный, зато я понимаю, как он работает
Главное понимать, как работать с ним. Как он сам работает, знать не обязательно. В этом смысл IP-блоков. Хотя и интересно иногда Пользоваться им очень просто — проверяешь готовность, если готов, то выдаёшь адрес на шину, на следующем тике забираешь данные. В обратную сторону аналогично. Посмотри видео короче. Там кстати ещё обсуждается вопрос перехода между временнЫми доменами, демонстрируется суть проблемы, и пути решения.
0>Я взял пока sprache. Простой монадический парсер, который позволяет правила грамматические прямо в коде писать. Вчерась я добил ассемблер до функциональности, идентичной прототипу на VBA, но внутри пока ужас-ужас 0>К тому же я хочу сделать ассемблер, который можно легко перенастроить на сборку другого ассемблера, т.к. мне следующим шагом надо будет новый микрокод реализовывать.
А зачем? Если поменяются коды команд, то тебе нужно будет адаптировать только кодогенератор. Парсер останется тем же. Или ты сам язык хочешь поменять?
0>Ну, если не браться за всю библиотеку разом, а писать функции по необходимости, то не так страшно будет, я думаю 0>Слона надо есть по частям
Ну ты посмотри на неё — там все функции завязаны друг на друга. Кстати я бы посоветовал тебе взять исходники crt от какого-нить промышленного МК (тот же AVR, или 8-битный PIC), ибо они создавались под те же условия, в которых придётся работать тебе (медленный чип, мало памяти). Кстати какая тактовая частота у твоего проца?
0>Дык, прогресса почти что и нет пока Времени мало, к тому же я сейчас не делаю новые вещи, а довожу до ума уже сделанные. Я же до сих пор по сути прототипировал. 0>Я вот щас сделаю новую микроархитектуру, которая позволит эволюционировать процессор дальше, и займусь новыми вещами: байтовую адресацию прикручу, прерывания, более рациональную систему и формат команд, монитор напишу. 0>Вот после этого можно новую публикацию делать.
"Жду" (С) "Иван Васильевич меняет профессию"
Здравствуйте, 0x7be, Вы писали: 0>Возможность развивать дизайн эволюционно — это функция мягкости материала. Раньше и программы начинали делать со структурной схемы, потому что рефакторить было слишком накладно. Как появились адекватные инструменты, эволюционный дизайн вошёл в моду. С появлением ПЛИСов в железе тоже стала появляться такая возможность.
Поигравшись немного на выходных, беру свои слова обратно. Конечные автоматы рулят! Я пытался сделать UART-передатчик (чтобы FPGA по нажатию кнопки отправила "Hello, world!!" в COM-порт ) и полдня провозился с сигналами, запутав сам себя кучкой сигналов в стиле skip_next_clock_cycle. После чего на следующее утро снёс нафиг всё это богатство, и заменил на конечный автомат — в итоге код передатчика заработал с первой попытки и безо всяких проблем! А сейчас буквально за полчаса наваял код приёмника (он принимает байты из COM-порта, и отображает их двоичный код на LED) — и опять же всё завелось со второй попытки (всё работало и на первой попытке, но я просто перепутал порядок бит LSB <-> MSB, и потому двоичный код символов был "вверх ногами")! Конечно, он не обрабатывает ошибочные ситуации, но мне всё же кажется, что код очень неплохой Саму схему верхнего уровня я всё равно сделал визуально, но все девайсы — на верилоге. Если интересно — вот код приёмника
UART-receiver
module UART_RX(input clock, input rx_pin, output reg data_ready, output reg [7:0] data);
localparam IDLE = 2'b00, RX_IN_PROGRESS = 2'b01, RX_COMPLETED = 2'b10;
reg [1:0] state = IDLE;
integer bit_idx = 0;
reg [7:0] buff = 8'h00;
initial begin
data_ready <= 0;
data <= 8'h00;
end
always @(posedge clock)
begin
case (state)
IDLE:
begin
if (rx_pin == 0)
begin
//tx is beginning, start bit is 0, while "bus idle" is 1
bit_idx <= 0;
buff <= 8'h00;
state <= RX_IN_PROGRESS;
data_ready <= 0;
end
end
RX_IN_PROGRESS:
begin
buff[7 - bit_idx] <= rx_pin;
if (bit_idx == 7)
begin
//this is last bit, next bit will be stop bit
state <= RX_COMPLETED;
end
else
begin
bit_idx <= bit_idx + 1;
end
end
RX_COMPLETED:
begin
//rx is complete, output result and raise data_ready flag
data_ready <= 1;
data <= buff;
state <= IDLE;
end
endcase
end
endmodule
А вот вся схема:
Схема
Должен сказать, что на моей девплате хидеры расширения (как будто специально!) сделаны так, что если на пины 2-4-6-8-10-12 "надеть" преобразователь USB-UART, то "земля" хидера как раз окажется в нужном месте, а прочие пины подключатся к пинам, напрямую подключенным к FPGA (а именно GPIO_01 -> RX, GPIO_03 -> TX, остальные пины не используются). Таким образом я по сути бесплатно (в смысле паять ничего не надо) получил инструмент для дебага в стиле printf И в принципе заменил VGA-порт на окно putty, и оно даже само умеет скроллиться
A>>А ты не хочешь его заопенсоурсить? Может в тебе дремлет второй (третий?) Линус Торвальдс?
L>аппаратный линукс сделать? каждая команда в линуксе за 1 такт
С тактовой частотой 10 герц, да говно вопрос я думаю это вполне возможно!
Практической и научной ценности в моём проекте нет, но как некий простой пример системы, которая может быть интересна таким же начинающим людям, это сгодится.
, пока я не вспомнил про эту "тонкость" (видел это в одном из видео по Ардуино), и соорудил более мощный внешний источник питания. После этого всё сразу взлетело, а я от радости заорал матом так, что ко мне соседи прибежали выяснить, не убивают ли тут кого 
