jenya7 0 1 марта, 2017 Опубликовано 1 марта, 2017 (изменено) · Жалоба Зря вы отвергли предлагаемые вам пути решения проблемы (предлагали в других темах) У вас "программистическое" мышление, ну так и надо делать программисткие описания. Будет не супер оптимально, зато результат будет без боли и гораздо быстрее. У меня для вас даже есть рецепт успеха, всего то надо на верилог переехать, программистам там удобнее. я не все отверг. кое что взял. :) но верилог это тоже описание железа. там работают те же концепции - и там и там пишем под одно и то же железо - FPGA. Вобщем то многие вопросы отпали бы если разрешить один вопрос - достаточно ли одного клока для захвата сигнала другим процесом. допустим частота 50 Мега - клок 20 нано. время распостранения сигнала - я не помню точные цифры но что то вроде 5-10 нано на логическом элементе. несколько элементов и сигнал потерян? Изменено 1 марта, 2017 пользователем Jenya7 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Flip-fl0p 4 1 марта, 2017 Опубликовано 1 марта, 2017 (изменено) · Жалоба первый опасный. у второго процесса будет только один клок захватить ram_command. а второй это идея. SPI_DATA_LATCH защелкнет мне и состояние ram_command . да. это идея.... следущая тема будет - где поднять и где опустить SPI_DATA_LATCH. :) Так а почему вдруг другой процесс не сможет следующим клоком захватить ram_command ? У вас логики почти нет в процессе, где формируется ram_command. По сути передачу сигналов между двумя процессами можно рассматривать как передачу данных между двумя D триггерами. Допустим по 3 клоку у вас формируется новый сигнал ram_command. На 4 клоке этот сигнал принимается следующим процессом. Вы ради интереса промоделируйте с временнымии задержками. Вопросы отпадут сами собой. Обычно беды появляются когда очень много слоёв логики формируют сигнал.... Изменено 1 марта, 2017 пользователем Flip-fl0p Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jenya7 0 1 марта, 2017 Опубликовано 1 марта, 2017 (изменено) · Жалоба Так а почему вдруг другой процесс не сможет следующим клоком захватить ram_command ? У вас логики почти нет в процессе, где формируется ram_command. По сути передачу сигналов между двумя процессами можно рассматривать как передачу данных между двумя D триггерами. Допустим по 3 клоку у вас формируется новый сигнал ram_command. На 4 клоке этот сигнал принимается следующим процессом. Вы ради интереса промоделируйте с временнымии задержками. Вопросы отпадут сами собой. Обычно беды появляются когда очень много слоёв логики формируют сигнал.... а вы думаете там формируется два D-FLOP? хм...а что если буфферизировать для надежности? RAM_COMMAD_1 <= RAM_COMMAND; и второй процесс считывает RAM_COMMAD_1. тогда сигнал точно не потеряется. или даже так RAM_COMMAD_1 <= RAM_COMMAND; RAM_COMMAD_2 <= RAM_COMMAND_1; такую шутку делаю в энкодерах. Poor man debouncing. Изменено 1 марта, 2017 пользователем Jenya7 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Flip-fl0p 4 1 марта, 2017 Опубликовано 1 марта, 2017 · Жалоба а вы думаете там формируется два D-FLOP? хм...а что если буфферизировать для надежности? RAM_COMMAD_1 <= RAM_COMMAND; и второй процесс считывает RAM_COMMAD_1. тогда сигнал точно не потеряется. или даже так RAM_COMMAD_1 <= RAM_COMMAND; RAM_COMMAD_2 <= RAM_COMMAND_1; Ну в процессе который формирует RAM_COMMAND, этот процесс записывает эту команду в регистр. А регистр в ПЛИС это обычно набор D-триггеров. В зависимости от количества слоёв логики для формирования этого сигнала, после переднего фронта сигнал формируется с некоторой задержкой. А вот что происходит во втором процессе я без понятия. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jenya7 0 1 марта, 2017 Опубликовано 1 марта, 2017 · Жалоба Ну в процессе который формирует RAM_COMMAND, этот процесс записывает эту команду в регистр. А регистр в ПЛИС это обычно набор D-триггеров. В зависимости от количества слоёв логики для формирования этого сигнала, после переднего фронта сигнал формируется с некоторой задержкой. А вот что происходит во втором процессе я без понятия. да. по моему кое что прояснилось. спасибо. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
andrew_b 14 1 марта, 2017 Опубликовано 1 марта, 2017 · Жалоба допустим частота 50 Мега - клок 20 нано. время распостранения сигнала - я не помню точные цифры но что то вроде 5-10 нано на логическом элементе. несколько элементов и сигнал потерян? Для современных FPGA 50 МГц пустяки. STA вам скажет, укладываетесь вы в требуемую частоту или нет. Если нет, тогда и будете вставлять лишние регистры. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jenya7 0 1 марта, 2017 Опубликовано 1 марта, 2017 · Жалоба Для современных FPGA 50 МГц пустяки. STA вам скажет, укладываетесь вы в требуемую частоту или нет. Если нет, тогда и будете вставлять лишние регистры. а я нигде не определил частоту клока. я даже не нашел у квартуса в настройках где там частоту выбирать. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Flip-fl0p 4 1 марта, 2017 Опубликовано 1 марта, 2017 · Жалоба а я нигде не определил частоту клока. я даже не нашел у квартуса в настройках где там частоту выбирать. Задавать Вы её будете потом когда начнете описывать констрейны в .SDC файле. А максимальная частота проекта показывается после полной компиляции пректа, либо в программе TimeQuest. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jenya7 0 1 марта, 2017 Опубликовано 1 марта, 2017 · Жалоба да .вижу. спасибо. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться