[SFx 0]

Среда 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]

Наблюдал такой же глюк в Моделсиме для тестбенча и модуля на Verilog.

Входы "рисуете тестебенчем"? Попробуйте по другому описать тестбенч - по меньше не синтезируемых конструкций. Мне это помогло. Глюк событийной модели.

[Gorby 6]

Наблюдал такой же глюк в Моделсиме для тестбенча и модуля на Verilog.

Входы "рисуете тестебенчем"? Попробуйте по другому описать тестбенч - по меньше не синтезируемых конструкций. Мне это помогло. Глюк событийной модели.

 

Оба не правы.

 

Отвлекитесь от программизма. И подумайте, что физически происходит в триггере.

А потом соотнесите это с вашей моделью.

А то сразу "авторемонтное изменение сосудов..." (с)Жванецкий

 

Правильный ответ: если хочется симулировать именно поведенческую модель,

то после КАЖДОГО присваивания сигналу (не переменной) ставим волшебное слово "after 1nS".

Хорошенько подумайте, зачем.

 

Если бы вы были более последовательны, то сделав имплементацию вашего творения в кристалл и получив модель для post-layout симуляции (с реальными таймингами), вы были бы приятно удивлены: всё бы работало, как задумано. Хорошенько подумайте, почему.

 

Подсказка: в реальном чипе ВСЕГДА имеется промежуток времени от фронта клока до изменения выхода триггера. А в вашей идеальной симуляции триггер изменяет свое состояние через 0 пикосекунд после фронта. Что вызывает массу интересных побочных эффектов.

 

Удачи.

[SFx 0]

........ Что вызывает массу интересных побочных эффектов.

 

про after 2ns - это хорошее замечание.

Смех смехом, а почему тогда всегда это работало, а щас не пашет? самое забавное, что когда я создал новый workspace там эта проблемам исчезала, а в Квартусе это поведение просимулировал, там тоже все шоколадно. и на функциональной и на временной. я сколонен считать что это все таки недоработка симулятора нежеле некорректность описания. тут симуляция функциональная же, почему же один сигнал, в одном и том же процессе, задерживается, а другой сигнал не хочет на отрез? Мне интересно, как выявить такие баги сразу и каким средствами. в моем случае тут все легко оказалось - 4 сигнала всего. а если такие глюки будут проявлсят на более серьезных проектах - как их обнаружить?

 

Наблюдал такой же глюк в Моделсиме для тестбенча и модуля на Verilog.

Входы "рисуете тестебенчем"? Попробуйте по другому описать тестбенч - по меньше не синтезируемых конструкций. Мне это помогло. Глюк событийной модели.

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

я раньше тоже такие баги встречал в моделсиме. он вообще ими кишит. правда и в алдеке были такие моменты. в 7.1 версии. искренне думал что все такое убрали. анн нет....

[Gorby 6]

про after 2ns - это хорошее замечание.

Смех смехом, а почему тогда всегда это работало, а щас не пашет?

Мне интересно, как выявить такие баги сразу и каким средствами. в моем случае тут все легко оказалось - 4 сигнала всего. а если такие глюки будут проявлсят на более серьезных проектах - как их обнаружить?

 

я раньше тоже такие баги встречал в моделсиме. он вообще ими кишит. правда и в алдеке были такие моменты. в 7.1 версии. искренне думал что все такое убрали. анн нет....

 

Повторяю: это НЕ баги. Тем более, не баги сред моделирования. (у сред тоже бывают баги, но их вы повстречаете гораздо позже и реже).

 

Баг - в вашей голове, если Вы думаете, что существует идеальный триггер.

 

Давайте проведем мысленный эксперимент. Есть два идеальных Д-триггера. Клок общий.

Выход первого соединен со входом второго (последовательно).

Изменяем сигнал на входе Д первого триггера. Так вот, в нарушение всех законов очевидности и причинно-следственности, Вы увидите изменившийся сигнал на выходе ВТОРОГО триггера по ТОМУ ЖЕ фронту клока, который зарегистрировал изменение входа на первом. Ибо состояние выхода первого триггера изменилось ОДНОВРЕМЕННО с фронтом клока. И уже ИЗМЕНЕННОЕ, зафиксировалось как входное для второго триггера.

Таким образом, сигнал "пролетит" любое количество триггеров. Вы ведь своими руками построили такую модель. Самое неприятное, что разные симуляторы разруливают такую ситуацию по-разному. Ибо ситуация сродни делению нуля на ноль. Возможное решение я Вам уже указал.

 

Теперь чем "кишит" Моделсим. Моделсим показывает Вам Ваши собственные ошибки. Научитесь внимательно разбираться, чего он от Вас хочет. Как и компилятор Си, без причин он не ругается.

[Des333 0]

Gorby:

По вашему предположению, все присваивания, написанные без указания задержек будут при моделировании(наприме, в Modelsim) выполняться одновременно и никак не буду соответствовать поведению реального триггера?

То есть результат симуляции такого простого куска кода:

always @(posedge clk)
  begin
    signal_d1 <= signal;
    signal_d2 <= sigbel_d1;
  end

Не будут соответствовать работе 2-х триггеров?

 

Я Вас правильно понял?

[RobFPGA 28]

Повторяю: это НЕ баги. Тем более, не баги сред моделирования. (у сред тоже бывают баги, но их вы повстречаете гораздо позже и реже).

 

Баг - в вашей голове, если Вы думаете, что существует идеальный триггер.

 

Давайте проведем мысленный эксперимент. Есть два идеальных Д-триггера. Клок общий.

Выход первого соединен со входом второго (последовательно).

Изменяем сигнал на входе Д первого триггера. Так вот, в нарушение всех законов очевидности и причинно-следственности, Вы увидите изменившийся сигнал на выходе ВТОРОГО триггера по ТОМУ ЖЕ фронту клока, который зарегистрировал изменение входа на первом. Ибо состояние выхода первого триггера изменилось ОДНОВРЕМЕННО с фронтом клока. И уже ИЗМЕНЕННОЕ, зафиксировалось как входное для второго триггера.

Таким образом, сигнал "пролетит" любое количество триггеров. Вы ведь своими руками построили такую модель. Самое неприятное, что разные симуляторы разруливают такую ситуацию по-разному. Ибо ситуация сродни делению нуля на ноль. Возможное решение я Вам уже указал.

 

Теперь чем "кишит" Моделсим. Моделсим показывает Вам Ваши собственные ошибки. Научитесь внимательно разбираться, чего он от Вас хочет. Как и компилятор Си, без причин он не ругается.

Круто но не в тему... :smile3009:

 

Это все же таки глюк стимулятора! В момент изменения состояния Clk (с точки зрения стимулятора это уже ПОСЛЕ изменения Clk) стимулятор рассчитывает НОВЫЕ значения состояния для ВСЕХ триггеров, и только после этого меняет состояние самих триггеров. При оптимизации этого процесса при компилировании и могут происходят подобные глюки. Порой просто перестановка строк текста меняет поведение модели.

В более старых версиях Aldec Active-HDL этот глюк всплывал чаще , сейчас я почти не сталкиваюсь с подобным .

 

Самый простой способ борьбы с этим как рази есть использование задержки при присвоении.

 

Успехов! Rob.

[des00 25]

Самый простой способ борьбы с этим как рази есть использование задержки при присвоении.

 

правда напрягает писать #Tp постоянно :)

 

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

[SFx 0]

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

 

А какие в систем верилоге есть механизмы для борьбы с этими гонками?

[andrew_b 15]

Давайте проведем мысленный эксперимент. Есть два идеальных Д-триггера. Клок общий.

Выход первого соединен со входом второго (последовательно).

Изменяем сигнал на входе Д первого триггера. Так вот, в нарушение всех законов очевидности и причинно-следственности, Вы увидите изменившийся сигнал на выходе ВТОРОГО триггера по ТОМУ ЖЕ фронту клока, который зарегистрировал изменение входа на первом. Ибо состояние выхода первого триггера изменилось ОДНОВРЕМЕННО с фронтом клока. И уже ИЗМЕНЕННОЕ, зафиксировалось как входное для второго триггера.

Таким образом, сигнал "пролетит" любое количество триггеров. Вы ведь своими руками построили такую модель. Самое неприятное, что разные симуляторы разруливают такую ситуацию по-разному. Ибо ситуация сродни делению нуля на ноль. Возможное решение я Вам уже указал.

Присоединяюсь к недоумевающему коллеге des333: вы несёте феерическую ахинею.

[Gothard 0]

Правильный ответ: если хочется симулировать именно поведенческую модель,

то после КАЖДОГО присваивания сигналу (не переменной) ставим волшебное слово "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]

LOL. Зачем тогда существует механизм дельта-задержек в симуляторе?

 

Он не "зачем", а "как работает в конкретном симуляторе".

 

Имеем тот эффект, что время срабатывания описанного кривыми руками триггера равно нулю.

А нуль, очевидно (жаль, не всем), всегда меньше любой дельты.

 

Причем этот эффект влияет не на текущий триггер (он-то сработал), а на последующий за ним, по цепочке. Или на текущий тоже, если перед ним стоял триггер тактируемый тем же клоком. А поскольку порядок обработки симулятором триггеров непредсказуем, то от изменения мест триггеров в проекте меняется результат симуляции.

[sazh 3]

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

 

А какие в систем верилоге есть механизмы для борьбы с этими гонками?

 

Причем тут гонки. Сравните с моделсимом. В моделсиме прекрасно все работает и без всяких там #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]

Присоединяюсь к недоумевающему коллеге des333: вы несёте феерическую ахинею.

 

Коллега des333 абсолютно точно выразил мысль. И недоумевал - имеет право.

А Вы оскорбляете. Ответьте за базар. Скриншот симулирования двух идеальных триггеров - в студию.

[SFx 0]

По теме: есть идея на счет того, где ваша проблема - вы каким образом подаете клок на этот блок по отношению к принимаемому сигналу?

Если в пути клока существует "промежуточный сигнал" (извините за сумбур), то это приведет к дополнительной дельта-задержке в клоке и тогда будет наблюдаемый вами эффект (т.е. действительно клок на триггере, появится уже с изменившимся сигналом rd_din_val, а не за одну дельта задержку до него.

 

 

О! вот это ценное замечание, действительно такой сигнал есть. пример 2 подходит под это. я всегда считал что такие переименования не видут к проблемам, оказывается на функциональной симуляции такие вещи делать нельзя. теперь понятно почему в Quartus этот сигнал успешно переименовал и все, а у в Aldec'е произошла бага.

Вот такая вот штука. получается что кроме понимания работы архитектуры системы нужно отлично понимать алгоритмы работы САПР, в котором эта архитектура верифицируется.

Очень было бы полезно почитать про дельта-задержки. Что бы в будущем таких "глюко-фич" избегать. Не подскажете, где и что почитать? Спасибо!

 

ЗЫ. В симуляторе после замены сигнала clk (в который перенапраялся вход модуля clk_in) на непосредственно сам вход, проблема исчезла полностью.