[Maverick_ 15]

все будет работать, он же не заводит эти сигналы на процессы со срабатыванием по фронту/спаду.

про это он(Rundll) не писал :)

Я не знаю, а может и будет заводить?

[Rundll 0]

Забить%), у вас же синхронный дизайн, у меня большинство тестов с текстовым выходом и в железе всё работает с полпинка. Один раз решил глянуть вейвформу там была куча таких дельтацикловых финтов, но т.к. дизайн был синхронный ни к чему плохому это не приводило.

Спасибо за Ваш оптимизм =)

 

Ну и кроме того добавлю, что сигнал prt_data_next это есть следующее значение триггера prt_data_reg, таким образом фичи наблюдаются у комбинационного prt_data_next, а у синхронного prt_data_reg после приема по клоку значения prt_data_next в следующем такте этих фич уже нет.

 

про это он(Rundll) не писал smile.gif

Я не знаю, а может и будет заводить?

Нет, заводить ничего никуда не буду.

[ViKo 1]

Ну и кроме того добавлю, что сигнал prt_data_next это есть следующее значение триггера prt_data_reg, таким образом фичи наблюдаются у комбинационного prt_data_next, а у синхронного prt_data_reg после приема по клоку значения prt_data_next в следующем такте этих фич уже нет.

prt_data_next у вас - выход комбинационной логики? (или триггера? я плохо разбираюсь в VHDL, но этот сигнал, кажется, описан, как регистр).

Тогда получается что триггер prt_data_reg по тактовому фронту регистрирует данные в виде глитча. Как насчет удовлетворения временам установления/удержания сигнала? Вероятны метастабильные состояния.

Только благодаря тому, что сигнал в комбинационной логике формируется уже после тактового сигнала, можно надеяться на удовлетворение упомянутым временам. Для надежности можно задержать prt_data_next в LCELL.

upd. С другой стороны, все сдвиговые регистры так работают, и ничего! Снимаю свое замечание.

[rloc 51]

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

Чтобы было понятно, откуда появляются пички, открывайте "modelsim_user.pdf" и читайте внимательно раздел "Expanded Time in the Wave and List Windows".

 

Для простоты понимания, можно рассмотреть 2 примера:

1)

if clk'event and clk='1' then
  a <= b;
  c <= a;
end if;

Если бы все задержки были равны нулю, то мы бы получили, что в один момент времени a = b и c = b. Поэтому моделсим вводит небольшую дельту (не путать с Resolution Time) и c = b только на следующем фронте clk.

 

2)

a <= b;
c <= a xor b;

Здесь также моделсим добавляет небольшую дельту между сигналами a и b, в результате при поведенческом моделировании при смене состояния b из '0' в '1' или наоборот на выходе c мы увидим пички с длительностью в одну дельту. Чтобы внимательно рассмотреть эти дельты открывайте меню Wave->Expanded Time->Expand All

[CaPpuCcino 0]

Если бы все задержки были равны нулю, то мы бы получили, что в один момент времени a = b и c = b. Поэтому моделсим вводит небольшую дельту

нехорошо говорить "небольшую дельту", потому что у дельты нет размера, точнее её размер НОЛЬ. дельта - модельная сущность, модельная абстракция (по сути слот событий) её физически не существует. эти волосы на диаграмме - просто особенности работы алгоритма рисовалки. они даже в glitch и skew не обязательно превратятся - всё будет зависеть от инертности физ. модели.

[rloc 51]

нехорошо говорить "небольшую дельту", потому что у дельты нет размера, точнее её размер НОЛЬ. дельта - модельная сущность, модельная абстракция (по сути слот событий) её физически не существует. эти волосы на диаграмме - просто особенности работы алгоритма рисовалки.

В данном случае - это абстракция, введенная разработчиками моделсима и ее вполне можно рассмотреть :rolleyes:

Event-based simulators such as ModelSim may process many events at a given simulation time.

Multiple signals may need updating, statements that are sensitive to these signals must be

executed, and any new events that result from these statements must then be queued and

executed as well. The steps taken to evaluate the design without advancing simulation time are

referred to as "delta times" or just "deltas."

 

Ладно, поправлюсь, в данном случае N*deltas<Resolution Time при сколько угодно большом N

[Vadim 0]

В данном случае - это абстракция, введенная разработчиками моделсима

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

ЗЫ Я извиняюсь, но может не стОит больше вводить начинающих в заблуждение?

[rloc 51]

Думаю начинающие простят мое незнание стандартов по моделированию.

 

Для закрепления усвоенного материала, привожу простенький кусочек тестового кода для функциональной симуляции и результаты моделирования в Моделсиме (каждый может проверить). Это к вопросу CaPpuCcino об особенностях алгоритма рисовалки.

library ieee;
use ieee.std_logic_1164.all;       
use ieee.std_logic_unsigned.all;

entity gluk is
port(
  clk : in std_logic;
  cnt : out std_logic_vector(7 downto 0));
end gluk;

architecture behavioral of gluk is     
  signal a, b, c: std_logic;
  signal tmp: std_logic_vector(7 downto 0) := X"00";
begin
  a <= clk;
  b <= a xor clk;
  c <= not (b or clk);
  
  process (c)
  begin
    if c'event and c = '1' then
      tmp <= tmp + X"01";
    end if;
  end process;
  cnt <= tmp;

end architecture;

[Maverick_ 15]

Думаю начинающие простят мое незнание стандартов по моделированию.

 

Для закрепления усвоенного материала, привожу простенький кусочек тестового кода для функциональной симуляции и результаты моделирования в Моделсиме (каждый может проверить). Это к вопросу CaPpuCcino об особенностях алгоритма рисовалки.

library ieee;
use ieee.std_logic_1164.all;       
use ieee.std_logic_unsigned.all;

entity gluk is
port(
  clk : in std_logic;
  cnt : out std_logic_vector(7 downto 0));
end gluk;

architecture behavioral of gluk is     
  signal a, b, c: std_logic;
  signal tmp: std_logic_vector(7 downto 0) := X"00";
begin
  a <= clk;
  b <= a xor clk;
  c <= not (b or clk);
  
  process (c)
  begin
    if c'event and c = '1' then
      tmp <= tmp + X"01";
    end if;
  end process;
  cnt <= tmp;

end architecture;

простите но я ничего не понял, поясните, плиз, подробнее (читал с 19 сообщения и все последующие). Где "волоски" должны быть и где их не должно быть? В чем прикол? ;)

[rloc 51]

простите но я ничего не понял, поясните, плиз, подробнее

Все очень просто, счетчик tmp (cnt) инкрементирует не "+1", а "+2" по каждому фронту сигнала с. Даже если я раззумлю график до масштаба 1пс, никаких гонок сигналов вы не увидите не по clk, не по c

[CaPpuCcino 0]

Для закрепления усвоенного материала, привожу простенький кусочек тестового кода для функциональной симуляции и результаты моделирования в Моделсиме (каждый может проверить). Это к вопросу CaPpuCcino об особенностях алгоритма рисовалки.

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

UPD извините - долго писал

 

Даже если я раззумлю график до масштаба 1пс, никаких гонок сигналов вы не увидите не по clk, не по c

и?

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

 

дельтациклы времени не имеют (ещё раз повторюсь), поэтому зумить можно сколько угодно. нужно просто смотреть сколько раз произошёл апдейт "с". очевидно он произошёл дважды. вы это хотели продемонстрировать и закрепить? если да, то вопросы выше сняты.

[rloc 51]

Автор этого топика спрашивал про сигнал prt_data_next, в котором наблюдались непонятные "скачки". Я так понимаю Вы попытались объяснить это следующим образом:

эти волосы на диаграмме - просто особенности работы алгоритма рисовалки.

Т.е. если я правильно понял, Вы говорили о неправильном отображении на экране.

 

Я попробовал объяснить "скачки" особенностями работы алгоритма Моделсима и вполне корректным отображением на экране. Кто разберется с понятием "дельты", тот сможет не только объяснить, но и сделать скриншот в Моделсиме, поясняющий глюк функциональной симуляции моего примера.

[CaPpuCcino 0]

Автор этого топика спрашивал про сигнал prt_data_next, в котором наблюдались непонятные "скачки". Я так понимаю Вы попытались объяснить это следующим образом:

можно, наверное, и так сказать, хотя я говорил не о конкретном примере, а в общем о пиках в вейвформе при логическом моделировании(я не вникал в начальный пост, а высказал своё замечание по поводу последующих)

Т.е. если я правильно понял, Вы говорили о неправильном отображении на экране.

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

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

[rloc 51]

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

Будем считать наши позиции совпадают.

[sazh 5]

Думаю начинающие простят мое незнание стандартов по моделированию.

 

Для закрепления усвоенного материала, привожу простенький кусочек тестового кода для функциональной симуляции и результаты моделирования в Моделсиме (каждый может проверить).

a <= clk;

b <= a xor clk;

c <= not (b or clk);

 

А можно еще тест бенч приложить.

У меня не получилось. Что в Квартусе, что в моделсиме.

Все сминимизировалось к инверсному клоку с шагом +1