Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 56
Ну самые современные FPGA умеют конфигурироваться и по PCIe при желании. Но вот переключать их конфигурации просто при смене выполняемой задачи это все же нетривиально — надо ведь не только конфигурацию хранить, но и состояние всех внутренних ресурсов. Может к этому когда и придет, но тут нужна более плотная интеграция с ядром процессора. Ну и сама «конфигурация» FPGA должна быть либо стандартаризована для всех процессоров либо надо осуществлять прекомпиляцию при первом запуске ПО (типа как какие-то текстуры генерятся в ряде игр для каждого видеоадаптера).
Про реализации Жизни на FPGA — чисто теоретически в указанный кристалл (10000 логических элементов) может влезть порядка 3000 клеток. Объяснение простое — каждая клетка берет информацию от 8 соседей, т.е. надо реализовать логическую функцию от 8 аргументов. Внутри логических элементов (этой FPGA) использованы 4-входовые таблицы перекодировки (LUT4). Т.е. на каждую клетку выходит 3 LUTa. Может быть оптимизациями логики можно повысить эффективность, но сразу не сообразить, а думать лень. Плюс накладные расходы на ввод-вывод. Возможность читать и писать состояние каждой клетки извне, тоже, кстати, сильно влияет на расход ресурса.
Про реализации Жизни на FPGA — чисто теоретически в указанный кристалл (10000 логических элементов) может влезть порядка 3000 клеток. Объяснение простое — каждая клетка берет информацию от 8 соседей, т.е. надо реализовать логическую функцию от 8 аргументов. Внутри логических элементов (этой FPGA) использованы 4-входовые таблицы перекодировки (LUT4). Т.е. на каждую клетку выходит 3 LUTa. Может быть оптимизациями логики можно повысить эффективность, но сразу не сообразить, а думать лень. Плюс накладные расходы на ввод-вывод. Возможность читать и писать состояние каждой клетки извне, тоже, кстати, сильно влияет на расход ресурса.
Я то же так думал, но потом реализовал загрузку и чтение таблицы и размер сильно вырос…
Вы считаете, что любую функцию от 8 переменных можно реализовать при помощи трёх 4-входовых LUT'ов?
Какой коварный вопрос ;)
Нет конечно, думал о чем-то совсем другом, прекрасном, когда писал.
На самом деле, для того варианта о котором я думал надо 5 лутов: Две пары по входу дают полусуммы по одной и второй четверке, пятый компаратор проверяет общий результат.
Как выяснилось, я несколько подзабыл правила и аргументов должно быть 9 (надо считать и саму клетку), так что получается 6. Но это надо вдумчиво писать руками.
Чтобы реабилитироваться — немного побаловался с синтезатором квартуса. Если делать в лоб, как автор, то получается как раз-таки около 20 лутов. Если сделать какое-нибудь подобие дерева сумматоров, то выходит 9 лутов.
Нет конечно, думал о чем-то совсем другом, прекрасном, когда писал.
На самом деле, для того варианта о котором я думал надо 5 лутов: Две пары по входу дают полусуммы по одной и второй четверке, пятый компаратор проверяет общий результат.
Как выяснилось, я несколько подзабыл правила и аргументов должно быть 9 (надо считать и саму клетку), так что получается 6. Но это надо вдумчиво писать руками.
Чтобы реабилитироваться — немного побаловался с синтезатором квартуса. Если делать в лоб, как автор, то получается как раз-таки около 20 лутов. Если сделать какое-нибудь подобие дерева сумматоров, то выходит 9 лутов.
Не, не 6 — 7 надо минимум.
У меня реализация xcell.v занимает минимум 9 LUT'ов.
Не поделитесь своей? :)
Не поделитесь своей? :)
А поделитесь реализацией на 9 LUT'ов? Как получить меньше 20?
Вот моё на 7: (серые блоки не считаются, потому что повторно используются)
Увы, меньше 8, похоже все-таки никак. Да и то пришлось хитрый трюк задействовать — использовать асинхронный ресет триггера. ASIC-овцы скривятся, а мы скажем: «Похер, халява!» ;)
Да простят меня за кривой полуночный код. Можно написать компактнее, но не сегодня…
Да простят меня за кривой полуночный код. Можно написать компактнее, но не сегодня…
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity life_cell is
port (clk : in std_logic;
neighbor : in std_logic_vector(7 downto 0);
state_out: out std_logic);
end entity life_cell;
architecture rtl of life_cell is
signal state : std_logic := '0';
signal sum1s, sum2s : unsigned(2 downto 0);
signal sum : unsigned(3 downto 0);
begin
process(neighbor)
variable sum1, sum2 : unsigned(2 downto 0);
begin
sum1 := "000";
sum2 := "000";
for i in 0 to 3 loop
if neighbor(i) = '1' then
sum1 := sum1 + 1;
end if;
end loop;
for i in 4 to 7 loop
if neighbor(i) = '1' then
sum2 := sum2 + 1;
end if;
end loop;
sum1s <= sum1;
sum2s <= sum2;
sum <= resize(sum1,4)+resize(sum2,3);
end process;
process(clk, sum1s)
begin
if sum1s(2) = '1' then
state <= '0';
elsif rising_edge(clk) then
if sum2s(2) = '1' then --or sum1s(2) = '1'
state <= '0';
else
if (sum = to_unsigned(3,4)) or (sum = to_unsigned(2,4) and state = '1') then
state <= '1';
else
state <= '0';
end if;
end if;
end if;
end process;
state_out <= state;
end;
Интересная задумка! ОС могла бы сама на своем уровне переконфигурировать такое устройство в зависимости от требований процессов. Например, смотришь кино — она загружает схему декодера и т.д.
Хотя больший профит наверное будет, если сам разработчик будет на низком уровне конфигурировать такое устройство для выполнения своих специфических операций. Правда, не знаю что делать, если приложений, которые используют устройство будет несколько, на сколько будет затратно переключать контекст.
Хотя больший профит наверное будет, если сам разработчик будет на низком уровне конфигурировать такое устройство для выполнения своих специфических операций. Правда, не знаю что делать, если приложений, которые используют устройство будет несколько, на сколько будет затратно переключать контекст.
Есть «небольшая» проблема. Писать что то для FPGA не так просто как кажется, грубо говоря это и не програмирование, а описание устройства текстовым способом. Конструкции похожи, но это ещё больше запутывает. И даже что то написав под FPGA и отдав это системе нужно ещё написать драйвер который поймёт как с этим работать, написание дров тоже процесс не простой. В итоге нужно делать два непростых дела. А через пол года вышел новый процессор, и спокойно компенсировал все эти заморочки повышенной частотой/ядерностью.
На Сyclone II по ощущением конфигурация считывается около секунды. Так что единственный вариант, эксклюзивный доступ, либо несколько «схем» на один чип грузить а внутри их как то коммутировать и уже ОС довать к ним доступ.
Правда, не знаю что делать, если приложений, которые используют устройство будет несколько, на сколько будет затратно переключать контекст.
На Сyclone II по ощущением конфигурация считывается около секунды. Так что единственный вариант, эксклюзивный доступ, либо несколько «схем» на один чип грузить а внутри их как то коммутировать и уже ОС довать к ним доступ.
Удел FPGA в данном случае — моментальная специализация под частное решение, которое вряд ли найдет поддержку в общем ядре (в ближайшее время). Тот же AES — сколько его там считали на общем CPU пока Intel не добавил в соответсвующую логику в некоторые процессоры. А придумают новый алгоритм — еще 10 лет ждать. Понятно, что это эффективно в первую очередь в том случае, если происходят активные вычисления.
Подобное решение, кстати, хорошо реализуется в процессоре NIOS, имплементируемом на кристаллах Altera. Там можно прямо в АЛУ процессора добавить свои собственные команды, реализующие собственную логику/алгоритмы под конкретную задачу. И дальше вызывать их из программы как обычные функции, по сути.
Подобное решение, кстати, хорошо реализуется в процессоре NIOS, имплементируемом на кристаллах Altera. Там можно прямо в АЛУ процессора добавить свои собственные команды, реализующие собственную логику/алгоритмы под конкретную задачу. И дальше вызывать их из программы как обычные функции, по сути.
Вы немного не правы, в статье обсуждается не использование DE5-Net иже с ней, а некое логическое продолжение этой платы.
Вспомните историю — сначала графику считали на проце, потом появились 3D ускорители, в которых появились шейдерные процессоры (которые требовалось программировать отдельно, кстати). И все начали программировать шейдеры и наслаждаться красивыми 3D играми, потом кому-то в голову пришло, что шейдерный процессор можно вполне запрограммировать на какую-нибудь не графическую математику, и в результате мы имеем GPGPU, и это настолько понравилось людям, что сейчас можно купить видеокарту, которая не умеет показывать видео, зато умеет быстро считать.
В статье упомянули, что Altera развивает стандарт OpenCL, а это как раз большой шаг в сторону описанного в статье устройства: пользователь запускает программу на OpenCL, и при наличии на борту FPGA-структуры из этой программы синтезируется схема, которая быстро и эффективно решит задачу. нет — посчитается на видео карте, там тоже ресурсов хватает, на крайний случай и CPU справится, правда не так быстро.
Вспомните историю — сначала графику считали на проце, потом появились 3D ускорители, в которых появились шейдерные процессоры (которые требовалось программировать отдельно, кстати). И все начали программировать шейдеры и наслаждаться красивыми 3D играми, потом кому-то в голову пришло, что шейдерный процессор можно вполне запрограммировать на какую-нибудь не графическую математику, и в результате мы имеем GPGPU, и это настолько понравилось людям, что сейчас можно купить видеокарту, которая не умеет показывать видео, зато умеет быстро считать.
В статье упомянули, что Altera развивает стандарт OpenCL, а это как раз большой шаг в сторону описанного в статье устройства: пользователь запускает программу на OpenCL, и при наличии на борту FPGA-структуры из этой программы синтезируется схема, которая быстро и эффективно решит задачу. нет — посчитается на видео карте, там тоже ресурсов хватает, на крайний случай и CPU справится, правда не так быстро.
Да, программировать быстро FPGA чертовский сложно, и мало людей вообще умеют это делать даже долго. Один из способов преодолеть это — сделать каркас приложения, включающий драйвер OS, интерфейсное ядро в FPGA (например PCIe или USB) и определить программные (на стороне хост-компьютера) и аппаратные (на стороне ПЛИС) интерфейсы для передачи данных между хостом и ускорителем FPGA. А само вычислительное ядро писать на языках высокого уровня типа C или OpenCL.
Тут в лидерах Altera — у них уже примерно с год как есть полноценная поддержка стандарта OpenCL для своих кристаллов с интерфейсом PCIe (драйвер, хост библиотеки и аппаратные ядра уже написаны, и прикладной разработчик использует документированную программную модель OpenCL). Xilinx в этом смысле отстает — у них пока из открытого и доступного есть только транслятор C-to-HDL называется Vivado HLS (бывший AutoESL), позволяющий довольно эффективно (есть оценки) перевести Си код в VHDL или Verilog, Но тут нет никакой системной поддержки, и драйвер и аппаратный интерфейс надо реализовывать самому.
Тут в лидерах Altera — у них уже примерно с год как есть полноценная поддержка стандарта OpenCL для своих кристаллов с интерфейсом PCIe (драйвер, хост библиотеки и аппаратные ядра уже написаны, и прикладной разработчик использует документированную программную модель OpenCL). Xilinx в этом смысле отстает — у них пока из открытого и доступного есть только транслятор C-to-HDL называется Vivado HLS (бывший AutoESL), позволяющий довольно эффективно (есть оценки) перевести Си код в VHDL или Verilog, Но тут нет никакой системной поддержки, и драйвер и аппаратный интерфейс надо реализовывать самому.
Мораль, — модель и средства программирования — основной фактор успеха. А удобной модели нет. HDL-и низкоуровневы до безобразия, уж аналог с++ шаблонов приделать могли бы. Трансляция из С — не верю, нельзя из локомотива напильником вертолёт выточить. OpenCL — и программировать трудно, и гибкость HDL теряется.
За неимение пока ничего лучше я ставлю все-таки на трансляторы. Много людей уже знают С, и если им дать удобный и настраиваемый каркас приложения, то они смогут на нем худо бедно программировать свои алгоритмы под FPGA. Другое дело, насколько это будет эффективно. Тут нужно только искать такие задачи, которые будут хорошо «ложиться» на FPGA.
Хорошая идея! Я, да и многие тоже задумывались об этом: плис, как сопроцессор.
Идея – «Жидкое ядро», меняем подход к вычислениям
Идея – «Жидкое ядро», меняем подход к вычислениям
Пока FPGA используется в качестве ускорителя вычислений только для одной задачи в одно время. Например у вас есть алгоритм из области биоинформатики или надо быстро посчитать покупать акции или продавать. Тогда если есть много денег и хочется побыстрее, то можно использовать FPGA ускорители. При этом если вы занимаетесь биоинформатикой, то врятли вы захотите запускать на том же компьютере финансовые задачи… Это я к тому, что на текущий день компьютеры с FPGA ускорителями — это не продукт широкого потребления типа GPU или Xeon Phi, и на них не запускают широкий спектр задач, а только ту, ради ускорения которой и покупался/строился этот очень дорогой компьютер.
Поэтому в том чтобы морочиться с выделением логических ресурсов плис каждому процессу на уровне ОС смысла сейчас нет, как нет и практических реализаций таких систем.
Были такие суперькомпьютеры от Cray
en.wikipedia.org/wiki/Cray_XT5
en.wikipedia.org/wiki/Cray_XD1
в которых в один из процессорных слотов на материнской плате на межпроцессорную шину сажался кристалл FPGA, расширяющий инструкции основного. Но, как мне сказал инженер Cray на одной выставке, народ этого не оценил, никто не покупал эти машины, и Cray свернул все свои дела с FPGA ускорителями.
Поэтому в том чтобы морочиться с выделением логических ресурсов плис каждому процессу на уровне ОС смысла сейчас нет, как нет и практических реализаций таких систем.
Были такие суперькомпьютеры от Cray
en.wikipedia.org/wiki/Cray_XT5
en.wikipedia.org/wiki/Cray_XD1
в которых в один из процессорных слотов на материнской плате на межпроцессорную шину сажался кристалл FPGA, расширяющий инструкции основного. Но, как мне сказал инженер Cray на одной выставке, народ этого не оценил, никто не покупал эти машины, и Cray свернул все свои дела с FPGA ускорителями.
По поводу описанного проекта — совсем очевидное замечание, но всё же напишу.
Если есть задача увеличить количество клеток, то не обязательно использовать ПЛИС большей емкости.
Можно просто уменьшить количество параллельных вычислений.
В крайнем случае можно хранить всё значения в блочной памяти и использовать только один вычислительный блок, который будет последовательно вычислять все новые значения для всех клеток.
Естественно, делать все вычисления за такт станет не реально, но я не думаю, что для Вашего проекта цель — это 100 млн. обновлений в секунду.
Дальнейшее развитие мысли — обратное увеличение параллельности, с использованием N вычислительных блоков, где 1 < N << количества клеток.
Если есть задача увеличить количество клеток, то не обязательно использовать ПЛИС большей емкости.
Можно просто уменьшить количество параллельных вычислений.
В крайнем случае можно хранить всё значения в блочной памяти и использовать только один вычислительный блок, который будет последовательно вычислять все новые значения для всех клеток.
Естественно, делать все вычисления за такт станет не реально, но я не думаю, что для Вашего проекта цель — это 100 млн. обновлений в секунду.
Дальнейшее развитие мысли — обратное увеличение параллельности, с использованием N вычислительных блоков, где 1 < N << количества клеток.
Для этого придется написать управляющее устройство в виде КА, которое в конечном итоге проще заменить процессором, а программу написать на С ;)
В каком-то конкретном случае — да.
В общем случае — зависит от количества вычислительных блоков, которые удастся реализовать в ПЛИС; частоте, на которой это всё заработает; емкости ПЛИС; частоте процессора; количеству ядер; стоимости компонентов и т.д.
Не уверен, что можно реализовать эту задачу на FPGA так, чтобы по соотношению производительность/стоимость вышло выгоднее, чем на CPU. Но допускаю это.
Почти уверен, что на FPGA можно сделать реализацию с большей производительностью, чем на CPU.
Точно уверен в том, что реализация на FPGA будет интересней :)
P.S. Пора заводить хаб, посвященный FPGA :)
В общем случае — зависит от количества вычислительных блоков, которые удастся реализовать в ПЛИС; частоте, на которой это всё заработает; емкости ПЛИС; частоте процессора; количеству ядер; стоимости компонентов и т.д.
Не уверен, что можно реализовать эту задачу на FPGA так, чтобы по соотношению производительность/стоимость вышло выгоднее, чем на CPU. Но допускаю это.
Почти уверен, что на FPGA можно сделать реализацию с большей производительностью, чем на CPU.
Точно уверен в том, что реализация на FPGA будет интересней :)
P.S. Пора заводить хаб, посвященный FPGA :)
Идея реконфигурируемых вычислений действительно весьма привлекательна, мне это представляется как супермаркет, перестраивающийся под текущий поток клиентов, то скажем, добавляя кассы, то убирая непопулярные полки. Но дело это нетривиальное: даже при наличии готовой схемы, её надо ещё как-то уложить на физическую топологию ПЛИС, это можно сделать заранее только для однозадачной системы, иначе будут конфликты за ресурсы.
Можно пофантазировать о применении клеточного автомата для локального конфигурирования ПЛИС, как-то так: в нашем супермаркете посетитель идёт вдоль ряда касс, если все кассы заняты, то он упирается в голову списка касс, где сидит генератор касс — специальная подпрограмма, способная к локальной модификации нашего супермаркета. Генератор создаёт для клиента новую кассу, если рядом есть свободное место.
Мне очень близка эта тема, сейчас пишу статью про свой реконфигурируемый компьютер.
Можно пофантазировать о применении клеточного автомата для локального конфигурирования ПЛИС, как-то так: в нашем супермаркете посетитель идёт вдоль ряда касс, если все кассы заняты, то он упирается в голову списка касс, где сидит генератор касс — специальная подпрограмма, способная к локальной модификации нашего супермаркета. Генератор создаёт для клиента новую кассу, если рядом есть свободное место.
Мне очень близка эта тема, сейчас пишу статью про свой реконфигурируемый компьютер.
А я то же все время про реконфигурируемый компьютер думаю…
FPGA очень много жрут электроэнергии, просто неимоверно много. Поэтому их применение всегда будет очень ограниченным. Как мне кажется, индустрия движется в сторону гетерогенных систем, т.е. противоположную от реконфигурируемых. Проще добавить в систему десять модулей, каждый из которых делает что-то свое (не исключено, что с некоторой степенью свободы, т.е. это может быть специализированный процессор), и отключать ненужные для экономии энергии. Транзисторы нынче дешевы.
FPGA за ненадобностью тоже можно отключить, как и остальные не нужные в данный момент компоненты системы. Надо будет ради эксперимента сравнить сколько энергии жрут на одинаковых задачах FPGA и CPU, при условии что задача распараллеливается и вообще эффективно реализуется на ПЛИС.
Да, относительно ASIC-ов ПЛИС-ы жрут. И тем не менее, их активно используют. Про реконфигурируемые говорить сложно, поскольку их ещё нет, но можно ожидать, что у них будут свои задачи, на которых они будут достаточно энергоэффективны.
Тут вы не правы. Все как раз наоборот. Если сравнивать потребление на реальных задачах, то FPGA бьют и CPU и особенно GPU. Есть такой параметр GFLOPS/WATT, так вот он для FPGA всегда высок.
Из доказательств смог быстро найти только это
docs.google.com/viewer?url=http%3A%2F%2Fwww.gstitt.ece.ufl.edu%2Fcourses%2Fspring13%2Feel4712%2Flectures%2Ffpga130-fowers.pptx
Из доказательств смог быстро найти только это
docs.google.com/viewer?url=http%3A%2F%2Fwww.gstitt.ece.ufl.edu%2Fcourses%2Fspring13%2Feel4712%2Flectures%2Ffpga130-fowers.pptx
ASIC конечно будет потреблять меньше, чем решающая ту же задачу ПЛИС, но у этих технологий совсем разные ниши. В области высокопроизводительных вычислений ASIC — не игрок, из-за того что эту микросхему не перепрограммируешь. Если только не строить ASIC под конкретную задачу типа Bitcoin mining.
А что такое высокопроизводительные вычисления сейчас? Шифрование? Обработка пакетов? Видео? Компьютерное зрение? Давно прошли те времена, когда эти функции в ASIC-ах делали на hard-coded логике, сейчас модны всякие ASIP, которые обеспечивают некоторую степень программируемости, поэтому больше нет нужды делать ASIC под каждый конкретный алгоритм. Погуглите, например, LDPC
( Low-density parity check code ), которые теперь повсеместно используются не только во всяких LTE, но и во многих SSD, где алгоритм меняется по мере износа диска. Допустим, я делаю какой-нибудь аццкий ускоритель на FPGA — я вижу, вы занимаетесь чем-то подобным — как часто в реальной жизни возникает нужда кардинально менять алгоритмы за время жизни продукта?
( Low-density parity check code ), которые теперь повсеместно используются не только во всяких LTE, но и во многих SSD, где алгоритм меняется по мере износа диска. Допустим, я делаю какой-нибудь аццкий ускоритель на FPGA — я вижу, вы занимаетесь чем-то подобным — как часто в реальной жизни возникает нужда кардинально менять алгоритмы за время жизни продукта?
В реальной жизни HPC на FPGA — это в основном шифрование/дешифрование. В общем, согласитесь, тут алгоритмы могут меняться. Обработка видео на FPGA в основном сейчас идет в embedded системах, думаю тут алгоритм обработки тоже может в общем меняться, по крайней мере могут добавляться новые фичи. Я же вообще стремлюсь к тому, чтобы на FPGA решать научные вычислительные задачи (например из области биоинформатики). В идеале — суперкомпьютер с FPGA ускорителями, к которому подключаются разные пользователи и запускают свои задачи (но это пока утопия=))
Из реальной же жизни компания www.timelogic.com/ предлагает готовое программно-аппаратное решение для решения задач биоинформатики, у них есть всего несколько различных алгоритмов, которые ускоряются на FPGA, но этот список может расширяться.
Из реальной же жизни компания www.timelogic.com/ предлагает готовое программно-аппаратное решение для решения задач биоинформатики, у них есть всего несколько различных алгоритмов, которые ускоряются на FPGA, но этот список может расширяться.
Кстати, вот идея для использования реконфигурируемого вычислителя или ПЛИС в потребительском устройстве — декодирование аудио. Процессор под это дело расходовать жалко, да и неэффективен он на таких задачах, а делать аппаратные декодеры ASIC мешает обилие разных аудиоформатов. Декодирование видео обычно делают аппаратными модулями, поскольку кодеков не так много, а пропускная способность требуется очень высокая.
Декодирование аудио делают на аудиопроцессорах. Для самых наикрутейших аудиоформатов типа DTS HD достаточно двухядерного DSP-процессора, работающего на частоте всего в несколько сотен МГц, потребляющего несколько милливатт и занимающего на кристалле столько же места, сколько 100 LUT-ов в ПЛИСе. Форматы можно менять как перчатки.
Поэтому я уверен на 99% что ПЛИС никогда не будут использоваться в масс-маркете. Помимо высокого энергопотребления у них есть еще один недостаток — цена. Разумеется, для ускорения научных расчетов им нет конкурентов, но это 0,001% рынка.
Поэтому я уверен на 99% что ПЛИС никогда не будут использоваться в масс-маркете. Помимо высокого энергопотребления у них есть еще один недостаток — цена. Разумеется, для ускорения научных расчетов им нет конкурентов, но это 0,001% рынка.
Ну ладно, а скажем, обработка видео с камеры смартфона, для feature detection или чего-то типа leap motion?
Да, сейчас это модная тема, называется embedded vision. Главное слово тут embedded, потому что никаких особых проблем с алгоритмической точки зрения нет — бери OpenCV и радуйся. Проблема только в энергопотреблении. Поэтому все люди, варящиеся в этой кухне, смотрят либо в сторону ASIP, либо в сторону процессоров с заточенными под это DSP-расширениями. Если есть время и желание, очень рекомендую посмотреть вот этот вебинар: Case study: Designing an application-specific multicore system for pedestrian detection, using Processor Designer. Это то, про что я говорил — люди понимают, что нужна программируемость и производительность, но, к сожалению, FPGA здесь никак не годится, поэтому изобретают другие способы.
Я, наверное, уже утомил всех в этой ветке разговорами про энергопотребление, однако этот параметр, по моим ощущениям (а мне приходится общаться с десятками компаний-разработчиков микросхем) вышел на первое место, обогнав площадь кристалла и производительность (кому она теперь нужна, когда любой микроконтроллер можно разогнать до 1ГГц на 22нм техпроцессе?)
Я, наверное, уже утомил всех в этой ветке разговорами про энергопотребление, однако этот параметр, по моим ощущениям (а мне приходится общаться с десятками компаний-разработчиков микросхем) вышел на первое место, обогнав площадь кристалла и производительность (кому она теперь нужна, когда любой микроконтроллер можно разогнать до 1ГГц на 22нм техпроцессе?)
Кстати библиотека OpenCV частично портирована на Xilinx FPGA через транслятор Vivado HLS. Тоже берите и пользуйтесь, и еще есть куча примеров реализации embedded vision на FPGA, например на платформе Zynq, так что FPGA являются реальными конкурентами DSP, и не так все однозначно…
У Xilinx есть онлайн полурекламный журнал www.xilinx.com/about/xcell-publications/xcell-journal.html там много реальных примеров использования FPGA в различных областях. Про Альтеру не знаю, но уверен, что у них тоже есть что-то подобное.
У Xilinx есть онлайн полурекламный журнал www.xilinx.com/about/xcell-publications/xcell-journal.html там много реальных примеров использования FPGA в различных областях. Про Альтеру не знаю, но уверен, что у них тоже есть что-то подобное.
Кстати спасибо за ссылку, обязательно посмотрю вебинар. Тема интересная.
Тогда уж декодирование видео — тут нужна большая производительность. Я одно время воображал устройство с USB типа флешки простой, но с FPGA на борту. Устройство вставлялось бы в ноутбук, конфигурировалось под определенную кодировку и дальше перекодировало бы фильм не за 1 час, а за время передачи данных через USB интерфейс (3.0) =))
Видео требует много грубой силы, и ядро там типовое, какой-нибудь DCT или FFT. Правда, принципиально новые кодеки не появляются во многом потому, что старые закрепились в железе. Так что реконфигурируемое железо может дать дорогу новым алгоритмам, на каких-нибудь вейвлетах.
Нужно понимать, что видео и т.д. — это рынок на сотни миллионов микросхем в год. FPGA никогда не сможет на нем конкурировать — для любого нового кодека через полгода китайцы выпустят микросхему, которая будет делать то же самое, но в десять раз быстрее и сто раз дешевле. И окажется, что запилить в такую микросхему реализацию всех известных кодеков все равно дешевле, чем реконфигурировать железо на лету.
Вообще, понятна любовь соотечественников к FPGA в условиях почти полного отсутствия собственных ASIC-дизайн-центров (я думаю, на всю страну их раз в сто меньше, чем в одном только Израиле).
Идеи типа USB-флэшек для перекодирования видео на самом деле здравые и могли бы взлететь, но FPGA годятся только на роль прототипов, чтоб найти инвесторов и начать делать микросхемы. К сожалению, у нас с этим проблемы, хотя это отнюдь не rocket science.
Идеи типа USB-флэшек для перекодирования видео на самом деле здравые и могли бы взлететь, но FPGA годятся только на роль прототипов, чтоб найти инвесторов и начать делать микросхемы. К сожалению, у нас с этим проблемы, хотя это отнюдь не rocket science.
Ключевое слово — новая микросхема. А реконфигурироемому устройству надо будет просто обновить софт.
Обновить софт к FPGA-флэшке за 10к, или купить новую у китайцев за 1k… Боюсь, что выбор очевиден
а сколько стоит разработать новую ASIC под кодек в зависимости от техпроцесса/количества логических элементов? и подскажите, по какой технологии сейчас делают такие микросхемы (полностью заказные, на стандартных/библиотечных элементах, структурированные ASIC)?
нету у вас кстати ссылки на обзор процесса изготовления современных ASIC?
нету у вас кстати ссылки на обзор процесса изготовления современных ASIC?
Подавляющее большинство фирм делают микросхемы на стандартных ячейках (уровень типа И, НЕ, ИЛИ, И-НЕ, И-ИЛИ-НЕ, отдельных триггеров и т.д. — на самом деле, обычно в библиотеке несколько сотен ячеек). Библиотеки разные для каждой фабрики и каждого техпроцесса, то есть разных библиотек тоже сотни (TSMC, UMC, Global Foundries, SMIC — можно купить все, что душе угодно, начиная от 180нм вплоть до 22нм). Можно купить любую, подключить ее к синтезатору типа Design Compiler, и синтезировать один и тот же Вериложный код под любой техпроцесс. Никто сам транзисторы не рисует, кроме разработчиков этих самый библиотек.
Ну а блоки памяти генерятся memory compiler'ами. Для однопортовой памяти — один компилятор, для двухпортовой — другой, для регистровых файлов — третий.
У меня нет полной раскладки на какой-нибудь проект, потому что я занимаюсь технической поддержкой, а не продажами (но даже если бы были, это конфиденциальная информация). Но могу примерно озвучить порядок.
1. Нужно купить софт. Как минимум, RTL-симулятор, синтезатор (RTL->Netlist) и средство для формальной верификации RTL vs Netlist. Три конторы, куда придется за этим пойти — Synopsys, Cadence и Mentor Graphics. Они делят, наверное, 99% рынка. Софт дорогой, порядок цен на все про все — несколько сотен тысяч долларов за рабочее место (разумеется, можно и впятером работать на одном симуляторе, или в три смены — у всего этого софта обычно floating license).
2. Купить библиотеку стандартных ячеек. Выбрать количество нанометров, Low Power или High Performance. Не могу сказать, сколько она стоит, но не думаю, что очень дорого. Возможно, что некоторые фабрики дают ее бесплатно при заказе кучи микросхем.
3. Купить IP-блоки. Обычно покупают процессоры, Bus Fabric-и (AXI, AHB/AHB-Lite, APB), контроллеры внешней памяти типа LPDDR3, PHY для PCIe/USB3/Ethernet и т.д. Цены могут быть совершенно разные. Кстати, PHY всегда продают под конкретные техпроцессы, потому что там внутри аналоговщина. Также покупают IP для верификации — модели шин и т.д. Все это, кроме PHY, можно сделать самому, но дешевле купить.
4. Разработать и верифицировать RTL. Цена зависит от размера проекта. Обычно от начала проекта до RTL-freeze, после которого начинают синтез и layout, проходит где-то от полугода до года. Для америкосов и европейцев стоимость — несколько сотен тысяч долларов, учитывая, что инженер стоит $100k в год. Для индусов и китайцев цифры, разумеется, гораздо меньше. Нужно учитывать, что RTL-дизайн и верификацию почти всегда делают разные люди. Для верификации ключевые слова — SystemVerilog и UVM. И если для RTL-дизайна можно сэкономить на симуляторе и взять бесплатный или условно-бесплатный, то для верификации такой фокус не пройдет, потому что нужен симулятор с полной поддержкой SystemVerilog.
5. Когда RTL готов, его синтезируют в нетлист, потом в нетлист добавляют всякие DFT-штуки типа scan test, BIST, контроллер JTAG-а. Проверяют при помощи формальной верификации, что в нетлисте ничего не сломалось (gate-level simulation почти не используют, потому что она чудовищно медленная — обычно запускают какой-нибудь примитивный тест и все).
6. Потом аутсорсят back-end — размещение, трассировку. Это совсем другой мир, лучше самому туда не лезть. Софт там еще дороже, возможностей накосячить еще больше. Забирают уже готовый GDSII. Наверное, если слать китайцам, то будет не очень дорого, но могут украсть нетлист :) А так цен я не знаю.
7. Шлют GDSII на фабрику. Цена подготовки к производству чудовищно большая, поэтому сначала делают test-chip на каком-нибудь шаттле ( www.tsmc.com/english/dedicatedFoundry/services/cyberShuttle.htm ). Это будет несколько десятков тысяч долларов за пару десятков микросхем.
8. Если тест-чип работает, запускают в серию. Подготовка к производству по техпроцессу 55нм, скажем, в Китае стоит ~$500k. Сами пластины с микросхемами стоят дешево. Поэтому чем больше серия, тем дешевле микросхема. Кстати, до сих пор огромное количество контор делает микросхемы по 130нм и 90нм, как бы это не казалось странным — правда, USB3 PHY для таких техпроцессов не купить.
Сложно сказать, какой техпроцесс нужен, когда не понятно, что именно нужно сделать и сколько МГц выжать. Но примерное представление можно получить, посмотрев на цифры для микроконтроллеров, например, вот из этого моего коммента: habrahabr.ru/company/intel/blog/194836/#comment_6770002
Ну а блоки памяти генерятся memory compiler'ами. Для однопортовой памяти — один компилятор, для двухпортовой — другой, для регистровых файлов — третий.
У меня нет полной раскладки на какой-нибудь проект, потому что я занимаюсь технической поддержкой, а не продажами (но даже если бы были, это конфиденциальная информация). Но могу примерно озвучить порядок.
1. Нужно купить софт. Как минимум, RTL-симулятор, синтезатор (RTL->Netlist) и средство для формальной верификации RTL vs Netlist. Три конторы, куда придется за этим пойти — Synopsys, Cadence и Mentor Graphics. Они делят, наверное, 99% рынка. Софт дорогой, порядок цен на все про все — несколько сотен тысяч долларов за рабочее место (разумеется, можно и впятером работать на одном симуляторе, или в три смены — у всего этого софта обычно floating license).
2. Купить библиотеку стандартных ячеек. Выбрать количество нанометров, Low Power или High Performance. Не могу сказать, сколько она стоит, но не думаю, что очень дорого. Возможно, что некоторые фабрики дают ее бесплатно при заказе кучи микросхем.
3. Купить IP-блоки. Обычно покупают процессоры, Bus Fabric-и (AXI, AHB/AHB-Lite, APB), контроллеры внешней памяти типа LPDDR3, PHY для PCIe/USB3/Ethernet и т.д. Цены могут быть совершенно разные. Кстати, PHY всегда продают под конкретные техпроцессы, потому что там внутри аналоговщина. Также покупают IP для верификации — модели шин и т.д. Все это, кроме PHY, можно сделать самому, но дешевле купить.
4. Разработать и верифицировать RTL. Цена зависит от размера проекта. Обычно от начала проекта до RTL-freeze, после которого начинают синтез и layout, проходит где-то от полугода до года. Для америкосов и европейцев стоимость — несколько сотен тысяч долларов, учитывая, что инженер стоит $100k в год. Для индусов и китайцев цифры, разумеется, гораздо меньше. Нужно учитывать, что RTL-дизайн и верификацию почти всегда делают разные люди. Для верификации ключевые слова — SystemVerilog и UVM. И если для RTL-дизайна можно сэкономить на симуляторе и взять бесплатный или условно-бесплатный, то для верификации такой фокус не пройдет, потому что нужен симулятор с полной поддержкой SystemVerilog.
5. Когда RTL готов, его синтезируют в нетлист, потом в нетлист добавляют всякие DFT-штуки типа scan test, BIST, контроллер JTAG-а. Проверяют при помощи формальной верификации, что в нетлисте ничего не сломалось (gate-level simulation почти не используют, потому что она чудовищно медленная — обычно запускают какой-нибудь примитивный тест и все).
6. Потом аутсорсят back-end — размещение, трассировку. Это совсем другой мир, лучше самому туда не лезть. Софт там еще дороже, возможностей накосячить еще больше. Забирают уже готовый GDSII. Наверное, если слать китайцам, то будет не очень дорого, но могут украсть нетлист :) А так цен я не знаю.
7. Шлют GDSII на фабрику. Цена подготовки к производству чудовищно большая, поэтому сначала делают test-chip на каком-нибудь шаттле ( www.tsmc.com/english/dedicatedFoundry/services/cyberShuttle.htm ). Это будет несколько десятков тысяч долларов за пару десятков микросхем.
8. Если тест-чип работает, запускают в серию. Подготовка к производству по техпроцессу 55нм, скажем, в Китае стоит ~$500k. Сами пластины с микросхемами стоят дешево. Поэтому чем больше серия, тем дешевле микросхема. Кстати, до сих пор огромное количество контор делает микросхемы по 130нм и 90нм, как бы это не казалось странным — правда, USB3 PHY для таких техпроцессов не купить.
Сложно сказать, какой техпроцесс нужен, когда не понятно, что именно нужно сделать и сколько МГц выжать. Но примерное представление можно получить, посмотрев на цифры для микроконтроллеров, например, вот из этого моего коммента: habrahabr.ru/company/intel/blog/194836/#comment_6770002
В суровом Челябинске Таганроге уже ребята давно занимаются интересной темой, мне их выступление на одной конференции понравилась.
Тут можно почитать.
Тут можно почитать.
Идее перемещать вычисления между процом и плисиной сто лет в обед. Пытались этим заниматься в автоматическом режиме ещё в конце 80х, но воз и ныне там. А всё потому что для решении подобной задачи, фактически, нужен искусственный интеллект, которого нет и не предвидятся. Ибо здесь надо сделать рывок, сравнимый с тем, что сделала когда-то обезъяна что бы стать человеком. Т.е. перейти от тупорылых раскладывателей примитивного HDL-кода по логике и регистрам к системам совсем другого уровня: компиляторов алгоритмов. Есть начальные телодвижения в эту сторону, например, OpenCl, но это ещё самое начало пути и вполне возможно не в ту сторону. А пока — отдельно сидит плисовод, отдельно программист и над ними возвышается system architect по совместительству алгоритмист. И пока замена этим храбрым парням не предвидится.
Т.е. вы считаете, что перепрограммируемый сопроцессор плохая идея? Можно иметь готовые шаблоны под задачи, и менять направленность процессора, т.е. расширять систему команд, необходимых в данный момент… Прошивка SRAM FPGA дело минут.
Нет, вы меня не поняли. Замена прошивки — да. Более того, мы так делали, например, в ГЛОНАСС-приёмнике: нам надо было максимально быстро хватать сигнал, а потом его на сопровождение. Пришлось после захвата сигнала быстро переливать прошивку плисины, что бы его сопровождать: и то и другое в плисину не лезло.
Я о задаче автоматического разбиения алгоритма на «софтовую» и «фирмварную» части. Там пока завал полный.
Я о задаче автоматического разбиения алгоритма на «софтовую» и «фирмварную» части. Там пока завал полный.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сумбурные размышления о будущем технологии FPGA