Comments 23
В смысле "как там"? Микроэлектроника в Российской Федерации переживает бум у молодежи. Регистрации на семинары в 2022 году бьют рекорды 2021 года. Конечно есть проблема, что из России ушли Synopsys, Cadence и Mentor Graphics, но для обучения ASIC design вместо их софта можно использовать открытые тулы - Open Lane. Если еще и российcкое государство и корпорации реализуют аналог партнерства Google + Skywater, при котором Google отбирает лучшие проекты сделанные с open source EDA tools и бесплатно изготавливает из на фабе Skywater - было бы вообще зашибись. Типа если бы скооперировался Yandex и зеленоградский Микрон.
Открытые тулы:
Программа Google + Skywater. Caravel - это template для SoC с служебным RISC-V процессором:
Публичные проекты, предложенные Гугло молодежью:
Ядра имели собственную архитектуру под названием Epiphany и были оптимизированы под энергоэффективные вычисления с плавающей точкой. По микроархитектуре каждое ядро было суперскаляром с внеочередными выполнением инструкций (out-of-order – OoO).
В статье (по ссылке) немножко другая информация: The Epiphany includes is an in-order dual-issue RISC processor...
Ааааа, напутал, спасибо, перепроверю. В принципе in-order с такой архитектурой более логично, а суперскаляр он возможно несимметричный (типа целочисленные и floating point).
Хм, а в википедии написано "out of order":
https://en.wikipedia.org/wiki/Adapteva
"The Epiphany architecture could accommodate chips with up to 4,096 RISC out-of-order microprocessors,"
Поправил:
Основой технологии Adapteva была решетка из большого количества процессорных ядер внутри одной микросхемы. Ядра имели собственную архитектуру под названием Epiphany и были оптимизированы под энергоэффективные вычисления с плавающей точкой. По микроархитектуре каждое ядро было суперскаляром с двойной выборкой и последовательным выполнением (в википедии ошибка, она говорит, что Epiphany был суперскаляр с внеочередными выполнением инструкций (out-of-order – OoO). Это логично: in-order для энергоэкономного CPU примерно двое энергоэффективнее, чем out-of-order.
Основатель Adapteva Andreas Olofsson может быть известен российскому читателю как автор DSP процессора TigerSharс ( https://habr.com/ru/post/314986/ )
Я заранее извиняюсь, я всего лишь верификатор а не дизайнер, у меня вопрос) А не должен ещё присутствовать BVALID и BREADY в условии ?
И тогда наверно можно через case описать
Нет, не должен. Каналы AW и B в общем случае работают независимо - т.е. можно выдать 10 транзакций по каналу AW (адрес записи), друг за другом, потом выдать 10 транзакций по каналу W (данные для записи) , а получить 10 подтверждений по каналу B. Протокол AXI это не запрещает. Фишка тут в другом.
На мой взгляд , все хорошо написано. По сути здесь АРВ интерфейс. Я бы добавил еще и буфер для записи данных, а не только для адреса. Сигналы axi_awready и axi_wready по сути одно и тоже. Хотя, синтезатор может это подчистить. Вот только с axi_bvalid у меня не все понятно. Если представить, что S_AXI_BREADY не отвечает сразу, то возможен пропуск ответа. Но скорее всего здесь одиночные циклы обмена и тип обмена предполагает отсутствие начала нового обмена до полного завершения предыдущего. Так в чем фишка ? :)
В коде две проблемы. Во-первых, он не позволяет back-to-back транзакции - перед приемом одной вставляется пропуск минимум в такт, что уполовинивает пропускную способность канала. Об этом непосредственно предупреждает спецификация (см. ниже). Чтобы этого избежать, ready должен восприниматься как "не busy" / "не занято", сбрасываться при reset в 1 и потом устанавливаться в 0 только если устройство не может принимать больше транзанзакций:
Здесь тяжело судить , т.к. автор целенаправленно делает обмен в 2 такта. Возможно, у него такое ТЗ. Кто знает. Адрес буферизируется, данные нет. За такт в такой конструкции не запишешь. То, что готовность по умолчанию ноль, не есть хорошо, но нужно смотреть этот модуль в системе. Входящие достоверности адреса и данных очевидно разрешаются адресным декодером снаружи. Значит и выходная готовность будет разрешаться этим сигналом. А там уже итоговый уровень будет так, как Вы написали. Если подходить с точки зрения верификации, то нужны исходные требования. Тогда можно к чему-то придираться. А так вообще можно было готовности держать всегда в 1 и делать запись каждый такт, если мастер готов принимать ответы каждый такт. Но может есть какие-то ограничения в дизайне, не поддерживающие такой темп.
С точки зрения верификации:
* пассивный монитор транзакций должен поддерживать оба режима - он должен просто считывать адрес когда valid & ready
модель axi slave (reference slave) должен иметь опцию как на ready default 0, так и на ready default 1, а также на случайную ready (так тоже должно работать)
активный bfm драйвер со стороны мастера должен быть написан так, чтобы ему было все равно. Он должен немедленно драйвить новую транзакцию после получения (ready & valid) на posedge clk , кроме случая, когда сценарий тестирования предполагает пропуски между транзакциями.
модель axi slave (reference slave) должен иметь опцию как на ready
default 0, так и на ready default 1, а также на случайную ready (так
тоже должно работать)
По-моему, попахивает шизофренией случайно дёргать ready, когда valid=0. В скриншоте выше указано требование что valid если уж вскочил в 1, то и остаётся как минимум до соответствующего ready. Логично и на ready наложить такое же условие -- если уж вскочило в 1, то остаётся в 1 минимум до соответствующего valid.
Это может казаться вам логичным, но:
Требование к valid ("если уж вскочил в 1, то и остаётся как минимум до соответствующего ready") в спецификации есть, а вот требование к ready - нет и
Я вполне могу представить дизайн с таким "шизофреничным" поведением ready - например если в дизайне есть несколько axi портов, и транзакции с них используют внутренний общий ресурс (например общую очередь, которую можно переполнить транзакциями, которые идут из второго порта, пока на первом ничего не происходит).
По поводу (2) вы можете сказать, что перед таким общим ресурсом стоит сделать дополнительный буфер для каждого порта, но на самом деле возражение (1) достаточно: если в спеке органичения нет, то модель не должна такое ограничение вводить.
п.2 с запаркованными на 1 редями всё равно потребует внутренних буферов на каждом порту, по крайней мере если каждый такой ready будет выходом с флопа, а не комбинаторной кашей. Ну и в целом -- я ни в коем случае не спорю с спекой, просто считаю, что такое дополнительное требование на реди -- рационально. Облегчает жизнь c обоих сторон подобного интерфейса (имею в виду valid-ready).
Кроме этого в спецификации сказано в явной форме, что valid и ready несимметричны: valid не может ждать ready=1 перед переходом с valid=0 в valid=1. valid должен выставится (невзирая на ready) и стоять колом, пока на фронте клока не окажется valid=1 и ready=1 - а потом или продолжить стоять, уже для другого трансфера, или сняться в valid=0.
А вот ready может ждать valid=1, хотя это не рекомендуется (лучше если ready по умолчанию 1 и становится 0 только когда устройство занято / busy):
Никакого текста, запрещающего ready ходить ходуном пока valid=0 в спецификации нет.
Юрий, спасибо за заметку.
Фрагмент кода, который вы вынесли в заголовок, генерируется софтом от Xilinx автоматически при создании нового IP c AXI. Непосредственно код Азамата начинается примерно с 677-й строки в том исходнике.
" Что в заметке показалось вам занимательным? "
Мне показалось наиболее занимательным, что приведены настоящие имена героев разработки! Страна должна знать своих героев!
От Шёлкового Пути — to the Road to Silicon: в Средней Азии есть RTL-дизайнеры