Комментарии 8
Статье не хватает вейвформ симуляции и ресурсоъёмкости именно вашего кода.
Нечасто вижу использование переднего фронта асинхронного сброса вместо заднего. Исторически так сложилось?
А в остальном спасибо за статью.
Нечасто вижу использование переднего фронта асинхронного сброса вместо заднего. Исторически так сложилось?
А можно развернуть намёк на предпочтение использования заднего фронта асинхронного сброса в утверждение с обоснованием? Желательно со ссылками. Как я понимаю, такое предпочтение выросло из особенностей техпроцессов на заре развития микроэлектроники. Но зачем этого правила придерживаться сейчас при разработки IP?
Вопрос не полемики ради, ответ «так принято в коммерческой разработке, вот ссылка на гайд одного крупного игрока рынка, вот второго, вот третьего» меня более, чем устроит. Ну, или хоть какие-то отсылки, где можно поискать такие данные. Я не настоящий сварщик, а любитель, который играется с FPGA (как с синхронными, так и с асинхронными схемами) лишь ради собственного интереса, но мне интересно как оно в индустрии.
Небольшое уточнение: меня интересуют правила взаимодействия между модулями, а не внешние интерфейсы — от ножки до модулей сигнал всё равно пройдёт через дерево сброса и один лишний инвертор в корне дерева вообще ничего не стоит.
А можно развернуть намёк на предпочтение использования заднего фронта асинхронного сброса в утверждение с обоснованием? Желательно со ссылками. Как я понимаю, такое предпочтение выросло из особенностей техпроцессов на заре развития микроэлектроники. Но зачем этого правила придерживаться сейчас при разработки IP?
Вроде как это девайсозависимо. Например в гайдах для ПЛИС Xilinx предлагают максимально воздерживаться от использования асинхронных ресетов да и в целом ресетов, а если ресетов не избежать, то они должны быть active-high, иначе доп. инвертер ухудшит прозводительность (с. 76 этого гайда).
воздерживаться от использования асинхронных ресетов
Вопрос был задан в контексте асинхронного сброса и даже подчеркнул, что имеется ввиду именно асинхронный сброс. И мой вопрос общий, не только про FPGA, CPLD, но и про ASIC. Да и для FPGA при пересечении clock domain сброс на входе всегда асинхронный, пока его явно не синхронизировали.
В документе по вашей ссылке Xilinx забыли сказать, что они имеют ввиду Global Reset и что триггеры в их логических ячейках то ли умеют только GR по переднему фронту, то ли вообще умеют только синхронный сброс по высокому уровню. Скорее второе. Локальный сброс проходит через LUT и для быстродействия фиолетово, высокий или низкий уровень выбран в качестве активного.
Если не ошибаюсь, в Xilinx CPLD триггеры умеют и синхронный (сброс в data path), и асинхронный сброс и какой уровень хочешь активным (сигнал через 2XOR проходит со вторым входом на бите конфигурации).
Если мы перейдём к ASIC, то, вероятно, выбор будет ограничен доступной библиотекой.
Так что, я соглашусь с первым вашим предложением: видимо, это до сих пор зависит от технологии/платформы. Но тема не раскрыта: я спрашивал про намёк на предпочтение использования заднего фронта асинхронного сброса
В документе по вашей ссылке Xilinx забыли сказать, что они имеют ввиду Global Reset
Откуда эти догадки? В Xilinx 6, 7 серии и в ульраскейлах например умеют и в асинхронный set/reset и не только лишь Global.
Локальный сброс проходит через LUT и для быстродействия фиолетово, высокий или низкий уровень выбран в качестве активного.
Почему вы так думаете? В 6 и 7 сериях например они не проходят через LUT, а являются входом CLB. Очевидно, что инверсия вносит доп. задержку в таком случае.
И мой вопрос общий
Имхо, на него нет общего ответа, что вам и продемонстрировано для кейса FPGA популярного вендора.
Долго смотрел на самый первый пример — и не понял: где содержимое (без компресиии) первой кэш-строки, где — второй. Просто содержимое — без сигналов, без служебных бит. Где base, где — delta для первой, где — для второй.
Мне могло бы помочь формальное описание алгоритма — я бы мог попробовать с ним сопоставить отрывочные данные из примеров — но его я тоже не увидел.
Короче, в такой форме статья — она для меня оказалась бесполезна.
А жаль.
Если я правильно понял ваш вопрос, то вот вам ответ. Примеры, которые там были, лишь представлены для демонстрации того, как происходит сжатие. Они не отражают принципов хранения этих строк в кэш-памяти вообще. Ответ на ваш вопрос: "где содержимое" - в данных примерах нигде. Сама реализация была описана после данных примеров. В кратце смысл такой: буфер чтения, равный 128 байт полезной информации, сжимается по этому алгоритму. Затем сжатые данные с буфера записываются в кэш-строку. Вот так. У исходной кэш-строки нет ни базы, ни дельты. Её содержимое разделяется на равные сегменты. Нулевой сегмент сохраняется в исходном объеме, это становится базой в сжатой строке. В этой же сжатой строке после базы идут дельты. Нулевая дельта - разность базы и нулевого сегмента, первая дельта - разность базы и первого сегмента. Дельты по объему получаются меньше, чем исходные сегменты, поэтому конечный объем меньше, чем исходный
Реализация кэш-компрессии по алгоритму base+delta