[Nagisa 0]

Странная проблема с автоматом состояний

 

localparam STATE_STM_WAIT	= 3'd0; 	// ждем =0 на STM_U_QBUS_IN_L
localparam STATE_STM_CLANK1= 3'd1; 	// антизвон
localparam STATE_STM_CLANK2= 3'd2; 	// антизвон
localparam STATE_STM_CLANK3= 3'd3; 	// антизвон
localparam STATE_STM_FLAG	= 3'd4;	// ждем установки флагов операции
localparam STATE_STM_DATA	= 3'd5;	// запоминаем данные для команды
localparam STATE_STM_OPER	= 3'd6;	// выполняем операцию
localparam STATE_STM_END	= 3'd7;	// ждем завершения - снятия синка 

reg [2:0] state_stm;
reg [2:0] next_state_stm;	

always @ (posedge CLK)
begin
	state_stm<=next_state_stm;
end

always @ *
begin
	case (state_stm)
		STATE_STM_WAIT:
			if(STM_U_QBUS_IN_L==0)
				next_state_stm=STATE_STM_CLANK1;
			else
				next_state_stm=STATE_STM_WAIT;
				
		STATE_STM_CLANK1:
				next_state_stm=STATE_STM_CLANK2;
			
		STATE_STM_CLANK2:
				next_state_stm=STATE_STM_CLANK3;
				
		STATE_STM_CLANK3:
				next_state_stm=STATE_STM_FLAG;
								
		STATE_STM_FLAG:
			if( stm_sync==1)// есть команда
				next_state_stm=STATE_STM_DATA;
			else if (STM_U_QBUS_IN_L==1)
				next_state_stm=STATE_STM_WAIT;			
			else
				next_state_stm=STATE_STM_FLAG;
				
		STATE_STM_DATA:
						next_state_stm=STATE_STM_OPER;
						
		STATE_STM_OPER:
				next_state_stm=STATE_STM_END;
				
		STATE_STM_END:
			if( stm_sync==0 || STM_U_QBUS_IN_L==1)
				next_state_stm=STATE_STM_WAIT;	
			else
				next_state_stm=STATE_STM_END;
			
		default:
				next_state_stm=STATE_STM_WAIT;
	endcase
end

соответственно на определенные состояния привязаны действия

вообщем обычный автомат который понимает квартус (которых в проекте куча и все работают нормально)

но засада в том, что он висит на STATE_STM_WAIT и игнорирует STM_U_QBUS_IN_L который регулярно падает в 0 (смотрю сигналтапом)

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

проблема гарантированно лечится выводом на любой пин любой части регистра state_stm, что явно переключает оптимизатор автомата

 

вопрос первый - в чем причина ? что не нравится оптимизатору, что он делает нерабочий автомат ?

и второй - как лечить ? те может какой-то хинт есть дабы объяснить оптимизатору оставить state_stm регистром ?

 

 

 

 

 

 

 

 

 

[des00 25]

Ну читая ваш код: асинхронные управляющие сигналы, 99%

[Nagisa 0]

53 minutes ago, des00 said:

Ну читая ваш код: асинхронные управляющие сигналы, 99%

так для того и автомат, дабы синхронизировать

 

вылечил так

reg [2:0] state_stm            /* synthesis syn_encoding="safe,gray" */;
reg [2:0] next_state_stm    /* synthesis syn_encoding="safe,gray" */;    

 

[Nagisa 0]

причина получается в том, что оптимизатор кодирует автомат в onehot  и как следствие у него есть недопустимые состояния, а они, очевидно из работы с асинхронными процессами, могут быть

соответственно необходимым и достаточным является указание кодирования без недопустимых состояний или их блокировка - те хинт safe

 

[iosifk 3]

10 минут назад, Nagisa сказал:

причина получается в том, что оптимизатор кодирует автомат в onehot  и как следствие у него есть недопустимые состояния, а они, очевидно из работы с асинхронными процессами, могут быть

соответственно необходимым и достаточным является указание кодирования без недопустимых состояний или их блокировка - те хинт safe

 

На самом деле причины и следствия абсолютно перепутаны. надо не выкручивать всё мозги автомату а совершенно стандартным образом провести привязку всех входных асинхронных сигналов к синхрочастоте на которой работает автомат. для этого смотрите описания Clock domain crossing

[Nagisa 0]

2 minutes ago, iosifk said:

На самом деле причины и следствия абсолютно перепутаны. надо не выкручивать всё мозги автомату а совершенно стандартным образом провести привязку всех входных асинхронных сигналов к синхрочастоте на которой работает автомат. для этого смотрите описания Clock domain crossing

это я в курсе, тут задача в том, что надо сразу отреагировать на изменение (1 такт)

а полноценный CDC даст отставание на  2 такта

 

[iosifk 3]

23 минуты назад, Nagisa сказал:

это я в курсе, тут задача в том, что надо сразу отреагировать на изменение (1 такт)

а полноценный CDC даст отставание на  2 такта

 

То есть, вы хотите сказать, что внешние приходящие в плис асинхронные сигналы изменяются с такой же скоростью, как и внутренния тактовая частота в 200 - 500 МГц? И как они передаются по плате? 

[Nagisa 0]

43 minutes ago, iosifk said:

То есть, вы хотите сказать, что внешние приходящие в плис асинхронные сигналы изменяются с такой же скоростью, как и внутренния тактовая частота в 200 - 500 МГц? И как они передаются по плате? 

источник STM32F407, тестирование показало, что он меняет состояние на порту за 1 такт внутренней частоты 162MHz (понятное дело, что есть оговорки)

конечно, в идеале надо было использовать SPI и не парится с костылями, но что есть то есть.

да, добавка safe полностью решила проблему, и сейчас тест оперативки идет даже на 162MHz (при заявленных 133). 

 

[xvr 12]

On 6/5/2021 at 12:13 PM, Nagisa said:

да, добавка safe полностью решила проблему,

Т.е. вместо нормального CDC для внешних сигналов вы добавили safe в автомат? Это не решение проблемы, а 'заметание её по ковёр'. Автомат не будет виснуть в запрещённых состояниях, но возможны самые непредсказуемые переходы между разрешёнными состояниями.

 

[des00 25]

16 hours ago, xvr said:

Т.е. вместо нормального CDC для внешних сигналов вы добавили safe в автомат? Это не решение проблемы, а 'заметание её по ковёр'. Автомат не будет виснуть в запрещённых состояниях, но возможны самые непредсказуемые переходы между разрешёнными состояниями.

 

сам автомат у него и есть CDC, если он чисто муровский и самосинхронный, то проблем для системы не будет, почти. регистры современных плис довольно быстро выходят из метастабильного состояния. странно тут другое, зачем вообще такой пост создавать если ТС и без форума все знал) Ну если только поговорить)

[xvr 12]

4 hours ago, des00 said:

сам автомат у него и есть CDC, если он чисто муровский и самосинхронный, то проблем для системы не будет,

А из за метастабильности в регистрах, хранящих состояние, не может произойти переход в неправильное состояние? Например должны переключиться 2 регистра и оба они перейдут в метастабильное состояние, из которого могут выйти в разные состояния (один переключится, а второй вернётся в оригинальное состояние).

 

Автомат из этого состояния выйдет, но переход явно будет неправильный

[RobFPGA 27]

Приветствую!

1 hour ago, xvr said:

А из за метастабильности в регистрах, хранящих состояние, не может произойти переход в неправильное состояние? Например должны переключиться 2 регистра и оба они перейдут в метастабильное состояние, из которого могут выйти в разные состояния (один переключится, а второй вернётся в оригинальное состояние).

Автомат из этого состояния выйдет, но переход явно будет неправильный

Не только могут, но будут. Поэтому и есть требование  синхронизации входных цепей  ДО использования в логике.  Так как реализация такой логики от входного сигнала в FPGA обычно имеет множество  путей  с разными задержками. 

Поэтому  TC  с такой реализацией "CDC" на FSM  играет в русскую рулетку (да еще и с автоматом а не револьвером  )    

Удачи!  Rob.

[des00 25]

1 hour ago, xvr said:

А из за метастабильности в регистрах, хранящих состояние, не может произойти переход в неправильное состояние? Например должны переключиться 2 регистра и оба они перейдут в метастабильное состояние, из которого могут выйти в разные состояния (один переключится, а второй вернётся в оригинальное состояние).

 

Автомат из этого состояния выйдет, но переход явно будет неправильный

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

[RobFPGA 27]

Приветствую!

1 minute ago, des00 said:

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

То есть переход такого автомата  по корректному входному воздействию в  некорректное состояние  это не ошибка?  

 

Удачи! Rob.

[des00 25]

1 minute ago, RobFPGA said:

То есть переход такого автомата  по корректному входному воздействию в  некорректное состояние  это не ошибка? 

это ошибка, но это ошибка этого автомата, не приводящего к ошибке в системе, при корректном проектировании. По сути тот же CDC, ошибка же в нем тоже появляется и это его нормальная работа, а вот за CDC она уже не выходит.