[cms 0]

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

Узость зависит от ракурса наблюдателя. Если заниматься изготовлением дискретной логики (типа 8-битных контроллеров) или бюджетными FPGA-проектами, то да, там необходимо и технически возможно вылизывание топологии и ручное размещение каждого из 2000 гейтов. Но когда вы делает чип для очередного DVD-проигрывателя на пару миллионов гейтов, то тут лучше накидать проверенных корок, добавить новизны какой-нибудь собственным видеофильтром разработанным в матлабе, все это отверифицировать и через полгода уже отгружать кастомерам готовый SoC.

 

P.S. Проценты себестоимости ИМХО эффективнее отжимаются бухгалтерий и менеджментом, нежели утаптыванием кремния.

[SergeyF 0]

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

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

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

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

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

За три месяца. Единственное, менее гибко настраиваемую, для своих целей. Расширить на разные разрядности проблем нет. В отличие от Альтеры обрабатывает поток кадров переменной длины без пауз, вызванных дополнением кадра нулями в Альтеровском. И латентность выхода много меньше :)))

 

Я ее декриптовал ради интереса сначала, когда разбирался в теме. Верхний уровень там так накручен, что я смеялся и плакал. Явно писали в лоб, не думая о математике.

 

Замечу, что по тому же Риду-Соломону на IEEE куча статей по решателям вплоть до того, что мы переделаем уравнения вот так, это даст нам возможность переставить триггеры в аппаратной реализации Берлекемпа-Месси вот так, будет чуть быстрее, но чуть больше по объему, чем раньше. Сейчас таких статей меньше, так как, действительно, кодеры разработаны.

 

Но получается, что ученые формулируют алгоритм так, чтобы он эффективно отобразился в аппаратуру и думают о триггерах. И это дает возможность сделать эффективное аппаратное решение. Тот же вариант без дополнения нулями мы сделали сначала, подумав о операциях в поле Галуа. И какое здесь место архитекторам, которые не знают аппаратуры и формируют требования и кодерам, которые пишут код на C, если вернуться к началу темы? Можно еще о функциональных языках для HLS поговорить тогда - вроде бы тихо умерло направление, не так ли? Вот блоки в симулинке и стоящие за ними IP - с перспективностью такого подхода я согласен.

[cms 0]

За три месяца. ученые формулируют алгоритм так, чтобы он эффективно отобразился в аппаратуру и думают о триггерах. И какое здесь место архитекторам, которые не знают аппаратуры и формируют требования и кодерам, которые пишут код на C, если вернуться к началу темы? Можно еще о функциональных языках для HLS поговорить тогда - вроде бы тихо умерло направление, не так ли? Вот блоки в симулинке и стоящие за ними IP - с перспективностью такого подхода я согласен.

Три месяца московского инженера стоят больше 4k$. Архитекторы чипов очень хорошо знают аппаратуру, гораздо лучше RTL дизайнеров. На С (или матлабе) пишут ученые. А потом архитекторы, минуя стадию RTL-перекодирования, напрямую используют C-модели и для синтеза, и для верификации. Направление функциональных HLS языков не умерло.

[des00 25]

За три месяца.

вы ответили только на первый вопрос, а на остальные 3 %) Если предположить что вы точно уложитесь в 3 месяца, то корка в вашем случае будет стоить явно больше 4к, вы же не альтруист %)

 

Единственное, менее гибко настраиваемую, для своих целей. Расширить на разные разрядности проблем нет. В отличие от Альтеры обрабатывает поток кадров переменной длины без пауз, вызванных дополнением кадра нулями в Альтеровском. И латентность выхода много меньше :)))

вы про кодер или про декодер? В кодере да требуется небольшая пауза между пакетами и латеность выхода данных там 3 символа. А декодер работает без пауз с латентностью в 3 кадра.

 

Я ее декриптовал ради интереса сначала, когда разбирался в теме. Верхний уровень там так накручен, что я смеялся и плакал. Явно писали в лоб, не думая о математике.

Но ведь работает, и ТТХ выполняются, а то что проиграли 200 плиток на кодере и 800 плиток на декодере, какая разница...

 

Сейчас таких статей меньше, так как, действительно, кодеры разработаны.

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

 

И какое здесь место архитекторам, которые не знают аппаратуры и формируют требования и кодерам, которые пишут код на C, если вернуться к началу темы? Можно еще о функциональных языках для HLS поговорить тогда - вроде бы тихо умерло направление, не так ли?

а место такое, будет в матлабе функция rs_encode, а за ней будет скрываться реализация. Вот и не нужны кодеры, достаточно архитекторов %)

 

Вот блоки в симулинке и стоящие за ними IP - с перспективностью такого подхода я согласен.

:)

[SM 0]

Если заниматься изготовлением дискретной логики (типа 8-битных контроллеров) или бюджетными FPGA-проектами, то да, там необходимо и технически возможно вылизывание топологии и ручное размещение каждого из 2000 гейтов. Но когда вы делает чип для очередного DVD-проигрывателя на пару миллионов гейтов, то тут лучше накидать проверенных корок

 

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

 

PS. А что остается делать, если ты сам главбух у себя по совместительству? И уже что мог по этой линии, то утоптал?

 

PPS. У меня кстати, к примеру, есть проектик где +-10 баксов в себестоимости вроде как и процент незаметный, и вроде как и хрен бы с ним, ПЛИС пожирнее поставить, "сляпать", и ладно... Однако начинаешь считать - и вылезает, что посидев-поутаптывав, можно себе накинуть пару-тройку килобаксов в год... Вот и получается - быстро на корках в серию пустил, а потом спокойно себе поутаптывал, пооптимизировав и заменив корки на свои решения.

 

 

Если предположить что вы точно уложитесь в 3 месяца, то корка в вашем случае будет стоить явно больше 4к, вы же не альтруист %)

 

ВОТ! В том и суть. Что против проекта с купленной коркой, эта корка через какое-то время отобъет и себя, и начнет приносить дополнительную прибыль, если, конечно, за счет нее стоимость деталей устройства упала (а иначе по любому смысла нет). И если ты работаешь на себя, а не "на хз кого", и участвуешь в прибыли - то есть прямой стимул ее поднимать, уменьшая за счет своей работы (разовое вложение) себестоимость по деталям, чтобы потом постоянно получать и получать эту разницу. Тайм-ту-маркет - ну сделать сначала девайс на готовой корке, и потом спокойно соптимизировать. По любому работа по уменьшению стоимости комплектующих будет вознаграждена.

[Leka 1]

Википедия говорит, что манипуляция кубиками - уровень новорожденного:

http://ru.wikipedia.org/wiki/%D0%9C%D1%8B%...%BD%D0%B8%D0%B5

"Классификация по психическим процессам

- Наглядно-действенное (Форма мышления, манипулирующая предметной сферой. Имеется у новорожденных и детей до 1,5 лет)

- Конкретно-предметное (Задачи решаются с помощью существующего, реального объекта. Формирование в возрасте от 1,5 - до 7 лет)

- Абстрактно-логическое (Мышление абстракциями — категориями, которых нет в природе. Формируется с 7 лет. Считается, что у животных нет абстрактного мышления.) "

[CaPpuCcino 0]

А давайте поговорим о зебрах? Или на крайняк о кильватерном следе?

 

ЗЫ: может пора всё-таки прикрывать лавочку? я вот сразу предлагал в офф-топик тему переводить - флуд был обеспечен априори

ЗЗЫ: про мышление прикольно подмечено было ;)

[SergeyF 0]

вы про кодер или про декодер? В кодере да требуется небольшая пауза между пакетами и латеность выхода данных там 3 символа. А декодер работает без пауз с латентностью в 3 кадра.

Я об укороченных кодах. Попробуйте на их декодер подавать пакеты различной длины вперемешку. Он отказывается брать следующий укороченный пакет без паузы. Сбрасывает sink_ena. То, что сделал я, кушает все пакеты без перерыва, т.е. торможения входного потока при любом сочетании длин кадров от 57 до 228 символов. Может, конечно, в последних версиях модифицировали, но я в этом сомневаюсь.

 

Ну а то, что кодеру надо время вставить контрольные символы - это понятно. Больше ему никаких перерывов не надо.

 

После того, как вылижут LDPC, следующее поколение кодов все равно оптимизируют на уровне регистров и логики в IP-модулях исходя из чистой математики, а потом следующее и т.д.. Но я не вижу, где тут место высокоуровневого синтеза с C.

[SergeyF 0]

Три месяца московского инженера стоят больше 4k$. Архитекторы чипов очень хорошо знают аппаратуру, гораздо лучше RTL дизайнеров. На С (или матлабе) пишут ученые. А потом архитекторы, минуя стадию RTL-перекодирования, напрямую используют C-модели и для синтеза, и для верификации. Направление функциональных HLS языков не умерло.

Секундочку, мы начали разговор с того, что професия RTL дизайнера отомрет, так как архитектор описывает требования к модулям, а тупой кодер их реализует на C. Тут Вы нагружаете архитектора несколько иными функциями.

 

Откройте любую статью или книгу по кодам. Ведь читали, наверняка. Я там ни одной реализации на C не видел. Математика и схемы на уровне вплоть до регистров и логики. Примеры в большинстве случаев псевдокод или Матлаб. Зачем там архитекторы, если математики все придумали? Перелопачивать m-файлы или модели в симулинке в требования к программе на C?

 

Насчет направления функциональных языков. Я периодически смотрю работы, они есть. Но ни перспективы в них как-то не видно, ни тем более success stories. А если исходить из предположения, что надо отказываться от Verilog, потому что тупые C-кодеры и синтезатор все заменят, то совсем непонятно, зачем нужны функциональные языки, которыми владеют единицы, в таком контексте.

 

UML еще не вспомнили, кстати. :)

 

 

Но ведь работает, и ТТХ выполняются, а то что проиграли 200 плиток на кодере и 800 плиток на декодере, какая разница...

Справедливости ради, по объему я проиграл, но такой цели и не было. Цель была обработать непрерывный поток.

[cms 0]

ЗЫ: может пора всё-таки прикрывать лавочку? я вот сразу предлагал в офф-топик тему переводить - флуд был обеспечен априори

Ну не торопитесь пока. Лично мне интересно послушать SM, des00, Sergey'F - то что переодически вклиниваются флудовые посты ничуть не умалаяет ценности соержательных постов. А тема далеко не исчерпана - оно конечно очень хочется сунутьт голову с песок и твердить себе RTL-рулез, С - сакс, но жизнь-то не стоит на месте, подойдет сзади, да так что и голову вытащить не успеешь.

 

Секундочку, мы начали разговор с того, что професия RTL дизайнера отомрет.

 

Архитектор делает систему, в том числе и выставляет требования к модулям. При этом он отлично понимает как работает железо на всех уровнях. Прежде чем писать статью нормальные люди проверяют свои выкладки на софтварной модели - С или МАТЛАБ. Современный псевдокод - это выдержки из C. Хотя если вы имеете в виду книги 70-80х годов то да, там может быть что угодно. И первая практическая реализация алгоритма с большой вероятностью делается на DSP. Что вы понимаете под функциональными языками?

[SM 0]

Что вы понимаете под функциональными языками?

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

[CaPpuCcino 0]

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

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

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

кстати тот же MentorGraphics недавно вновь запустил синтез с SystemC уже в Катапульте. к чему бы это, если всё так хорошо ложится в untimed С?

 

сообщение было отредактировано автором

[SergeyF 0]

Что вы понимаете под функциональными языками?

Ну да, Haskell, ML и так далее.

Даже вот еще встречаются, чего-то обсуждают:

http://keel.martin-robson.com/hfl/hfl07/HF...-Programme.html

http://keel.martin-robson.com/hfl/hfl09/programme.html

Пытались одно время привязать к описанию аппаратуры. Чего только туда не пытались привязать.

[SM 0]

вновь запустил синтез с SystemC уже в Катапульте. к чему бы это, если всё так хорошо ложмтся в untimed С?

 

На мой взгляд совершенно ничего не ложится на untimed C. Оно с виду кажется, что ложится, а на самом деле - нет. Я бы сказал, что даже наоборот, на HDL описывается что угодно, и с HDL можно в равной мере синтезировать как схему устройства, так и программу, эмулирующую его работу и делающую ту же функцию, но при помощи последовательных вычислений на исполнительном устройстве. А программистам (а их много и они наглые и с амбициями) просто очень хочется вот так сразу, не изучая схемотехники, не изучая внутреннего устройства исполнительных/вычислительных устройств, не вникая в предмет, отсинтезировать по их программе чип. Лучшее, на что можно надеяться при таком подходе - синтез какого-то ядра, которое исполнит эту программу, ну и некое условное распараллеливание, может быть на несколько исполнительных устройств. Но все равно, количество тактов, затраченное на вычисление в результате синтеза с untimed C будет на околопорядок отличаться от изначально описанного устройства на HDL, и все равно будет синтезирован вычислитель (или несколько), исполняющий[ие] программы. Просто это совершенно разные подходы - программирование и описание устройств. Соответственно, все таки, на мой взгляд обозримое будущее за HDL, и SystemC один из них, а не за синтезом с С, который очень интересная игрушка, позволяющая программерам почуствовать себя разработчиками железа, но результаты этой игрушки далеки от идеала, и еще пока будут далеки довольно долго. Ментор это понял, что все таки SystemC для дела-то важнее и нужнее, и вернул его. А реального толку от синтеза с С не будет (ну кроме разве что возможности позагибать пальцы прогаммерам, какие они типа крутые), пока не придумают алгоритм преобразования программы в набор параллельных математических (в широком смысле, не только алгебра, а и дискретная математика) функций с последующим синтезом с них железяки с попутной конвейеризацией. Софта, который это нормально делает, сейчас нет, и не думаю, что появится в обозримом будущем (лет так 10).

[CaPpuCcino 0]

+1, даже про "лет 10" совпадаем