Krys

Как-то не очень понял преимущества... Вроде устраивает и просто лазение по сайту. Или я что-то не понимаю?

Я бы грешил всё же на бракованные ПЛИС. Либо на электромагнитные поля. Что очень маловероятно. У меня была ситуация, что плиска управляла импульсами лазера. И когда лазер выходил на мощность, то плиска уходила в анабиоз. Правда, прошивка до конца не сбивалась. Просто всё переставало работать и не реагировало на команды. Приходила в себя плиска где-то спустя минут 10... Плиска - какая-то альтера типа EPM7128

поддерживаю последнего оратора. Я ленивый. Так что сижу на Active-HDL. Но есть глюки. Какой-то он недоделанный, сыроватый. Иногда было желание перейти на Моделсим.

Коды Грея годятся только для последовательно изменяющихся величин. Для случайных они не дадут изменение в одном бите. Т.е. это подходит только для счётчиков.

Автор, дак у Вас заработало или нет? Если нет, то можете тестовый проект выложить, который не работает. Мы попробуем...

Согласен. И именно при таком условии мы это используем.

В коде это тоже не очень красиво и не очень быстро. Да и в графике не так трудно подправить один порт. У нас была необходимость выводить сигналы не напостоянно, а при отладке. Тогда мы, чтобы не переделывать графику, временно дописывали нужные порты прямо в коде. Когда отладка заканчивалась, достаточно было перегенерировать код из схемы - и всё возвращалось на пути своя. А чтобы выводить сигналы напостоянно - это нам не требовалось, т.к. в сложных проектах необходимо заранее продумывать интерфейсы стыков между блоками

Это пока единственный минус, который нам реально мешает. Хотя генерэйт на верхних уровнях обычно не требуется. Т.к. описывает просто соединение блоков, а не их поведение.

Но появился другой вопрос: блок параметров предполагает запись типа name = value Однако при генерации кода появляется такая конструкция: parameter resync_period = 200 Т.е. нет в конце точки с запятой. Компилятор дальше естественно ругается. При том у коллеги ситуация совершенно противоположная. Таким образом, мы вынуждены в одном случае ставить во всех модулях точку с запятой, а в другом - убирать. Обмениваться проектами крайне неудобно... - эти вопросы так и остались... Неужели никто не работает в Active-HDL?...

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

А когда не работает, то как вы это запускаете? Судя по всему (моё предположение), что у Вас файлы не связаны друг с другом. Т.е. не объединены в проект. Следовательно, среда не знает, откуда брать указанный сигнал. Ну это как предположение. А компиляцию верилог-файла с кодом делали?

Мы тоже так пытались сделать. Правда, в Active-HDL и для Xilinx. Проблема в том, что шина может содержать в себе только сигналы одного направления. Т.е. либо все выходы либо все входы. А вот в интерфейс можно было запихивать сигналы любой направленности. В случае с шинами придётся делать отдельно шину на вход, шину на выход, что уже приводит к обрастанию связями.

Не принимаю. Это не у меня такая проблема возникла. У коллег на работе. Я сколько работал - с таким ни разу не сталкивался. Так что похоже мы с вами такое повторить не сможем :)))

нашёл ответ на свой последний вопрос насчёт того, что компонент числится на одном слое, а пады у него на другом слое: http://electronix.ru/forum/index.php?s=&am...st&p=892868 Остаётся вопросик: помогите пожалуйста составить правило, чтобы найти компоненты, у которых пады не на том слое, что сам компонент.

Бага с залоченными примитивами компонента. Начало здесь: http://electronix.ru/forum/index.php?s=&am...st&p=890570 Кратко: в свойствах компонента он числится на одном слое, а его пады (компонент СМД) - на другом слое. В результате коллизии с конструкторскими и технологическими программами. Выяснилось, что к подобному эффекту приводит такое неумелое действие: у компонента (допустим резистор 0402) выделяются пады, потом переходим в PCB Inspector, меняем слой на другой. Всё прекрасно. НО: в свойствах компонента галочка Lock Primitives установлена. Следовательно, менять отдельно свойства пада не должно. А оно меняет. Вот в этом и бага. Заодно вопросик: помогите пожалуйста составить правило, чтобы найти компоненты, у которых пады не на том слое, что сам компонент.

Парные слои распространяются только на механические слои. А у меня пады (т.е. электрические слои) переходят на другую сторону. Парные слои я подумал в первую очередь. Но видимо не они...

Всем спасибо за разъяснения. А можно про такое правило поподробнее. Как его составить, чтобы оно заработало. Сейчас попробовал: не то. "Отзеркалены" - не подходящий термин. Компонент числится на одном слое, а его пады и графика на другом слое. При просто зеркалировании по X или Y этого не происходит. Компонент и его графика остаются на "правильных" слоях.

Здравствуйте. Коллеги натолкнулись на такой глюк: на PCB имеется куча одинаковых компонентов с одинаковыми паттернами. При этом почти все паттерны без глюка. А отдельные - "хитро отзеркалены". Сейчас объясню. Компоненты эти представляют собой SMD. Т.е. компонент допустим на топе - и пады тоже должны быть на топе. И если мы компонент переворачиваем на другую сторону, то в свойствах компонента числится слой боттом и в свойствах пада тоже числится слой боттом. А вот глюк для отдельных таких компонентов заключается в том, что сам компонент числится на боттом, а пады у него на топ. И из-за этого потом проблемы с CAM350 и пр. Кто-то сталкивался с таким глюком? Откуда он берётся? Как с ним бороться? Как можно обнаружить такие компоненты хитрые? Пока что обнаружили чисто случайно, по ошибкам в CAM350. Визуально всё красиво, ничего не найдёшь. Возможно, нужно создать некое правило (не знаю какое), чтобы оно проверяло, что в свойствах компонента слой не соответствует слою в свойствах падов. Боремся с этим просто (если найдём, конечно): удаляем компонент, а после Import Changes свежий компонент из библиотеки затягивается уже без глюков.

на отображение падов, не соответствующее реальности, я уже когда-то жаловался в этой же теме... А 256 символов в имени файла - это разве не ограничение самой оси?

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

А что конкретно делает этот механизм Clock Correction? Приведите, пожалуйста, доку и номер страницы.

покажите проект

Master of Nature, может пригодится: в Open Office есть фича напечатать документ в PDF со всеми гиперссылками. Думаю, документ будет интереснее, чем просто HTML. И картинки легче вставлять.

IDE, гордыню, пожалуйста, отключите. А если Вас не Владимир попросит? Он вобщем-то может и не для себя просил, а для всех. С надеждой на понимание.

Я работаю в Active-HDL (с ПЛИС Xilinx), поэтому скажем по ISE не посоветую. Появляется этот файл после операции Implementation. В Active-HDL он называется для проекта с любым именем одинаково - time_sim.v. Этот файл создаётся автоматически (по крайней мере в Active-HDL, но он вызывает всё равно утилитки из ISE, своего имплементатора у него нету). Возможно, нужно поставить определённую галочку. А возможно, он уже и так у Вас создаётся. Поищите, может сами догадаетесь, под каким именем он скрывается. Но расширение точно *.v (для верилога). А что не так? Я ядра симулил, но не скажу, что много. Поэтому некоторых ошибок мог не встречать. Ядро DDR симулить не доводилось.