РУ, Карл. 581РУ1-2-3. Лучше оригиналы дековские читать, в советских переводах запутано изложено.
Вид для печати
Как и 588ВУх.
Да, временная диаграмма на 180 странице.
Хе-хе, похоже что ещё и "фрязинский" завод выпускал.
http://www.chipdb.org/data/media/102...12_2_chips.jpg
P.S. Знаю что не фрязинский, просто логотип похожий. :)
Структурировал проект реплики 1801ВМ1, добавил поддержку платы DE1.
На плате DE0 (Циклон EP3C16-C7) частота достигла 111 МГц, на DE1 (EP2C20-C7) 85 МГц.
Сделана библиотечка модулей, совместимых с Wishbone - UART, timer, портируемая, общая для всех поддерживаемых плат.
Сделан системный контроллер клока и сброса (теперь есть имитация включения питания по долгому нажатию сброса, полностью изолированы тактовые домены - было пару триггеров, это кстати, привело к повышению Fmax).
Так и не смог заставить Quartus нормально генерировать память, в итоге получилось две ветки процессора, переключаемые по параметру компиляции, портабельная имеет параметры похуже чем специализированная с компонентом под конкретную FPGA, для Циклонов 2 и 3 эти компоненты уже написаны и протестированы.
Проект красиво оформлен на гитхабе (ссылка на первой странице темы).
Чуть-чуть осталось - добавить платы DE2-115 и AX309 и можно переходить к ВМ2 :)
Vslav, или ещё кто опытный, подскажите, что я делаю не так.
Никак не могу забирать изменения из репозиториев на гитхабе. git всегда говорит, что фатал, автоматический мержинг файлед, и сделать ничего не может. Приходится сперва удалять локальную копию и делать заново клон.
Может нужны какие-то хитрые ключи дополнительные? Я обычно использую команду git.exe pull --progress -v "origin", которая нормально забирает все изменения со всех реп, кроме Vslavовских.
В общем-то понятно, что судя по .gitattributes, там бинарники отмечены как текстовые файлы, и мержер на них споткнётся. Но readme.md смержить не может почему?
Ты все делаешь так. Это меня на работе приучили достаточно вольно обращаться с гитом.
У меня в репке идут несколько параллельных проектов - ВМ1, ВМ2, итд. В бранчи их не засунешь, надо копипастить из одного в другой, да и не для того бранчи предназначены. Поэтому для изменения разных проектов собираю в отдельные коммиты - vm1: working commit, vm2: working commit и так далее. Потом когда их много накопилось я их сквошу в vm1: pre-release commit через интерактивный rebase и потом публикую push origin --force. Да, во всех книжках по гиту написано что так делать нельзя, но почти все в сложных проектах это периодически делают, а кто не делает - те давно на геррите сидят :). У меня контрибуторов других пока нет, поэтому для моего проекта это не критично вообще. Когда уже появляется уверенность что изменений не будет то этот коммит фиксируется как vm1: release 1.5a например (именно этот я собираюсь перезаписать, увы, обновились бинарники, жирно 30М лишних в репке держать).
Поэтому изменения надо забирать так:
На будущее - коммиты с тегами xxx: release x.x я буду стараться не изменять.Код:git fetch --all
git reset --hard origin/master
В итоге получится набор коммитов для нескольких проектов:
vm1: release 1.5a
vm2: release x.x
lsi: release x.x
vm2: release x.x
vm3: release x.x
vm1: working commit
lsi: working commit
PS. ВМ2 чуток позанимался, десяток ошибок в верилоге поправил, парочку на схеме, из сброса уже выходит, опрашивает блок прерываний, но следующую микрокоманду пока не стартует.