Перейти к содержанию
    

oval

Свой
  • Постов

    260
  • Зарегистрирован

  • Посещение

Сообщения, опубликованные oval


  1. Вот уже который день, заходя на форум, вижу следующее:

     

    С возвращением; Ваш последний визит: Jan 1 2009

     

    Соответственно, число "новых сообщений" только растет.

     

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

     

    Уважаемый udofun, большая просьба повысить по возможности приоритет исправления данной проблемы :rolleyes: Заранее благодарен.

  2. Добрый день!

     

    Цепь состоит из одного источника (driver) и двух приемников (receiver). Топология: driver -> точка разветвления -> два плеча к каждому receiver'у. Можно ли задать такое правило, которое задавало бы соотношение длин плечей (отрезки от точки разветвления до receiver'ов), например 1/3? Если можно, то каким образом или где про это можно прочитать?

     

    Заранее благодарен.

  3. Если говорить о средствах создания графических тестбэнчей, то можно посмотреть в сторону средств от компании SynaptiCAD. Правда некоторое время уйдет на освоение... Как уже говорилось выше, в HDL Designer от Mentor Graphics есть достаточно удобные средства создания тестбэнчей.

  4. Вопрос

    Реально ли вообще обойтись без каких бы то ни было микроконтроллеров/процессоров, имея только MAC-контроллер и программируемую логику, для организации обмена данными по сети?

    Может быть существуют другие, более оптимальные варианты взаимодействия ПЛИС с ПК по сети Ethernet?

     

    В данном случае, насколько я понимаю, потребуется достаточно развитое управление MAC уровнем в части приема/передачи/формирования пакетов, поэтому смотрите в сторону связки Microblaze (встраиваемое в ПЛИС процессорное ядро) + MAC + внешний PHY. При этом не потребуется никаких внешних управляющих микроконтроллеров и т.п.

  5. Можно попробовать использовать команды пересылки из расширений MMX/SSE, если речь идет о хосте x86 архитектуры. Сам не специалист по такого рода программированию, но было дело для пакетного обмена на высокой скорости через PCI заказчик использовал команды из этих расширений. При этом за одну транзакцию PCI пересылалось четыре слова. Как на эти команды отреагирует PCIe мост, сказать не могу. Кроме того, для PCI если обращения шли по последовательным адресам, то мост их "слепливал" в одну транзакцию шины.

  6. Прошло уже более полутора лет, возвращаясь к теме...

     

    Господа, на сегодняшний день кто-нибудь реально сталкивался с платформой i.MX? Какими средствами разработки/отладки софта пользовались? Какие впечатления?

  7. Подобные проблемы периодически возникают при выходе очередной версии HDL Designer. Выход - либо откатываться на предыдущие версии, либо, если уже вышла, на более позднюю.

  8. у меня не ответ, а вопрос -

    не встречалось ли программы обратного преобразования ( программа --- > блок-схема) допускающей подключения плагинов описания языка или написаной на каком-то скриптовом языке (или с доступными исходниками)

    интересуют языки Verilog|VHDL

    самому писать рисовалку схемы у меня способностей не хватит, ну а парсер языка - может я бы и задал...

    хотя мне нужно не блок-схема, а структурная

    ?????

     

    Для VHDL/Verilog из исходного текста получить блок-диаграмму (и много еще чего) можно с помощью функции HDL Import пакета HDL Designer от Mentor Graphics. Как Вы понимаете, полученный результат будет далек от идеала, но помогает, можно в конце концов и подправить "ручками".

  9. Доброго времени суток! Мы так же столкнулись с тем, что PCI контроллер (CYCLONEII ALTERA) "не идет" на некоторых матерях. Для отладки видимо нужен анализатор. Подскажите, пожалуйста, какие российские фирмы могут поставить такое оборудование? SMARTELECT утверждает, что у них анализаторов нет...

     

    Поскольку Вы используете ПЛИС, то можно воспользоваться анализатором, встраиваемым в ПЛИС. На мой взгляд очень удачным решением будет использование Synplicity Identify, можно также использовать SignalTap от самой Altera. Естественно, эти анализаторы позволят выявить лишь логические проблемы... Элекстрические, временные и т.п. - лишь косвенно и то не всегда.

  10. да, печаль-то как раз о том, что синтез с СЦ не стали двигать (на мой взгляд тоже злономеренно). был бы синтез, то прелесть концепции СЦ заключалась бы в том, что весь процесс разработки велся бы в одном едином языке (без нужды в копи-пэйсте) + система софт+хард тоже была бы доступна в едином языковом пространстве.

     

    Двигали :) , только в определенный момент, закрыли, ибо очевидно, что все остальное в этом случае просто бы вымерло... опять же, не я придумал, знаком с людьми, которые занимались написанием средств синтеза SC, но поступил приказ работы свернуть, финансирование прекратить...

     

    Что касается возможностей верификации и самых современных тенденций, то в SC, аналогично SV, все это также реализовано: библиотеки SCV (SC verification), TLM и т.д. Вообщем, для полноты не хватает только нормальной поддержки синтеза...

     

    Против SV ничего не имею, все достойно :)

  11. сунусь я в эту тему со своей проблемой (жалобой на врагов :) переставших поддерживать SC):

     

    в системе есть некая задача обработки сигналов

     

    модель этой задачи описывается на С++ (потом часть кода используется в боевом фирмваре)

     

    после отладки С++ модели, то что отображает железо (RTL) переписывается в HDL, а внешний сигнал задается в виде файла воздействия (иногда и проверки ожидаемых результатов)

     

    на HDL верифицируется (пишутся тестбенчи, проверяется их совпадение с С++ моделью и т.п.) затем синтезируется, верифицируется, изготовляется чип, плата...

     

    при этом ошибка начальной С++ модели требует исправления HDL, обнаружение трудноустранимой и/или незначительной ошибки HDL - требует исправления С кода для соответствия. исправления делаются руками.

     

    ========================

     

    как может помочь SV - я не понимаю.

    требуется переписать модель на SV, но 1) требуется обучить программистов, 2) пропадает связь с реальным фирмварем (компилировать в исполняемые коды (например АRМа) SV нечем, даже если бы и был - как быть с "повторным использованием" С++ кода)

     

    ------------------------------------------

     

    обидно, теряется возможность (и смысл, имхо) системного уровня - "подвигать" границу между софтом и железом (ну типа этот фильтр лучше реализовать в железке, а этот в софте)

     

    ------------------------------------------

     

    некое облегчение можно получить используя PLI и С код в HDL симуляторе, но это так... маленькая заплатка

     

    -----------------------------------------

     

    собственно - мое мнение, что по этой причине SV значительно хуже SC.

    то есть SC (как расширение С++) покрывало все - и системный уровень, и проектирование и синтез RTL, и разработку встраиваемого ПО (фирмвари)

     

    а SV требует переноса моделей с С++ (что опять же нагрузка на HDL-щиков), а результат потребует обратной трансляции в C++

     

    ----------------------------------------

     

    Присоединяюсь к мнению уважаемого yes. Действительно SC более удобен для сквозного проектирования системы в целом на всех уровнях. SV и его столь активное продвижение - "большая политика" мировых законодателей моды данного направления, причем это не придумал. :) Был период, когда поддержку SC активно развивали, но "деньги" взяли свое. Будем надеяться, что-нибудь изменится.

     

    SV безусловно хорош, практически все, чего не хватало в Verilog добавлено + развитые средства верификации. Еще не один год пройдет, пока SV начнут реально использовать, ибо такого рода внедрение стоит очень дорого...

  12. Может быть кто-то уже реализовывал такое:

     

    Необходимо Ethernet упаковать в Е1, причем необходимо использовать GFP, VCAT, LCAS, вопрос в какую Альтеровскую плисину это можно запихать?

     

    У нас GFP реализовано на спартане 3 вроде бы работает, но видимо проще будет полностью переделать под Альтеру чем пытаться разобраться в чужом проекте, ну и дорабатывать его все равно надо.

     

    Смотрите в сторону семейств Altera Cyclone II, III

  13. А если исходный нестабильный (скорее всего это или разводка была такая или мастер-чип такой)

    то напрямую разве будет лучше?

     

    Обычно со стороны PCI PLL не используется, сама спецификация PCI допускает, если я не ошибаюсь, достаточно "плохой" клок. Разводка и т.п. не причем.

     

    По моему разумению (это взято по примерам корок) PLL работает как развязка + повышение нагрузочгной способности + оптимальное использование специальных клоковых линий.

     

    Здесь важны только специальные буфера, PLL лишь может скомпенсировать фазу тактирования, то есть увеличить в некоторой степени запас по временам, но для частот PCI это не существенно.

     

    Не совсем понял.

    С PLL есть сигнал LOCK - имеете ввиду, что надо его отслеживать и обрабатывать ?

    Согласен.

    Но это уже во втором приближение, пока все это хочу просто поднять.

     

    Лучше продумать этот вопрос сразу же, ибо в худшем случае устройство просто не запустится правильно. Да, кроме сброса отдельных доменов устройства, нужно еще и сброс самих PLL продумать.

     

    Спасибо, учту.

    Пока оставлю PCI c PLL, но в случае проблем - есть вариант где копать.

    По неопытности упущение - подвел PCI клок не на пин, который может быть подключен прямо к дереву клоков, а на простой пин.

     

    Вот этот момент, конечно, не удачный... Можно долго провозиться. Причем PLL тут не особо поможет, можно конечно "играть" с фазой, но это не есть правильное решение. Если есть возможность, лучше сразу завести PCI клок на глобальный вход.

     

    PAR это пропускает, но "осуждает".

    Исходя из этого, в конечном итоге так может быть все-таки лучше.

     

    См. выше. PLL в данном случае проблему не решает.

     

    Вообще, лучше сразу делать продуманно и правильно, ибо если не повезет, то больше времени потратите на выявление причин. Но может и повести :)

  14. Весьма упрощенная схема системы в прицепе.

     

    Это мой первый проект на FPGA.

    Но , к сожалению, без такой "кучерявости" по клокам никак...

    Отдельные блоки написаны, симулированы.

    PCI target уже проверен в железе.

    В девайсе два независимых канала DDR266,

    т. е. предусматривается вариант - один пишется, второй читается на PCI.

     

    Вопрос такой.

    Как правильней поступить с клоками?

    Что будет лучше:

    - Запитать PLL 2 от выхода PLL3 (установлено у меня сейчас так).

    - Запитать PLL 2 от выхода PLL1.

    - Запитать PLL 2 тоже от осциллятора (внешний кварц) .

    - Какой-то другой вариант...

    - Или все едино будет плохо, трудно будет добиться чтобы все это вместе работало :-).

    - "я дую на воду" :-)

    Входной поток - 660 мегабайт/сек

     

    Нужный функционал девайса на этом этапе:

    режим 1 (фоновый) - запись в память и чтение на PCI, rating определяется от PCI.

    допустимы пропуски во входном потоке данных.

    режим 2. запись до заполнения в оба канала DDR последовательно, стоп и

    затем чтение через PCI.

    Работа устройства начинается с инициализации регистров по PCI,

    затем и управляется (в основном) посредством записи команд в регистры через PCI.

    т. е. без PCI - "нет устройства".

    Может взять исходный для PLL 2-3 клок от PLL 1?

    Наверное это не есть хорошо, не знаю когда поднимается PCI clock (от Linux машины)- нет осцилографа под рукой.

     

    FPGA - Lattice EC33, 672 pin

     

    PLL1 вообще исключить, ибо далеко не всегда тактовый сигнал шины PCI является достаточно "качественным" для стабильной работы блока PLL. Не хочу сказать, что это обязательно будет так, но были случаи нестабильной работы.

     

    PLL2 и PLL3 тактировать внешним генератором, можно одним и тем же.

     

    Ну и не забыть разумеется про правильный сброс устройства с учетом сигналов захвата фазы от всех PLL.

  15. А что Вы подразумеваете под реальным временем в контексте задачи?

    Это ведь может быть и интервал между кадрами и просто отрезок времени пока объект можно считать статичным.

    Разница ведь может составить не один порядок.

    Если Вы знакомы с ПЛИС и модель есть, то может лучше начать с составления

    "бюджета требуемых затрат" вычислительной мощности.

    Если математика с плавающей зпт, относительно сколько ее? или все удалось свести к целым.

    IMHO, наиболее правильно сначала приводить модель максимально близко к языку HDL (verilog/vhdl и т.п.) или точнее к реализации в логике.

    Как распараллеливается модель?

    Т. е. сколько регионов/пикселов позволяет (или надо) обрабатывать одновременно.

     

    Симуляция даст тестирование и требуемые затраты по быстродействию.

    Реализация может вылится далеко не в одну ПЛИС, а группу, работающую параллельно.

    evolution board Вам поможет разве что обкатать отдельные модули для оценки фактических выч. затрат

     

    Я так подозреваю что алгоритм не может быть весьма статичным.

    У него наверняка есть куча параметров, которые надо изменять в зависимости от условий.

    Т. е. наличие в системе процессора для интерфейса с пользователем может оказаться весьма существенным.

    Оптимальной может оказаться структура CPU + ПЛИС.

    Например, ПЛИС делает черновую первичную обработку - то что хорошо параллелится и минимум плавающей математики.Почти все производители имеют чипы с блоками DSP.

    А окончательное решение уже может ложится на процессор.

    Здесь важен тип интерфейса CPU - ПЛИС.

     

    Все зависит от математики, возможно она лучше ложится на DSP процессор и Вы на ПЛИС фактически его и реализуете, с большей затратой сил.

    Хорошо адаптированная модель - сильно упростит систему.

    В общем, чем лучше подготовить модель - тем меньше потом потери.

    Что касается выбора ПЛИС - это уже на следующем этапе, когда имеете более конкретные требования к железу.

     

    +1. Очень многое зависит от конкретного алгоритма, который требуется реализовать. Vladimir :a14: , говорит о правильном подходе, при котором будет результат, все остальное - "пальцем в небо". Зачастую в подобных задачах используется связка CPU (DSP) + ПЛИС, все зависит от алгоритма обработки.

  16. Самому конечно можно, только сколько времени и здоровья я на это потрачу?

    Хотелось бы совет опытного разработчика чтобы делетанстских ошибок небыло.

     

    to All: Господа, автор темы в какой-то степени прав, по поводу целесообразности самостоятельной разработки, ибо все зависит от бизнес-плана проекта. :) Можно освоить и разработать самостоятельно все, что угодно, рано или поздно. Но если есть вполне конкретные сроки проекта и подобные факторы, то тут самодеятельностью серьезные люди (компании) не занимаются. Вообщем, все зависит от того, насколько качественный и насколько оперативно нужно получить результат.

     

    Если проект учебный, сроки позволяют и т.п., то можно и освоить...

  17. а у Менторов подобный аналог есть?

     

    На данный момент мне не известно средств других производителей подобных Synplicity Identify. Когда занимался этим вопросом, то было пару предложений, но их качество значительно уступало Identify. Возможно сейчас что-то и сдвинулось с места. Со стороны MG таких предложений не встречал и о планах разработки такого средства не слышал...

  18. Приходилось пользоваться Identify. Самым значительным преимуществом Identify, по сравнению со средствами подобными ChipScope, является то, что анализатор работает непосредственно с исходным кодом, то есть вся иерархия, сигналы и т.п. представлены в оригинальном виде. Средства, подобные ChipScope, работают с синтезированным "нетлистом", что зачастую очень затрудняет поиск нужных сигналов. Правда, если использовать Identify, то в качестве синтезатора придется использовать Synplify.

  19. Кстати, а почему CPLD исключается?

     

    В CPLD попросту нет необходимого количества ресурсов для реализации такой логики.

     

    Предложение Xilinx Spartan-3AN конечно хорошее, но вроде бы пока эти кристаллы проблематично достать...

     

    Кстати, еще следует учесть, что если поддерживать 5 вольтовую PCI, то потребуются внешние по отношению к ПЛИС преобразователи уровней на все сигналы шины PCI, что приводит к некоторому удорожанию устройства.

  20. Нужно сделать PCI устройство. Взять готовый PLX не удобно. Потому что хочеться поставить один паук, который бы и PCI сделал и еще некоторые функции реализовал. Цена должна быть МИНИМАЛЬНОЙ! От PCI требуется поддержка 2 функций, bus-master не будет. ну PCI 2.1 должна быть

     

    Какую плис взять? CPLD или FPGA? какую модель конкретно?

     

    CPLD исключается, нужно ставить FPGA. Смотрите семейства Xilinx Spartan 3(3E) или Altera Cyclone II (III). Какой конкретно кристалл выбрать (по емкости), зависит от того, что за функции требуется реализовать.

×
×
  • Создать...