v_mirgorodsky

Каденс я тест-драйвил, для рисования отдельных плотных целов времени тратится раза в 4 больше, чем в электрике :( Или я не правильно методологически их там рисую, либо под кастом каденс заточен слабо. Дело в том, что в электрике каждый кусочек металла представляет собой арку, т.е., связь между двумя точками. Далее я могу перемещать компоненты и части металлов относительно друг друга без нарушения связности. Условно говоря, выбрать и подвинуть на 50nm все p- или n-транзисторы для электрика есть тривиальная задача. Может я не до конца разобрался, но в Каденсе подвинуть десяток транзисторов у меня заняло минут пять. Плюс к этому в электрике есть встроенный простой DRC и совсем неплохой LVS. Фактически, к услугам внешних DRC и LVS программ я прибегаю после завершения сравнительно крупного блока. Плюс в электрике есть совершенно поразительный режим с альфа-блендингом. Фактически все элементы имеют некую прозрачность, что позволяет видеть ситуацию с металлами и переходными отверстиями на выбранном участке дизайна без лишних движений просто на экране. Разобраться с ходу в каденсовском штриховом кодировании у меня так сразу не получается - может я не привык еще к картинке, а может куча прямоугольников в одном месте с разнообразными штриховками и не предполагает понимания топологии участка дизайна "с ходу" :( Я конечно понимаю, что воспользовавшись горячими клавишами подвязанными к разным конфигурациям фильтров я могу упростить картинку для себя, но в электрике я вижу это все совершенно без лишних движений. Таких вот мелочей, положительно влияющих на производительность труда в электрике очень много. Может быть я слишком многого хочу, но работать с Каденсом мне не понравилось. Я как-бы понимаю, что 28nm - это последний процесс, в котором использование электрика все еще возможно ввиду отсутствия дабл-паттернинга на металлах. Понимаю, что при отсутствии альтернатив таки придется подружиться с Каденсом, поскольку поддержка дабл и трипл паттернинга официально есть только в нем. Однако никто не мешает мне поискать альтернативы пока еще позволяет время.

Жаль, придется использовать существующую методологию. Асинхронные схемы обладают просто громадными преимуществами по сравнению с синхронными схемами, однако поддержка их проектирования со стороны существующего софта отсутствует как факт.

А кто говорит о бесплатном софте? Меня интересует хороший удобный пакет для кастом-дизайна, его бесплатность на данном этапе уже была бы минусом, поскольку теперь мне нравятся поддерживаемые и развивающиеся продукты ;)

Доброго времени суток, В последнее время много работаю с фулл-кастомом. Сейчас для рисования схем и топологий использую GNU Electric. В самом начале пути относился к пакету скептически, считал его жуткой недоделкой но время поджимало и варианты искать другой тул не рассматривались. После года работы с электриком мне он больше не кажется таким уж плохим тулом. Он особенный, некоторые вещи сделаны в нем сильно неоптимально, однако свою функцию он успешно выполняет. Для скептиков, чип на 80млн. транзисторов с интеграцией покупных IP блоков для него оказался вполне подъемной задачей. К сожалению, электрик больше не развивается, поскольку после покупки Sun Oracle разработка процессоров стала не приоритетной. Вот, собственно, и вопрос. Что бы можно было посмотреть в качестве альтернативы?

Доброго времени суток, Собственно - $subj. Изучаю вопрос проектирования чипа с использованием асинхронных пайплайнов. I.E. Sutherland, ‘‘Micropipelines’’ неплохо описывает концепцию и дает понимание о том, как работают вычислители при таком подходе, однако как делать управляющие стейт-машины в этой работе не рассматривается. Подход, предложенный в ASYNCHRONOUS FINITE STATE MACHINE DESIGN: A LOST ART? Christopher Carroll, University of Minnesota-Duluth мне не понравился. Другие книги, которые я просмотрел по теме, учат вариациям на тему той-же методологии, однако кардинально ничего не улучшают. В результате асинхронные стейт-машины представляют собой диких паучков из нандов и норов с обратными связями, крайне тяжело модифицируются, плохо верифицируются, короче - обладают целым рядом недостатков, делающих их реальное применение неоправданно дорогим и сложным. Есть ли у кого мысли как упростить этот процесс и сделать его более простым и контролируемым?

Доброго времени суток, Ну что, ответ от eASIC я получил. Они хотят денег за подготовку, после продают чипы сравнительно дешево, по той цене, о которой мы договоримся с ними в момент начала работ. После фазы НРЕ заказывать чипы можно любыми партиями, количество в 10к за год для них вполне нормальное. На выбор предлагаются два решения - 90нм и 45нм. Подготовка на 45нм существено дороже. Контора обладает своими тулзами для разработки. Сами чипы чем-то напоминают однократно программируемые FPGA - роутинг и настройка лютов осуществляется однократным прожиганием переходных отверстий в нужных местах. По скоростям обещают 500МГц. Дальше собираемся работать в двух направлениях - первое, попробуем прикинуть стоимость разработки и производства с честным Structured ASIC по какому-нибудь сравнительно "толстому" тех-процессу с самым простым возможным корпусом, второе - продолжим разговаривать с eASIC. К сожалению, у подходящих по размеру eASIC-ов очень большие BGA-шные корпуса, а я слышал, что именно корпус является самой дорогой частью в готовой микросхеме. Может получиться, что Structured ASIC по "толстому" тех-процессу в результате окажется дешевле :) BTW, с eASIC тех-процесс выбирают они сами. Если нам по ресурсам подойдет только 45нм nExtreme2 - придется работать с 45нм nExtreme2. Логику из устройства выкинуть не получится.

Спасибо за консультацию, какая-то совсем нерадостная картина получается :( Ладно, подождем ответов от eASIC, может не все так плохо окажется :(

Девайсов нужно 10000. Я так думал, что eASIC предлагает весь НРЕ сделать в пределах этих самых $45k, а потом можно пытаться штамповать девайсы пачками. Собственно на это и был весь расчет. Я ошибся? Есть вариант дизайна на чистом VHDL совершенно без примесей платформенно зависимых элементов самого Spartan6. Есть и результат ручной оптимизации/выпиливания под его архитектуру, однако приемлемой частоты все равно достичь не удалось. Очень бедные роутинговые ресурсы внутри кристалла. Вариант 1 не подходит по умолчанию. Их Easy-Path это все тот-же Spartan6 с жестко загруженной прошивкой - дорогое и неэффективное решение. А еще очень прожорливое по мощности. Вариант 3 тоже сомнителен из-за отсутствия необходимых навыков да и нет необходимости эмулировать Spartan в ASICe. Думаю, что существующее описание должно неплохо подойти для варианта 2. Собственно, осталось понять как наиболее эффективно получить желаемый результат в железе с минимальной стоимостью чипа и минимальной стоимостью НРЕ. Может кто может поделиться тулзами для eASIC? Там дают тулзы на покататься на 30 дней, запрашивать уже начали, но похоже, что получим мы их совсем не скоро. А решение хотелось бы принять уже сейчас. Может наш дизайн окажется трудно совместим с eASIC, поскольку создает очень серьезную нагрузку на роутинг между элементами дизайна. BarsMonster, а откуда такая оценка по стоимости? Если eASIC делает 45 чипов за $45k, то не в убыток же себе они их делают?

Доброго времени суток, Есть дизайн крипто-сопроцессора в Spartan6 LXT150 FPGA. В чипе 180 тысяч логических блоков и триггеров. Дизайн использует около 90% ресурсов. Как перевести эти цифры в гейты - не знаю. Из самой быстрой FPGA удается отжать частоту порядка 250 мегагерц, вендор X согласился продавать микросхемы немногим дешевле их розничной цены на Digi-Key, что практически убило возможность успешного коммерческого использования девайса на этом чипе. В качестве выхода из сложившейся ситуации рассматривается переход на ASIC. Ожидается, что тактовая частота будет не хуже 450 мегагерц, а стоимость готового чипа сравнимого объема не выше $15 в партиях до 10 тысяч штук. В качестве варианта рассматривается eASIC. У них там есть некая акция вида - $45к - 45nm - 45 девайсов на выходе. Это предложение включает полный цикл НРЕ и 45 самплов на выходе. К сожалению, опыта проектирования ASIC у меня нет совсем. Есть значительный опыт проектирования FPGA, но здесь он применим слабо. Хотелось бы понять, какие трудности ожидают на этом пути, реальны ли частоты и цены на чипы и с чего надо начинать. Заранее, спасибо всем :)

Исследовались, но дело не в железе, а в операционной системе. А ни одна из существующих ОС поддерживать этот режим не собирается. Поддержка в железе виртуальных каналов заявлена, но не отлажена, поскольку нет софта, который бы этим хотел воспользоваться. В слоте видеокарты она живет хорошо. Только вот слотов видеокарты в современных компах мало :)

Ну, раз никто мне не отвечает, придется самому ;) Изохронный режим передачи данных по PCI-e не поддерживается ни одной из существующих ОС. Вот так вот грустно... Нельзя гарантировать, что поддержка такого режима никогда не появится в будущем, но если это и произойдет, то отнюдь не скоро. Люди в MS считают, что реализация и поддержка этого механизма бесперспективна... Потому рассчитывать на такую возможность в будущем опрометчиво.

Vladimir_SE Вы из Киева? Я с трудом могу представить как организовать удаленную работу над этим материалом :( Есть ли примеры ранее успешно выполненых работ?

Доброго времени суток, Украина, Киев Что есть: Наша компания разработала библиотеку функций по работе с нашими устройствами захвата видео информации. На данный момент существует несколько разрозненных файлов, описывающих различные аспекты функционирования библиотеки и описание функций. Существующее описание написано по русски, "корявым" програмистским языком. В документах предприняты некоторые усилия по форматированию текста, однако до хорошего "читабельно/юзабельного" вида не доведено. Что требуется: 1. Критически оценить уже готовые материалы. 2. Привести стилистику описания в соответствие с требованиями к читабельности. 3. Используя уже готовые описания и технические подробности скомпилировать мануал по работе с библиотекой. 4. Восполнить при необходимости при полном содействии со стороны авторов зияющие пробелы в документации, если таковые будут обнаружены. Пожелания к кандидату: 1. Техническое образование. 2. Примеры успешно выполненных к текущему моменту работ.

Не нормальный, работать совсем не будет :( У кондеров есть такой специфический параметр, как ESR. У керамики ESR низкий, у танталовых конденсаторов он сравнительно высокий, у советских алюминиевых конденсаторов он запредельный :) Телепатирую: исходя из моего опыта, речь идет о 2.2μF - керамическом конденсаторе, а 22μF возле процессора - такой себе танталовый конденсатор. У "того" кондера на 2.2μF ESR лежит далеко за границами реально доставаемого в нашей местности, а стоимость его за штучку в небольших партиях может составить порядка $0.5 за один. Потому не ведитесь на красивую цифирьку 2.2, а ставьте доставабельную керамику микрофарад на 10, дабы обойтись без следующих итераций разводки платы хотя бы в этом вопросе. То же самое относится и к кондеру на питании самого проца. Вы то не знаете что сделали буржуи и какие параметры у кондера который они поставили - правильно? Потому 22μF танталового конденсатора - это минимально допустимая емкость блокировки по рейлу питания для слабо потребляющего процессора. В ряде случаев она может оказаться недостаточной. И еще, 22μF - это очень небольшой танталовый конденсатор типоразмера А. Для справки, есть еще типоразмеры B, C, D и E. Вот последние в списке действительно большие и очень дорогие. Да, и как сказал(а) DpInRock, необходимо также рассыпать в непосредственной близости от пинов керамику на 0.1μF - без этого тоже не "взлетит" :)

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

Исходя из задаваемых вами вопросов проект h.264 Encoder на ПЛИС не для вас. Готовые реализации h.264 Encoder стоят очень больших денег. В общем доступе возможно можно найти нечто типа Base Profile, с сильно обкоцаными возможностями. По быстродействию - да, реализация на 50-баксовой ПЛИС обставит по скорости обработки все существующие на сегодняшний день ДСП. Практически любая реализация также потребует наличие в системе высокоскоростной динамической и статической памяти.

Сделали устройство на XIO2000A. На вторичном сегменте PCI запустили нашу FPGA, которая порождает поток данных порядка 170-180МВ/сек. И тут выяснился небольшой облом - на старых чипсетах пролетает все с легким свистом, чем чипсет новее, тем больше полезных данных приходится просто выбрасывать по ходу дела. Естественно, ситуация напрягла, и по этому поводу были отправлены несколько запросов в Интел. После долгой переписки выяснилось, что скорость на сегменте PCI-e на слотах, подключенных к Южному мосту "режут" специально. И чем новее чипсет, тем меньше полоса выделяется для всех "южных" слотов PCI-e. В качестве припарки больному Интел посоветовал активировать изохронный режим передачи данных по PCI-e. Быстрое изучение регистров XIO2000A обнаружило требуемые области для инициализации. Только вот ничего это не дало. Скорость так и осталась нестабильной во времени и низкой в среднем. Возникло два подозрения. Первое - неверная конфигурация регистров XIO2000A, второе - для реализации изохронной передачи необходима нативная поддержка PCI-e со стороны самой ОС. В обоих случаях нагуглить ничего не получилось. Собственно, вопрос. Знает ли кто что-то большее по теме?

Хороший подход, но сложный :( Как-то отлаживал грамматику собственного скриптового языка на YACC - отладил, но было очень долго и кошмарно ловить некоторые ошибки на стыке связки парсер - лексический анализатор. А вообще-то, в инете существуют стандартные уже написанные грамматические файлы определений под YACC для распространенных языков программирования. Встречал C/C++, Basic, Pascal. Думаю, что и Verilog в их числе. Может таким образом будет проще.

Может я чего-то не понимаю, а может, есть действительно реальная необходимость в использовании решений типа PEX8311AA? В чем его преимущество перед стандартным мостом PCIe-PCI? Тем более, что мост PCIe-PCI доступен как минимум от трех разных производителей, а PEX8311AA аналогов у других производителей не имеет. В нашем случае мы использовали мост PCIe-PCI XIO2000A. Максимальная производительность линка зависит от конкретного чипсета, но на цифру порядка 160MB/sec в сторону памяти компьютера от PCIe платы можно рассчитывать всегда. Пишем мастером, мастер реализован в FPGA Cyclone III, работаем на 66Mhz PCI шине. К недостаткам решения относится полудуплексная передача данных - общий недостаток PCI как таковой, сравнительно медленная скорость чтения данных из памати компьютера - порядка 100MB/sec, относительная сложность отладки готового устройства. Лучших результатов можно достичь только имея встроенное в проект ядро, однако в нашем случае это приводит к неоправданному и сильному удорожанию всего проекта.

Это в Москве что ли? Так в теме же написано - Киев ;) Для Киева $1500 - вполне разумная сумма за полный рабочий день. Больше - это уже аутсорсинг или зарубежные представительства. beer_warrior Вы бы зашли к людям, поговорили. Может, если ваша практическая ценность так же высока как и ваше самомнение, то люди может и скорректируют предложение лично для вас :)

Нет, у нас все попроще. У нас многоканальные системы сжатия изображений. Для облегчения процесса отладки мы подключили кодек на PCI в качестве таргета и кормим его некими исходными данными - благо есть софтовая реализация того же алгоритма на C++. Для отладки был написан некий специализированный драйвер, были выведены точки обмена информацией и несколько пользовательских функций, которые можно переопределять на этапе компиляции :) Если ошибка не находится сразу, приходится те же данные "гнать" через симулятор, что уже намного дольше и сложнее. Так мы и живем. Такой подход позволяет достаточно легко "ловить" ошибки реализации, однако целостной картины жизни пректа не дает. Вот для этих целей я и пытаюсь найти платформу, которая позволит увидеть всю систему в целом.

Уважаемый CaPpuCcino, А можно примеры реального инструментария, который все это "тянет"? А еще, какие бы книги вы бы посоветовали для начала? Мы пишем для альтеровских FPGA, для RTL описаний используем VHDL, укладываем готовые устройства во вторые Cyclone. К счастью, наши проекты пока не такие огромные, что описанные вами методики становятся единственным возможным вариантом проектирования, но отголоски тех проблем я начинаю ощущать уже сейчас. Основной проблемой является попробовать нечто "а что будет, если..." На текущем этапе развития приходится городить сложную модель на C++, генерировать из нее даные, кормить ними синтезатор - короче, очень затратно и по времени и по ресурсам. Другой очень существенной проблемой является перевод модулей с одних принципов построения на другие. Просто очень сложно оценить быстродействие пути даных при вариациях функциональности отдельных модулей.

Так и есть. Где-то на гуглях можно в конференциях найти мою дискуссию с господином из Зайлинкса по поводу документирования использования этих ног. Однако по результату мне было сообщено, что необходимости в них для PCI-33 нет. Физически - это некий маленький кусочек PCI-ной логики, привязанный аппаратно к определенным пинам для ускорения неких логических функций.

Если ввод/вывод нехитрый, то проще написать свою собственную корку. На Spartan3e можно точно обеспечить выполнение всех таймингов PCI-33. Вышеозначенные пины были введены Зайлинксом для возможности поддержки PCI-66.

Похоже на то. Я заходил по другой ссылке: http://www.latticesemi.com/solutions/techn...036;28E$60 , называлось "DDR SDRAM Controller" и обладало выше описанным быстродействием. По вашей ссылке действительно лежит нечто гораздо более стоящее. Круто Латексы извратились :a14: