dxp

Спасибо, Nixon! Я впервые вижу такое исчерпывающее объяснение. а вы в курсе, что использование LUT это не необходимый и достаточный признак ФПГА? существуют так же SLC (simple logic cells) и логические модули на основе мультиплексоров - см. Actel - и вообще то что запихано в Лоджик Блок значения-то особого не имеет - там хоть транзисторные пары могут быть. а фишка по моему заключается в системе межсоединения - у ФПГА они сегментированные, с поддержкой иерархической системы при желании, и система межсоединений распределена по всему устройству (ФПГА) - в ЦПЛД же имеется ПМС (программируемая матрица соединений) суть её заключается в том что каждая ЛЯ в пределе может быть соединена с каждой на прямую - отсюда более сложен и рискован процесс разводки (при этом возможна также иерархическая организация - если на пальцах - то каждая ЛЯ представляет ЦПЛД сама по себе - то есть тоже организована по принципу ПМС). Вообще-то, насколько меня учили, FPGA - Field Programmable Gate Array - вентильный массив с возможностью программирования в полевых условиях (вольный перевод), т.е. дивайс, который может быть сконфигурирован "на лету" (это смысл). Именно это и подразумевает название FPGA, ничего более. Как там оно внутри реализовано - дело пятнадцатое. То, что в большинстве применяются LUT'ы, это просто удобная и эффективная реализация. А CPLD - Complex Programmable Logic Device - сложное программируемое логическое устройство, - сегодня просто традиционно устоявшийся термин. Этот класс появился раньше, чем FPGA, тогда это было круто, это были действительно сложные по сравнению с распространенной тогда рассыпухой устройства. Сегодня это название только вводит некоторую неразбериху - реально почти любая FPGA гораздо круче и сложнее, CPLD среди программируемой логики занимают, наверное, последнее место по сложности. И по функциональности. И по характеристикам. Однако все равно они сложные дивайсы. :) Переименовывать, конечно, теперь уже никто не будет, но путаница остается и начинающих сбивает с толку.

......однако лихо!......... :a14: Тут не в лихости дело, а характере работы. Если Вам нужно тучи цифровых шин таскать, то имеет смысл задуматься о автотрассировщике, т.к. большой объем работы, более-менее поддающейся качественной автоматизации. У меня же почти все схемы цифро-аналоговые, причем цифровая часть относительно небольшая (типа проц, ПЛИС, память, шина на все это дело), руками это выполняется за вполне приемлемое время при приемлемых трудозатратах. Зато аналоговый тракт, АЦП/ЦАП и подобное никакой автотрассировщик нормально не сделает. На сегодняшний день. Вторая причина: чтобы автотрассировщик хорошо проводки водил, надо им рулить как следует, а это требует времени на освоение оной технологии и поддержания формы - т.е. некая периодичность, иначе оно начинает забываться и каждый раз как в первый. Если заниматься только дизайном плат, то, не спорю, имеет смысл освоить какой-нить хороший автотрассировщик. У меня же, как уже говорил, разработка ПП занимает по времени очень небольшую часть, основное время уходит на другое. Поэтому мне проще, быстрее и надежнее делать руками.

Я не пользуюсь автотрассировщиком. Делаю все руками.

По средствам от Ментор это не ко мне. Я все это смотрел только в порядке ознакомления. Первое впечатление - ужас, тьма всего, что к чему, не понятно, и т.д. :) До второго впечатления не дошел. :) Пакет, безусловно, могучий, может, наверное, все. Но разобраться со всем этим - это надо этому делу посвятить... Поскольку трассировка платы у меня занимает какие-то проценты от общего времени, затрачиваемого на разработку, то я посчтитал нецелесообразным для себя тратить ценный ресурс (время) на освоение пакета, который что-то умеет лучше (пусть даже сильно лушче), нежели Протел. В общем, народ работает, хвалит. Одна только ремарка: полный пакет называется ISD2004, в него входит очень много всяких программ, начиная от законченных пакетов типа WG2004 и заканчивая отдельными утилитами. Помимо собственно пакетов там еще есть так называетмые лицензионные сборки, т.е. в чем-то урезанные версии. Для собственно дизайна плат нужен, насколько знаю, WG2004. Еще есть другой пакет, тоже от Ментора, PADS называется. Этот гораздо скромнее по размерам и разнообразию и ориентирован исключительно на дизайн ПП. PCB его народ очень хвалит, а вот схемный редактор - не очень. Задайте лучше отдельно этот вопрос. Подозреваю, что многие, кто мог бы дельно ответить, просто не читают эту ветку, т.к. Протелом не интересуются.

Про эти вещи я как рас недавно думал, очень нужно было,.... разбирался со спекттрой, там вроде как нашел... rooms помоему... DXP как система в целом хорошая, я лишь высказал фю о ПСБ редакторе... Не, румы - это несколько не то. Их, конечно, можно использовать при создании правил, ставя атрибут принадлежности/непринадлежности к руму. Но это совсем не то получается, что area rules. :(

Я спросил в прошлый раз, что это такое? Если имеется в виду преобразование изгибов проводника, то это удобнее делать путем просто переразводки фрагмента - при этом эффективно убираются петли и результат достигается тот же самый. По трудоемкости это почти одно и то же. Да, такая бяка есть. Трек лучше не тащить, а переразвести. В случае одиночного трека оно выходит где-то так же, как и перетаскивание, если не быстрее. Конечно, когда их много, тут ёк - приходится париться. Справедливо. Драга там реально нет. И это действительно, порой, очень неудобно. Думаю, что корни у этого недостатка ровно те же, что и у предыдущего. Тут ничего не скажу, не пользуюсь. Но вряд ли это можно отнести к серьезным недостаткам именно PCB. Это интерфейсный модуль недоделан. А это и неудивительно - Пикад совсем другая программа, у нее свои особенности, естественно, что при импорте/экспорте из одной в другую часть информации теряется. Впрочем, я лично каких-то фатальных траблов не заметил. А от подобных операций логично ожидать "пенок" из-за несовместимости. Опять же, это не сам PCB как таковой, а модуль импорта/экспорта. Что касается того, что их делает одна контора, то это только формально так. На деле Пикад был просто куплен Протелом и развивается параллельно и самостоятельно. Идеология в оба продукта была заложена задолго до того, как они стали жить под одной крышей. Автотрассировщика там нет, что бы не утверждал Альтиум. То, что там есть, это полная фигня. Тут даже обсуждать нечего. Дело не в том, мало или много. Возможно, покажусь категоричным, но из всего списка серьезными замечаниями являются только про drag объектов (как компонентов, так и проводников). Остальное либо мелочи, либо не относятся непосредственно к PCB. Лично мне в его PCB не хватает (помимо drag) area rules - чтобы можно было задавать правило не только на компоненты, цепи, пады (и их классы), но и на зоны и чтобы при входе/выходе из зоны автоматом менялись параметры объекта. Например, вошел в зону, где многоногий корпус с мелким шагом между ногами, толщина проводника автоматом уменьшилась до указанного размера. Вышел из зоны, толщина увеличилась. Как в WG. Второе - это возможности таскать не по одному проводнику, а сразу целыми группами/шинами. Вот это действительно, имхо, серьезные минусы, над которыми следовало бы поработать. Тем более, что сделать это технически несложно - не автотрассировщик какой-нить. Нет, тут немного не так. Дело не в том, на скорую руку или нет, не на скорую (во всяком случае не более, чем у других производителей). Дело тут в том, что Альтиум, как уже неоднократно в разных местах сообщал Юрий Потапов (и совершенно справедливо), перестал уделять должное внимание PCB в своем продукте, сконцентрировавшись на развитии ПЛИС и программерского направлений. В результате почти все значимые возможности в сегодняшнем Протеле - это все то, что было еще в Протелах 9х. С тех пор изменилась только "морда" - графика, оболочка. Добавились, правда, некоторые новые возможности, но они больше относятся не столько к PCB, сколько к самому пакету в целом. Например, очень удобная фенька, когда можно выделить фрагмент на схеме и скомандовать проге, чтобы она выделила эти же компоненты на плате. Это архиудобно при размещении - не надо лазать по плате и искать каждый отдельно - сразу всю функционально связанную группу выделяешь и тащишь в то место на плате, где она должна быть разведена. Неплохое добавление - мультиканальный дизайн. Правда, у него есть, как говорят, обратная сторона - при back annotate из платы в схему какие-то проблемы у народа возникают. Не знаю, не сталкивался - я всегда от "печки" пляшу, т.е. от схемы. :) Зато очень удобно одинаковые куски делать. Тут еще много что можно написать. Но и достоинств у пакета немало. Во-первых, он достаточно простой и интуитивно понятный - в нем сразу можно начать рисовать схему, трассировать плату. Попробуйте-ка это проделать в крутом WG. Там Вам придется потратить тучу времени на разбирательство, что к чему, как оно все огранизовано, зачем такая туча программ, чем они все друг от друга отличаются и т.д. и т.п. Если Ваша цель - разводка, разводка и только разводка, причем на приличном уровне, сложные платы, то разумеется имеет смысл тратить это время и разбираться. И терпеть WG'шные неудобства (а их, как и у любого пакета, есть), если его достоинства для Вас перевешивают. Во-вторых, что ни говорите, а процесс ручного таскания проводника в Протеле сделан выше всяких похвал - look-ahead режим, когда видно, куда ляжет следующий сегмент, - это очень удобно и создает комфорт. Нигде лучше этого я не видел. Даже в PADS, где этот момент очень хвалят, оно не впечатлило - в Протеле эта операция сделана лучше. Причем, это в нем было сделано еще в старых версиях, т.е. это не достоинство нового продукта. В-третьих, очень хорошая и правильная фишка - это процессы с возможностью их "проталкивания в стек" - реально удобно, экономит время и силы. В-четвертых, система синхронизации не через eco файлы, а на основе уникальных ID компонентов упрощает процесс синхронизации. Ну и вообще, разводчик - разводчиком, а смотреть-то надо систему в целом. А в целом она неплоха - рисование схемы, навигация по проекту(!), работа с параметрами (!), глобальный поиск, выделение и редактирование (!), синхронизация, печать, отчеты - в сумме все это вполне на уровне. А помеченное (!) - так вообще достойно высокой похвалы. Если будете смотреть другие продукты, то, например, в таких признаных, как PADS, столкнетесь, что схемый редактор его весьма отстойный, даже апологеты этого пакета от него плюются, хотя от разводчика в востоге. С WG аналогичная картина - разводчк крут, множество продуманных и навороченных возможностей, но схемный редактор достаточно убог - даже встречал рекомендацию использовать не WG'шный редактор схем, а DxDesigner. Ну и с дружественностью к пользователю там, имхо, значительно хуже. Т.ч., повторю, идеального пакета нет, в каждом что-то лучше, что-то хуже. И при выборе надо просто определить для себя компромисс, который более Вам окажется пригодным.

Можно конкретнее, что именно не устраивает (списком прямо) и что в Пикаде мощнее, чем дерибасе? А что это такое? Ответ предвижу: WG или PADS. На худой конец Zuken. Только надо быть готовым к разочарованиям и там. Идеального пакета нет.

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

А какие средства для обработки имеются? Какая скорость обработки требуется? В общем случае, предположим, что есть некий МК, время не слишком критично (десяток мс, скажем, есть в запасе). Тогда просто полученное значение подать на вход функции линеаризации - функции, обратной той, которая реализованна в потенциометре. Если там чистый логарифм, то искомая функция степеннАя. Ее можно разложить в ряд и вычислять до энного члена - тут от требуемой точности зависит. Этот вариант скорее всего потребует плавающей точки, зато он самый простой в реализации. Можно функцию реализовать путем выборки по таблице с последующей кусочно-линейной интерполяцией. Тут придется повозиться с диапазонами и погрешностями. Зато этот способ значительно быстрее предыдущего. В общем, для конкретного совета слишком мало данных. А в общих чертах оно где-то так, как сказал чуть выше.

Да, встроенный в CCS. Я так понимаю сначала в проц прошивается некая прога, используя которую через API заливается основная пользовательская прога. На основе API сделать свой аналогичный программатор проблем нет. Фишка, видимо, заключается в том, чтобы прошить первоначальную прогу в чистый кристалл. <{POST_SNAPBACK}> Делать первоначальную загрузку во флешь нет необходимости - достаточно загрузить программу в ОЗУ и пускать оттуда. Для этой начальной загрузки внутри проца есть жестко зашитый бутлоадер. И вообще саму прогу можно загрузить через JTAG. А вот чтобы продолжить прошивку через JTAG нужно иметь доступ со стороны железа МК к его же внутреннему JTAG контроллеру, через который получать данные для прошивки их во флешь. Вот эта часть (взаимодейтсвие с JTAG котнроллером) и закрыта от пользователя. Т.е. пользователю остается подавать данные через какой-либо из внешних интрефейсов (UART, SPI, параллельный), что не есть то, чего бы хотелось.

С чего вы взяли? У филипсовских например только одна HW точка остановки. У филипковских два брейкпоинта при работе из флеши. И много при работе из ОЗУ. Учитывая, что ОЗУ там дофига, можно прямо из него программу пускать, заодно и скорость повыше будет.

Простите, Вы кем работаете? Инженер-разработчик, у которого на столе разрабатываемое устройство, там же лабораторный источник питания, вольтметр и, разумеется, осциллограф (и другое контрольно-измерительное оборудование), такие слова говорить не станет. Для него очевидно, что прибор под названием "осциллограф", который является "глазами" разработчика в мире электронных железяк, должен иметь средства для оперативного руления и отображения. Т.е. ручки/кнопки управления и экран. Это все понятно. И это все крайне неудобно при оперативной работе как с осциллографом. Убеждать в обратном не надо - проходили. Сколько стОит эта плата сбора? И сколько стОит крейт? Короче, во что выливается этот комплект?

Дело не в том, с чем его скрестили, а в том, что это просто не осциллограф, а совсем другой дивайс. Да? Я что-то не увидел там ручек руления разверткой, вертикальным усилением, режимами синхронизации, смещениями и прочего. Я не увидел, как это поставить на стол. И т.д. Это не законченный прибор, а просто плата. Если я у своего WR6051A выдеру осциллографическую часть, которая является PCI устройством, установленным в PC, то она от этого осциллографом не станет. Вот именно, что надо еще крейты и прочее. И по сумме не вполне уверен, что оно будет сильно дешевле полноценного скопа. Этот дивайс - не осциллограф, а плата сбора данных, это, повторяю, отдельный класс устройств, рассчитанный на несколько другие применения, нежели осциллографы. Таких плат уже давно есть. И более крутых (хотя может и более дорогих - несколько лет назад попадалась плата с частотой дискретизации 2 ГГц, стОила около 2 тонн зеленых). 100 МГц (и даже 200 МГц) оцифровки - это сегодня откровенно мало почти во всех областях за исключением разве что звука. Еще там не увидел данных о полосе пропускания. Если подобные платы считать осциллографом, то аудиокарточка - тоже осциллограф.

Это тот, который встроен в CCS? Просто задача стоит сделать собственный JTAG-программатор. И пока всё грустно... Представитель-продавец от TI говорит, что это вроде как их закрытая тема, и они секретничают... :-( <{POST_SNAPBACK}> Именно так. Вот ссылка на ru.embedded, где это обсуждалось некоторое время назад. Про API программирования флеши.

Э... Пардон, но осциллографом это назвать никак нельзя. Это платы сбора данных. Совсем другой класс приборов.

IAR лучше avr-gcc во всем, кроме цены. Кодогенерация у него лучше, управление проще, поддержка оперативнее. Ничего не мешает использовать для сборки make (или хоть батник), чем лично я и пользуюсь.

Посмтрите описание на прогу $\IAR\avr\bin\postlink.exe Сама дока лежит здесь $\IAR\avr\doc\postlink.htm Обратите еще внимание на $\IAR\avr\bin\postlink.bat Это вам поможет <{POST_SNAPBACK}> Postlink уже давно obsolete. Все разруливается через опции линкера. Подробнее не скажу, копаться надо, давно было, все уже забыл. :)

Этот набор правил смахивает на прибивание самого себя к стулу, чтобы вдруг ненароком с него не упасть. То, что вставать со стула, мягко говоря, неудобно, во внимание не принимается. Или как, типа, выломать с клавы кнопку Delete, чтобы вдруг чего-то не того не удалить.

Это как это "инициализированных при декларации регистров в Verilog"? Что, уже можно написать: reg a = 1; и это будет синтезабельная конструкция? Или тут что-то другое имелось в виду? <{POST_SNAPBACK}> Это всегда была синтезабельная конструкция, по крайней мере для Xilinx FPGA. Для компилятора нет никаких проблем в Xilinx FPGA поставить начальное состояние триггера в bit-файле равным определенному значению. У нас на этом принципе была написана пара модулей, которые не требовали изначального ресета. В Альтере ситуация с этим похуже :( Там синтезатор просто игнорирует эту конструкцию и триггер по умолчанию всегда установлен в нуль. С этим связана разница в one-hot КА кодировании. У Альтеры первое состояние всех триггеров всегда нулевое, у Xilinx - произвольное. Если КА для Альтеры имеет ненулевые биты состояния стартового состояния (такой себе каламбурчик), то компилятор генерирует предупреждение, что мол схеме для корректной работы необходим стартовый ресет. <{POST_SNAPBACK}> Насчет синтезабельности этой конструкции. В языке Верилог объекты reg не являются триггерами. И вышепривденный объект 'a' может быть как триггером, так и простой логичекой связью (node, если по AHDL'ному). Во втором случае смысла в начальной инициализации просто нет. Сейчас уже не помню, давно было, когда разбирался, но, afair, присваивания (в том числе и начальные) к объектам reg можно делать только в поведенческих блоках initial и always. При этом блоки initial являются несинтезабельными - синтезатор в лучшем случае их игнорирует. Сам же всегда синтезуруемые объекты привожу к исходному состоянию явно в описании логики - для этого (и только для этого) использую асинхронный сброс триггеров непосредственно после влючения ПЛИС. Что касается исходного состояния триггеров в ПЛИС от Альтеры, то и тут, насколько помню, не так, как Вы сказали. Есть там возможность установить их при загрузке, сам пользовался этим несколько лет назад, когда работал на AHDL, это был какой-то из ACEX'ов.

Это как это "инициализированных при декларации регистров в Verilog"? Что, уже можно написать: reg a = 1; и это будет синтезабельная конструкция? Или тут что-то другое имелось в виду?

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

Я не спорю, возможно все так и есть, и любой проц даже с питанем 1.8 В без проблем работает с 3.3 В уровнями. Только вот зачем тогда на USB-ICE пишут три уровня питания?

В EMU-AD установлено фиксированный уровень LVTTL питание +3.3В, совместимый с TTL питание +5В. Для ликбеза, а зачем нужны иные уровни напряжений? <{POST_SNAPBACK}> Ну, к примеру, если у меня на плате уровень I/O 2.5 В, то от эмулятора потребуются соответствующие уровни. Понимаю, что раньше этой проблемы не стояло, 3.3 В всех устраивало. И сегодня тоже в большинстве случаев этого достаточно (у меня по, кр. мере, 3.3 В и применять другие пока не планирую). Но ситуации разные бывают, и может потребоваться напряжение 2.5 В - если хочется энергопотребление снизить, например. Тот же BF в плане потребления очень неплохо смотрится, для него переход на 2.5 В выглядит вполне разумным. Вот как-то так. :)

Ничего не понял. О каком программировании? Речь шла о скорости передачи данных со скопа на другой комп.

Каким образом задается уровень напряжений? Как у USB'шных вариантов руками через оболочку?