[dxp 33]

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

FPGA дизайнер получается.

Если речь о ПЛИС, то железо уже создано. Остаётся только его запрограммировать, определив логические функции на имеющиеся логических блоках и соконфигурировав межсоединения между ними.

[bogaev_roman 0]

А кто такой программист? Вообще? И почему человек, занимающийся программируемыми логическими схемами (aka ПЛИС) является не программистом, а неким схемотехником? Я вот вообще не понимаю, причём тут схемотехника. Схемотехника - это проектирование схем, т.е. проектирование устройств в графических моделях. А в ПЛИС рулит HDL, т.е. язык.

Регулярно встречается термин FPGA программист.

FPGA дизайнер. HDL - язык описания цифровой аппаратуры, дискретных устройств. Да, есть схожесть с языками программирования, но создан он для других целей. Конечно, если использовать скажем SV для верификации со всеми возможностями, то это уже будет подобно программированию. Я же веду речь лишь применительно к синтезируемым конструкциям. Конструкция на verilog/vhdl будет воспринята синтезатором/разработчиком как конкретное логическое устройство - шифратор/мультиплексор/память, а не некое абстрактное понятие. И схемотехник, а не программист рассчитывает все эти блоки и соединяет их между собой с учетом особенностей архитектуры конкретной ПЛИС.

[ViKo 1]

Если речь о ПЛИС, то железо уже создано. Остаётся только его запрограммировать

Э-э-э... запрограммировать... :crying:

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

И только потом запрограммировываю... :) Никто мне ничего не создает.

Неподалеку от ПЛИС у меня микроконтроллер. Его тоже запрограммировываю :)

[dxp 33]

FPGA дизайнер. HDL - язык описания цифровой аппаратуры, дискретных устройств. Да, есть схожесть с языками программирования, но создан он для других целей. Конечно, если использовать скажем SV для верификации со всеми возможностями, то это уже будет подобно программированию.

Как насчёт SystemC? Или работы с CUDA? Или когда уже и на настольном компе стоит энядерный процессор и там реально происходит распараллеливание выполнения программы? Чем это принципиально отличается от написания программы на HDL?

 

Я же веду речь лишь применительно к синтезируемым конструкциям. Конструкция на verilog/vhdl будет воспринята синтезатором/разработчиком как конкретное логическое устройство - шифратор/мультиплексор/память, а не некое абстрактное понятие. И схемотехник, а не программист рассчитывает все эти блоки и соединяет их между собой с учетом особенностей архитектуры конкретной ПЛИС.

А что мешает программисту рассчитывать все эти блоки, какими они будут, как они будут соединены, как они будут работать? Почему вы отказываете программисту в этом? Ведь и при написании программы для обычного микропроцессора, но работающего под управлением вытесняющей ОС, скажем, с карусельным планировщиком, программист должен иметь в виду, что у него куча кода выполняется параллельно (во всяком случае - логически), и должен заботится от синхронизации между этими параллельно выполняемыми [алгоритмическими] блоками.

 

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

[bogaev_roman 0]

Как насчёт SystemC? Или работы с CUDA? Или когда уже и на настольном компе стоит энядерный процессор и там реально происходит распараллеливание выполнения программы? Чем это принципиально отличается от написания программы на HDL?

Здесь я ничем не могу ответить, ибо в данном вопросе некомпетентен.

А что мешает программисту рассчитывать все эти блоки, какими они будут, как они будут соединены, как они будут работать? Почему вы отказываете программисту в этом?

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

Не раз видел, когда программист "программируя" алгоритм на ПЛИС вместо структуры case использует кучу вложенных if, или использует схему с нереальной разрядностью с использованием деления, а потом удивляется почему у него все это не влазит или работает не на сотни мегагерц, а на килогерцах.

Изменено 8 июня, 2011 пользователем bogaev_roman

[RobFPGA 27]

Приветствую!

 

Все эти "звездные войны" 'схемотехник by программист' происходят из за стереотипов и узости восприятия соответствующих терминов.

Поскольку скорости развития технологий и инструментов в этих областях действительно космические.

Первые проекты я рисовал в MaxplusII и не представлял что можно как то по другому. К слову как раз дружественный интерфейс MaxplusII очень сильно помог в быстрой адаптации к "виртуальному железу". Однако лень как известно двигатель прогресса :) и когда рисования стало мало начался переход от рисования схемотехники к программированию железа.

Сейчас различные инструменты разработки позволяют выбрать каким способом вы будете реализовывать ваше устройство. Можно ПРОГРАММИРОВАТЬ железо в FPGA. Можно РИСОВАТЬ схемы для генерации программ в DSP. В обоих случаях результат будет зависит в первую очередь от КВАЛИФИКАЦИИ разработчика и понимании им того что он делает и с чем работает. Особенно это важно в области обработки сигналов.

 

Успехов! Rob.

 

 

[dxp 33]

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

Не раз видел, когда программист "программируя" алгоритм на ПЛИС вместо структуры case использует кучу вложенных if, или использует схему с нереальной разрядностью с использованием деления, а потом удивляется почему у него все это не влазит или работает не на сотни мегагерц, а на килогерцах.

Ну, так тут вопрос просто в квалификации. Если человек, много писавший на РС, начинает писать программу на tinyAVR и не вникает в особенности целевого МК, не представляет, во что выливаются его конструкции на С при кодогенерации, то результат будет плачевен. И, вроде, тут уж точно все программисты - и для РС, и для МК.

 

По вашим аргументам получается, что "программист" - это человек, который берётся за низкоуровневое программирование, но не разбирающийся в нюансах целевой платформы. Будь то МК или ПЛИС. Ровно та же ситуация, кстати, и при программировании с использованием CUDA - без чёткого понимания, как там оно структурно организовано, что может выполняться эффективно, а что нет, без знания всех этих системных нюансов целевой платформы успеха не достичь.

 

Да и схемотехники на ПЛИС как таковой нет - схема там почти готовая, а работа сводится к заданию логических функций и передаче возвращаемых значений (выходов) одних функций в качестве аргументов другим (на входы). Программирование, то бишь. Только с использованием в качестве целевой платформы структуры с аппаратными параллельно работающими ресурсами. Что, кстати, вполне справедливо и для той же CUDA.

 

Термин "схемотехника", используемый в контексте ПЛИС, возник исторически и до сих пор жив, пока живы соответствующие стереотипы. Но уже недолго осталось. :)

[RobFPGA 27]

Приветствую!

 

Термин "схемотехника", используемый в контексте ПЛИС, возник исторически и до сих пор жив, пока живы соответствующие стереотипы. Но уже недолго осталось. :)

 

 

Вот вот - как только уйдут монстры схемотехники которые еще помнят то время когда триггеры были большими (155TM2 DIP14) :)

 

Успехов! Rob.

[sasamy 9]

Термин "схемотехника", используемый в контексте ПЛИС, возник исторически и до сих пор жив, пока живы соответствующие стереотипы. Но уже недолго осталось. :)

 

Даже очень недолго :-) За дело уже взялись крупные игроки

http://newsroom.intel.com/community/intel_...90004-c1-262281

 

Microsoft так уже давно этими вопросами занимается

http://research.microsoft.com/apps/pubs/de...t.aspx?id=71425

[bogaev_roman 0]

Да и схемотехники на ПЛИС как таковой нет - схема там почти готовая, а работа сводится к заданию логических функций и передаче возвращаемых значений (выходов) одних функций в качестве аргументов другим (на входы). Программирование, то бишь. Только с использованием в качестве целевой платформы структуры с аппаратными параллельно работающими ресурсами. Что, кстати, вполне справедливо и для той же CUDA.

Хорошо, а что тогда в Вашем понимании вообще цифровая схемотехника? Я, например, считаю что логика работы основных устройств и задание логических функций это и есть именно она, а не программирование. И тогда объясните мне, почему ООП и Паскаль изучаются на 1-2 курсах института, а языки описания дискретных устройств (кстати также как и DSP) на 3-4 и только после цифровой схемотехники и дискретной математики? И еще - что значит

схемотехники как таковой нет

, что в ПЛИС уже есть готовые шифраторы, конечные автоматы или их самому наворотить надо? Тогда нафиг вообще знать что такое триггер и счетчик? И вообще - почему разработчики до сих пор полностью не перешли скажем на xilinx core generator - чего там - взял модель матлаба, разрисовал ее из xilinx блоков и все - готовый синтезируемый RTL?

[[email protected] 0]

Есть вариант - посмотри http://www.xmos.com/

 

Дешевые чипы с параллельной обработкой, поддержкой функций DSP (на среднем уровне), программируются на С/С++ с open-source средой, отладчиком, симулятором... Сам захотел пока писал :)

[dxp 33]

Хорошо, а что тогда в Вашем понимании вообще цифровая схемотехника?

Как следует из самого термина, схемотехника - это создание устройств (систем) путём организации межсоединений между готовыми элементами. Цифровая схемотехника - подраздел, где элементы имеют выходы и выходы, способные работать с сигналами, представляющими собой логические уровни. Это позволяет драматически уменьшить требования к качеству передаваемых сигналов, но в то же время порождает свои специфические нюансы:

• сигналов в таких схемах, как правило, много больше, чем в аналоговых;
• сигналы являются быстроизменяющимися во времени (фронты), что накладывает требования на конструкцию (проблема целостности сигналов);
• возникают сопутствующие проблемы с организацией питания (быстродействующие импульсные токи) - обилие развязывающих конденсаторов, SSN и т.п. - тема достаточно непростая.
• организация схемы (и топологии конечного устройства) так, чтобы времена распространения сигналов были учтены и не возникало нарушения логической целостности работы устройства из-за гонок (один из способов борьбы - использование синхронного дизайна, который является основным при разработке устройств на FPGA по причине того, что сам класс этих ПЛИС спроектирован для организации дизайна именно по этому методу.

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

 

Когда этот конечный пользователь пересел на ПЛИС, он фактически перестал быть схемотехником (кроме вопросов, связанных со схемным обрамлением ПЛИС на печатной плате). Все вышеперечисленные вопросы внутри ПЛИС он уже не решает, а остаётся ему только запрограммировать совокупность готовых функциональных блоков под свои нужды. И даже когда он рисует схему - эта схема не является той принципиальной моделью, каковой она была в случае реализации в виде печатной платы, а тут схема - это функциональная модель, которая описывает только алгоритм. А конечная точная принципиальная модель получается уже после синтеза. Т.е. по сути "схемотехником" в каком-то смысле являются синтезатор и P&R.

 

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

 

Поэтому по большому счёту нет никакой принципиальной разницы, как вводится функциональная модель - текстом на HDL, схемой, в виде временных диаграмм, на основе блок-схемы и т.п. - это всё является программированием, отличающимся только способом ввода модели

 

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

А на Си вы когда пишете программу - вот все эти функции, передача аргументов при вызове одних функций из других, разве это не задание логики работы? А когда у вас тестбенч работает на HDL - это не программа? И когда вы пишете этот код, который будет исполнятся на симуляторе и который впоследствии будет обработан синтезатором - это не один и тот же код? Да, понятно, что синтезируемый код должен разрабатываться с учётом известных ограничений и нужно иметь всё это в виду, иначе удачи не видать, но принцип от этого не меняется.

 

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

 

И тогда объясните мне, почему ООП и Паскаль изучаются на 1-2 курсах института, а языки описания дискретных устройств (кстати также как и DSP) на 3-4 и только после цифровой схемотехники и дискретной математики?

Ну, ООП на первом курсе - это уровень так себе, скорее просто познакомить с термином и слегка ввести в курс дела. Паскаль же сам по себе очень простой язык (почему и снискал популярность). А почему ПЛИС идёт позже - это естественно: программирование параллельных систем много сложнее программирования последовательных. И как уже говорилось выше, надо всегда включать голову при разработке этих вещей, поэтому совершенно необходимо иметь представление о том, как там оно внутри реализовано. Например, реализация логики в FPGA осуществляется на основе LUT - таблицы данных. Которая представляет собой не что иное, как память с организацией Nx1. А что такое память, какие бывают её виды, какие преимущества и недостатки у них имеются - это всё надо знать хотя бы на уровне общего представления.

 

Аналогично по устройствам хранения информации - триггерам. Поэтому сперва нужно человеку дать основы аппаратной части, потом уже учить программированию на её основе. Сам этот принцип универсален и применим, например, к тому же программированию МК, т.е. устройства с очень ограниченными ресурсами. Программист должен очень хорошо представлять, во что выливаются его конструкции на Си (if'ы, for'ы, вызовы функций и т.п.).

 

И еще - что значит , что в ПЛИС уже есть готовые шифраторы, конечные автоматы или их самому наворотить надо? Тогда нафиг вообще знать что такое триггер и счетчик?

Это частный вопрос о том, на какой степени детализации реализованы внутренние программируемые блоки. Например, полно ПЛИС с готовыми аппаратными устройствами в виде контроллеров памяти, DSP блоков и т.п.

 

Что касается "знать", то для достижения эффективности знать надо всегда. И не только в области ПЛИС, но и традиционного программирования тоже. Про CUDA уже говорил, но и для настольных РС всё это справедливо - если пишете программу, которая должна рабоать максимально эффективно и выжать всё из целевой платформы, то надо эту платформу знать - например, сколькиядерный процессор, и как эти ядра меж собой взаимодействуют, как разложить потоки по ядрам и как организовать синхронизацию между ними. Область другая, нежели плисоводство, но суть ровно та же.

 

И вообще - почему разработчики до сих пор полностью не перешли скажем на xilinx core generator - чего там - взял модель матлаба, разрисовал ее из xilinx блоков и все - готовый синтезируемый RTL?

А такая тенденция уже давно есть. И не только на основе генератора, а прямо из матлаба. Или эта софтина Synphony от синопсиса (Synplify). Тендеция, кстати, такова, что по мере увеличения ресурсов ПЛИС меньше приходится тратить времени и сил на оптимизацию алгоритмов. В пределе это сводится к тому, что алгоритм описывается вообще на высокоуровневом языке типа Ruby, Python или даже функциональных языках, а синтезатор делает реализацию. Пока этот путь далёк от эффективности, поэтому массового перехода нет. Но тенденция устойчивая.

 

Эта же тенденция была и остаётся в области традиционных компьютеров. Ещё 20-30 лет назад писать программы для настольных компьютеров на ассемблере было часто оправдано и эффективно, а сегодня в ходу языки, где одна строчка кода делает работы, как сотни строк на асме. Да, на асме это можно было бы реализовать куда эффективнее (наверное даже в разы, если не в десятки раз), но если производительность алгоритма на современной платформе устраивает, то кого это волнует?

[Herz 4]

не знаю чем заняться, что бы не оказалось что время потрачено зря...

 

Водку пейте. И не терзайте себя глупостями. С утра не принял - день потрачен зря.

А если серьёзно, вопрос не должен так стоять вообще. Займитесь и тем, и другим. Развитие извилин ещё никогда зря не проходило.

[Mahagam 0]

А такая тенденция уже давно есть. И не только на основе генератора, а прямо из матлаба. Или эта софтина Synphony от синопсиса (Synplify). Тендеция, кстати, такова, что по мере увеличения ресурсов ПЛИС меньше приходится тратить времени и сил на оптимизацию алгоритмов. В пределе это сводится к тому, что алгоритм описывается вообще на высокоуровневом языке типа Ruby, Python или даже функциональных языках, а синтезатор делает реализацию. Пока этот путь далёк от эффективности, поэтому массового перехода нет. Но тенденция устойчивая.

 

Эта же тенденция была и остаётся в области традиционных компьютеров. Ещё 20-30 лет назад писать программы для настольных компьютеров на ассемблере было часто оправдано и эффективно, а сегодня в ходу языки, где одна строчка кода делает работы, как сотни строк на асме. Да, на асме это можно было бы реализовать куда эффективнее (наверное даже в разы, если не в десятки раз), но если производительность алгоритма на современной платформе устраивает, то кого это волнует?

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

[RobFPGA 27]

Приветствую!

 

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

 

Как это ни печально - как раз такой подход сейчас очень активно развивается/применяется. И иногда очень даже успешно. В Matlab набросали кубиков из Xilinx SystemGenerator - ап - и модуль обработки готов! При этом люди рисующие кубики о FPGA до этого ничего не знали - только прослушали 2-х недельные курсы обучающие работе с SystemGenerator!. Естественно в трюмах этого красивого лайнера мечты во всю трудятся кочегары/системщики перелопачивая горы угля/кода. Но их всего 2 а вот пассажиров на этом корабле много!. И корабль плывет!!!

 

 

Успехов! Rob.