v_mirgorodsky
-
Постов
341 -
Зарегистрирован
-
Посещение
Сообщения, опубликованные v_mirgorodsky
-
-
Жаль, придется использовать существующую методологию. Асинхронные схемы обладают просто громадными преимуществами по сравнению с синхронными схемами, однако поддержка их проектирования со стороны существующего софта отсутствует как факт.
-
А кто говорит о бесплатном софте? Меня интересует хороший удобный пакет для кастом-дизайна, его бесплатность на данном этапе уже была бы минусом, поскольку теперь мне нравятся поддерживаемые и развивающиеся продукты ;)
-
Доброго времени суток,
В последнее время много работаю с фулл-кастомом. Сейчас для рисования схем и топологий использую 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, может не все так плохо окажется :(
-
Тут надо определится - сколько девайсов нужно, 45 или 10000, это совершенно разные пути.
Девайсов нужно 10000. Я так думал, что eASIC предлагает весь НРЕ сделать в пределах этих самых $45k, а потом можно пытаться штамповать девайсы пачками. Собственно на это и был весь расчет. Я ошибся?
Начинать надо с имеющегося описания проекта на HDL.Насколько оно синтезабельное на базе SCL возможного производителя?
Если описание есть только в ячейках FPGA и их соединений, то пути 3 (или):
1. Отдаться полностью сервису Ксайлинксов и производить ASIC только через них. Не знаю точно, есть у них такая услуга? И есть ли такая услуга для больших тиражей?
2. Переписать HDL в поведенческом виде, для возможности синтеза схемы\топологии на любой подходящей стандартной библиотеке ячеек.
3. Взяв за основу библиотеку стандартных ячеек выбранного производителя и перелопатить её (по сути, разработать заново) по принципу полной эквивалентности ячейкам Spartan6 LXT150 FPGA. Потом подставить ссылку на эту новую либу при синтезе\трассировке топологии из имеющегося структурного HDL.
Есть вариант дизайна на чистом 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 низкий, у танталовых конденсаторов он сравнительно высокий, у советских алюминиевых конденсаторов он запредельный :)Хорошо, а если в даташите стабилизатора написано: Stable with 2.2 μF Ceramic Capacitor и они уже стоят 2.2 сразу после него, а эти монстры по 22 заменить скажем на 5-10uF. Нормальный ход?Телепатирую: исходя из моего опыта, речь идет о 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, скорость вашей мысли значительно обгоняет скорость набора ваших пальцев на клавиатуре ;) А если серьезно, то время на продумывание сколь нибудь сложной схемы никак не соизмеримо со временем на ее написание. Поскольку реализация модуля по моему опыту занимает два часа, а продумывание идеи и структуры - пару дней :( К тому же, всегда приятно знать, что твоя схема четко соответствует тому, что ты написал, а строгая типизация и отсутствие неоднозначности в трактовке конструкций компилятором - ключ к этому.Убийство времени - понятие относительное. Если просто посчитать кол-во символов в исходнике (при одинаковых идентификаторах) то VHDL/verilog 1.5...2/1 - и времени на написание ровно во столько же больше. А время на продумывание архитектуры одинаково. Вот и голимое убийство. Плюс раздражение и нервы от этих лишних преобразований. -
Исходя из задаваемых вами вопросов проект h.264 Encoder на ПЛИС не для вас. Готовые реализации h.264 Encoder стоят очень больших денег. В общем доступе возможно можно найти нечто типа Base Profile, с сильно обкоцаными возможностями. По быстродействию - да, реализация на 50-баксовой ПЛИС обставит по скорости обработки все существующие на сегодняшний день ДСП. Практически любая реализация также потребует наличие в системе высокоскоростной динамической и статической памяти.
-
Сделали устройство на XIO2000A. На вторичном сегменте PCI запустили нашу FPGA, которая порождает поток данных порядка 170-180МВ/сек. И тут выяснился небольшой облом - на старых чипсетах пролетает все с легким свистом, чем чипсет новее, тем больше полезных данных приходится просто выбрасывать по ходу дела. Естественно, ситуация напрягла, и по этому поводу были отправлены несколько запросов в Интел. После долгой переписки выяснилось, что скорость на сегменте PCI-e на слотах, подключенных к Южному мосту "режут" специально. И чем новее чипсет, тем меньше полоса выделяется для всех "южных" слотов PCI-e. В качестве припарки больному Интел посоветовал активировать изохронный режим передачи данных по PCI-e. Быстрое изучение регистров XIO2000A обнаружило требуемые области для инициализации. Только вот ничего это не дало. Скорость так и осталась нестабильной во времени и низкой в среднем. Возникло два подозрения. Первое - неверная конфигурация регистров XIO2000A, второе - для реализации изохронной передачи необходима нативная поддержка PCI-e со стороны самой ОС. В обоих случаях нагуглить ничего не получилось.
Собственно, вопрос. Знает ли кто что-то большее по теме?
-
давно вынашиваю идею собственного обфускатора для верилога, но ничего лучше чем забить в PLY/YACC полную семантику языка, если делать без упрощений, на ум не приходит.
Но вообще планирую полную замену всех идентификаторов(имена модулей, порты, параметры, сигналы, метки и т.д.) на 64х символьные идентификаторы вида p01101010.....01010. Так изменяется все, кроме портов топ-модуля, удаляются все не нужные разделители, комментарии, модули собираются в один файл. Думаю что для проектов от 2-3 тысяч строк, без представления о функциях устройства, даже на слабо никто не возьмется "дизассемблировать" %))))
Хороший подход, но сложный :( Как-то отлаживал грамматику собственного скриптового языка на 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-ной логики, привязанный аппаратно к определенным пинам для ускорения неких логических функций.Видимо, автор имел в виду, что это было сделано (назначены специальные ноги для этих сигналов) Зайлинксом, чтобы попасть в тайминги для 66 МГц. -
Если ввод/вывод нехитрый, то проще написать свою собственную корку. На Spartan3e можно точно обеспечить выполнение всех таймингов PCI-33. Вышеозначенные пины были введены Зайлинксом для возможности поддержки PCI-66.
-
Похоже на то. Я заходил по другой ссылке: http://www.latticesemi.com/solutions/techn...036;28E$60 , называлось "DDR SDRAM Controller" и обладало выше описанным быстродействием. По вашей ссылке действительно лежит нечто гораздо более стоящее. Круто Латексы извратились :a14:очень странно, может быть у нас разные доки ?
Хороший тул для кастом дизайна
в Разработка цифровых, аналоговых, аналого-цифровых ИС
Опубликовано · Пожаловаться
Каденс я тест-драйвил, для рисования отдельных плотных целов времени тратится раза в 4 больше, чем в электрике :( Или я не правильно методологически их там рисую, либо под кастом каденс заточен слабо. Дело в том, что в электрике каждый кусочек металла представляет собой арку, т.е., связь между двумя точками. Далее я могу перемещать компоненты и части металлов относительно друг друга без нарушения связности. Условно говоря, выбрать и подвинуть на 50nm все p- или n-транзисторы для электрика есть тривиальная задача. Может я не до конца разобрался, но в Каденсе подвинуть десяток транзисторов у меня заняло минут пять. Плюс к этому в электрике есть встроенный простой DRC и совсем неплохой LVS. Фактически, к услугам внешних DRC и LVS программ я прибегаю после завершения сравнительно крупного блока.
Плюс в электрике есть совершенно поразительный режим с альфа-блендингом. Фактически все элементы имеют некую прозрачность, что позволяет видеть ситуацию с металлами и переходными отверстиями на выбранном участке дизайна без лишних движений просто на экране. Разобраться с ходу в каденсовском штриховом кодировании у меня так сразу не получается - может я не привык еще к картинке, а может куча прямоугольников в одном месте с разнообразными штриховками и не предполагает понимания топологии участка дизайна "с ходу" :( Я конечно понимаю, что воспользовавшись горячими клавишами подвязанными к разным конфигурациям фильтров я могу упростить картинку для себя, но в электрике я вижу это все совершенно без лишних движений.
Таких вот мелочей, положительно влияющих на производительность труда в электрике очень много.
Может быть я слишком многого хочу, но работать с Каденсом мне не понравилось. Я как-бы понимаю, что 28nm - это последний процесс, в котором использование электрика все еще возможно ввиду отсутствия дабл-паттернинга на металлах. Понимаю, что при отсутствии альтернатив таки придется подружиться с Каденсом, поскольку поддержка дабл и трипл паттернинга официально есть только в нем. Однако никто не мешает мне поискать альтернативы пока еще позволяет время.