Flip-fl0p

Его не стоит избегать, а надо просто понимать что inout - это двунаправленный порт доступный только на выходных пинах. И применяется именно в качестве двунаправленного порта. Например шина данных DRAM памяти. Внутри самой ПЛИС никаких двунаправленных портов нет и попытка описать логику через такой порт - банальная ошибка в проектировании.

Всё просто: REG_OUT_SEL1 : out std_logic_vector(5 downto 0); REG_OUT_SEL2 : out std_logic_vector(5 downto 0); signal out_sel1 : std_logic_vector(5 downto 0); signal out_sel2 : std_logic_vector(5 downto 0); signal iREG_OUT_SEL1 : std_logic_vector(5 downto 0); -- Внутренний сигнал для выдачи наружу и чтения signal iREG_OUT_SEL2 : std_logic_vector(5 downto 0); -- Внутренний сигнал для выдачи наружу и чтения out_sel1 <= iREG_OUT_SEL1; -- Читаем наш внутренний сигнал out_sel2 <= iREG_OUT_SEL2; -- Читаем наш внутренний сигнал REG_OUT_SEL1 <= iREG_OUT_SEL1; -- Выдаем наш внутренний сигнал наружу REG_OUT_SEL2 <= iREG_OUT_SEL2; -- Выдаем наш внутренний сигнал наружу when ST_WORD_READ => when X"0022" => sspi_data_out <= "0000000000" & out_sel1; when X"0023" => sspi_data_out <= "0000000000" & out_sel2; when ST_WORD_WRITE => when X"0022" => iREG_OUT_SEL1 <= sspi_data_in(5 downto 0); when X"0023" => iREG_OUT_SEL2 <= sspi_data_in(5 downto 0); Вообще VHDL 2008 вроде как поддерживает и чтение выходных портов внутри архитектурного тела. Но работает криво и не всегда.

Через промежуточный сигнал надо все делать.

Это и есть причина. Sel не формируется. Поэтому выражение не выполняется. Поэтому всегда у нас работает ветка когда sel = 0 т.е на выход присваивается константа. Вот только странно. В первом сообщении нужен обычный мультиплексор. А сейчас Вы хотите, чтобы он тактировался, т.е чтобы где-то ещё стоял триггер. Так как вам надо то сделать ?

Что значит термин клокироваться ?

Никакой разницы между X <= A when (SEL = '1') else B; и process(all) begin if (sel = '1') then x <= a ; else x <= b ; end if; end process; У нас нет. А вот с задержкой распространения чуть сложнее. Т.к эта задержка сильно зависит от конкретной FPGA. Но 2..3 нс. слишком много. В FPGA большие задержки от физического входа (ножки) до самой матрицы. Как и наоборот, от матрицы до выхода.

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

Вот заниматься переводом чисел в калькуляторе это и есть заморачиваться. А преобразовывать типы - это не заморочки. Причем зачем везде писать std_logic_vector ? Его имеет смысл использовать только на входных\выходных интерфейсах, или на интерфейсах, сопрягаемых с IP корками.

Спасибо ! Не знал.... А последний вроде VHDL-2008 ?

Ну Вы сами и ответили :rolleyes: В случае если: signal sig : std_logic_vector(7 downto 0); То действительно выражение sig <= X"003" выдаст ошибу, ибо вы "впихиваете невпихуемое" Примерно то же и с sig <= 3. Ибо сколько разрядов у Вас - знаете только Вы. Напишите вот так: sig <= std_logic_vector(to_unsigned(3,8)); Т.е явно укажите разрядность при конвертации типа стандартными библиотеками - то VHDL вас поймет.

Потому-что никто кроме Вас не знает какая в итоге нужна разрядность для представления вашего числа. VHDL - строг. Вы сами должны контролировать разрядность чисел.

Вроде можно так: 10#3#

Насколько я помню параметр настраивается когда вы вытаскиваете компонент на поле схематика. Ведь вы же из VHDL описания создаете графический символ. И когда этот символ поместите в схематике в свойствах этого компонента настраиваете параметр. Вроде даже можно на этот блок мышкой жамкнуть 2 раза - и настроить все параметры. Точно не помню, т.к. со схематиком уже давным-давно не работал- нет необходимости в этом. P.S. А разве в ISЕ есть схематик ? Xilinx же вроде от него отказались...

Не совсем так. Можно прекрасно обойтись например и bit_vector, у которого есть одно важное свойство - он не resolved и ,как следствие, можно внести в код некоторый контроль ошибок. И для синтеза прекрасно применяется variable, что приведет к меньшим потребляемым ресурсами системы на моделировании - и как следствие большей скорости моделирования. И integer\natural(который я всегда применяю) - прекрасно синтезируются. А <= это оператор назначения сигнала. И только. Но важно не забывать про свойство этого оператора - дельта задержке. Применяйте тот тип с которым Вам проще описать схему - и забудьте про ограничение : Оно было придумано только от непонимания языка(хотя я сам ещё не все фишки VHDL понимаю) P.S. Вот только с Shared variable надо быть очень осторожным...

Огромное и Человеческое спасибо за то что вы пытаетесь нам помочь ! Но всё-же хотелось бы немного уточнить про выходной автомат. Что понимается под термином "выходной автомат" ? В моем случае в качестве автомата, который задает выходные синхроимпульсы - является пара автоматов: Один прыгает по состояниям back_porch_st => visible_area_st => front_porch_st => HS_st => back_porch_st ... и.т.д. Он генерирует сигнал DE для горизонтальных линий, он генерирует сигнал строчной синхронизации, и генерирует сигнал окончания строки для второго автомата. Другой автомат точно также прыгает по состояниям: back_porch_st => visible_area_st => front_porch_st => VS_st => back_porch_st ... И.Т.Д. Он принимает сигнал окончания строки от первого автомата считает строки и генерирует DE для вертикальных линий, генерирует сигнал кадровой синхронизации. Фактически пара автоматов - реализуют классический синхрогенератор для генерации таймингов в соответствии с VESA. Я могу запустить мой "синхрогенератор" в нужное мне время за счет того, что у меня автоматы начинают работу с состояния IDLE (которое нужно для первичной инициализации счетчиков, и возможности сброса синхрогенератора). Я всё пытаюсь понять сказанное Вами, и никак не могу взять в толк, а что я должен делать с автоматом, чтобы добиться синхронности ? Допустим я посчитал положительную или отрицательную задержку и запустил автомат в нужное время и первый кадр нового изображения вывелся как положено. Но потом у нас получается, что в реальности новый кадр может начать генерироваться либо чуть раньше (относительно прошлого кадра, т.е мой синхрогенератор ещё не завершил работу - досчитывает длительность кадрового импульса), либо чуть позже (т.е выходной автомат начал рассчет back_porch_st нового кадра). Я могу даже величину этой рассинхронизации посчитать в pixel_clk нового изображениея. И для того чтобы синхронность не нарушилась я должен: 1. Либо раньше начать генерировать изображение, в случае если у нас входные кадры идут чуть чаще чем выходные. т.е не выдать полную длительность VSYNC а начать генерировать back_porch_st нового кадра. 2. Либо я должен чуть подождать при генерации нового изображения случае если у нас выходные кадры идут чуть медленнее чем выходные - т.е удлинить длительность back_porch_st нового кадра. Но в обоих вариантах ожидание или "опережение" приводит к тому, что фактически искажается back_porch_st (в первой строке) что неминуемо ведет к искажению всего изображения (проверено на практике).