> На зайлинксах это есть уже долгое время. При этом во время реконфигурации
> остальная часть чипа продолжает работать.По своему круто. Но тут вопрос кто еще так умеет. Не окажется так что это только 1 производитель умел и теперь все жестко завязано на него?
> А производители FPGA-то и не знали! Поэтому в некоторых FPGA с завода
> идут нереконфигурируемые готовые блоки с контроллерами памяти, распространёнными
> интерфейсами и ARM-ядрами. На самом деле зависит от цели.
Я думал вы про внешний чип. Внутри это лишь IP-блок. Ничему не противоречит, но вот ASIC выпускать как раз не требует.
> FPGA - это основа для своей числомолотилки. А ей надо взаимодействовать с внешним миром.
> У моей идеи цель - универсальная плата в каждый компьютер, способная
> не только заменить и превзойти GPU, но и заменить многое другое,
Вообще чипсеты AFAIK на FPGA вроде и прототипят порой. Правда это не платы. Они между процом и IO скорее. И дают процу новые возможности по (довольно шустрому) IO, при том до некоторой степени реконфигурируемому.
Однако когда выходит новый стандарт - вон то в его электрические спеки может вписаться. А может и нет. Без гарантий.
> требующее сейчас специализированных железок, и обновляемая во многом через замену прошивки
> вместо покупки нового устройства.
Специализированные железки все же эффективнее, by design. И в целом generic решение обычно сложнее сделать. Особенно чтобы потом не вылезло ограничений.
>>надо что-то как-то ремапить видимо
> В процессе синтеза и роутинга нужно учитывать карту дефектов.
Я не очень крутой эксперт по синтезу для FPGA но в например флешах - дефектлисты это гемор на всю голову, настолько, что в итоге RAW NAND стали предпочитать заменять на eMMC где это "счастье" делегировано отдельному процику и его фирмвари. Не случится что-то такое же, когда сложность возрастает настолько что никто не захочет с этим возиться?
> Коммутация не халявная, но регулируемая. Во-первых некоторую избыточность можно заложить
> на стадии проектирования FPGA, и она не пропадёт, её можно утилизировать
> в случае отсутствия дефектов.
Интересно. А чего из нее такого можно сделать в этом случае? Но вообще идея выглядит по своему круто. Был бы я прозводителем FPGA - взял бы этого анона в R&D, посмотреть насколько это (не)бред. Редко кто попадается с настолько необычными идеями.
> так, чтобы дефекты не мешали, то можно из простаивающих ячеек сделать
> обходные пути.
А это задержек разве не добавит? И как при этом синхронизация, максимальные частоты и проч будут себя ощущать? Тоже на фазе синтеза все это учитывать предлагаете?
> Чем меньше дефектов - тем меньше обходных путей нужно в среднем.
Более-менее практичные дизайны типа сабжа как я понимаю на FPGA гоняют близко к пределу возможностей для сколь-нибудь приемлимых скоростей. Если что-то такое огорошить таким изменением правил игры - уровень сложности не пробьет потолок? Но вообще - на лично мой вкус мне кажется что это одна из областей которые еще не исследованы в должном объеме.
> Соответственно, чем меньше дефектов - тем более универсален чип,
> и чипы с меньшим количеством дефектов можно продавать пожороже. То есть
> цена на каждый чип должна быть своя, а чипы - продаваться
> на аукционах.
Вообще в этой идее что-то есть. В принципе желающие нахаляву проскочить могли бы даже патчить свои дизайны чтобы в кривой "вот так" чип - лезло бы без проблем. Может производитедям просто не хочется спускаться до смертных настолько, черт знает.
> же L. Только тогда чипы нужно соединять - а это издержки,
> а соединения между чипами - это уязвимые места с точки зрения
> надёжности и узкие места с точки зрения роутинга. Поэтому лучше 1 чип.
На практике приходит к тому что выше некоего размера чипы дико дорогие, и это не лечится. Если даже каждый второй чип поражен дефектом и выкинут - окей, но половина пригодна к продаже, придется поднять цену но есть что продавать. А если они были крупнее и акрыло все чипы - упс, выход около ноля. Продавать нечего. Хотя с fault tolerant дизайном - вообще, это какое-то не очень изведанное измерение.
Чипмейкеров это тоже не радует, они и опробуют всякие промежуточные сценарии, типа мультичиповых сборок на interposer. Где технологии кремниевые и можно что-то крутое, типа 4096-бит шин раскидать. Видимо идеальных решений нет и еще есть что улучшить. Получается ессно круто но - опять же дорого.
> Нужно уменьшать не стоимость чипа путём уменьшения чипа (мы не можем уменьшить
> чип, он будет большим), а уменьшать стоимость чипа путём увеличения количества
> пластин с чипами и размазывания издержек по большему числу пластин, и
> увеличения площади пластин, но тут уже проблемы будут.
Ну тут уж упс, за раз делается - вот столько. Времени на процесс - вот столько. Чем больше с "забега" получилось - тем дешевле чип. Если за раз условно 10 чипов vs 100 чипов, 100 чипов имеют предпосылки стоить примерно в 10 раз меньше. За то же время с теми же процессами их получилось в 10 раз больше. Поэтому дешевые чипы с большим кристаллом - упс, так вроде не бывает.
> Там не ремап, там в ходе синтеза вентили мапятся на ячейки. Всегда.
> С учётом ограничений, таких как задержки. То, что некоторые ячейки нельзя
> использовать и надо отключить - это такое же ограничение.
Вообще вроде звучит разумно. Интересно, никто не хочет этого анона в R&D какого-нибудь FPGAшного вендора нанять? Будет довольно тупо если эти идеи окажутся не исследованы. Может сами черканете кому из них? Чем черт не шутит. Вы кажется очень неплохо разбираетесь в inner working этого добра. Во всяком случае это первый анон на этом глобусе давший мне такой годный мастеркласс по теме.
> Скажем так, расчёт роутинга - это далеко не халявная задача сама по
> себе, это NP-сложная задача.
Оптимизация программ IIRC в принципе тоже, но если немного срезать углы...
> Я выше приводил примеры. Алгоритмы, реализованные в виде схем для FPGA обычно
> производительнее и энергоэффективнее, чем реализованные программно для GPU.
В каком-то роде принимается, памятуя о истории SHA256... только потом ASIC пришли и дали всем мастеркласс на тему эффективности. А кроме счета SHA256 от них ничего и не требовалось и то что они именно ASIC всем как бы и норм. GPUшки то остались полезны для других вещей.
> Конкретно в майнинге так было. Нет оснований считать, что для шейдеров будет по-другому.
Майнинг все же специфичная штука: 1 алго, фиксированый, несложный и надо макс. скорость любой ценой. Реконфигурацию опосля и тем более на ходу не надо.
> Плюс FPGA открывают возможности, которые для GPU недоступны в принципе,
> такие как SDR или высокоскоростные аппаратные протоколы.
There's no such word as impossible.
1) На RasPI через GPIO сделали миниму FM TX - а по моему и 433MHz OOK даже (радиопультики и проч). Just because they can. Ессно все софтом. Там есть способы оооооочень быстро махать лапами GPIO. Это "direct synth", похабный, зато из подручного гамна за копейки. Чем и круто.
2) Лично я экспериментировал с STM32+DMA и в конце концов нашел апнот от STMicro как делать параллельную шину юзая GPIO, таймер и DMA автомат. И TX-side и RX side. И если туда DAC/ADC на ...цать MSPS подвесить... когда нельзя но очень хочется, можно и почти на вашем поле немного поиграть :). У более жирных внешняя шина есть хардварно, там какой DAC/ADC можно почтенно прокачать, используя все тот же DMA и таймер. В STM32 DMA похрен куда писать/что читать и это дает довольно много "странных" возможностей, в том числе и по части синтеза странных протоколов. Правда все же не настолько быстрых как вон то.
3) На самом деле у меня есть нечто весьма угарное. Проц и проводок к лапке. А воооон там, через весь дом, его коллега - ловит это. Деталей не будет, скажу лишь что в силу маргинальности такого "передатчика" пришлось сделать оооочень забавный формат сигнала.
4) Никогда не видели MIPI DSI сделаный из SPI ESP32 при помощи делителя напряжения и одного триггера? Знаю где такое есть. Конечно полные скорости оно не будет, и в 1 сторону, но иногда это и не надо, если у панели RAM набортный есть то те бандвизы и не требуются. И там сложнее всего как раз понять какая из панелек под такой финт годится. Иные реализации потребовали бы FPGA с специфичными драйверами - и это были бы совсем другие бабки.
> То есть представь, что чтобы у тебя в компьютере появился последний Thunderbolt
> или новый "аппаратный" декодер тебе бы не новый компьютер покупать пришлось,
Боюсь что по электрическим спекам оно бы много где не пролезло. Ну вот допустим я хочу отрастить себе пусть тот же MIPI DSI. А там - тыдыщ - уровень сигналов довольно специфичный. Generic железо сделаное без этого интерфейса в уме - врядли сможет ЭТО изобразить.
Из FPGA это сделать можно. Из некоторых. Если вы заранее условиились что делаете вот это и правильно развели все, и вольтажи подходящие есть. А вот заранее ДО выпуска спеков протокола в generic железе - можно и обломиться это ОПОСЛЯ сделать на СУЩЕСТВУЮщЕЙ разводке. Даже если перераскинув ее оно и получится - но вот кто ж заранее знал что вон то будет вон так?
А как вы представляете себе "произвольные" драйверы линий, что дифференциальные что single ended с "произвольными" вольтажами, чего доброго несколько разных на пин, разведенное "в количестве" и чтобы это не стоило как самолет потом? И откуда возьмутся нужные разъемы?
> а всего-лишь нетлист/исходник скачать и отроутить конкретно под твой FPGA
> (автоматически, писать самому код на верилоге не обязательно). Но сейчас
> большие FPGA золотые и позволить себе их могут немногие.
Ну я как бы немного в курсе "продвинутых" интерфейсов и догадываюсь что "generic" электрические моменты - это боль. Ну вот диф пара. А что если вон там номинальное волновое сопротивление одно, а вон там - другое? Это программно не решается - вопрос топологии печатки.
При том это все актуально для почти всех скоростных и-фейсов, наверное у части можно что-то общее нащупать но далеко не 100%. На правах мечты - это офигенно, но я туго представляю себе практическую реализацию. Даже на уровне "и как мы роутим печатку?!"
> Ну суть предложения от этого не меняется. Есть исток, есть сток, есть
> конвеер без всякого предсказания ветвлений и ненужной для конкретного применения сложности.
Ну как, постепенно немного сложности добавили сделав чуть более похоже на обычные CPU. Скажем совсем без усложнений - VLIW было мучительно програмить. Пришлось фронтэндов поставить и сделать CU с группами ALUшек и wave (у нвидии вроде что-то сравнимое, они это warp называют).
> Только сдаётся мне, научить машину автоматически бить шэйдеры на куски так,
> чтобы оптимально задействовать ресурс FPGA, и выбирать интерфейс между набором команд
> и netlist-реализованными блоками может быть очень нетривиально.
Ну как бы шейдеры изначально все же программы. Хотя учитывая что вооооон тот кодек AV1 транслируют через HLS - это вероятно "сложно" но не "невозможно".
Айти забавная штука. Тут почти нет "невозможно". Но иногда оказывается "нецелесообразно". Однако особо упертые индивидуалы все равно могут всем назло сделать "невозможное".
