Странная проблема возникла:
есть довольно простенький проэкт под Xilinx XCR3064CS48 CPLD. Проэкт драйвит некоторый електромагнит в системе.
Код на VHLD. Я вообще сижу на Латтисе, на данный момент временно требуется данный Xilinx (в дальнейшем он заменится на соотв. Латтисе, но пока это то что есть), посему дизайн симулирован в среде Lattice (Модельсимом для Латтиса), затем когда симуляция ОК - открываю ISE, синтезирую под XCR3064CS48 и т.д.
Есть UCF файл в проэкте в ISE где определил ноги чипа под сигналы.
Проблема в том что после прожига не работает в чипе. Прежняя версия того-же дизайна работала ОК, сейчас внес изменения в код (UCF не трогал) - на выходах ничего нет. Прожигаю старую версию - чип работает ОК (согласно старой версии ессно).

Проверяю в ISE насчет констрейнов ног: содержимое UCF имеет описание всех ног, тогда как в окне где UCF разбивается на части (Timing COntraints таб) - два выхода из четырех вроде как не определены в плане ног.

Присоединены screenshots того о чем говорю. Также присоединен source VHDL как reference - хотя симуляция показывает что код вроде работает ОК.

Со средой ISE знаком плохо, да и нет намерения углубленно изучать ее ибо Латтисе удовлетворяте потребости, может что-то не определено для проэкта в ISE и посему не работает в чипе ?

Заранее благодарен за помощь.

Ради интереса в квартусе прогнал. Куча предупреждений, на неполный список чувствительности процесса. Что интересно, реализвция зависит от типа кристалла (CPLD, FPGA)
лачи в RTL какие то бессмысленные.

Да, дополнил списки чуствительности в процессы. Прогнал опять, не помогло...
Вариант без счетчиков - работает в чипе ОК. Код варианта без счетчиков присоединен...

Почему не работает Ваш - не знаю. Вряд ли от ного зависит. Но и работающий никуда не годится.
Нет там during system power-up. Закладка на синтезатор и тип семейства. (Скорее всего этот коре ду все же fpga по сути).
Скачайте xst.pdf и реализуйте в стиле декодера. У Вас же всего 8 входных состояний (MOTIN0 не используется), простробированных триггерами.
По идее каждый входной сигнал принять на 2 триггера по клоку. Реализовать case на 8 состояний для каждого из 4 выходов и простробировать выходными триггерами. Чего проще.
А power - up по нулям, так это от структуры кристалла зависит. Если это флеш, то номер наверно не пройдет.

Да, отсутствие power-up reset это мне известно. Увы, борд был спроэктирован подрядчиком, я унаследовал то что получилось, оживлял/изправлял его. На борту есть данный CPLD, их конкретный дизайн - полностью асинхронный, безо-всякого power-up reset. Спасибо им за то что хотя-бы удосужились вставить clk (которым они не пользовались в дизайне). Входа reset нет физически. Посему и извращался пытаясь каким-то образом задать обнулевку счетчика по началу работы...

Возможно не будет выхода и придется прособачить внешний RC от power на какию-нит торчащую свободную ногу чипа в качестве power-up reset системы...

Посмотрите на самом ли деле это структура CPLD. Сейчас модно структуру скрывать.
Да и у xilinx своя система установки начального состояния. Если регистры можно по включению питания в ноль установить, то и внутренний сигнал обнуления по клоку тоже можно сформировать.
Тогда и Ваша инициапизация в описании сигналов работать будет.
Надо только позаботиться, чтобы синтезатор не оптимизировал эту один раз срабатывающую структуру.


module power_up // Power-Up Don't Care - off
(
input clk,
output reg reset_power_up_n
);

reg [9:0] cnt_power_up;

always @(posedge clk)
begin
if (cnt_power_up == 10'd1023) reset_power_up_n <= 1'b1;
if (cnt_power_up != 10'd1023) cnt_power_up <= cnt_power_up + 1'b1;
end

endmodule

Сейчас подумалось - возможно есть толика истины в вашем предположени зависимости power-up установки регистров от технологии...
Я ведь как и упоминал симулировал под CPLD Латтиса а затем пере-синтезировал под Xilinx и прожигал. Возможно структура Xilinxа отлихается от Lattice и в плане началчной установки регистро по power-up и тогда вполне естественно симуляция под Lattice не дааст уверенности в результате под другого производителя....
Кроме того, я не уверен покажет учитывает-ли симулятор power-up setup регистров конкретного семейства которое он симулирует...при отсутствии implied/forced внешнего reset ??

А, стоп, мало того - я-то симулировал только functional, забыл про post-route....

я в основном все процессы делаю синхронными и в список чувствительности вписываю только клок
ни разу проблем не было

у ксайлинкса действительно все регистры изначально ставятся в ноль если не указать типа := '1'

Да, без пояснений оно не совсем понянто со стороны:
в системе есть проблема в том что при power-up срабатывает ложная комманда на на включение одного из режимов (видимо в результате влияния включения питания на конфигурацию системы которая драйвит данный CPLD), посему нужно было сделать что-то что-бы заблокировало первый sequence комманд (ложный). Посему получились latches о который и кручал синтезатор.



вообще-то стандарт рекоммендует иказывать полный sense list в процессе. Не уверен на что повлияет не полное указание сигналов в списке, но я в принципе, как минимум в качестве начинающего, стараюсь приделживаться стандарта (когда не забываю...). Иногда забываю все релевантные сигналы внести в список, получаю warnings, но до сих пор все работало и так...
Интересно на что влияет не полный список чуствительности...

Со стороны все и так понятно. От ложной команды на время устаканивания системы можно избавиться, подставив свою нужную команду. Введя входные триггера и установив (в интервале нужной длительности временного интервала) после включения питания на них нужные значения.
Лачи у Вас появились не сознательно, а от не корректного описания проекта.

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

З.Ы. Где-то на форуме этот вопрос поднимался

А временнОе моделирование автор делал? Еще интересный вопрос - как соотносятся с тактовым сигналом по времени управляющие входы?
Кроме того, триггеры и выходные сигналы MPH2 и MPH3 очевидно эквивалентны MPH0 и MPH1 соответственно, поэтому выбрасываются синтезатором.

Да, ессно, latchи появились в результате описания, трудно не согласиться.
Вы имеете ввиду управлять flip-flopами синхронизации входных сигналов управления ? Т.е. например держать их в resetе на протяжении начального временного интервала в течении которого появляется ложная комманда ?

Да. Только не в ресете. А по сформированному ресету в нужном Вам состоянии. А лачи наверно из за неполного описания состояний в case. Надо или полное или состояния по умолчанию.

Временное моделирование сделал сейчас только - но тоже для Lattice (нет симулятора для Xilinxа) - все тоже самое...
По входам упрявляющие сигналы никак не синхронизированы с клоком чипа, посему кака видимо правильно советовал sazh - неплохо-бы их засинхронизировать перед вводом в логику.
MPH1 и MPH3, MPH0 и MPH2 запараллелены вместе, так должно быть. Нет проблем если синтезатор выбросит логику паралельных выходов и просто подсоединит параллельные выходы к своим ногам..

Отнюдь, сравни



и



первый - D тригер с АСИНХРОННЫМ сбросом, второй - с СИНХРОННЫМ

да, но если убрать posedge из первого списка:



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



я ошибаюсь ?



Значит без внешнего resetа все-таки не обойтись... , т.е. придется шить на борту...

Нужен Моделсим + подключить библиотеки.Именно.

Я же выкатил реализацию, как без внешнего ресета обойтись. Если нужна запись константы в регистр только по включению питания. Сплошь и рядом ее по включению питания (Альтера) использую.
И на xilinx должно пройти. Пробуйте. Смотрите реализацию в RTL просмотрщике и количество задействованных ресурсов.

Я имел ввиду при описании на VHDL

У меня ModelSim под Латтис (OEM Lattice edition)...

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

Это не асинхронный сброс - это вообще невесть что, оно будет защелкивать D в Q по заднему фронту

reset (в добавок к положительному фронту clk). Синтезатор должен обругаться

Ошибаешься, это СИНХРОННЫЙ сброс, само по себе выставление reset в 1 не сбросит Q в 0, а произойдет это только по переднему фронту clk (это собственно и определяется списком чуствительности)




А что, VHDL каким то особенным способом интерпретирует списки чуствительности? Или синтезатор при синтезе с VHDL имеет право их проигнорировать, заодно нарушив семантику?

Может быть, я не знаком с синтаксисом Verilogа



Да, опять-же синтакс Verilogа мне мало знаком (если вообще), посему наверно и недопонял.



Спасибо за подсказку, реализовал что-то подобное. Дало возможность (в смысле реализация такого resetа) и использовать счетчик на задержку начало работы контролей выходов .
Симулируется хорошо в functional, синтезировал под Xilinx, загрузил в чип - работает как часы...

Но странная вещь происходит: пытаюсь симулировать в post-route functional и post-route timing - reset (и все что на него завязано) не работают... . Симуляция показывает reseta не происходит вообще.
Не пойму почему...то-ли такая реализация сильно привязана к технологии конкретного чипа/бренда (возможно в Xilinxовой CPLD работает, а в Latticeовской (под которую и симулировал) - не будет ?)
Странно....

Если я правильно понял, в железе xilinx реализация типа моей работает, а post-route timing в моделсиме это не работает. так не должно быть. Если конечно отрабатываются указания синтезатору при моделировании. Нюанс такой реализации заключается в том, что схема базируется на установке всх регистров по включению питания в ноль. А далее нужно смотреть как синтезатор отнесся к той части схемы, на которой реализованы внутренний ресет по включению питания. Эта часть схемы функционирует только во время "инициализации" по включению питания и не обладает периодичностью, как если бы ресет был бы внешний.
Синтезатор и может быть симулятор (если во времени это не ощущает) может минимизировать эту часть схемы, выбросив формирователь ресета и задать его константой 1, а значит и интервала не будет.
У Квартуса например есть специальное указание синтезатору. Кстати, указание внутренним сигналам в разделе инициализации проекта не минимизирует такую схему. Это по ресурсам в мап технологическом видно (константа 1 или счетчик формирования интервала). И временное моделирование это показывает в Квартусе, пакет цельный, а в связке с моделсимом я такую конструкцию не пробовал.
Если во временном моделировании этого интервала нет. А по ресурсам такая схема есть, и в железе работает, значит при моделировании в моделсиме в связке с xilinx что то не то. Наверное.
Я ведь выкатил реализацию в том числе и в надежде, что кто то это на других системах опробует.

Это бага в ISE Xilinx'а (точнее в генераторе post-route модели) Они зачем то сигнал glbl.PRLD (это загрузка начальных значений после reset'а) сделали локальной цепью в сгенерированной post-route модели (вместо того, что бы подключить ее к цепи PRLD модуля glbl) И сигнал этот никуда не подключен Добавь в bench.v

- заработает

В том то и дело что вначале синтезирую и симулирую под Lattice (у меня симулятор OEM ModelSim/Active-HDL Lattice). Затем, открываю ISE Web, синтезирую под Xilinx и загружаю в чип (CPLD) Xilinxа...
Т.е. говоря о симуляции (и functional и post-route) я имею ввиду симуляцию под Lattice. Значит получается так что функциональная симуляция под Lattice работает ОК а post-route functional & timing на Lattice не работает. При этом синтезируя для Xilinx XCR3064 - в чипе работает ОК.
Такхто видимо оно не имеет отношения к багам среды Xilinxа..





Да, в железе Xilinxа оно вроде работает, но в post-route симуляции в Lattice - не работает (обнулевка), хотя functional симуляция в том-же Латтисе - да работает. Ныло-бы интересно узнатч работает ли оно в симуляции post-route functional and timing в Xilinxе...а так-же интересно было-бы увидеть будет ли работать в железе Lattice...
Может RTL viewer Латиса даст ответ похему post-route симулятор в Латице не отрабатывает...
Завтра гляну....

А может кто-бы кто сидит на Xilinx смог-бы просимулировать код у него и рассказать нам как оно там работает ? Я бы дал VHDL код и test-bench...

Так как Вы привели примеры на Verilog, которого я к сожалению не знаю (знаком, но очень поверхностно) и не смог понять и проверить Ваши утверждения до конца. Из-за этого я так и написал.

З.Ы. Изначально вопрос стоял про Vhdl

Ой. Не понял тайного смысла делать post-route симуляцию на Lattice, если железка на Xilinx'е Или Lattice уже выкупил у Xilinx'а CPLD ветку и начал делать синтез для них?

Чистый functional наверно моделсимовский. Он оперирует процессами, к примитивам Латтисе не привязан и к Латтисе отношения не имеет.
А чтобы привязаться к Латтисе, нужна имитация включения по питанию. У xilinx эту функцию выполняет GSR.
Короче, смотрите структуру выбранного семейства (eeprom, sram), можно ли эту структуру в ноль инициализировать, читаете раздел как активизировать инициализацию регистров по включению питания в симуляторе. По ресурсам кристалла определяете, выбросил или нет синтезатор часть схемы, реализующую формирование внутреннего ресета (Ищите опцию в смнтезаторе типа игнорировать состояния регистров по power-up или нет. Если игнорировать, то и смысла в схеме формирования начальных состояний этих регистров нет, синтезатор вместо этой схемы константу подставит).
Если все регистры по включению в ноль инициализируются без внешних сигналов и схема формирования внутреннего ресета в ресурсах присутствует, то и в железе рабоать будет.

не, все гораздо прозаичней...я на работе работаю с 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 но не по отношению к клоку.