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, и оно даже само умеет скроллиться
Вообще после "запуска" операции чтения/записи нужно ждать сигнала READY от чипа (у разных чипов/контроллеров он по-разному называется, но смысл его одинаков). ну либо закладываться на тайминги памяти (в принципе ничего себе подход, если заранее известны тайминги памяти), и напедалить нужное количество NOP'ов в микрокод, ну или реализовать микрокоманду NOP x с тем же смыслом). Так поступают реальные процы, и называется это cpu stall кажись. Собственно все свистопляски с prefetch'ем, предсказанием переходов и конвейером как раз и придумали, чтобы уменьшить вероятность этого простоя.
На верилоге тот же функционал требует раза в два меньше букав 
