Как стать автором
Обновить
3
0.1

Пользователь

Отправить сообщение

Во времена Alpha (середина 1990-х) эти трюки не считались важными, дизайнеры их не использовали, и это вероятно главная причина, почему Alpha жрала больше чем могла бы для своей частоты и техпроцесса.

Clock-gating в какой-то форме всё же был в Alpha. Есть статейка интересная на тему устройства клоков в этих процессорах (в открытом доступе тоже гуглится).

2) Почему они сказали что сделать low-power невозможно, они про их конкретную микроархитектурную реализацию?

Имхо, Alpha очень богата трюками, даже слишком. Мне кажется, проблема с переделкой Alpha в том, что многое на самом низком уровне (та же сеть клоков) рождено своими кустарными алгоритмами до нормальных EDA. Эти алгоритмы порождают серию допущений и предположений, на которых строится вся дальнейшая реализация. Поэтому возможно на других допущениях такая производительная вещь не соберётся.

Кроме того, этот процессор многими вещами заточен на высокую производительность, есть ощущение, что его целиком выстрадали под эту цель, на всех уровнях. Переделка под другие цели даст что-то среднее.

 Множество контактов напоминает HBM память, которая толком не прижилась за более чем 10 лет. Всё из-за большого процента брака и отвалов.

Наверно поэтому её сейчас постоянно ставят в топовые роутеры и GPU, которые на наших глазах творят революцию в ИИ.

Полезная инфа, спасибо!

Лично я не знаю традиционного криптохеша, который мог бы принимать данные каждый такт.

В примере из Электроникса, насколько понимаю, ограниченная постановка: хэшируют блоки фиксированной длины 64 байта, а не произвольной.

Интересная инфа, спасибо!

Круто! Если не секрет, какие получились характеристики: сколько оно заняло по ресурсам (ПЛИС), на какой частоте, какую производительность в МБ/с имеет?

время эксплуатации изделия превышает время поддержки конкретного микроконтроллера

Кстати, в недавнем анонсе Spartan Ultrascale+ (достаточно бюджетной плисины) Xilinx акцентировала внимание на 15+ годах поддержки своих моделей.

Разговор про ничтожную стоимость ошибки, как в программировании. 

Но вот издержки должны учитываться и не следует убеждать начальство, что они ничтожны))

Также должны учитываться издержки на 1 итерацию и скорость итераций, как быстро может быть получена ценность. FPGA по этим критериям позволяют приблизиться к гибким методологиям в софте, получать рабочие промежуточные результаты, адаптироваться к изменениям в требованиях и тестировать в приближенных к реальным условиях. Частые итерации позволяют снизить стоимость ошибки и уменьшить требования к кадрам.

Насколько понял, Catapult где-то тогда разделился на ветку ускорителей ИИ Brainwave и ветку прочих ускорителей для Azure. Brainwave что-то исследовали, поначалу что-то получалось, но сейчас уже всё, уступили место GPU. В Azure ускорители ушли зарабатывать деньги в продакшн, поделившись ещё на какие-то ветки. Одна, Azure Boost примерно соответствует функциональности Catapult и здравствует до сих пор, но про исследования не слышно.

Если плис используется в более менее сложной массовой аппаратуре, то даже на тестирование этой аппаратуры уходят существенные ресурсы - автоматизация, симуляция, помещение, стойки, логи, люди. Ошибка требует исправления, верификации, и, как правило, полного цикла тестирования перед выводом в релиз, это меняет графики текущей разработки, сдвигает сроки.

И всё же цена ошибки получается на порядки меньше цены ошибки для ASIC-ов, не правда ли? Ведь не требуется делать респин, выкладывая за это очередные миллионы долларов и месяца времени ожидания. Время обратной связи, имхо, критический фактор, в случае FPGA респин занимает от пары минут до нескольких часов. NRE существенно меньше в случае FPGA даже для сложной массовой аппаратуры, вот пример, где Microsoft делится своими восторгами по поводу скорости разработки хардвера, которая была у них при использовании FPGA. Их начинку Azure-карточек на всех стадиях делала команда из 5 FPGA-шников и горстки программистов.

Интересно, что такое люди пилят на этих микросхемах по 10k$ за штуку?

Акселераторы для датацентров, быструю финансовую аналитику для всяких банков и ведомств, акселераторы для некоторых задач HPC, некоторую прочую графовую аналитику, некоторые сетевые вещи, базовые станции для 5G, ускорители видеостриминговых сервисов (Twitch не так давно девайсы Xilinx массово для этого закупал) и т.д. Всё, что требует быстрого выхода на рынок, имеет неустоявшиеся/меняющиеся требования, и высокие требования по производительности при низкой задержке.

 И вместо экономии на логистике - возникает увеличение затрат, т.к. произведенные в Штатах чипы нужно будет везти назад в Азию, собирать изделия и везти обратно. 

Импортозамещение в США затеяно потому, что чипы для их военки и прочего national security делают другие страны. США хочет перенести такое чувствительное производство себе. Поэтому везти в Азию не придется, ведь военные производства, потребители этих чипов, расположены в США.

AMD, скорее всего, не будет использовать чиплетную компоновку, поскольку для перехода на эту технологию необходимо затратить дополнительные ресурсы, и немало.

AMD вовсю использует чиплеты, в предложении имелся ввиду Apple?

 Но как мне кажется в архитектуре Плис этого нет, но наверное можно запрограмировать такую функцию если необходимо и использовать, так как конфигурация организации массива памяти позволяет этоорганизовать разработчиком

Во многих архитектурах ПЛИС в каждой брамке есть блок ЕСС. Скрин из мануала на брамки Xilinx:

Для начала хотелось бы выделить два основных свойства внутренней памяти ПЛИС

Важное свойство брамок low-latency доступ. Про это вспоминают всегда, когда проектируют устройства с большими требованиями к памяти и решают, что оставить в ПЛИС, а что держать в DDR и т.д. Ещё одно важное свойство -- высокий параллелизм. Ведь брамок на кристалле может быть сотня или тысяча, у каждой свои независимые порты (или порт), и при желании можно обращаться к каждой в каждом такте.

Насчёт свойства удобства, имхо, это что-то неизмеримое.

Да, видим, что каждый наш модуль занял по 1 M9K, но задействовал не полностью и я пока не встречал, чтобы Quartus автоматических оптимизировал такое использование внутренней памяти ввиду её архитектуры.

Синтезатор не умеет читать мысли. Ресурс памяти -- это не только про объём, но и про использование портов в том числе во времени. В данном случае проектировщик знает свой проект и то, что может безболезненно уменьшить производительность системы в 4 раза (ведь было 4 независимых буфера, а остался один), а синтезатор этого угадать не может. Если это знание отразить в коде, возможно, синтезатор приятно удивит.

Для чего хороши ПЛИС

Также ПЛИС хороши для применений, где спектр выполняемых задач не очень чётко сформулирован, не устоялся или быстро изменяется. Например, так FPGA-акселераторы заняли свою нишу в датацентрах. Там было много разнородных задач, которые требовалось ускорить, но непонятно в каких пропорциях (пропорции ещё и изменялись с течением времени, а также в зависимости от локации и т.д.). В некоторых случаях тиражи составляли миллионы таких акселераторов, а бюджет -- миллиарды долларов. Другим таким применением стали базовые станции 5G, где параметры обработки сигналов, алгоритмы предобработки и прочее меняются быстрее и чаще, чем есть возможность и экономическая целесообразность выпускать под это ASIC.

В интернете довольно много примеров для ZynQ, Artix, меньше для Spartan, а вот по Kintex я нашел крайне мало информации, так что пришлось проводить параллели с примерами для других плат и пытаться опытным путем найти подходящее решение.

Kintex просто более дорогая и мощная серия плисин. Не по карману многим хоббистам, поэтому не попадает в туториалы. Если что-то сходится и работает на Artix, то предполагается, что оно точно сойдется и будет работать на Kintex.

И это как раз те программные комплексы, где писать скрипты - себе дороже и проще использовать GUI.

Без скриптов не получится CI. Не сможете погонять регрессионные тесты. Со скриптами какой-нибудь Jenkins раз в сутки будет собирать ваш проект и гонять полсотни тестбенчей в автоматическом режиме, а затем рисовать какую-то красивую статистику по этому поводу.

Крутой замысел, респект!

Именно это я имею ввиду. Именно об этом-то я и толкую. По сути, опыт, нормальный опыт (а не вышеприведённый "киньте 22 пФ и всё починится") опирается исключительно на документацию. Кто больше знает больше документации, тот более опытен - всё просто.

Не соглашусь. Вот например корка имеет два варианта интерфейсов X и Y. Среда генерит корку под Х нормальную, а под Y -- с неправильным направлением одного порта. По документации -- всё норм, корке без разницы с какими интерфейсами её юзают. А по факту Y в этой версии использовать нельзя. Если точились на него -- переделывайте.

Или корка генерит неправильную обёртку, заменяет STD_LOGIC порты на STD_LOGIC_VECTOR(0 downto 0). Вляпавшись в это ранее, опытный человек уже будет знать, что обёртку можно исправить и всё будет работать. А не зная, первый раз придётся до этого дойти. Доки опять молчок про это.

1
23 ...

Информация

В рейтинге
2 969-й
Зарегистрирован
Активность