не, все гораздо прозаичней...я на работе работаю с Lattice, т.е. все тулы их, ессно под реализацию в CPLD/FPGA Латтиса. Однако, один из бортов системы над которой сейчас работаю был заказан (еще до меня в данной фирме) у подрядчика, и те кто заказывали не дали четких требований к проэктировке (т.е. например бренд CPLD/FPGA, требования к конечной документации и т.д. и т.п.). Подрядчик завязан на Xilinx, посему и исползьзовал Xilinx. Мало того, они не работают со стандартными тулами производителя (ISE ежели в применении к CPLD/FPGA Xilinx либо других стандартных пакетов), Orcad/Altium/Mentor/... пакеты для schematic capture и т.д.....
Они склепали свою какую-то аппликацию для schematic capture (достаточно уродскую, не стабильную и полную багов), к ней присобачили графический редактор логики который привязали к синтезатору и P&R Xilinxа (у них какое-то полу-левое сoглашение с Xilinx по этому поводу). Т.е. они не пишут код логики VHDL/Verilog а вместо этого все рисуют графикой. Посему иьх дизайн логики абсолютно не портируемый, привязан исключителчно к ихней аппликации, сорсов как таковых нет (ибо в графике которая сугубо proprietary ихней проге). Вот мне и досталасч эта головная боль в наследство (пришел в фирму за месяц-два до поставки тех бортов). Кучу проблем с их дизайном (отчасти по вине моей конторы которые не задали четких и исчерпывающих тех. заданий оставив широкое поле выбора понимания подрядчику).
Вот и натолкулся на проблему их дизайна логики в CPLD Xilinxа который на борту. Т.е. у меня вся линейак тулов под Lattice (а инсталлировать не лицензионное на работе (в отличие от дома) - категорически исключено и не принято, по крайней мере в наших краях), пришлось "теорию" гонять под Латисе, а железо - то хто сидит на борту, т.е. Xilinx..





Functional показывал одинаково и в ModelSimе и в Active-HDLе (сейчас перехожу на Aldec). Да впрочем и весь post-route тоже пробовал и в Модельсиме и в Альдеке- оба показывали одинаково.
В целом согласен с вашими советами. Хотя данная конкретная реализация CPLD предназначена только для данного Xilinx чипа (ибо новая версия ботра будет делаться мной в недалеком будущем), будет интересно и поухителчно попробовать разобраться в нюансах влияния технологий такого рода чипов на мой случай (и ему подобные). Свою версию борта буду делать на Lattice ессно. Кроме того, вспомнил что у меня на работе лежит evaluation board Lattice ECP2 FPGA - думаю прожечь сегодняшнюю реализацию в нем по посмотреть будет ли работать как в Xilinx CPLD...

Но все-таки интересно услышать от пользователей Xilinxа - работает ли данный дизайн в post-route симуляции Xilinxа....я-бы дал свой сорс + test-bench....

Давай, попробую прогнать (если найдется время )

Спасибо, буду признателен..
Дал source и простенкий test-bench. Проверьте пожалуйста как работает в чисто функциональной симуляции и port-route functional и post-route timing. Пожалуйста обратиие внимание на началчные временны интервалы (там reset по идее будет/не будет работать)..

Проверил (функционал и post-route), поведение идентичное

Ага, отлично, спасибо.
Значит можно сделать вывод что post-route симуляция видимо действительно отражает реальную технологию конкретного бренда/семейства, т.е. действительно такое решение не работало-бы наверно в CPLD Lattice, но работает в Xilinxе, т.е. CPLD от данных производителей отлихаются технологией (возможно у одного по power-up flip-flopы устанавливаются в '0', у другого - не гарантировано (либо наоборот - устанавливаются в '1'). Ьотя пока это домыслы. Почитаю datasheet на них - посмотрим. Закину так-же сей вопрос на support Латиса...

В догонку - буду баlaгодарен за помощь:
дал два сорса, единственное отличие в том что во втором появился счетчик длительносит состояния forward автомата drive_state в целью идерживания состяния даже после окончания действия управляющих входов задающих данное состояние (input_state = "100").
Проблема в том что после добавления этого счетчика, автомат видимо стал работать не совсем как надо ибо то что вижу что сразу после окончания состояния revese есть прыжок в other, как и должно быть, но затем, без прихода соотв. упарвляющего входа - идет прыжок в forward и состояние удерживается счетчиком. После окончания счетчика - прыгает в other (как задано) затем уже согласно управляющему входу - прыгает в forward.
Т.е. в кратце, после добавления счетчика fwrd_counter появился паразитный прыжок из reverse в forward и в other, т.е. прыжок в forward без нуажного на то управляющего входа.

В первом сорсе нет данного счетчика и все работает ОК. Не мойму, как сей счетчик влияет на такое поведение автомата ?

Дал так-же test-bench. Самое интересное, в functional simulation такое странное поведение (при наличие счетчика) не проявляется, но при прожиге в чип (Xilinx XCR3064) - то что происходит (отслеживал скопом).

Может мне кто откроет глаза...

Все, всем спасибо, решено.
Управлающие входа были проблематичны в железе - выдавали glitches вскоре после послезного сигнала. Подрубился ко входам logic analyzerом - тогда все стало понятно. Эти glitches и сводили с ума state machine в моем коде. Добавил в state machine еще одно состояние с маленьким счетчиком блокирующее glitchеs, переписал test bench с точным моделированием тайминга контролных входов включая glitchи, просимулировал - все ОК.
Прожег в Xilinx - все встало на свои места, работает согласно симуляции.

Всем спасибо за помощь и поддержание духа...

Старайтесь использовать родные примитивы и стараться все сводить к ним. Иначе будут проблемы. Такие проблемы обычно возникают при использовании и R и S. Ну и стараться делать синхронную схему и в дальнейшем операции разносить по тактам для остутствия гонок. При наличии ассинхронности полезно сигналы простробировать внутренней частотой для дальнейшей беспроблеммности.
Тут правильно сказали, что надо симулировать и реализацию. Поглядите, что там насинтезировалось. Будете удивлены наверняка.


Ну Вы уже все и сами поняли.
Добавлю, что лучший симулятор ModelSim, а все остальное ...


Опоздал, извините. Грузинская тема интереснее.

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

Спасибо anyway...




Да нет, автомат у меня классический, полностью синхронный.
Просто по управляющим входам проходит glitch как раз совпадающий с одним из сигналов управления автоматом и с таймингом подходящим, в результате чего автомат переходил в другое состояние не вовремя чем сбивалась работа конечного устройства.
Glitch там не должен быть по specу и инфе полученной от конторы к чьему устройству я подлкюхаюсь

Ну ничего, теперь все ОК, glitch заблокирован автоматом (в данном случае не имеется ввиду glitch в смысле тайминга короче клока, что просто как короткий (короче обычного полезного сигнала но достаточно длинный для автомата - несколчко десятков клоков) управляющий сигнал там где его не должно быть. Во временном интервале конкретного устройства - это как glitch но не по отношению к клоку.