[kuchynski 0]

Я, конечно, не в курсе зачем нужны данные vid_wr_fifo_din. Но маловероятно что они нужны постоянно, скорее кто-то смотрит по этому же клоку (clk_video_input), когда s_64bit_ready = '1'. Соответственно неоптимально хранить те же биты данных в vid_wr_yc_data_d1, в vid_wr_yc_data_d2 и в vid_wr_fifo_din.

[Golikov 0]

Это неправильно или просто не оптимально?

 

Опять та же ошибка:

 

неправильно это использовать асинхронный сигнал без синхронизации и защиты от метастабильности

неправильно это смешивать блокирующие и не блокирующие присвоения не понимая зачем они нужны

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

есть еще много чего неправильного - это все относится к нарушению стандартов языка и физических принципов построения ПЛИС.

 

все остальное правильно. Любая конструкция допустимая с точки зрения стандарта языка, синтезируемая (если вам нужна в итоге прошивка), и не нарушающий принципов ПЛИС - годиться. Дальше все решение вашей задачи.

 

конкретно в этом примере у вас 3 вектора по 20 бит и один вектор 60 бит.

каждый такт

первый вектор сохраняет входной результат.

второй вектор сохраняет первый

третий вектор сохраняет второй

и большой сохраняет их всех разом, ставя друг за другом.

 

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

 

Это не вопрос правильно - не правильно, оптимально - не оптимально, это вопрос конечной цели. Часто удобство поддержки проекта удобнее и ценнее пары потраченных ЛУТов. Как то так...

[FLTI 0]

Извините, я решил, что kuchynski нашёл ещё одну ошибку в коде, поэтому и решил уточнить.

[kuchynski 0]

Это я извиняюсь. Так, доколупался со скуки, не обращайте на меня внимания.

[FLTI 0]

Поясните ещё пожалуйста, почему для упаковки используется конструкция

if (clk_video_input'event and clk_video_input = '1') then

,а для распаковки

 if (rising_edge(clk_video_output)) then

Это просто погрешности написания или выдирания из какого-то источника или есть принципиальная разница?

 

И ещё, распаковка там почему-то вынесена из основного процесса в отдельный процесс, но ведь она должна быть в основном процессе, который начинается с

if (clk_video_input'event and clk_video_input = '1') then

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

[andrew_b 14]

Поясните ещё пожалуйста, почему для упаковки используется конструкция

if (clk_video_input'event and clk_video_input = '1') then

,а для распаковки

 if (rising_edge(clk_video_output)) then

Это просто погрешности написания или выдирания из какого-то источника или есть принципиальная разница?

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

[Golikov 0]

когда писал на VHDL тоже писал (clk_video_input'event and clk_video_input = '1'). Как то привык, и если бы сейчас начал что-то писать так бы и написал, ни о каких rising_edge() даже бы не подумал. Кстати видел недавно человек зачем-то переписывал все rising_edge на первый вариант, то ли число подключаемых библиотек уменьшал,то ли конфликты какие то были...

 

Еще из бонусов первого варианта, перевод с переднего фронта на задний происходит исправление 1 на 0, а не переписыванием слова, но может это и плохо...