M_A 0 9 апреля, 2005 Опубликовано 9 апреля, 2005 · Жалоба Делаю проектна Cyclone. Работаю на частотах близких к его предельным. при этом возникают существенные задержки обрабатываемых сигналов по сравнению с периодом клока, что приводит к следующему: изначально делал функциональный анализ, добился требуемых результатов, сделал временной- не пашет. Манипуляции с сигналом у меня происходят по высокому уровню клока, я предположил, что сигнал из-за задержек сместился, сделал чтоб все происходило по низкому уровню- времянка заработала как надо. Но теперь ерунда с функционалкой... Сделать, чтобы симулировалось нормально одновременно и в функционалке и во времянке не получилось. Микросхемы пока до меня не добрались, поэкспериментировать с железом не могу, посему вопрос: достаточно только временного симулирования? что в этом случае посоветуете? чем все это грозит и какие могут быть проблемы в железе после прошивки? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Vjacheslav 0 9 апреля, 2005 Опубликовано 9 апреля, 2005 · Жалоба Как раз временное моделирование и дает настоящий результат, а не функциональное, результаты которого весьма приближенные/предварительные! Вообще никогда не делаю функциональное моделирование. В сущности выражение "временное моделирование" не очень корректное - точнее надо бы называть это "полное моделирование". Результаты такого моделирования у Altera весьма точны - как отмоделировали, так и будет работать. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
3.14 0 9 апреля, 2005 Опубликовано 9 апреля, 2005 · Жалоба Хотя на вопрос уже ответили, для общего развития ... У Xilinx типов моделирования - 4: 1) Поведенческое 2) Уровня RTL 3) PostMAP 4) PostPAR 1 - работа алгоритма 2 - после того как над вашей писаниной прошелся синтезатор и выкинул "не нужные" части Вашего кровью полученного кода. 3 - после работы "размещателя" на кристалле 4 - после окончательного размещения элементов и разводкой соединений Зачем столько типов, оставили бы только PostPAR. Если проект развесистый, времени на симуляцию будет уходить - сто тыщ мильёнов :) А так можно еще выявить, в каком месте получается 2+2=35. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
M_A 0 10 апреля, 2005 Опубликовано 10 апреля, 2005 · Жалоба Vjacheslav, 3.14 Большое спасибо за ответы! :) Вопрос возник вот из чего, я заводил подобную тему на Телесистемах, там многие ответили, что пользуются или функциональным моделированием, или временным, но полностью уверены, что в функциональном у них то же самое. Я же изначально тоже всегда только времянкой пользовался, вот и подумал, может у меня неправильный подход к разработке проектов на ПЛИС? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sazh 8 10 апреля, 2005 Опубликовано 10 апреля, 2005 · Жалоба Я и сейчас могу подтвердить, что у меня в функциональном и в временном моделировании одни и те же результаты ( в пределах интервала глобального клока). И к этому надо стремиться. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Andrey Filippov 0 10 апреля, 2005 Опубликовано 10 апреля, 2005 · Жалоба У Xilinx типов моделирования - 4: 1) Поведенческое 2) Уровня RTL 3) PostMAP 4) PostPAR ... Зачем столько типов, оставили бы только PostPAR. А я уже давно отказался от всех, кроме первой. И то, симуляция минимального размера кадра занимает больше 10 минут, а с латентностью - уходит не меньше получаса. А более сложные случаи - и того больше - часы. Хотя раньше, особенно в меньшего размера однократно программируемых FPGA QuickLogic, я обычно использовал последнюю. Сейчас - функциональная симуляция - отдельно, анализ времен - отдельно. И максимальные частоты, получаемые в железе совпадают с предсказанными Xilinx-овскими тулами с примерно 5-10% точностью. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
M_A 0 11 апреля, 2005 Опубликовано 11 апреля, 2005 · Жалоба Исходя из всего вышесказанного у меня вопрос к тем, кто пользуется только функциннальным моделированием: В железе из-за задержек возникают всякие траблы вроде пиков, иголок, данные приходят раньше клока, иногда даже генерация выскакивает.... Как при готовом проекте это обнаруживаете и как с этим боретесь? Я думал что такие вещи только на времянке можно увидеть, хотя чувствую что не только, а думал так по не знанию, ламер пока Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Andrey Filippov 0 11 апреля, 2005 Опубликовано 11 апреля, 2005 · Жалоба Исходя из всего вышесказанного у меня вопрос к тем, кто пользуется только функциннальным моделированием: В железе из-за задержек возникают всякие траблы вроде пиков, иголок, данные приходят раньше клока, иногда даже генерация выскакивает.... Как при готовом проекте это обнаруживаете и как с этим боретесь? Я думал что такие вещи только на времянке можно увидеть, хотя чувствую что не только, а думал так по не знанию, ламер пока <{POST_SNAPBACK}> Когда устройство достаточно сложное, проверить все такие "иголки" очень сложно или невозможно, поэтому нужно так писать код, чтобы их не было вообще (т.е. не было в том месте и в то время, когда они бы могли на что-то повлиять). Как именно это делать - тонны литературы существует, но основная суть проста - синхронный дизайн, тщательный разбор устройств на границе клоков (желательно использовать в таких случаях готовые, проверенные решения), учет возможной метастабильности. Если полагаться на результаты симуляции полностью разведенной микросхемы (опять таки - для сложного устройства тестов может быть очень много), то после любого минимального изменения может измениться раскладка всего остального, узлов никак не связанных с тем, где было внесено изменение. Конечно, можно замораживать разводку проверенных модулей - но это стоит делать только тогда, когда уже ничего другого не остается. Желательно, чтобы пригодная раскладка генерировалась из исходных текстов с минимальным набором (максимально общих) временных ограничений. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dxp 65 11 апреля, 2005 Опубликовано 11 апреля, 2005 · Жалоба Как раз временное моделирование и дает настоящий результат, а не функциональное, результаты которого весьма приближенные/предварительные! Вообще никогда не делаю функциональное моделирование. Да, Post P&R моделирование дает более близкое поведение к железу. Но цена за это чрезмерна: [1] чуть-ли не на порядок бОльшее время, затрачиваемое симулятором (а вот мне надо один или несколько видеокадров прогнать - дык замучаешься ждать); [2] и крайнее неудобство при работе - все имена попереименованы, свои интересующие объекты найти - еще та работа. В случае функционального моделирования обеих этих трудностей нет - все работает максимально быстро, удобство при отладке полное - все переменные на месте. В итоге я почти никогда не использую P&R моделирование, а в основном только функциональное. P&R использую только в редких случаях, когда надо посмотреть/отследить какие-то конкретные времянки в каких-то конкретных точках (например, в последний раз надо проконтролировать, через сколько времени после фронта клока на триггере I/O элемента данные вываливаются на пин - интерфейс с асинхронной памятью отлаживал). Но это редкость. И пользоваться этим для отладки функционирования - имхо, мазохим. :) Реально подавляющее большинство ошибок - в функциональной модели. И именно функциональное моделирование их эффективно выявляет. Разумеется, для того, чтобы потом эта функциональная модель адекватно реализовывалась в железе, надо и проектировать, и писать ее соответственно, с учетом ограничений как синтезатора, так и целевой ПЛИС. В этом случае, когда на функциональном уровне описание работает правильно, после синтеза и разводки, при условии, что временнОй анализатор тоже не сообщает проблемах с времянками (т.е. что, типа, что-то не успевает), все работает ожидаемым образом. В сущности выражение "временное моделирование" не очень корректное - точнее надо бы называть это "полное моделирование". Результаты такого моделирования у Altera весьма точны - как отмоделировали, так и будет работать. <{POST_SNAPBACK}> Не так давно столкнулись с непоняткой: микруха MAX3128, в ней простой мультиплексор, симулятор в Квартусе (и в Альдек пробовали передавать - ровно то же самое, что и понятно) выдает время переключения около 20 нс, а реально в железе - где-то около 12-14 нс. Спрашивали поддержку Альтеры, они сказали, что, дескать, юзайте последние версии софта. А софт, понятное дело, был последней версии. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
vetal 0 11 апреля, 2005 Опубликовано 11 апреля, 2005 · Жалоба Vjacheslav, 3.14 Большое спасибо за ответы! :) Вопрос возник вот из чего, я заводил подобную тему на Телесистемах, там многие ответили, что пользуются или функциональным моделированием, или временным, но полностью уверены, что в функциональном у них то же самое. Я же изначально тоже всегда только времянкой пользовался, вот и подумал, может у меня неправильный подход к разработке проектов на ПЛИС? <{POST_SNAPBACK}> А вы в своем проекте уверены? Схема должна работать при любых условиях! В вашем случае получается ограничение на минимальную тактовую частоту, если вы по каким либо причинам переместите схему в более быстрый кристалл, то схема может перестать стабильно работать. На сколько я понял, ограничения на длину конвейера, чисто символические, попробуйте воставить дополнительную ступень. Не так давно столкнулись с непоняткой: микруха MAX3128, в ней простой мультиплексор, симулятор в Квартусе (и в Альдек пробовали передавать - ровно то же самое, что и понятно) выдает время переключения около 20 нс, а реально в железе - где-то около 12-14 нс. Спрашивали поддержку Альтеры, они сказали, что, дескать, юзайте последние версии софта. А софт, понятное дело, был последней версии. Был у меня подобный случай, на max7s, когда целую неделю пытался переписать данные из одного регистра в другой на частоте 30 МГц, при расчетной частоте схемы 80. Проблемма решилась ручным синтезом(в макроэлементы) и разводкой(компоновкой). Причем и функциональная и временная модели работали как нужно. Не известно почему,но файл временных задержек, не соответствовал действительности в 2-2.5 раза. При этом использовалась самая последняя версия ПО. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Joker 0 11 апреля, 2005 Опубликовано 11 апреля, 2005 · Жалоба Vjacheslav, 3.14 Большое спасибо за ответы! :) Вопрос возник вот из чего, я заводил подобную тему на Телесистемах, там многие ответили, что пользуются или функциональным моделированием, или временным, но полностью уверены, что в функциональном у них то же самое. Я же изначально тоже всегда только времянкой пользовался, вот и подумал, может у меня неправильный подход к разработке проектов на ПЛИС? <{POST_SNAPBACK}> Функциональное мод. не учитывает задержек между элементами и служит для проверки функциональной работы схемы. Временное мод. учитывает задержки внутри ПЛИС.Поэтому я обычно провожу функц. мод. и только в конце когда функц. мод. меня устраивает провожу временное мод.Если временное мод. не совпадает с функциональным то смотрю пути в мах. задержками и как-то модифицирую их так чтобы результаты и функц. и временного мод. совпадали .Таким образом необходимо использовать и то и другое мод.(функц. кстати проходит значительно быстрее). Если у Вас проходит временное мод. и не проходит функц. то вероятно схеиа работает на задержках что вобщем-то не правильно.Должно проходить и то и другое.(кстати временоое мод. не проходит если не описаны ВСЕ входные ножки ПЛИС ) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Vjacheslav 0 12 апреля, 2005 Опубликовано 12 апреля, 2005 · Жалоба Если Вы занимаетесь разработкой скоростных устройств - близко к пределу, используемой ПЛИС, то несовпадение фукционального и временного моделирования обычное дело. Не стоит принимать это "близко к сердцу". У меня ситуация чаще всего именно такая - поэтому наплевал давно на функциональное - тем более уже давно не делаю ошибок в функции (как правило - тьфу ....). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
BSV 0 12 апреля, 2005 Опубликовано 12 апреля, 2005 · Жалоба Зачем столько типов, оставили бы только PostPAR. Если проект развесистый, времени на симуляцию будет уходить - сто тыщ мильёнов :) А так можно еще выявить, в каком месте получается 2+2=35. <{POST_SNAPBACK}> Был у меня случай, когда синтезатор неправильно обрабатывал VHDL-модуль. То есть логическая модель работала, а post-translate уже нет. Железка тоже естественно не работала. Надо правда сказать, что это было вызвано кривостью кода (не мной написанного) и после нескольких ударов зубилом по нужным местам все пришло в норму. В нормальной же ситуации первого и последнего типа моделирования хватает за глаза. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
popeye 0 7 сентября, 2005 Опубликовано 7 сентября, 2005 · Жалоба Уважаемые гуру, проясните, пожалуйста, вот такой вопрос. Если у меня выполняются все временные ограничения на рабочую частоту, то какая разница, сработает ли логика между парой регистров за 50 пс до очередного фронта клока или за 5 нс до него? И для чего тогда вообще временное моделирование? P.S. Я всегда использовал функциональное моделирование и данные временного анализатора после компиляции проекта, а времена предустановки и clock-to-out, по-моему, надо учитывать отдельно (вместе с времянкой внешних устройств). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
3.14 0 7 сентября, 2005 Опубликовано 7 сентября, 2005 · Жалоба Нет никакой гарантии что Вы затяните констрейнами все пути своего проекта, тем более что сделаете это правильно, а метастабильность... Ну а использование симулятора, практически позволяет осуществить макетирование (причем с учетом диапазона температур и питания), только в большинстве "наших" проектов это выходит дороже макетирования. Ну а если Ваш проект вход - конвеер - выход, тогда достаточно знать что констрейн для данного тактового сигнала выполнен (ну и путь логика - пин то же). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться