SFx 0 19 марта, 2009 Опубликовано 19 марта, 2009 · Жалоба Среда Aldec Active-HDL 8.1. process(clk) begin if rising_edge(clk) then s_rd_din_val_reg<=rd_din_val; if (rd_addr_in(5 downto 3)<5) then data_out_val <= rd_din_val; else data_out_val <= not s_rd_din_val_reg; end if; data_out<=rd_din; end if; end process; Сигнал 1 - rd_din_val - является входным с топлевела тестбенча и выходит из другого модуля после тригерра такого же clk. Сигнал 2 - s_rd_din_val_reg - по возрастанию фронта clk должен быть сигналом 1, задерженым на такт. Сигнал 3 - data_out - такойже вход (только шина из того же модуля проходит через топлевел) благополучно на такт задерживается. Где подвох? уже пробывал переписывать и так и эдок, все одно. перегружался, чистил проект - Сигнал 2 так и не задерживается на такт. Почему??? Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Kopart 0 19 марта, 2009 Опубликовано 19 марта, 2009 · Жалоба Наблюдал такой же глюк в Моделсиме для тестбенча и модуля на Verilog. Входы "рисуете тестебенчем"? Попробуйте по другому описать тестбенч - по меньше не синтезируемых конструкций. Мне это помогло. Глюк событийной модели. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Gorby 6 19 марта, 2009 Опубликовано 19 марта, 2009 · Жалоба Наблюдал такой же глюк в Моделсиме для тестбенча и модуля на Verilog. Входы "рисуете тестебенчем"? Попробуйте по другому описать тестбенч - по меньше не синтезируемых конструкций. Мне это помогло. Глюк событийной модели. Оба не правы. Отвлекитесь от программизма. И подумайте, что физически происходит в триггере. А потом соотнесите это с вашей моделью. А то сразу "авторемонтное изменение сосудов..." (с)Жванецкий Правильный ответ: если хочется симулировать именно поведенческую модель, то после КАЖДОГО присваивания сигналу (не переменной) ставим волшебное слово "after 1nS". Хорошенько подумайте, зачем. Если бы вы были более последовательны, то сделав имплементацию вашего творения в кристалл и получив модель для post-layout симуляции (с реальными таймингами), вы были бы приятно удивлены: всё бы работало, как задумано. Хорошенько подумайте, почему. Подсказка: в реальном чипе ВСЕГДА имеется промежуток времени от фронта клока до изменения выхода триггера. А в вашей идеальной симуляции триггер изменяет свое состояние через 0 пикосекунд после фронта. Что вызывает массу интересных побочных эффектов. Удачи. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SFx 0 19 марта, 2009 Опубликовано 19 марта, 2009 · Жалоба ........ Что вызывает массу интересных побочных эффектов. про after 2ns - это хорошее замечание. Смех смехом, а почему тогда всегда это работало, а щас не пашет? самое забавное, что когда я создал новый workspace там эта проблемам исчезала, а в Квартусе это поведение просимулировал, там тоже все шоколадно. и на функциональной и на временной. я сколонен считать что это все таки недоработка симулятора нежеле некорректность описания. тут симуляция функциональная же, почему же один сигнал, в одном и том же процессе, задерживается, а другой сигнал не хочет на отрез? Мне интересно, как выявить такие баги сразу и каким средствами. в моем случае тут все легко оказалось - 4 сигнала всего. а если такие глюки будут проявлсят на более серьезных проектах - как их обнаружить? Наблюдал такой же глюк в Моделсиме для тестбенча и модуля на Verilog. Входы "рисуете тестебенчем"? Попробуйте по другому описать тестбенч - по меньше не синтезируемых конструкций. Мне это помогло. Глюк событийной модели. входы управляеются процессом того же клока в другом модуле, который находится на одном уровне с этим в тестбенче, сигналы просто замаплены на прямую. я раньше тоже такие баги встречал в моделсиме. он вообще ими кишит. правда и в алдеке были такие моменты. в 7.1 версии. искренне думал что все такое убрали. анн нет.... Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Gorby 6 19 марта, 2009 Опубликовано 19 марта, 2009 · Жалоба про after 2ns - это хорошее замечание. Смех смехом, а почему тогда всегда это работало, а щас не пашет? Мне интересно, как выявить такие баги сразу и каким средствами. в моем случае тут все легко оказалось - 4 сигнала всего. а если такие глюки будут проявлсят на более серьезных проектах - как их обнаружить? я раньше тоже такие баги встречал в моделсиме. он вообще ими кишит. правда и в алдеке были такие моменты. в 7.1 версии. искренне думал что все такое убрали. анн нет.... Повторяю: это НЕ баги. Тем более, не баги сред моделирования. (у сред тоже бывают баги, но их вы повстречаете гораздо позже и реже). Баг - в вашей голове, если Вы думаете, что существует идеальный триггер. Давайте проведем мысленный эксперимент. Есть два идеальных Д-триггера. Клок общий. Выход первого соединен со входом второго (последовательно). Изменяем сигнал на входе Д первого триггера. Так вот, в нарушение всех законов очевидности и причинно-следственности, Вы увидите изменившийся сигнал на выходе ВТОРОГО триггера по ТОМУ ЖЕ фронту клока, который зарегистрировал изменение входа на первом. Ибо состояние выхода первого триггера изменилось ОДНОВРЕМЕННО с фронтом клока. И уже ИЗМЕНЕННОЕ, зафиксировалось как входное для второго триггера. Таким образом, сигнал "пролетит" любое количество триггеров. Вы ведь своими руками построили такую модель. Самое неприятное, что разные симуляторы разруливают такую ситуацию по-разному. Ибо ситуация сродни делению нуля на ноль. Возможное решение я Вам уже указал. Теперь чем "кишит" Моделсим. Моделсим показывает Вам Ваши собственные ошибки. Научитесь внимательно разбираться, чего он от Вас хочет. Как и компилятор Си, без причин он не ругается. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Des333 0 19 марта, 2009 Опубликовано 19 марта, 2009 · Жалоба Gorby: По вашему предположению, все присваивания, написанные без указания задержек будут при моделировании(наприме, в Modelsim) выполняться одновременно и никак не буду соответствовать поведению реального триггера? То есть результат симуляции такого простого куска кода: always @(posedge clk) begin signal_d1 <= signal; signal_d2 <= sigbel_d1; end Не будут соответствовать работе 2-х триггеров? Я Вас правильно понял? Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
RobFPGA 33 20 марта, 2009 Опубликовано 20 марта, 2009 · Жалоба Повторяю: это НЕ баги. Тем более, не баги сред моделирования. (у сред тоже бывают баги, но их вы повстречаете гораздо позже и реже). Баг - в вашей голове, если Вы думаете, что существует идеальный триггер. Давайте проведем мысленный эксперимент. Есть два идеальных Д-триггера. Клок общий. Выход первого соединен со входом второго (последовательно). Изменяем сигнал на входе Д первого триггера. Так вот, в нарушение всех законов очевидности и причинно-следственности, Вы увидите изменившийся сигнал на выходе ВТОРОГО триггера по ТОМУ ЖЕ фронту клока, который зарегистрировал изменение входа на первом. Ибо состояние выхода первого триггера изменилось ОДНОВРЕМЕННО с фронтом клока. И уже ИЗМЕНЕННОЕ, зафиксировалось как входное для второго триггера. Таким образом, сигнал "пролетит" любое количество триггеров. Вы ведь своими руками построили такую модель. Самое неприятное, что разные симуляторы разруливают такую ситуацию по-разному. Ибо ситуация сродни делению нуля на ноль. Возможное решение я Вам уже указал. Теперь чем "кишит" Моделсим. Моделсим показывает Вам Ваши собственные ошибки. Научитесь внимательно разбираться, чего он от Вас хочет. Как и компилятор Си, без причин он не ругается. Круто но не в тему... :smile3009: Это все же таки глюк стимулятора! В момент изменения состояния Clk (с точки зрения стимулятора это уже ПОСЛЕ изменения Clk) стимулятор рассчитывает НОВЫЕ значения состояния для ВСЕХ триггеров, и только после этого меняет состояние самих триггеров. При оптимизации этого процесса при компилировании и могут происходят подобные глюки. Порой просто перестановка строк текста меняет поведение модели. В более старых версиях Aldec Active-HDL этот глюк всплывал чаще , сейчас я почти не сталкиваюсь с подобным . Самый простой способ борьбы с этим как рази есть использование задержки при присвоении. Успехов! Rob. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
des00 25 20 марта, 2009 Опубликовано 20 марта, 2009 · Жалоба Самый простой способ борьбы с этим как рази есть использование задержки при присвоении. правда напрягает писать #Tp постоянно :) еще более правильный способ уйти от поведенческой модели верилога, к поведенческой модели систем верилога, в которой минимизировали гонки сигналов. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SFx 0 20 марта, 2009 Опубликовано 20 марта, 2009 · Жалоба в принципе понятно, если нет бабла и поддержки со стороны производителя симулятора - то самый простой способ борь бы - ставить эти задержки. если же есть возможность проапдейтится - то лучше и проще это сделать. я более склонен к тому что это гонка сигналов. жаль что в моем случае это приводит к тому что от смены строк ничего не меняется. А какие в систем верилоге есть механизмы для борьбы с этими гонками? Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
andrew_b 16 20 марта, 2009 Опубликовано 20 марта, 2009 · Жалоба Давайте проведем мысленный эксперимент. Есть два идеальных Д-триггера. Клок общий. Выход первого соединен со входом второго (последовательно). Изменяем сигнал на входе Д первого триггера. Так вот, в нарушение всех законов очевидности и причинно-следственности, Вы увидите изменившийся сигнал на выходе ВТОРОГО триггера по ТОМУ ЖЕ фронту клока, который зарегистрировал изменение входа на первом. Ибо состояние выхода первого триггера изменилось ОДНОВРЕМЕННО с фронтом клока. И уже ИЗМЕНЕННОЕ, зафиксировалось как входное для второго триггера. Таким образом, сигнал "пролетит" любое количество триггеров. Вы ведь своими руками построили такую модель. Самое неприятное, что разные симуляторы разруливают такую ситуацию по-разному. Ибо ситуация сродни делению нуля на ноль. Возможное решение я Вам уже указал. Присоединяюсь к недоумевающему коллеге des333: вы несёте феерическую ахинею. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Gothard 0 20 марта, 2009 Опубликовано 20 марта, 2009 (изменено) · Жалоба Правильный ответ: если хочется симулировать именно поведенческую модель, то после КАЖДОГО присваивания сигналу (не переменной) ставим волшебное слово "after 1nS". LOL. Зачем тогда существует механизм дельта-задержек в симуляторе? По теме: есть идея на счет того, где ваша проблема - вы каким образом подаете клок на этот блок по отношению к принимаемому сигналу? Если в пути клока существует "промежуточный сигнал" (извините за сумбур), то это приведет к дополнительной дельта-задержке в клоке и тогда будет наблюдаемый вами эффект (т.е. действительно клок на триггере, появится уже с изменившимся сигналом rd_din_val, а не за одну дельта задержку до него. Проще на примере показать, как может такое получиться. -- example 1 -- clk_gen - сигнал по которому вы генерируете данные -- data generation rd_din_val <= "..." when clk_gen'event and clk_gen='1'; clk <= clk_gen; -- уже достаточно для такой ошибки -- example 2 -- на это раз не так явно -- data generation rd_din_val <= "..." when clk'event and clk='1'; -- UUT port map ( ... rd_din_val <= rd_din_val, clk_in <= clk, ... ); ------------------- -- UUT Inside ... signal clk; ... begin ... clk <= clk_in; ... или же U_BUFG : bufg port map (I=> clk_in, O=>clk); ... P.S. поправил чуть для понятности Изменено 20 марта, 2009 пользователем Gothard Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Gorby 6 20 марта, 2009 Опубликовано 20 марта, 2009 · Жалоба LOL. Зачем тогда существует механизм дельта-задержек в симуляторе? Он не "зачем", а "как работает в конкретном симуляторе". Имеем тот эффект, что время срабатывания описанного кривыми руками триггера равно нулю. А нуль, очевидно (жаль, не всем), всегда меньше любой дельты. Причем этот эффект влияет не на текущий триггер (он-то сработал), а на последующий за ним, по цепочке. Или на текущий тоже, если перед ним стоял триггер тактируемый тем же клоком. А поскольку порядок обработки симулятором триггеров непредсказуем, то от изменения мест триггеров в проекте меняется результат симуляции. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sazh 8 20 марта, 2009 Опубликовано 20 марта, 2009 · Жалоба в принципе понятно, если нет бабла и поддержки со стороны производителя симулятора - то самый простой способ борь бы - ставить эти задержки. если же есть возможность проапдейтится - то лучше и проще это сделать. я более склонен к тому что это гонка сигналов. жаль что в моем случае это приводит к тому что от смены строк ничего не меняется. А какие в систем верилоге есть механизмы для борьбы с этими гонками? Причем тут гонки. Сравните с моделсимом. В моделсиме прекрасно все работает и без всяких там #T localparam div = (10*xtal_clk) / baud; initial begin sys_clk = 1'b0; forever #(halfperiod) sys_clk = ~sys_clk; end initial begin tx_data = 8'h00; rst = 1'b0; repeat (div/4) @(posedge sys_clk); rst = 1'b1; tx_data = 8'h55; И с квартусом все прекрасно сходится. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Gorby 6 20 марта, 2009 Опубликовано 20 марта, 2009 · Жалоба Присоединяюсь к недоумевающему коллеге des333: вы несёте феерическую ахинею. Коллега des333 абсолютно точно выразил мысль. И недоумевал - имеет право. А Вы оскорбляете. Ответьте за базар. Скриншот симулирования двух идеальных триггеров - в студию. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SFx 0 20 марта, 2009 Опубликовано 20 марта, 2009 · Жалоба По теме: есть идея на счет того, где ваша проблема - вы каким образом подаете клок на этот блок по отношению к принимаемому сигналу? Если в пути клока существует "промежуточный сигнал" (извините за сумбур), то это приведет к дополнительной дельта-задержке в клоке и тогда будет наблюдаемый вами эффект (т.е. действительно клок на триггере, появится уже с изменившимся сигналом rd_din_val, а не за одну дельта задержку до него. О! вот это ценное замечание, действительно такой сигнал есть. пример 2 подходит под это. я всегда считал что такие переименования не видут к проблемам, оказывается на функциональной симуляции такие вещи делать нельзя. теперь понятно почему в Quartus этот сигнал успешно переименовал и все, а у в Aldec'е произошла бага. Вот такая вот штука. получается что кроме понимания работы архитектуры системы нужно отлично понимать алгоритмы работы САПР, в котором эта архитектура верифицируется. Очень было бы полезно почитать про дельта-задержки. Что бы в будущем таких "глюко-фич" избегать. Не подскажете, где и что почитать? Спасибо! ЗЫ. В симуляторе после замены сигнала clk (в который перенапраялся вход модуля clk_in) на непосредственно сам вход, проблема исчезла полностью. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться