9 сентября 2014 в 12:10

Сумбурные размышления о будущем технологии FPGA

image

Работая над очередным игровым (обучающим) проектом ПЛИС для платы Марсоход2 я столкнулся с тем, что мне явно не хватает места в кристалле. Кажется и проект не очень сложный, но моя реализация такова, что требует много логики. В принципе, это ерунда, дело-то житейское. Ну, если очень будет нужно, то можно выбрать ПЛИС с большей емкостью. Собственно мой проект — это игра «Жизнь», но реализованная в ПЛИС на языке Verilog HDL.

Про логику игры, рассказывать не буду, про нее и так написано уже достаточно.

Идея проекта вот такая: каждая клетка в игровом поле представляет собой самостоятельный вычислитель. В каждом вычислителе есть своя логическая функция и свой регистр, который хранит текущее состояние клетки (живая/не живая). Все пространство для жизни клеток — это двумерный массив вычислителей, вычислители образуют целую сеть. Все вычислители работают синхронно, так как на все регистры подается единая тактовая частота. Рисунок вверху должен прояснить схему проекта.

Так вот. На моей плате стоит ПЛИС Cyclone III EP3C10E144C8 компании Альтера. 10тыс логических элементов. Сперва я думал, что смогу сделать двумерный массив клеток 128x64=8192 клетки. Не помещается. 64x64=4096 — то же не помещается в кристалл. Как же так. Я сумел вместить в ПЛИС только 32x16=512 клеток. Пичалька…

Размышления приводят меня к мысли, что возможно, в будущем, технология ПЛИС перерастет в нечто большее, чем программируемая логика. Вот об этом своем видении я хотел бы рассказать. Искушенному читателю сразу скажу, что многое далее написанное есть просто плод воображения и может быть даже бред.
Однако..

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

Мы знаем, например, что компания Альтера предлагает и продвигает технологию OpenCL
Просто говоря — это такой C-подобный язык для описания параллельных вычислений в FPGA акселераторе. Кстати, Nvidia и ее видеокарты так же поддерживают параллельные вычисления c OpenCL.

Таким образом, видно, что Альтера явно задумываются о том, как донести «обычные» C-подобные параллельные вычисления FPGA в народ. Посмотрим, что там с ценами на платы для параллельных вычислений с FPGA? Плата Terasic DE5-Net.

image

25 пользователям нравится цена 8 тыс баксов (шучу).

Есть и другие попытки привезти FPGA в народ — Altera выпустила совместно с Intel микросхему серии E6x5C, где в едином корпусе соединен процессор Atom и ПЛИС Arria II. Хорошая попытка, но технология так кажется и не смогла найти массового потребителя.

Видимо существующие кристаллы ПЛИС плохо вписываются в современную парадигму программирования.
А какая у нас сейчас современная парадигма «нормального» программирования?

Мне кажется, что как-то так:

  • на компьютере всегда одновременно исполняется несколько вычислительных процессов и потоков
  • состояние процессов и потоков хранится в памяти, процесс может запросить у ОС столько памяти, сколько нужно; можно даже попросить больше, чем есть физической памяти — и процесс может реально получить эту виртуальную память.
  • вычисления производятся процессором, иногда он имеет много ядер. Обычно процесс или поток не знают (или не хотят знать) в каком ядре процессора сейчас исполняется задача.
  • более приоритетная задача может вытеснить менее приоритетную задачу. Вытеснить — это значит сохранить состояние страниц памяти вялого процесса на диск и переключиться на более приоритетный процесс. Выделить ему больший слайс времени.


Понятно, что чем больше памяти и чем больше ядер процессора, тем быстрее работают все процессы в системе.
Память и ядра процессора — это ресурсы компьютера, вычислителя, которые операционная система распределяет между процессами.

Теперь представим себе, что в будущем мы получим компьютеры, где на ряду с памятью и ядрами процессора будут иметься в наличии еще блоки логики «как-бы-плис». Этот ресурс «как-бы-плис» по своим свойствам находится где-то между процессором и памятью. С одной стороны «как-бы-плис» = это вычислитель, то есть ближе к процессору, но с другой стороны это и память, ибо в регистрах плис хранится довольно много информации. Состояние вычислителя «как-бы-плис» уже довольно трудно будет сохранить в структуре task_struct при переключении контекста задачи. Но, наверное, можно попытаться вытеснить состояние блоков логики в swap файл, как виртуальную память. И временно ОС может подгрузить другие блоки логики для активного потока…

Кстати, и Altera и Xilinx уже довольно давно имеют FPGA с возможностью частичной перезагрузки отдельных участков, блоков логики (Partial Reconfiguration) — то есть в принципе они как-то идут в эту сторону…

Программист может выделить для процесса столько «как-бы-плис», сколько нужно. Буквально функцией lalloc (logic alloc) по аналогии с malloc (memory alloc). Потом из файла считать туда «прошивку ПЛИС» и она будет жить и работать. Мы, программисты, по большому счету не должны думать есть эта память/логика «как-бы-плис» у системы или ее нет. А не наше это дело. Да, иногда может быть очень медленно при ограниченных ресурсах, но разве мы не знаем как «лагают» видеоигры на слабых видеокартах? Пользователи знают, что за сильное железо придется платить, но хорошо бы, чтоб даже минимальная система уже имела в базовом варианте логические блоки «как-бы-плис» для использования в программах.

На самом деле, конечно, я представляю себе, что такая технология вряд ли скоро появится, слишком все это сложно и не реализуемо. По крайней мере существующие микросхемы ПЛИС мало подходят для этих целей хотя бы потому, что для конфигурирования ПЛИС используются медленные последовательные интерфейсы типа JTAG. Но может быть, когда-то кто-то из нас сделает это?

ЗЫ: кстати, а вот и моя игра жизнь в ПЛИС, такая маленькая, 32x16… ну нет у меня виртуальной памяти «как-бы-плис», чтобы сделать поле игры шире и выше…



ЗЫ2: все исходники и подробное описание проекта игры Жизнь можно взять здесь.
Николай @nckma
карма
186,0
рейтинг 9,7
Программист
Похожие публикации
Самое читаемое Разработка

Комментарии (56)

  • +2
    Ну самые современные FPGA умеют конфигурироваться и по PCIe при желании. Но вот переключать их конфигурации просто при смене выполняемой задачи это все же нетривиально — надо ведь не только конфигурацию хранить, но и состояние всех внутренних ресурсов. Может к этому когда и придет, но тут нужна более плотная интеграция с ядром процессора. Ну и сама «конфигурация» FPGA должна быть либо стандартаризована для всех процессоров либо надо осуществлять прекомпиляцию при первом запуске ПО (типа как какие-то текстуры генерятся в ряде игр для каждого видеоадаптера).

    Про реализации Жизни на FPGA — чисто теоретически в указанный кристалл (10000 логических элементов) может влезть порядка 3000 клеток. Объяснение простое — каждая клетка берет информацию от 8 соседей, т.е. надо реализовать логическую функцию от 8 аргументов. Внутри логических элементов (этой FPGA) использованы 4-входовые таблицы перекодировки (LUT4). Т.е. на каждую клетку выходит 3 LUTa. Может быть оптимизациями логики можно повысить эффективность, но сразу не сообразить, а думать лень. Плюс накладные расходы на ввод-вывод. Возможность читать и писать состояние каждой клетки извне, тоже, кстати, сильно влияет на расход ресурса.
    • +1
      Я то же так думал, но потом реализовал загрузку и чтение таблицы и размер сильно вырос…
      • +1
        Вы посмотрите статистику в Квартусе. Он вам покажет, сколько точно ячеек занято. Также межсоединения могут быть проблемой.
      • 0
        Скорее даже не статистику, а отчёт-схему от fitter-а, чтобы понять, что ограничивает — количество LUT-ов (базовых ячеек ПЛИС) или же коммутатор не тянет такую топологию.
    • +3
      Вы считаете, что любую функцию от 8 переменных можно реализовать при помощи трёх 4-входовых LUT'ов?
      • +2
        Какой коварный вопрос ;)
        Нет конечно, думал о чем-то совсем другом, прекрасном, когда писал.
        На самом деле, для того варианта о котором я думал надо 5 лутов: Две пары по входу дают полусуммы по одной и второй четверке, пятый компаратор проверяет общий результат.

        Как выяснилось, я несколько подзабыл правила и аргументов должно быть 9 (надо считать и саму клетку), так что получается 6. Но это надо вдумчиво писать руками.

        Чтобы реабилитироваться — немного побаловался с синтезатором квартуса. Если делать в лоб, как автор, то получается как раз-таки около 20 лутов. Если сделать какое-нибудь подобие дерева сумматоров, то выходит 9 лутов.

        • 0
          Не, не 6 — 7 надо минимум.
          • 0
            У меня реализация xcell.v занимает минимум 9 LUT'ов.
            Не поделитесь своей? :)
            • 0
              А поделитесь реализацией на 9 LUT'ов? Как получить меньше 20?
            • 0
              Вот моё на 7: (серые блоки не считаются, потому что повторно используются)

              • 0
                О, интересно, а можно соответствующий код на verilog/vhdl? Я не уверен, что понимаю схему.
                • 0
                  Извиняюсь, на картинке ошибка, не получается на семи.
            • 0
              Увы, меньше 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;
              

  • 0
    Интересная задумка! ОС могла бы сама на своем уровне переконфигурировать такое устройство в зависимости от требований процессов. Например, смотришь кино — она загружает схему декодера и т.д.
    Хотя больший профит наверное будет, если сам разработчик будет на низком уровне конфигурировать такое устройство для выполнения своих специфических операций. Правда, не знаю что делать, если приложений, которые используют устройство будет несколько, на сколько будет затратно переключать контекст.
    • +3
      Есть «небольшая» проблема. Писать что то для FPGA не так просто как кажется, грубо говоря это и не програмирование, а описание устройства текстовым способом. Конструкции похожи, но это ещё больше запутывает. И даже что то написав под FPGA и отдав это системе нужно ещё написать драйвер который поймёт как с этим работать, написание дров тоже процесс не простой. В итоге нужно делать два непростых дела. А через пол года вышел новый процессор, и спокойно компенсировал все эти заморочки повышенной частотой/ядерностью.

      Правда, не знаю что делать, если приложений, которые используют устройство будет несколько, на сколько будет затратно переключать контекст.

      На Сyclone II по ощущением конфигурация считывается около секунды. Так что единственный вариант, эксклюзивный доступ, либо несколько «схем» на один чип грузить а внутри их как то коммутировать и уже ОС довать к ним доступ.
      • 0
        Удел FPGA в данном случае — моментальная специализация под частное решение, которое вряд ли найдет поддержку в общем ядре (в ближайшее время). Тот же AES — сколько его там считали на общем CPU пока Intel не добавил в соответсвующую логику в некоторые процессоры. А придумают новый алгоритм — еще 10 лет ждать. Понятно, что это эффективно в первую очередь в том случае, если происходят активные вычисления.
        Подобное решение, кстати, хорошо реализуется в процессоре NIOS, имплементируемом на кристаллах Altera. Там можно прямо в АЛУ процессора добавить свои собственные команды, реализующие собственную логику/алгоритмы под конкретную задачу. И дальше вызывать их из программы как обычные функции, по сути.
      • +1
        Вы немного не правы, в статье обсуждается не использование DE5-Net иже с ней, а некое логическое продолжение этой платы.

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

        В статье упомянули, что Altera развивает стандарт OpenCL, а это как раз большой шаг в сторону описанного в статье устройства: пользователь запускает программу на OpenCL, и при наличии на борту FPGA-структуры из этой программы синтезируется схема, которая быстро и эффективно решит задачу. нет — посчитается на видео карте, там тоже ресурсов хватает, на крайний случай и CPU справится, правда не так быстро.
      • +1
        Да, программировать быстро FPGA чертовский сложно, и мало людей вообще умеют это делать даже долго. Один из способов преодолеть это — сделать каркас приложения, включающий драйвер OS, интерфейсное ядро в FPGA (например PCIe или USB) и определить программные (на стороне хост-компьютера) и аппаратные (на стороне ПЛИС) интерфейсы для передачи данных между хостом и ускорителем FPGA. А само вычислительное ядро писать на языках высокого уровня типа C или OpenCL.

        Тут в лидерах Altera — у них уже примерно с год как есть полноценная поддержка стандарта OpenCL для своих кристаллов с интерфейсом PCIe (драйвер, хост библиотеки и аппаратные ядра уже написаны, и прикладной разработчик использует документированную программную модель OpenCL). Xilinx в этом смысле отстает — у них пока из открытого и доступного есть только транслятор C-to-HDL называется Vivado HLS (бывший AutoESL), позволяющий довольно эффективно (есть оценки) перевести Си код в VHDL или Verilog, Но тут нет никакой системной поддержки, и драйвер и аппаратный интерфейс надо реализовывать самому.
        • 0
          Мораль, — модель и средства программирования — основной фактор успеха. А удобной модели нет. HDL-и низкоуровневы до безобразия, уж аналог с++ шаблонов приделать могли бы. Трансляция из С — не верю, нельзя из локомотива напильником вертолёт выточить. OpenCL — и программировать трудно, и гибкость HDL теряется.
          • 0
            За неимение пока ничего лучше я ставлю все-таки на трансляторы. Много людей уже знают С, и если им дать удобный и настраиваемый каркас приложения, то они смогут на нем худо бедно программировать свои алгоритмы под FPGA. Другое дело, насколько это будет эффективно. Тут нужно только искать такие задачи, которые будут хорошо «ложиться» на FPGA.
  • 0
    Хорошая идея! Я, да и многие тоже задумывались об этом: плис, как сопроцессор.
    Идея – «Жидкое ядро», меняем подход к вычислениям
    • 0
      Строго говоря, идея конфигурирования ПЛИС по мере надобности настолько давно появилась, что даже вынесена в название: FPGA — как раз и означает "Field-Programmable Gateway Array" т.е. программируемый в полевых условиях массив лог. вентелей.
  • +4
    Пока FPGA используется в качестве ускорителя вычислений только для одной задачи в одно время. Например у вас есть алгоритм из области биоинформатики или надо быстро посчитать покупать акции или продавать. Тогда если есть много денег и хочется побыстрее, то можно использовать FPGA ускорители. При этом если вы занимаетесь биоинформатикой, то врятли вы захотите запускать на том же компьютере финансовые задачи… Это я к тому, что на текущий день компьютеры с FPGA ускорителями — это не продукт широкого потребления типа GPU или Xeon Phi, и на них не запускают широкий спектр задач, а только ту, ради ускорения которой и покупался/строился этот очень дорогой компьютер.

    Поэтому в том чтобы морочиться с выделением логических ресурсов плис каждому процессу на уровне ОС смысла сейчас нет, как нет и практических реализаций таких систем.

    Были такие суперькомпьютеры от Cray
    en.wikipedia.org/wiki/Cray_XT5
    en.wikipedia.org/wiki/Cray_XD1
    в которых в один из процессорных слотов на материнской плате на межпроцессорную шину сажался кристалл FPGA, расширяющий инструкции основного. Но, как мне сказал инженер Cray на одной выставке, народ этого не оценил, никто не покупал эти машины, и Cray свернул все свои дела с FPGA ускорителями.
  • +2
    По поводу описанного проекта — совсем очевидное замечание, но всё же напишу.

    Если есть задача увеличить количество клеток, то не обязательно использовать ПЛИС большей емкости.
    Можно просто уменьшить количество параллельных вычислений.
    В крайнем случае можно хранить всё значения в блочной памяти и использовать только один вычислительный блок, который будет последовательно вычислять все новые значения для всех клеток.

    Естественно, делать все вычисления за такт станет не реально, но я не думаю, что для Вашего проекта цель — это 100 млн. обновлений в секунду.
    Дальнейшее развитие мысли — обратное увеличение параллельности, с использованием N вычислительных блоков, где 1 < N << количества клеток.
    • 0
      Для этого придется написать управляющее устройство в виде КА, которое в конечном итоге проще заменить процессором, а программу написать на С ;)
      • +2
        В каком-то конкретном случае — да.
        В общем случае — зависит от количества вычислительных блоков, которые удастся реализовать в ПЛИС; частоте, на которой это всё заработает; емкости ПЛИС; частоте процессора; количеству ядер; стоимости компонентов и т.д.

        Не уверен, что можно реализовать эту задачу на FPGA так, чтобы по соотношению производительность/стоимость вышло выгоднее, чем на CPU. Но допускаю это.
        Почти уверен, что на FPGA можно сделать реализацию с большей производительностью, чем на CPU.
        Точно уверен в том, что реализация на FPGA будет интересней :)

        P.S. Пора заводить хаб, посвященный FPGA :)
  • +1
    Идея реконфигурируемых вычислений действительно весьма привлекательна, мне это представляется как супермаркет, перестраивающийся под текущий поток клиентов, то скажем, добавляя кассы, то убирая непопулярные полки. Но дело это нетривиальное: даже при наличии готовой схемы, её надо ещё как-то уложить на физическую топологию ПЛИС, это можно сделать заранее только для однозадачной системы, иначе будут конфликты за ресурсы.
    Можно пофантазировать о применении клеточного автомата для локального конфигурирования ПЛИС, как-то так: в нашем супермаркете посетитель идёт вдоль ряда касс, если все кассы заняты, то он упирается в голову списка касс, где сидит генератор касс — специальная подпрограмма, способная к локальной модификации нашего супермаркета. Генератор создаёт для клиента новую кассу, если рядом есть свободное место.
    Мне очень близка эта тема, сейчас пишу статью про свой реконфигурируемый компьютер.
    • +1
      А я то же все время про реконфигурируемый компьютер думаю…
      • 0
        Будем надеяться, с исчерпанием возможностей экстенсивного роста, электроника начнёт развиваться в новых направлениях. Понадобятся во-первых, типовые задачи, чтобы показать перспективы альтернативных архитектур, а во-вторых инструментарий.
    • 0
      FPGA очень много жрут электроэнергии, просто неимоверно много. Поэтому их применение всегда будет очень ограниченным. Как мне кажется, индустрия движется в сторону гетерогенных систем, т.е. противоположную от реконфигурируемых. Проще добавить в систему десять модулей, каждый из которых делает что-то свое (не исключено, что с некоторой степенью свободы, т.е. это может быть специализированный процессор), и отключать ненужные для экономии энергии. Транзисторы нынче дешевы.
      • 0
        FPGA за ненадобностью тоже можно отключить, как и остальные не нужные в данный момент компоненты системы. Надо будет ради эксперимента сравнить сколько энергии жрут на одинаковых задачах FPGA и CPU, при условии что задача распараллеливается и вообще эффективно реализуется на ПЛИС.
      • 0
        Да, относительно ASIC-ов ПЛИС-ы жрут. И тем не менее, их активно используют. Про реконфигурируемые говорить сложно, поскольку их ещё нет, но можно ожидать, что у них будут свои задачи, на которых они будут достаточно энергоэффективны.
        • 0
          Я же не спорю, что их активно используют, когда нет денег сделать нормальную микросхему :) И вообще, я ПЛИСы люблю, с них начинал и до сих пор кое-что на них делаю, правда в моей области они используются исключительно для прототипирования ASIC-ов.
      • 0
        Тут вы не правы. Все как раз наоборот. Если сравнивать потребление на реальных задачах, то 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
        • 0
          ASIC конечно будет потреблять меньше, чем решающая ту же задачу ПЛИС, но у этих технологий совсем разные ниши. В области высокопроизводительных вычислений ASIC — не игрок, из-за того что эту микросхему не перепрограммируешь. Если только не строить ASIC под конкретную задачу типа Bitcoin mining.
          • 0
            А что такое высокопроизводительные вычисления сейчас? Шифрование? Обработка пакетов? Видео? Компьютерное зрение? Давно прошли те времена, когда эти функции в ASIC-ах делали на hard-coded логике, сейчас модны всякие ASIP, которые обеспечивают некоторую степень программируемости, поэтому больше нет нужды делать ASIC под каждый конкретный алгоритм. Погуглите, например, LDPC
            ( Low-density parity check code ), которые теперь повсеместно используются не только во всяких LTE, но и во многих SSD, где алгоритм меняется по мере износа диска. Допустим, я делаю какой-нибудь аццкий ускоритель на FPGA — я вижу, вы занимаетесь чем-то подобным — как часто в реальной жизни возникает нужда кардинально менять алгоритмы за время жизни продукта?
            • 0
              В реальной жизни HPC на FPGA — это в основном шифрование/дешифрование. В общем, согласитесь, тут алгоритмы могут меняться. Обработка видео на FPGA в основном сейчас идет в embedded системах, думаю тут алгоритм обработки тоже может в общем меняться, по крайней мере могут добавляться новые фичи. Я же вообще стремлюсь к тому, чтобы на FPGA решать научные вычислительные задачи (например из области биоинформатики). В идеале — суперкомпьютер с FPGA ускорителями, к которому подключаются разные пользователи и запускают свои задачи (но это пока утопия=))

              Из реальной же жизни компания www.timelogic.com/ предлагает готовое программно-аппаратное решение для решения задач биоинформатики, у них есть всего несколько различных алгоритмов, которые ускоряются на FPGA, но этот список может расширяться.
              • 0
                Кстати, вот идея для использования реконфигурируемого вычислителя или ПЛИС в потребительском устройстве — декодирование аудио. Процессор под это дело расходовать жалко, да и неэффективен он на таких задачах, а делать аппаратные декодеры ASIC мешает обилие разных аудиоформатов. Декодирование видео обычно делают аппаратными модулями, поскольку кодеков не так много, а пропускная способность требуется очень высокая.
                • +1
                  Декодирование аудио делают на аудиопроцессорах. Для самых наикрутейших аудиоформатов типа DTS HD достаточно двухядерного DSP-процессора, работающего на частоте всего в несколько сотен МГц, потребляющего несколько милливатт и занимающего на кристалле столько же места, сколько 100 LUT-ов в ПЛИСе. Форматы можно менять как перчатки.

                  Поэтому я уверен на 99% что ПЛИС никогда не будут использоваться в масс-маркете. Помимо высокого энергопотребления у них есть еще один недостаток — цена. Разумеется, для ускорения научных расчетов им нет конкурентов, но это 0,001% рынка.
                  • 0
                    Ну ладно, а скажем, обработка видео с камеры смартфона, для feature detection или чего-то типа leap motion?
                    • +1
                      Да, сейчас это модная тема, называется embedded vision. Главное слово тут embedded, потому что никаких особых проблем с алгоритмической точки зрения нет — бери OpenCV и радуйся. Проблема только в энергопотреблении. Поэтому все люди, варящиеся в этой кухне, смотрят либо в сторону ASIP, либо в сторону процессоров с заточенными под это DSP-расширениями. Если есть время и желание, очень рекомендую посмотреть вот этот вебинар: Case study: Designing an application-specific multicore system for pedestrian detection, using Processor Designer. Это то, про что я говорил — люди понимают, что нужна программируемость и производительность, но, к сожалению, FPGA здесь никак не годится, поэтому изобретают другие способы.

                      Я, наверное, уже утомил всех в этой ветке разговорами про энергопотребление, однако этот параметр, по моим ощущениям (а мне приходится общаться с десятками компаний-разработчиков микросхем) вышел на первое место, обогнав площадь кристалла и производительность (кому она теперь нужна, когда любой микроконтроллер можно разогнать до 1ГГц на 22нм техпроцессе?)
                      • 0
                        Кстати библиотека OpenCV частично портирована на Xilinx FPGA через транслятор Vivado HLS. Тоже берите и пользуйтесь, и еще есть куча примеров реализации embedded vision на FPGA, например на платформе Zynq, так что FPGA являются реальными конкурентами DSP, и не так все однозначно…
                        У Xilinx есть онлайн полурекламный журнал www.xilinx.com/about/xcell-publications/xcell-journal.html там много реальных примеров использования FPGA в различных областях. Про Альтеру не знаю, но уверен, что у них тоже есть что-то подобное.
                      • 0
                        Кстати спасибо за ссылку, обязательно посмотрю вебинар. Тема интересная.
                • 0
                  Тогда уж декодирование видео — тут нужна большая производительность. Я одно время воображал устройство с USB типа флешки простой, но с FPGA на борту. Устройство вставлялось бы в ноутбук, конфигурировалось под определенную кодировку и дальше перекодировало бы фильм не за 1 час, а за время передачи данных через USB интерфейс (3.0) =))
                  • 0
                    Видео требует много грубой силы, и ядро там типовое, какой-нибудь DCT или FFT. Правда, принципиально новые кодеки не появляются во многом потому, что старые закрепились в железе. Так что реконфигурируемое железо может дать дорогу новым алгоритмам, на каких-нибудь вейвлетах.
                    • 0
                      Нужно понимать, что видео и т.д. — это рынок на сотни миллионов микросхем в год. FPGA никогда не сможет на нем конкурировать — для любого нового кодека через полгода китайцы выпустят микросхему, которая будет делать то же самое, но в десять раз быстрее и сто раз дешевле. И окажется, что запилить в такую микросхему реализацию всех известных кодеков все равно дешевле, чем реконфигурировать железо на лету.
                      • 0
                        Вообще, понятна любовь соотечественников к FPGA в условиях почти полного отсутствия собственных ASIC-дизайн-центров (я думаю, на всю страну их раз в сто меньше, чем в одном только Израиле).

                        Идеи типа USB-флэшек для перекодирования видео на самом деле здравые и могли бы взлететь, но FPGA годятся только на роль прототипов, чтоб найти инвесторов и начать делать микросхемы. К сожалению, у нас с этим проблемы, хотя это отнюдь не rocket science.
                      • 0
                        Ключевое слово — новая микросхема. А реконфигурироемому устройству надо будет просто обновить софт.
                        • 0
                          Обновить софт к FPGA-флэшке за 10к, или купить новую у китайцев за 1k… Боюсь, что выбор очевиден
                          • 0
                            а сколько стоит разработать новую ASIC под кодек в зависимости от техпроцесса/количества логических элементов? и подскажите, по какой технологии сейчас делают такие микросхемы (полностью заказные, на стандартных/библиотечных элементах, структурированные ASIC)?

                            нету у вас кстати ссылки на обзор процесса изготовления современных ASIC?
                            • +2
                              Подавляющее большинство фирм делают микросхемы на стандартных ячейках (уровень типа И, НЕ, ИЛИ, И-НЕ, И-ИЛИ-НЕ, отдельных триггеров и т.д. — на самом деле, обычно в библиотеке несколько сотен ячеек). Библиотеки разные для каждой фабрики и каждого техпроцесса, то есть разных библиотек тоже сотни (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
                              • +1
                                Я лучше останусь на FPGA =))
  • 0
    В суровом Челябинске Таганроге уже ребята давно занимаются интересной темой, мне их выступление на одной конференции понравилась.

    Тут можно почитать.
  • 0
    Идее перемещать вычисления между процом и плисиной сто лет в обед. Пытались этим заниматься в автоматическом режиме ещё в конце 80х, но воз и ныне там. А всё потому что для решении подобной задачи, фактически, нужен искусственный интеллект, которого нет и не предвидятся. Ибо здесь надо сделать рывок, сравнимый с тем, что сделала когда-то обезъяна что бы стать человеком. Т.е. перейти от тупорылых раскладывателей примитивного HDL-кода по логике и регистрам к системам совсем другого уровня: компиляторов алгоритмов. Есть начальные телодвижения в эту сторону, например, OpenCl, но это ещё самое начало пути и вполне возможно не в ту сторону. А пока — отдельно сидит плисовод, отдельно программист и над ними возвышается system architect по совместительству алгоритмист. И пока замена этим храбрым парням не предвидится.
    • 0
      Т.е. вы считаете, что перепрограммируемый сопроцессор плохая идея? Можно иметь готовые шаблоны под задачи, и менять направленность процессора, т.е. расширять систему команд, необходимых в данный момент… Прошивка SRAM FPGA дело минут.
      • 0
        Нет, вы меня не поняли. Замена прошивки — да. Более того, мы так делали, например, в ГЛОНАСС-приёмнике: нам надо было максимально быстро хватать сигнал, а потом его на сопровождение. Пришлось после захвата сигнала быстро переливать прошивку плисины, что бы его сопровождать: и то и другое в плисину не лезло.

        Я о задаче автоматического разбиения алгоритма на «софтовую» и «фирмварную» части. Там пока завал полный.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.