Jump to content

    

Recommended Posts

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

 


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 регистром ?

 

 

 

 

 

 

 

 

 

Share this post


Link to post
Share on other sites
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" */;    

 

Share this post


Link to post
Share on other sites

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

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

 

Share this post


Link to post
Share on other sites
10 минут назад, Nagisa сказал:

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

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

 

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

Share this post


Link to post
Share on other sites
2 minutes ago, iosifk said:

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

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

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

 

Share this post


Link to post
Share on other sites
23 минуты назад, Nagisa сказал:

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

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

 

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

Share this post


Link to post
Share on other sites
43 minutes ago, iosifk said:

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

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

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

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

 

Share this post


Link to post
Share on other sites
On 6/5/2021 at 12:13 PM, Nagisa said:

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

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

 

Share this post


Link to post
Share on other sites
16 hours ago, xvr said:

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

 

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

Share this post


Link to post
Share on other sites
4 hours ago, des00 said:

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

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

 

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

Share this post


Link to post
Share on other sites

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

1 hour ago, xvr said:

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

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

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

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

Удачи!  Rob.

Share this post


Link to post
Share on other sites
1 hour ago, xvr said:

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

 

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

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

Share this post


Link to post
Share on other sites

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

1 minute ago, des00 said:

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

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

 

Удачи! Rob.

Share this post


Link to post
Share on other sites
1 minute ago, RobFPGA said:

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

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.