> На зайлинксах это есть уже долгое время. При этом во время реконфигурации
> остальная часть чипа продолжает работать.По своему круто. Но тут вопрос кто еще так умеет. Не окажется так что это только 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 - это вероятно "сложно" но не "невозможно".
Айти забавная штука. Тут почти нет "невозможно". Но иногда оказывается "нецелесообразно". Однако особо упертые индивидуалы все равно могут всем назло сделать "невозможное".
Вариант для распечатки
