[slog 0]

Как правильно организовать запуск процессов?

У меня получается какая-то ерунда, чего-то не понимаю.

 

Вообщем вот такой процесс описан в отдельном файле и включен в главный модуль в виде компонента

PORT    (
    clk           : IN STD_LOGIC;
    process_start : IN STD_LOGIC
    )
ARCHITECTURE RTL OF TX_block IS
SIGNAL process_run    : STD_LOGIC;

PROCESS (clk, process_start)
BEGIN
    IF rising_edge(clk) THEN
        IF process_start = '1' THEN
            process_run = '1';
        ELSE     process_run = '0';
        END IF;
    END IF;
END PROCESS;

 

запускается этот процесс из самого главного процесса таким образом

    variable start_cnt     : integer range 0 to 500 :=0;
    IF rising_edge(clk) THEN
        
        start_cnt := start_cnt + 1;
        CASE start_cnt IS
            WHEN 100 => process_start <= '1';
            WHEN 101 => process_start <= '0';
            WHEN 500 => start_cnt := 0;
        END CASE;
    END IF;

У меня получается что process_run через раз устанавливается.

Счётчик start_cnt прошёл через 100 а process_run не установился.

clk везде общий.

 

если в CASE поменять условия таким образом

            WHEN 100|101|102 => process_start <= '1';
            WHEN 103|104|105 => process_start <= '0';

 

То process_run устанавливается каждый проход счётчика.

Получается что одного такта не хватает чтобы вся схема переключилась. Схема работает всего на 33MHz.

 

Почему не хватает одного такта?

Как правильно запускать процессы

[StewartLittle 44]

Процесс запускается по изменению любого сигнала из списка чувствительности. Т.е. в Вашем случае интересующий процесс будет запускаться по любому изменению clk и process_start.

Ну а поведение - это, как в старом анекдоте - надо не кран менять, а всю систему :)

[slog 0]

Я тоже думал что процесс должен запускаться всегда, если во время фронта clk сигнал process_start = '1'. Осциллограф кажет что нет, бывают пропуски. Кол-во не пропущенных и пропущенных тактов зависит х.з. от чего, и оно меняется при некоторых изменениях в программе. Вся схема работает с одного клока и синхронна, по крайней мере я так думаю.

Но на самом деле что-то не так. И я пока не понимаю из за чего это.

[StewartLittle 44]

Я тоже думал что процесс должен запускаться всегда, если во время фронта clk сигнал process_start = '1'.

Неправильно. Не смешивайте понятие "запуск процесса" и алгоритм работы Вашего устройства. Еще раз повторюсь, что Ваш процесс будет запускаться по любому изменению сигналов clk и process_start.

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

[Ender 0]

Во-первых, даже если вы думаете, что она синхронна, синхронна она может быть, к сожалению, только в идеале. Т.е., если вы хотите добиться гарантированно корректной синхронизации, используйте не общую синхронизацию (т.н. System Synchronization согласно лексикону Xilinx), а синхронизацию от предыдущего блока. Т.е., например, предыдущий блок выдал данные и выдал тот же клок, что поступил ему на вход, только сдвинутый на полтакта. Вот этот новый клок и будет использоваться для нового блока для уверенности, что он уже принял данные (т.к. они уже будут идти полтакта).

Насчет промоделировать в симуляторе.. Да, конечно. Промоделируйте. Вначале в behavioral - т.н. поведенческом. Он покажет вам, ТЕОРЕТИЧЕСКИ правильно работает ваш код или нет. Никаких задержек здесь не учитывается. И далее - в Post-Place and Route Simulation. Т.е. симуляции после разводки и размещения элементов. Если и там будет результат, аналогичный behavioral, то уже можно быть более спокойным.

 

P.S.: согласно личному опыту. И при отладке и по быстродействию, да и по всему... Проект в ПЛИС необходимо разбивать на максимально МАЛЕНЬКИЕ функционально блоки. Соответственно, раз блок маленький, то и ненужно там будет делать более одного процесса. И вообще, более одного процесса в модуле желательно избегать, дабы не происходило каких-то бы ни было конфликтов драйверов сигналов.

Изменено 8 марта, 2008 пользователем Ender

[Artem_Petrik 0]

Насколько я вижу ваш процесс - это всего лишь D триггер. Так ли он синтезируется думаю несложно посмотреть в RTL viewer, или тем что его заменяет у ксайлинкса.

Глюк у вас явно не в приведенных участках кода. Утверждение "всего 33Мгц" тоже может быть не совсем корректным, я вот наспор могу набросать модуль, которому и 1 Мгц много :) .

Действительно все стоит погонять на симуляторе, посмотреть состояние различных промежуточных сигналов.

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

К сожалению по имеющимся данным точнее угадать причину глюка тяжело.

 

Т.е., например, предыдущий блок выдал данные и выдал тот же клок, что поступил ему на вход, только сдвинутый на полтакта. Вот этот новый клок и будет использоваться для нового блока для уверенности, что он уже принял данные (т.к. они уже будут идти полтакта).

Улыбноуло :) . Похоже вам, уважаемый Ender стоит поподробнее разобраться в том, что такое синхронная схема, и зачем там тактовая частота. Изложенная вами концепция - полный бред.

[Ender 0]

Насколько я вижу ваш процесс - это всего лишь D триггер. Так ли он синтезируется думаю несложно посмотреть в RTL viewer, или тем что его заменяет у ксайлинкса.

Глюк у вас явно не в приведенных участках кода. Утверждение "всего 33Мгц" тоже может быть не совсем корректным, я вот наспор могу набросать модуль, которому и 1 Мгц много :) .

Действительно все стоит погонять на симуляторе, посмотреть состояние различных промежуточных сигналов.

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

К сожалению по имеющимся данным точнее угадать причину глюка тяжело.

Улыбноуло :) . Похоже вам, уважаемый Ender стоит поподробнее разобраться в том, что такое синхронная схема, и зачем там тактовая частота. Изложенная вами концепция - полный бред.

 

Изложенная мной схема - если и полный бред, то бред от XILINX!!! И называется данный БРЕД SOURCE_SYNCHRONOUS в его лексиконе. Почитайте подробнее User Guide.

К тому же этот, так называемый вами бред, позволяет добиться частоты в 370 МГц на Virtex-4 при реализации RAKE-приемника, например!

 

Выбирайте выражения в следующий раз.

[CaPpuCcino 0]

Проект в ПЛИС необходимо разбивать на максимально МАЛЕНЬКИЕ функционально блоки. Соответственно, раз блок маленький, то и ненужно там будет делать более одного процесса. И вообще, более одного процесса в модуле желательно избегать, дабы не происходило каких-то бы ни было конфликтов драйверов сигналов.

тоже сомнительно. так можно и обратно к графическому вводу сползти - трудновато будет большие систем так проектировать

[Ender 0]

тоже сомнительно. так можно и обратно к графическому вводу сползти - трудновато будет большие систем так проектировать

 

Ну, я уж не спускаюсь в крайности - не до триггеров уж) Имею ввиду, что всегда был приверженцем модульного стиля программирования. Тут уж, как говорится, на вкус и цвет...

[CaPpuCcino 0]

Тут уж, как говорится, на вкус и цвет...

наверное так, мне вот наоборот сложнее читать код в котором куча инстансов и межсоединений (трудно понять), предпочитаю принцип функциональной локатьности

[Ender 0]

наверное так, мне вот наоборот сложнее читать код в котором куча инстансов и межсоединений (трудно понять), предпочитаю принцип функциональной локатьности

 

Насчет функциональной локальности - полностью согласен! Одна функция - один блок - рулит... Предпочитаю просто разбивать на функции поменьше - а результат соединений просматривать на RTL. Поэтому обычно не возникает проблем, что непонятно, что с чем соединено - на RTL заметно сразу.

 

Т.е., для примера... Тот же самый RAKE. Состоит из блоков 1-го уровня, условно - КИХ, блок улавливания корр. пиков; блок анализа результата. Далее - 2-й уровень: блок улавливания - из сдвигового регистра для отлова задержки, двух компараторов, блока анализа амплитуд. Третий уровень - каждый из этих блоков реализуется через эл. ячейки... Полностью иерархическая структура, на каждом уровне детализация позволяет прозрачно просмотреть всю структуру. RTL ведь почти Schematic, только PC рисует аккуратней)

Изменено 10 марта, 2008 пользователем Ender

[CaPpuCcino 0]

Т.е., для примера... Тот же самый RAKE.

кстати, насчёт source synchronous наверное нужно отметить что это характерно для внешних интерфейсов (?)

[Ender 0]

кстати, насчёт source synchronous наверное нужно отметить что это характерно для внешних интерфейсов (?)

 

Почему, совсем не обязательно. У самого Xilinx написано, цитирую (в переводе, естественно, и с авторскими примечаниями ;) ). System Synchronous применяется в большинстве случаев и представляет собой тактирование от единой ветки клока. Source Synchronous применяется в системах, в которых требуется обеспечить высокую тактовую частоту, при этом сигнал клока передается от одного элемента к последующему, но при этом, как вы им будете управлять и подавать - ваше дело) Т.е. они умывают руки, что естественно) Далее написано, что с Source Synchronous выполняются, например, DDR-модули.

 

Прирост в тактовой частоте порой просто огромен. Что называется, с 100 МГц до 650 по версии синтезатора) Утверждение не голословное, легко можете проверить сами.

[CaPpuCcino 0]

Почему, совсем не обязательно. У самого Xilinx написано, цитирую (в переводе, естественно, и с авторскими примечаниями ;) ). System Synchronous применяется в большинстве случаев и представляет собой тактирование от единой ветки клока. Source Synchronous применяется в системах, в которых требуется обеспечить высокую тактовую частоту, при этом сигнал клока передается от одного элемента к последующему, но при этом, как вы им будете управлять и подавать - ваше дело) Т.е. они умывают руки, что естественно) Далее написано, что с Source Synchronous выполняются, например, DDR-модули.

 

Прирост в тактовой частоте порой просто огромен. Что называется, с 100 МГц до 650 по версии синтезатора) Утверждение не голословное, легко можете проверить сами.

просто на мой взгляд для таких штуков внутри ФПГА клоковых доменов не хватит (тех же DCM). к тому же это хорошо в поточных архитектурах - иначе будут запарки с метастабильностью из-за увеличения кол-ва связей между блоками

[Artem_Petrik 0]

Изложенная мной схема - если и полный бред, то бред от XILINX!!! И называется данный БРЕД SOURCE_SYNCHRONOUS в его лексиконе. Почитайте подробнее User Guide.

К тому же этот, так называемый вами бред, позволяет добиться частоты в 370 МГц на Virtex-4 при реализации RAKE-приемника, например!

 

Согласен, насчет ПОЛНОГО бреда я погорячился, такая концепция имеет право на существование, однако в достаточно ограниченных применениях, и уж ни коим образом не является способом "гарантированно корректной синхронизации". Это прием, позволяющий скомпенсировать задержку распространения в некоторых случаях, однако это уже отклонение от концепции "полностью синхронной схемы". В синхронной схеме есть один клок, и только один! И это гарантирует отсутствие головняков. Если же у каждого блока своя тактовая, пусть и сделанная из главной при помощи задержек, то уже нужно держать ухо востро. Головняки возникают на пустом месте, уже скажем при необходимости завернуть один из сигналов с выхода второго блока назад на первый. Да описанный вами подход позволяет в некоторых случаях добиться увеличения скорости, но это уже далеко не чисто синхронный дизайн.

 

Извиняюсь за засорение темы, и уход от проблемы описанной автором топика, не выдержал :)