[ArAhis 0]

Вот такой вот кусок кода:

entity accum is
   port (
      n : in std_logic_vector(5 downto 0);
      clk : in std_logic;
      din : in std_logic_vector(35 downto 0);
      dout : out std_logic_vector(41 downto 0)
   );
end accum;

architecture Behavioral of accum is

type accum_64_t is
   array (0 to 63) of std_logic_vector(41 downto 0);

signal din_42 : std_logic_vector(41 downto 0);
signal data : accum_64_t;

begin

din_42(34 downto 0) <= din(34 downto 0);
gen1 : for t in 35 to 41 generate
   begin
      din_42(t) <= din(35);
   end generate;

data(0) <= din_42;

...

dout <= data(0);

end Behavioral;

Это тестовый кусок кода, в котором я просто пытался понять, почему Modelsim 5.8d на выход dout выводит "UUU..."! Если вместо dout <= data(0); написать dout <= din_42; моделирование будет происходить нормально, на выходе dout будет сигнал din_42??

С чем это связано, может я не правильно использовал массив???

[CaPpuCcino 0]

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

и вообще не понятно - 1) какова практическая ценность этого кода - что хотели изобразить-то? 2)зачем вам блоки generate? 3) где у вас процесс чувствительный к тактирующему сигналу (коль вы уж его заводите на порт)?

объяснитесь - мож чего и подскажем :)

[ArAhis 0]

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

Не забываю, это в тестбенче делаю.

1) какова практическая ценность этого кода - что хотели изобразить-то?

Я же написал, что это тестовый кусок кода, на самом деле сигналу dout присваивается сумма всех 64-х значений data(i), суть не в этом, а в том что ModelSim не хочет выводить сигналы массива в сигнал dout.

2)зачем вам блоки generate?

Если есть другие предложения как передать бит din(35) в биты (41 downto 35) сигнала din_42, буду только рад!

3) где у вас процесс чувствительный к тактирующему сигналу (коль вы уж его заводите на порт)?

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

[id_gene 0]

Если есть другие предложения как передать бит din(35) в биты (41 downto 35) сигнала din_42, буду только рад!

что-то вроде

din_42 <= (34 downto 0 => din (34 downto 0), others => din(35));

[CaPpuCcino 0]

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

[evgeniy_s 0]

Уважаемый ArAhis, все замечания, которые Вам сделал CaPpuCcino - правильны. Даже тестовые примеры нужно писать с соблюдением основных правил, к которым относится наличие процесса, пусть даже асинхронного, но с соответствующим списком чувствительности. А то вы можете долго разбираться в сути кода, думая, что в нём ошибка, а на самом деле ошибка будет в неправильном срабатывании процесса или ещё чего-нибудь в этом роде. Я, например, если нужно что-то проверить отдельно от основного проекта пишу тестовый файл и сразу заношу туда тактовый сигнал и ресет, причём тактовый сигнал провожу через DCM, а ресет, как положено, завожу на GSR. И только после этого можно экспериментировать с кодом.

В Вашем случае код конечно компилируется и выполняется правильно (в смысле моделируется). Я его моделировал в Aldec'е - всё в порядке. На dout выводится то что нужно т.е. data(0). Посмотрите направление отображения сигналов в Modelsim'е. Если там отображаются сначала старшие ячейки массива data(63), то возможно Вы просто не увидели конец этого длинного массива. Если нет, то попробуйте всё-таки написать правильно код - с использованием процесса. Может быть Modelsim более чувствителен к этому, чем Aldec. А может вместо многоточия у Вас там ещё чего-нибудь есть, что портит эти сигналы - посмотрите внимательней. И заодно рекомендую почитать книгу: Суворова Е.А., Шейнин Ю.Е. Проектирование цифровых систем на VHDL. - СПб.: БВХ-Петербург, 2003. - 576 с.: ил.

И ещё, не стоит делать диапазоны у сигналов разные, всмысле использовать в проекте и to и downto - запутаетесь где какой порядок. Когда перейдёте к процессу - незабудьте заменить generate на более правильную структуру для сигналов loop.

Желаю удачи. :)

[CaPpuCcino 0]

и сигнал data(0) в список чувствительности не забудьте при переходе на процесс поставить - а то вот абсолютно точно именно такой глюк как описали получите - процесс будет срабатывать по din а событие для записи dout в модели будет отсутствовать (по поводу generate - вы создаёте реплики объектов - а зачем? завели бы процесс и обошлись бы простым loop-ом)

[Oldring 0]

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

[CaPpuCcino 0]

по семантике может и ненужная, но ток:

1) никакого глюка здесь не было - этот код в представленном здесь виде работает нормально - проверяли 2 человека

2) можно и без процессов - но тогда ввод проекта сведётся к "сxематическому" вводу (шаг всторону от поведения) - только не графеским методом а при помощи описания на языке ХДЛ, что к стати замедлит симуляцию из-за большего числа обьектов в пространстве обьектов моделирования

Изменено 13 декабря, 2005 пользователем CaPpuCcino

[evgeniy_s 0]

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

Уважаемый Oldring, Вы абсолютно неправы. Грамотное написание исходного кода ещё никогда никому не вредило. Ведь обозначив процесс вы тем самым производите декомпозицию схемы на более мелкие подсхемы и сосредотачиваете своё внимание на конкретном объекте, на его работе и поведении. Тем самым облегчаете себе поиск ошибок. А если всё лепить в кучу - то ничего не будет работать и сложно будет разобраться в причинах. Как, например, и в данном случае - 2 уважаемых человека проверили исходный код, причём на разных системах и всё работает, а у автора данного топика - нет. И вот мы уже дошли до обсуждения основ VHDL, а на вопрос почему у ArAhis'а не работает пример так и не ответили - потому, что при таком написании исходного кода может быть всё что угодно. А если бы код был бы написан правильно, то мы сейчас обсуждали бы конкретику и наверняка уже выяснили бы глюк ли это Modelsim'а или ошибка ArAhis'а.

[Oldring 0]

Грамотное написание исходного кода ещё никогда никому не вредило.

 

С этим утверждением согласен абсолютно.

 

Теперь о том, с чем я не согласен.

 

Во-первых, каждое параллельное присваивание сигнала является процессом. Если моделсим на таких конструкциях глючит - то к грамотности написания кода это не имеет никакого отношения. Моделирование кусков плоской логики через параллельные конструкции без обратных связей - это стандартная практика. Не вижу у нее больших недостатков. Особенно, когда речь касается просто переформатирования шины.

 

Во-вторых, то, что два человека попробовали этот код, и у них все нормально, еще больше склонило меня к выводу, что это был именно глюк Моделсима. Альтернатива - это то, что автор вопроса лопухнулся и вынес на всеобщее обсуждение не тот код, который тестировал. Она, конечно, тоже имеет право на рассмотрение. Но я еще раз повторю, что лично видел у Моделсима другие подобные глюки с массивами и не только, и я сам уже раньше подозревал, что эти глюки сродни порче памяти - понять условия их возникновения я не смог. Просто, когда они возникали - переписывал код так, чтобы они исчезали. В моделсиме глючит все, от симулятора до GUI. Рассматриваемый пример только укрепил мои подозрения в природе данного программного продукта. Вот только какая ему реальная альтернатива?

[evgeniy_s 0]

... автор вопроса лопухнулся и вынес на всеобщее обсуждение не тот код, который тестировал.

Отлично сказано. Ещё хочу добавить, что автор данного вопроса, видимо, уже потерял интерес к своему же вопросу, надеюсь, что у него всё получилось.

В моделсиме глючит все, от симулятора до GUI.

Абсолютно согласен.

Вот только какая ему реальная альтернатива?

А меня, например, полностью устраивает Aldec. Там есть всё, что мне нужно: и неплохие библиотеки и великолепный интерфейс и качественное моделирование. Смарт-модели можно подключить через соответствующие библиотеки. Как-то давным-давно при переходе от Active-HDL 4.2 к Active-HDL 5.1 я попробовал поработать на моделсиме - непонравилось и вот сейча использую уже своё третье поколение Aldec'а (6.2) и вполне доволен. Предстоит работать с Virtex 4, надеюсь, что в Active-HDL 7.1 и ISE 7.1 будут соответствующие библиотеки. :)