[des00 25]

VHDL, Verilog и т.д....меня вот больше беспокоит другая проблема, ставя перед собой ТЗ, прорабатывая теорию и алгоритмику, знаю что и как описать что бы заработало. Но вот кодить руками, отлаживать мелочи в симуляторе, рисовать в симулинке, натягивать констрейны лень :(.....надо нейроинтерфейс как у тони старка, пить чай, а код сам пишется шаблонами, по командам получаемым из мозга

ЗЫ. во избежание обвинения в том что задачи легкие, задачи посложнее счетчика)

[dxp 33]

Возможно, HLS решит часть этим проблем.

[des00 25]

19 minutes ago, dxp said:

Возможно, HLS решит часть этим проблем.

От ручного кодирования и проверки все равно не уйти. При разработке алгоритма я сразу его отображаю на стуруктуру плис, там будет тоже самое рукоблудие)

ЗЫ. Вот парочка кодо-негров, с прямым нейроинтерфейсом к ним в голову мне бы не помешала. Но студенты сейчас не очень высокого качества пошли(ну либо я слишком требователен).

[syoma 1]

20 minutes ago, des00 said:

От ручного кодирования и проверки все равно не уйти. При разработке алгоритма я сразу его отображаю на стуруктуру плис, там будет тоже самое рукоблудие)

ЗЫ. Вот парочка кодо-негров, с прямым нейроинтерфейсом к ним в голову мне бы не помешала. Но студенты сейчас не очень высокого качества пошли(ну либо я слишком требователен).

Тю, мы давно уже убрали кодонегров, заменив их Matlab/Simulink + HDL Coder/System Generator. Текстовые спецификации уходят в прошлое - спец по силовой электронике рисует в симулинке модельку, которая делает все, что ему нужно, передает ее вместе со своими тестовыми кейсами товарищу, который переводит это все в fix point, добавляет задержки, проверяя, что моделька все еще делает то, что нужно и моделька готова для синтеза в ПЛИС. Она же отдается автору, как новый референс. Когда все развелось в ПЛИС, другой товарищ выполняет  формальную верификацию по тем же тестовым кейсам. 

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

ПС1 - у нас таким образом делается и сложные DSP и управление и PCIe, Ethernet корки - уже Gen. 3 и 10G

ПС2 - но и чипы не маленькие - Virtex-7, Ultracale. 

[des00 25]

15 minutes ago, syoma said:

Тю, мы давно уже убрали кодонегров, заменив их Matlab/Simulink + HDL Coder/System Generator. Текстовые спецификации уходят в прошлое - спец по силовой электронике рисует в симулинке модельку, которая делает все, что ему нужно, передает ее вместе со своими тестовыми кейсами товарищу, который переводит это все в fix point, добавляет задержки, проверяя, что моделька все еще делает то, что нужно и моделька готова для синтеза в ПЛИС. Она же отдается автору, как новый референс. Когда все развелось в ПЛИС, другой товарищ выполняет  формальную верификацию по тем же тестовым кейсам. 

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

ПС1 - у нас таким образом делается и сложные DSP и управление и PCIe, Ethernet корки - уже Gen. 3 и 10G

ПС2 - но и чипы не маленькие - Virtex-7, Ultracale. 

мы уже с вами это обсуждали. вы круты. симулинк модели я переношу в плис руками, используя библиотеку своих дсп "примитивов"

Ну вообще мне сложно представить как можно нарисовать ну хотя бы дма контроллер PCI-e в HDL кодере, ну или LDPC декодер. как сделать это текстом я знаю, а вот как в HDL кодере нет. Вставка корок не интересна, интересует именно разработка с нуля.

ЗЫ. Ну и опять же, я же про другое речь виду. убрать работу медленными руками, в область работы нейроинтерфейса) ну как у тони старка в человеке-утюге)

ЗЗЫ. Вот как раз HLS может помочь в разработке того же LDPC декодера, вопрос конечно будет с качеством распаралеливания, но тем не менее да, там поможет скорее всего.

[syoma 1]

1 hour ago, des00 said:

Ну вообще мне сложно представить как можно нарисовать ну хотя бы дма контроллер PCI-e в HDL кодере,

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

Мы делаем дизайн вокруг PCIe Hardware Endpoint - стандартного wrappera, который предлагается с аппаратным ядром Xilinx. Наш контроллер полностью контролирует процесс обмена данными по PCIe шине между ПЛИС <-> памятью процессора и ПЛИС <-> DSP (TI C6678). Т.е. условно каждые 25мкс наша корка записывает и читает примерно 2к 32-х битных слов данных в/из памяти DSP, в которые она пихает кучу измерений от АЦП, полученных через Ethernet и прочие интерфейсы. После записи она шлет прерывание, чтобы DSP обработало эти данные, а потом читает из памяти результат обработки и выдает на выходы. В перерывах между этими та же корка записывает и читает примерно 16к 64-битных слов в/из памяти процессора (Intel) каждые 500мкс. При этом она еще и добавляет всякие timestampы к ним, чтобы проц этим не занимался.

В итоге все сделано в Симулинке, правда не на HDL Coder, а в System Generator, так как там есть некоторые блоки, типа Fifo и Block RAM, которые значительно облегчают дизайн таких вещей по сравнению с HDL Coderoм. Несколько планировщиков, shared memory, CDC логика и все оно летает вот как-то. Пока грузим PCIe Gen.2 x4 на 67%.

Вот как-то так.

 

[des00 25]

5 hours ago, syoma said:

Мы делаем дизайн вокруг PCIe Hardware Endpoint - стандартного wrappera, который предлагается с аппаратным ядром Xilinx...

Вот мне как раз интересен уровень разработки внутренностей этого самого wrapperа средствами HDL кодера)

А по остальной системе, такую потоковую обрабоку я представляю как сделать в System Generator и Simulink. Пробовал несколько раз, но на рутине срубался, впрочем, мы это уже тоже обсуждали с вами)

[syoma 1]

Кстати только недавно закончили бенчмаркинг перерисовки Verilog кода в Симулинке с нуля. В результате сгенерированный код занял примерно на 5-10% больше ресурсов в ПЛИСе, чем оригинал. 

5 hours ago, des00 said:

Вот мне как раз интересен уровень разработки внутренностей этого самого wrapperа средствами HDL кодера)

А зачем??? Зачем туда лезть? Вы разве сделаете лучше, чем производитель? Чем вас стандартная корка не устраивает? Весь смысл в том, чтобы не лезть в hardware-specific блоки - и использовать стандартные интерфейсы - тогда ваша модель легко перенесется на другую серию ПЛИС, а в некоторых случаях (например обработка MAC в Ethernet у нас сделана чисто в Stateflow) и на другого производителя, так как вообще аппаратно-независимый код. 

[dxp 33]

12 минут назад, syoma сказал:

Пока грузим PCIe Gen.2 x4 на 67%.

Т.е. у вас поток на этой штуке порядка 8-10 Гбит в секунду?

[des00 25]

7 minutes ago, syoma said:

А зачем??? Зачем туда лезть? Вы разве сделаете лучше, чем производитель? Чем вас стандартная корка не устраивает? Весь смысл в том, чтобы не лезть в hardware-specific блоки - и использовать стандартные интерфейсы - тогда ваша модель легко перенесется на другую серию ПЛИС, а в некоторых случаях (например обработка MAC в Ethernet у нас сделана чисто в Stateflow) и на другого производителя, так как вообще аппаратно-независимый код. 

затем что я коре писатель и разрабатываю корки, которые потом другие вставляют кубиками в свои системы) вашу корку, для вашей плис, тоже разработал какой нибудь ХДЛщик, которого вы списываете в анналы истории)

[syoma 1]

9 minutes ago, des00 said:

затем что я коре писатель и разрабатываю корки, которые потом другие вставляют кубиками в свои системы) вашу корку, для вашей плис, тоже разработал какой нибудь ХДЛщик, которого вы списываете в анналы истории)

Ааа, ну так мы ж аппликейшн-писатели. Хлеб у вас не забираем :-)

Хотя с другой стороны есть коллеги, которые отвечают за корку PON, все написано на Verilog. И сидят они за своими симуляторами день и ночь уже который год, вылизывая баги протокола, которые они наделали, и чешутся у меня руки все это прибрать.

[alexadmin 0]

Мне эта дискуссия напомнила один семинар. Xilinx'а что ли. Там HLS, SystemC, OpenCL, все модно и красиво. И одной из вечно повторяющихся "маркетинговых" картинок в слайдах был компьютер, за ним сидит белый мужчина средних лет. Вокруг стоят внимают тетка, молодой негр и индус вроде. И негр тыча пальцем в экран как бы говорит: "Чо ты мне тут паришь своим OpenCL? Мне надо 400 портов к трансиверу подключить и 500 параметров задать из которых 80% недокументированные". Так и тут примерно - каждый занимается своей областью и оценивает инструменты исходя из своих задач.

[blackfin 16]

6 hours ago, syoma said:

ПС1 - у нас таким образом делается и сложные DSP и управление и PCIe, Ethernet корки - уже Gen. 3 и 10G

ПС2 - но и чипы не маленькие - Virtex-7, Ultracale. 

А что там может быть из "сложного DSP"? У вас же, Энергетика? То есть, частоты сигналов низкие (~50 Гц), частоты дискретизации тоже едва ли больше 10 кГц, алгоритмы тоже простые - всякие PID'ы, простенькие FIR'ы, ну и БПФ "для приличия" на 1024 точки. Откуда там взяться "сложным DSP", ума не приложу.. :)

[syoma 1]

4 hours ago, a123-flex said:

Я в матлабе у спецов по кодогенерации про эффективность информацию получил. Уж если кто и заинтересован оценки эффективности завышать, так это они.

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

Открою вам секрет - Матлаб продвигает свой HDL Coder для полных неспецов в FPGA, предлагая кучу опций по автоматической оптимизации дизайнов (перевод в fixed-point, вставка pipeline delay, time domain multiplexing) из которых часто получается полная хрень, которая не только не эффективна, но и часто вообще не работает как надо.

Мы с ними об этом много раз общались и в итоге в большинстве случаев мы эти оптимизации не используем, а используем bit и cylce-true подход, при котором модель исполняет в симуляции ровно то, что делает в железе. А всякие оптимизации добавляем в симулинке вручную. И сами матлабовцы такой подход находят оптимальным, причем по эффективности он почти не отличается от написанных руками дизайнов, но при этом гораздо быстрее в разработке и отладке. Да чего уж там - они сами предлагали моему же спецу проводить лекции по HDL Coder для них, так как сами не до конца понимают, для чего он нужен и как его правильно использовать.

Стоимость решения зависит не только от стоимости железа, а и от стоимости разработки. Если изделие не будет продаваться миллионным тиражом, стоимость разработки, раскиданная на количество выпущенных изделий, может быть в разы выше стоимости голого железа в этом же изделии. В итоге можно попытаться сэкономить на железе кукую-то копейку, всунув всю функциональность в более дешевую ПЛИС, но при этом потратив XXX денег на оптимизации, а можно просто взять ПЛИС подороже, но не заворачиваться с оптимизациями вообще, сократив время разработки вдвое, а то и втрое. И не факт, что в первом случае итоговая себестоимость одного выпущенного изделия будет ниже, чем во втором. И не факт, что решение в США будет таким же, как и решение в России (цена часа разработчика разная)

[syoma 1]

7 minutes ago, blackfin said:

А что там может быть из "сложного DSP"? У вас же, Энергетика? То есть, частоты сигналов низкие (~50 Гц), частоты дискретизации тоже едва ли больше 10 кГц, алгоритмы тоже простые - всякие PID'ы, простенькие FIR'ы, ну и БПФ "для приличия" на 1024 точки. Откуда там взяться "сложным DSP", ума не приложу.. :)

Ну не сонары и не радары, конечно. Семплируем не на 10кГц, а ближе к 250кГц. Всякие синхронизации, да PLL-лки. Для вас конечно, просто.