Krys

А девайс у Вас какой? Видели в приведённом выше тексте такое: "Note This setting is supported for Spartan-6 and Virtex-6 devices only"? А на это есть такая цитата: "XST places all macros in the DSP blocks whenever possible". Я это понимаю так, что он пытается сделать всё, что возможно, на DSP-блоках, невзирая на занятые ресурсы. Сначала сделает, потом посмотрит получившиеся ресурсы. "This option enables you to see how many DSP blocks are used for a compiled submodule" - а тут я понимаю, что эта опция позволяет весь проект измерить в DSP-блоках. Т.е. скомпилить невзирая на размер, что и получается из предыдущего предложения. ... короче всё криво :)

закрома - это местный фтп-сервер, туда доступ только для "своих". Как стать "своим" читайте в соответствующем разделе этого форума.

По первому вопросу: предлагаю слово "пад" не использовать, т.к. вопрос в общем "как сориентировать 3D-модель относительно Footprint". И в ответ желательно добавить, что перед последующими действиям необходимо перейти в 3D-режим отображения.

А вроде же уже что-то подобное реализовано в виде скрипта для АД? http://electronix.ru/forum/index.php?s=&am...st&p=631935

Класс! Прошу Вас добавить этот вопрос в ФАК: http://electronix.ru/forum/index.php?showtopic=79105

Точное интегрирование можно обеспечить максимум на минуту. Потом будет накапливаться ошибка, и показания уже не будут соответствовать действительности. Тогда надо успевать за минуту на 100м перенести девайс :)))

выложите хотябы сюда датащиты названных Вами микрух. Чтобы нам самим это не искать и не качать. Почитаем, может что-нибудь подскажем. Я думаю, нужно вести поиск в направлении входа DVI (цифровая часть) или HDMI. Тогда с компом состыкуется. Если в компе видеокарточка позволит включит такое низкое разрешение.

автору нужны были просто "среднепотолочные цифры", а вы тут умничать начали и язвить...

Да конечно, если думать, то зачастую можно исхитриться. Но, насколько я сталкивался, на любую микросхему BGA (от 256 ног) идёт рекомендация от 6 слоёв и выше. У них вообще похоже BGA не ставят на платы меньше 4х слоёв. Там даже всякие QFN и SOP советуют разводить в 4х слоях. А наши все "если исхитриться" всегда используют 2хслойку. Так что думаю, 6 слоёв стесняться не стОит.

Полностью поддерживаю! Я например к любой работе подхожу творчески, долго думаю, прежде чем принять то или иное решение, куда вывести шину, например. Поэтому разводится у меня дооолго... Но на выходе - конфетка, аж самому приятно. Не надо гнуть пальцы :)

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

Я что-то находил, но уже не помню. Возможно, Multi-Inno на сайте Промэлектроники. Там до -30 было, если не путаю. А вообще, лучше задайте этот вопрос Alex_VI, это он говорил: А я скорее скепсис проявляю...

насколько я знаю, automotive - это один из диапазонов, наряду с Commercial или Industrial, наиболее широкий. Так что если проходите по температуре, то применяйте обычные.

Даже мне стало понятно :) Часть с определениями во-первых содержит устаревшую информацию (мы уже с Владимиром несколько улучшили формулировки, и он это отразил, см. сообщения выше), во-вторых, уж очень расплывчатое определение БД. К определению таблицы я предлагал сделать дополнения (см. переписку выше). Их тоже желательно учесть. А сами документы предлагалось выкладывать в другом месте (Владимир завёл хранилище, см. выше).

Да, подтверждаю, на местных закромах всё это есть, сам качал оттуда. Так что Вам надо прямо уверенно попросить (может прямо отдельной темой - потому что в этой сразу из заголовка непонятно, в чём Ваша просьба) форумцев поделиться SP1. Сам бы поделился, да инет не позволяет... У меня пока нет необходимости в спартане6, но немножко начали задалбывать глюки вэйвформ едитора, поэтому захотел перейти на 8.3. Скачал. Но у меня ISE 11.1, а к ней для Active-HDL 8.3 нет библиотек Xilinx Verilog. Надо скачивать ISE. Решено. Если скачивать - то конечно свежий. До недавних пор это был 12.2. Но на местных закромах он в виде единого архива, инет тоже не позволяет его целиком стянуть. Зато недавно выложили 12.3. Стянул. Даже лекарство нашёл. А оказывается Aldec для него ещё не выпустил библиотеки Xilinx Verilog. Такая вот санта-барбара...

Напомню, речь об этом сообщении (#187): http://electronix.ru/forum/index.php?s=&am...st&p=823647 И в нём говорится не о вообще нецелесообразности группировки файлов с УГО по папочкам или группировки компонентов по их функции. Говорится о нецелесообразности одному компоненту давать несколько ссылок на несколько УГО. Т.е. каждому компоненту сопоставлен только одно УГО. Точнее один файл *.schlib (если говорить конкретно об АД), если в каждом файле лежит по одному УГО. Либо один элемент (ячейка, строка таблицы SCH Library Panel) такого файла, если в каждом файле по нескольку УГО для разных компонентов. Как говорилось выше, одного УГО на один компонент достаточно по причине того, что (по крайней мере в АД) один УГО может содержать разные представления (альтернативные виды). А каждый вид может содержать составляющие (Part). Если в других САПР не поддерживается несколько альтернативных видов на один УГО, тогда, действительно, необходимо в нашу базу (или систему, я так и не понял отличие базы от системы, прошу конкретизировать эти понятия в том вордовском документе с определениями) заложить несколько полей для альтернативных УГО. Прошу знающих другие САПР уточнить этот вопрос. Мы же стремимся, чтобы наша система (или база) годилась для любой САПР?...

Подтверждаю, копировал группой много раз, глюков не было. А какой глючок Вы заметили? Какой вопрос в ФАКе?

может эта тема поможет: http://electronix.ru/forum/index.php?s=&am...st&p=818461

Вот я об этом и твержу.

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

Весь датащит и не надо. Задача параметрического поиска - лишь ограничить область выбора. И чем по большему числу параметров можно будет искать, тем Уже будет область выбора. А дальше, естественно, читать датащит и только после этого принимать решение об использовании. Вопрос только в том, что без параметрического поиска рыться придётся условно говоря в 15 датащитах, а с таковым - в 3х. Либо помнить, как Вы, всё в уме, тогда параметрический поиск не требуется. Но помнить в уме нереально. То, что Вы полностью всю работу проделываете вручную (поиск сразу среди датащитов и т.п.) - это не является признаком профессионализма. Это скорее показывает неумение (или отсутствие возможности на предприятии) пользоваться инструментами, облегчающими инженеру работу. Лень - двигатель прогресса. Отсюда и желание параметрического поиска. А пофигизм - он же не вообще на всё. Это такой локальный пофигизм, "здоровый пофигизм", как бывает "здоровый эгоизм". Потому что если голова будет болеть сразу обо всём - она лопнет. Нужно лишнее из неё выкинуть и сосредоточиться на действительно инженерской работе, поручив параметрический поиск компьютеру, а не вручную по датащитам. Естественно, как я писал, по результатам параметрического поиска я всё равно полезу в датащит. Так что "невозможность изготовления" будет исключена (либо она возникнет совершенно по другим причинам, не связанным с проведённым параметрическим поиском и "здоровым пофигизмом"). Хорошо. Тогда я задам встречный вопрос. А в АД легко сделать параметрический поиск по текстовым полям вида Um = 0,7 V, чередующимися с записью Vм = 0,7 В? Это, если и возможно, то крайне ненадёжно. Т.к., как показано, при вводе можно случайно допустить вольность типа Um и Vм и т.п. А чтобы это детектировать и приводить к нужному виду - требуется наворачивать очень длинные условия поиска, длинные макросы... Получается, что поиск по текстовым строкам с группой параметров также неудобен, как и поиск по отдельным полям параметров. Но если нет разницы, то давайте хотябы параметры друг от друга отделим. Хоть какая-то дифференциация. В текстовой строке даже порядок упоминания параметров может быть какой попало. И при поиске придётся подключать мозг и каждую строчку анализировать ещё и на это. Извините, если обидел. Тут лично мне как далёкому от БД непонятно, что значит "подключение" и что значит "одной строкой"? Или несколькими? и чем плохо первое или второе. Тут чисто терминологическое предложение сказать так: Таблица - двумерный массив данных, состоящий из строк и столбцов. Строки являются записями (сразу же дать определение записи). Запись состоит из полей (что такое поля?). Каждая запись имеет одно или несколько ключевых полей, которые в пределах таблицы уникальны (неключевые поля неуникальны? тут надо разжувать имхо). И в конце нужно добавить: одноимённые поля каждой записи образуют столбцы таблицы. Можно ещё примерно такое предложение добавить: в пределах одной таблицы все записи имеют одинаковый набор полей. Дело в том, что данное определение подошло бы не только к компоненту. Но и к любой другой сущности, описываемой в таблице. Например (чисто условно, т.к. я в БД - ноль) таблица футпринтов. Короче тут надо конкретизировать. А то у таких как я - недопонимание определений. А может перед сравнением эти значения можно преобразовать через какие-либо функции (такие как в языках программирования типа StrToVal ()) в числовое значение? Ну это тоже как гипотеза, т.к. я в этом ничего не понимаю.

Ну тогда прошу пожалуйста за всех не говорить и не навязывать своё мнение в данном вопросе. Как говорил Владимир, кажется, "прогресс не стоит на месте", и, если это будет удобно, этим постепенно начнут пользоваться. У меня тут 2 довода: 1. Вы не верите, что рано или поздно данная общественная база будет очень большой? 2. У крупных контор (я имею в виду наших работодателей) на складе огромное количество элементов. Зачем плодить номенклатуру, если можно выбрать из имеющихся? Но при отсутствии параметрического поиска это практически невозможно... 3. А если ещё и думать в перспективе, что кто-то её захочет прикрутить общественную базу к своей базе наличия на складе предприятия - тогда тем более параметрический поиск не помешает. Вот Вам простой пример: мне пофиг, какую деталь применить, лишь бы параметры подходили. Но время ограничено, поэтому при выборе рисовать или не рисовать компоненты, я выбрал бы применить уже нарисованные компоненты. Тогда я захожу в базу, делаю параметрический поиск и применяю уже готовые компоненты, ничего не рисуя своего. Я так понял, уже все согласились с тем, что база будет проектироваться с расчётом на более широкое использование, чем просто АД. При том САПР может быть несколько. И вообще, САПР - это будет частный случай предназначения базы. П.С. прошу ещё раз перечитать это сообщение (#149): http://electronix.ru/forum/index.php?s=&am...st&p=822430 и вместе с ним исходное (#83): http://electronix.ru/forum/index.php?s=&am...st&p=819219 Там на примере дигикея я всё объяснил и мотивировал. У меня ощущение, что Вы не читали этих доводов. Осталось: " УГО могут иметь параметры." в п. 1.1.2.3. Дальше пока не смотрел. Да и не понимаю (в структуре БД) :)

Мои коррективы: 1.2. упоминается термин Footprint без его предварительного определения. Упоминается УГО. 1.3. модель и Footprint в АД иногда означают одно и то же. Точнее, футпринт - это по терминологии АД одна из разновидностей модели. Я с этим согласен чисто исходя из логики и русского языка. Предлагаю эти термины как-то конкретизировать. Учитывая, что модель - это более общее понятие, то среди терминов оставить только модель как основной термин. А футпринт, симуляционную модель и т.п. назвать подвидами моделей. 2. Не совсем понял, зачем в компоненте "ссылки на иные компоненты". Может, лучше упомянуть "ссылки на модели и УГО"? Можно ещё прибавить "ссылки на документацию, поставщиков" и т.п. 4. Чтобы п. 4 отличался от п. 3 предлагаю конкретизировать: "данные компонентов разного типа" (плюс ошибка: хранЯтся). А чтобы было понятно, что значит одного типа и разного типа, нужно дать определение "тип компонента". И ещё вопрос по п. 3 и 4: а библиотекой нельзя назвать файл или директорию файлов, где хранятся не данные компонентов, а данные моделей или УГО? Т.е. не компонентов в целом, а их составляющих. 5. Хранилище - это чисто из русского языка - само место, а не указание мест. А указание мест наверное лучше назвать "путь хранения" Ну это так... пока просто пожелания... А ещё предлагаю термины разместить в иерархическом порядке. Примерно так: 1. База. Составляющие: 1.1 библиотека. Составляющие: 1.1.1. Компонент. Составляющие: 1.1.1.1. УГО 1.1.1.2. Модель. Разновидности: 1.1.1.2.1. посадочное место 1.1.1.2.2. симуляционная модель 1.1.1.3. Параметры Ну и т.д.

проблема с ресурсами упирается в комбинаторику и боюсь встроенная память вам не поможет. и вообще-то меня терзают смутные сомнения... (правильно ли вы описываете то, что проектируете) Дело в том, что луты можно использовать как память. Ключевое слово Distributed RAM. Так что, наоборот, такие строчки из отчёта синтезатора говорят о том, что использование RAM-блока вполне может исправить ситуацию.

насколько я понимаю, в DVI есть сигналы изображения как аналоговые, так и цифровые. Если цифровые - то это LVDS. Поэтому можно напрямую сигналы изображения из DVI подать на HDMI допустим. Дисплеи о которых Вы говорите обычно работают по LVDS, как в разъёме HDMI. Или я чего-то не понимаю?