Есть 2 книги: Дж. Уэйкерли "проектирование цифровых" устройств и Харрис Сара Л., Хэррис Дэвид М. "Цифровая схемотехника и архитектура компьютера" Крайне советую к их прочтению.
Тут мы расскажем как правильно сделать, можем показать пример как можно сделать. Но код за Вас писать никто не будет.
Если кратко: для того, чтобы моргать Вам надо отсчитать периоды в одну секунду.
В цифровой схемотехнике для счета почти всегда используется счетчик. Вспоминаем курс цифровой схемотехники: у нас у счетчика есть несколько выходов. Каждый следующий вывод переключается с частотой в два раза меньше чем предыдущий. Сколько выходов у счетчика определяется разрядностью счетчика. Например вот у нас есть 32 разрядный счетчик.
signal counter : unsigned(31 downto 0) := (others => '0');
Так вот если Вам если нет требования моргать с частотой РОВНО в 1 секунду, то просто берете нужный разряд счетчика и используйте его в качестве сигнала разрешения.
Соответственно когда разрешено - светодиоды горят, когда запрещено не горят.
DVI констрейны по данным и не нужны по сути )
В соответствии со стандартом - положение клока относительно данных может быть абсолютно случайным. Задача приемника по тестовым данным (которые передаются пока DE = 0) подстроиться под центр глаза - соответственно констрейны никак не помогут
P.S. Лучше не в сдвиговый регистр 1:10 данные принимать. А в DDR регистр - сможете больше разрешений принять.
Есть файл конфигурации FPGA, он хранится на чем-то энергонезависимом, например EEPROM. Внутри самой FPGA прошивка хранится в что-то вроде SDRAM памяти (поправьте если я ошибаюсь) Так вот саму FPGA конфигурировать можно сколь угодно много раз. А вот читать память с файлом конфигурации - зависит только от этой памяти. Поэтому в Вашем случае все зависит от памяти, откуда ARM ядро вычитывает прошивку для конфигурирования FPGA.
Вот этого не скажу. У меня в проекте почти всегда есть PLL. PLL генерирует сигнал locked. Соответственно пока у меня не завелась PLL все в сбросе. А сбрасываю только то, что должно быть сброшено.
Типа того... Очень грубо говоря: при инициализации ПЛИС, после её конфигурации происходит глобальный сброс, который как раз и инициализирует регистры. Инициализация единицами может потребовать дополнительный слой логики, что может ухудшить времянку. Но про инициализацию лучше читать в даташите на ПЛИС.
В данном конкретном случае у нас нет никакой разницы: писать ветку else или же нет. Quartus и Vivado нормально такие конструкции раскладывают, проблем выявлено не было.
По поводу тредов - проблема решается просто: создается скрипт, который выполняется автоматически по запуску Vivado. Вот там Вы и указываете необходимое количество потоков.
Если протокол передачи предусматривает подачу тестовых данных, то есть варианты, когда можно играя фазой клока\задержкой данных на входе автоматически подстроиться ровно в центр. Тогда вообще можно без выходных констрейнов для клока и данных обойтись.
