[des00 25]

вы очереди там планируете ставить только с grant, или forward_grant тоже планируется? а теперь подумайте над этим вопросом хорошо (а ведь я знаю, вы это можете) и ответьте, вы правда в это верите, или предпочетаете как в МикроСофт тянутся за продуктивносттью?(тогда не понимаю чем вас Виндоус для обсчёта ЦОС не устраивает)

про очереди не совсем понял. Расскажу на собственном опыте, сделав различные 4 модема в симулинке и железе, используя свои и готовые IP блоки, я не вижу никаких проблем генерации данных модемов из модели симулинка. Интерфейсы всех модулей стандартизированные, синхронные и документированные, соотношение интерфейсов стрелкам в симулинке один в один, тоже самое относиться и к функциональности модулей. Единственное отличие железа от модели только в наличии логики управления и контроля состояния, которые просто описываются в том числе и на M языке. Но в крайнем случае все это можно вывести из модели и подключить к сгенерированному модулю снаружи.

 

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

 

Я понимаю какие именно проекты вы имеете в виду, но это не значит что все проекты выполняются полностью такими. Все определяется размером "строительного" кирпича. Если есть стандартизированные интерфейсы , то ничего не мешает собирать такие системы из готовых компонентов тыкая мышкой (пример тот же SOPC Builder) и дописывая стыковую логику на каком нить более простом чем ХДЛ языке (например на том же ДРАКОНе - языке "домохозяек").

 

UPD вот простой пример будущего. Нужна например система автоматического регулирования : АЦП, фильтрация, ПИД регулятор, ЦАП. Для этого нужны компоненты в симулинке: модель стыка с нужным АЦП/ЦАП, цифровой фильтр и из кубиков собрать логику ПИД закона регулирования. В качестве первого приближения все делать на одной частоте. Собираем кубики и гоняем параметры нашей системы на моделях нужных нам объектов. Выбираем параметры и синтезируем модуль. Всё просто.

[CaPpuCcino 0]

Выбираем параметры и синтезируем модуль. Всё просто.

с этим поспорить не могу /тчк/

 

ЗЫ: есть только одно но: когда вы нажимаете play в своём видеопроигрывателе, кодеки, которые проигрывают ваш фильм, так не думают; ну а так действительно всё просто - смотря с какого уровня абстракции смотреть (правда это к HLS всё-равно никак не относится)

[cms 0]

des00 говорит мудрые вещи. Model-based system-Level design - это очень интересный вариант. Если посмотреть внимательнее, то окажется, что число используемых алгоритмов в ЦОС вполне себе счетное множество и спустя 10 лет устаканивается в набор эффективных параметризуемых блоков, из которых можно набирать 90% ЦОС систем. Ну а небольшую часть, содержащуюю новизну, можно и на верилоге подписать, если не верите в C или M code-based synthesis.

 

Кстати, SoPC builder отличный пример model-based synthesis. Главное его ограничение - отсутствие высокоуровневого моделирования.

[SM 0]

и спустя 10 лет устаканивается в набор эффективных параметризуемых блоков,

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

[cms 0]

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

 

Рынок профессии сжимается. Уходит рынок систем, остается только разработка компонентов. А в компонентах быстро насупает насыщение. Уже сейчас видно, что огромное количество народа пишет LDPC кодеки - потому как ничего другого писать не надо - там поптимальнее уже все сделано. С видео таже история - чуть ли ни каждый день появляются новые AVC кодеки.

 

2 des00: А что такое язык ДРАКОН?

[Mahagam 0]

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

ну а теперь пусть менеджер продаст это, ага.

 

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

[des00 25]

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

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

 

2 des00: А что такое язык ДРАКОН?

 

ДРАКОН (Дружелюбный Русский Алгоритмический язык, Который Обеспечивает Наглядность)

язык для "домохозяек"

 

 

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

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

 

UPD

но до сих пор визардами в любой IDE только рыба создаётся. а дальше её долго и упорно точат тыщи индусов.

и форум завален вопросами типа "Дайте корку/Подскажите где взять корку/Помогите скачать", при этом запросы уже идут на уровне готовых кодеков h.264 %) Готовая IP-корка и программистская рыба это разного поля ягоды.

[Mahagam 0]

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

вы не поняли идеи: получаемый из таких тулзов результат будет коммерчески нафик никому не нужен.

[SM 0]

вы не поняли идеи: получаемый из таких тулзов результат будет коммерчески нафик никому не нужен.

 

Не, тут будет 50/50, как сейчас в микроконтроллерах. Часть задач - стоимость пофигу, лишь бы быстрее-быстрее тяп-ляп и на рынок, а другая часть - экономим каждый цент, скорость разработки не сильно важна. Оно и сейчас уже отчасти так.

[des00 25]

вы не поняли идеи: получаемый из таких тулзов результат будет коммерчески нафик никому не нужен.

я понял вашу мысль, но ИМХО вы ошибаетесь. Уже сейчас генераторы кода с матлаба показывают результат ненамного хуже чем ручное кодирование, кроме того большая куча готовых компонентов (кодеки, контроллеры, блоки математики) дают результат не хуже чем ручное кодирование. И всё это используется в коммерческих продуктах.

 

Возьмите простой пример, корка ReedSolomon coder/decoder от альтеры предлагается за 4 килобакса, а теперь вопросы

1. За какое время вы напишите аналог этого кодера?

2. Сколько денег вы за это попросите?

3. Какой запас на компенсацию багов вы заложите в изделие со своей коркой?

И последний вопрос, а стоило оно того, для коммерческого продукта, а не для прямоты пальцев ? %)

 

Ответ "Ну я ее крякну" не принимается, это специфика стран третьего мира и когда нибудь в нашей стране это станет не актуально %)

[SM 0]

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

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

 

Готовая IP-корка и программистская рыба это разного поля ягоды.

 

А готовая IP-корка и готовая программистская либа - абсолютно одного поля.

[Mahagam 0]

я понял вашу мысль, но ИМХО вы ошибаетесь. Уже сейчас генераторы кода с матлаба показывают результат ненамного хуже чем ручное кодирование, кроме того большая куча готовых компонентов (кодеки, контроллеры, блоки математики) дают результат не хуже чем ручное кодирование. И всё это используется в коммерческих продуктах.

вы мне покажите эти коммерческие продукты.

 

Возьмите простой пример, корка ReedSolomon coder/decoder от альтеры предлагается за 4 килобакса, а теперь вопросы

я пока что понятия не имею о сложности рида-соломона. так что не могу судить.

но есть аж три крайне примитивных примера где готовые корки просто никуда не годятся:

1. MAC-Ethernet. требуется 2 глобальных клока 25MHz на один MAC. вопрос: как в спартан-3 у которого 8 линий глобального клока впихать 4 эзернета? при условии что минимум две глобальных линии уходят на собственные нужды проекта. дотачивать корку? а если она куплена и закрыта? а время на доточку не больше ли чем собственная разработка?

2. нужно делать ресемплинг входных 44100/48000/96000 аудиопотока в 48000. корка от хилых умеющая конвертить из любой частоты в любую, но с трудом влезает в нужный чип. даже если её бесплатно отдадут - она обойдётся в стоимость громадной площади кристалла. самопальный CIC-интерполятор получился куда как меньше. и обеспечил требуемое качество.

3. DDR-контроллер как часть видеоадаптера. нужно читать из памяти на скорости ~85-90% от теоретической пропускной способности. особенность чтения в том, что адрес последующих чтений можно предвычислить. корка от хилых, насколько я помню даёт только 40% от пропускной способности памяти. самопал (дублирование содержимого памяти в разные банки и ротация открытых банков) давал почти 98% пропускной (остальное кушала регенерация).

 

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

[SM 0]

но есть аж три крайне примитивных примера где готовые корки просто никуда не годятся:

1. MAC-Ethernet. требуется 2 глобальных клока 25MHz на один MAC. вопрос: как в спартан-3 у которого 8 линий глобального клока впихать 4 эзернета? при условии что минимум две глобальных линии уходят на собственные нужды проекта. дотачивать корку? а если она куплена и закрыта? а время на доточку не больше ли чем собственная разработка?

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

[cms 0]

Но только не небольшой. Так как у "тяп-ляпщиков" рынок широкий, то и у тех, кто им кубики поставляет, тоже не менее широкий. Есть очень много всяких разных параметров, по которым можно конкурировать в разработке этих кубиков. Плюс еще рынок массовых изделий с маленькими себестоимостями. А готовая IP-корка и готовая программистская либа - абсолютно одного поля.

К сожалению, немного не так. Рынок у поставщиков кубиков очень узкий. Если систем-интегратору нужен нестандартный кубик, он обращается к своему IP-вендору и просит подточить то что есть, а не начинает рыскать по помойкам. NXP вообще отказалось мультивендорных закупок IP, заключив экслюзивный договор на IP-обеспечение с VirageLogic, потому как так проще, эффективнее и дешевле. Тоже самое делают и остальные системщики - им нужно гарантированное качество, а не богатый выбор. Про массовый рынок с маленькими себестоимостями - тоже миф. Себестоимость 300-миллиметровой вафли по 65нм процессу ~2000$, и поджатие площади на 10% ничего не даст по сравнению с потерей полугода или дополнительной итерацией шаблона. Поэтому системщики ставят везде едножды опробованные IP и даже не смотрят на новые предложения, если они минимум в два раза не перебивают текущий вариант по параметрам. Такова реальность.

вы мне покажите эти коммерческие продукты.

Любой SoC.

но есть аж три крайне примитивных примера где готовые корки просто никуда не годятся:

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

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

[SM 0]

Себестоимость 300-миллиметровой вафли по 65нм процессу ~2000$, и поджатие площади на 10% ничего не даст по сравнению с потерей полугода

Ошибочка тут. Есть ОЧЕНЬ много изделий, стоимость кристалла ИМС у которых до полудоллара. И там экономия площади на первом месте. Так что кто сделал кристалл на 5 центов дешевле, тот и занял почти весь рынок (сам лично занимаюсь зверскими ужиманиями проекта ради одного-двух центов, и не без оснований рассказываю об этом). И ради этого полгода потратить - нефига делать, чем собственно и занимаюсь. И в этих проектах, кстати, 0.65 непозволительные расходы на подготовку, которые не окупятся лет так 10, и стоимость вафли мало кого уже интересует после стоимости масок.

 

Что касается монстров типа NXP - тут да, они договорятся с одним поставщиком IP, а скорее еще сами его себе родят. Туде влезать никто и не советует. А мелкие конторы будут искать IP подешевле. И это реальные реалии. И не надо реальности мерять одним примером монстра п/п промышленности.

 

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