Перейти к содержанию

    

Tausinov

Участник
  • Публикаций

    137
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о Tausinov

  • Звание
    Частый гость
  1. Не хватает начального значения для счетчика
  2. FSM - это же объявленный тип, почему дальше в коде, вы с ним обращаетесь, как с сигналом?
  3. Первый вариант - асинхронный сброс, не требует наличия клока, но может привести к неприятным последствиям, если неправильно с ним обращаться. Второй вариант выдаст ошибку при синтезе, т.к. такое описание не является корректным с точки зрения используемых примитивов, а в симуляции приведет к лишнему срабатыванию ветки else при заднем фронте сброса. Третий вариант - синхронный сброс, без присутствия клока он работать не будет вообще.
  4. В приведенном вами коде описан асинхронный сброс, он работает не по фронту, а по уровню. Posedge в описании используется для корректной симуляции. Выделите фронт reset'а и подайте в качестве сброса на автомат выход этого детектора.
  5. Цитата(призрак @ May 10 2018, 18:07) 1. Для этого я пока ввёл промежуточный сигнал и 1 генерю им 2. Без обнулений были неопределённые значения Если все равно уже добавлен ресет, то можно устанавливать начальное значение по нему, без всяких промежуточных сигналов. Еще раз - дело не в обнулении, а в присвоении конкретных значений вместо дефолтных U, а нулевые они или нет - роли не играет. Цитата3. 56-59 - почему? это же просто сброс, он может потом раздельным быть, да и на не подключенные выводы ругается симулятор, до этого просто на земле сидел. Не важно, что это в вашем или чьем-либо другом понимании, с точки зрения языка сигнал может иметь несколько драйверов только в одном процессе. Из приведенного описания получается, что Qi ВСЕГДА равен FFi, но при этом по любому изменению сигналов из списка чувствительности еще и оказывается равен нулю - так не бывает.
  6. Цитата(призрак @ May 10 2018, 13:52) Потому что не повлияло на работу обнуление триггера в правой. Если сигналу в процессе значение присваивается несколько раз, то актуальным окажется самое последнее из выполненных присвоений, поэтому ничего и не изменилось.
  7. Цитата(призрак @ May 10 2018, 12:06) То есть если на элемент ИЛИ на один вход подаётся 1 а другой - неопределённый - логика не сработает? Выход просто окажется в том же самом неопределенном состоянии.
  8. Цитата(призрак @ May 10 2018, 11:26) Хорошо, но в данном случае что надо первоначально обнулять? D0...3? Q0...3? FF0...3? У вас внутренние состояния регистров U - т.е. неопределены, и из-за того, что на первый из регистров подается выход последнего прооренный со входным сигналом, это самое неопределенное состояние так и будет бесконечно на выходе каждого из регистров. Выше вам уже правильно посоветовали либо задать изначальные состояния этих самых регистров, либо устанавливать их по сбросу.
  9. PISO VHDL

    Цитата(MAXHAX @ Apr 12 2018, 16:31) мне надо, чтобы перед 3-им time bar было пол такта в нуле Из каких соображений "надо"? До прихода load или shift сдвиговый регистр хранит свое предыдущее состояние, в котором в младшем бите он имеет '1', почему вдруг на полтакта выход должен просесть в '0'? Цитата(MAXHAX @ Apr 12 2018, 16:58) ок, а как сделать синхронный load С точки зрения того самого "надо" это ничего не изменит. А так "синхронный" означает, что любые изменения выходных сигналов возможны только в момент одного из фронтов клока.
  10. PISO VHDL

    Цитата(MAXHAX @ Apr 12 2018, 16:20) теперь здесь идет не по clk, а по load идет, на скрине видно что по первому и 3-ему time bar они идут неверно Почему неверно? Сейчас все четко.
  11. PISO VHDL

    На первый взгляд, никакого криминала в коде нет. Единственное, что смущает - запятая после последнего сигнала в списке чувствительности. Было бы удобнее, если бы вы добавили еще и тестбенч, чтобы была возможность самому "пощупать".
  12. Цитата(NikSave @ Feb 16 2018, 18:33) Ну, во-первых, сигнал есть - это точно. Выводить их все на топ уровень, конечно, можно но это довольно гемморойно: обявить его в компоненте, объявить в топ-модуле, ну и в port map. И вообще мне одному кажется что vhdl какой-то нахлобученный и избыточный или не только мне?. Вот, например, зачем объявлять компонент в топ модуле? Нет, тут много таких. Некоторые сразу и довольно настойчиво начинают агитировать за Verilog. VHDL-2008 позволяет не объявлять. Можно делать так: Код     ....      U_1 : entity library_name.entity_name(structure_name)      .... Ну и еще некоторые упрощения, свойственные Verilog'у. Полный список можно легко найти в гугле. А так, VHDL несколько более избыточен, но это плата в том числе за то, что основные ошибки обнаруживаются еще на этапе компиляции. В общем полезнее знать оба, а чем уже пользоваться на постоянной основе - решать вам или подстраиваться под требования компании.
  13. Цитата(Flip-fl0p @ Jan 10 2018, 13:29) Вопрос тем кто пишет на VHDL. Для настроек модуля мне понадобилась функция округления значения до большего числа с отбрасыванием дробной части. В пакете ieee.math_real.all есть такая функция - ceil Насколько мне известно данная библиотека не является стандартной. Посему возникает вопрос, имеются ли подводные камни при использовании совместно библиотек: Код    use ieee.std_logic_1164.all;     use ieee.numeric_std.all;     use ieee.math_real.all; Если я не ошибаюсь, то можно отдельно только функцию "заинклудить", чтобы не беспокоиться о совместимости. И, вроде, даже есть еще более хитрый способ с вызовом функции через название пакета ieee.math_real.ceil, но это неточно. Кодuse ieee.math_real.ceil;
  14. Цитата(RobFPGA @ Dec 20 2017, 13:58) Приветствую! Вполне соответствует - Round-Robin это всего лишь арбитраж с циклическим приоритетом для равновероятного доступа и он не гарантирует строго последовательный выбор каналов. Для этого надо самому контролировать последовательность выдачи данных с канальных FIFO. Успехов! Rob. Понял, спасибо. Где-то в интернете набрел на похожую трактову Round-Robin, в итоге пришел к такому же выводу, но хотелось услышать стороннее мнение.
  15. Здравствуйте! Ситуация такая: использую ядро Xilinx axi4-stream interconnect 2.1 для коммутации 8-ми потоков в один, фифо для всех слейвов настроены на пакетный режим с переключением по tlast, арбитраж установлен в режим Round-Robin, клоки слейвов и свитча одинаковы, клок мастера асинхронен им. Данные идут пачками таким образом, что все фифо заполняются одновременно на размер достаточный для переключения. На каждую пачку на входе арбитра ожидал увидеть на выходе пакеты последовательно с каждого из фифо, начиная с нулевого. Но! Первый раз выкачка началась не с нулевого, а со второго или третьего фифо. Немного удивился, но придумал, как это обойти - задержал входы каждого следующего фифо на один такт, относительно предыдущего. Т.о. нулевое фифо заполняется до момента переключения первым, затем первое фифо и т.д. Как и ожидалось, выкачка началась с нулевого фифо, НО затем арбитр перепрыгнул на 7 фифо. Порядок данных на выходе важен, поэтому меня такой вариант не устраивает. Попытался разобраться в коде ядра, но с наскока ничего не вышло. Сталкивался ли кто-то с таким поведением, и насколько оно соответствует принципу Round-Robin?