[makc 207]

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

 

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

 

Мне в голову пришла идея, что можно реализовать схему сброса DCM, которая будет тактироваться от внешнего тактового сигнала и будет производить сброс DCM в самом начале (после конфигурации) и при пропадании сигнала LOCKED. При этом для того, чтобы избежать неизвестного состояния выходных тактовых сигналов DCM можно с помощью LOCKED управлять буферами BUFGMUX (например BUFGCE). Это теоретически должно позволить остановить на требуемое время ту часть схемы, которая тактируется от DCM.

 

Но при этом возникает один маленький вопрос - для DCM нужен сигнал обратной связи. Брать его с выхода BUFGCE нельзя, т.к. этот сигнал нужен еще до того, как будет LOCKED, но в то же время нужно его брать с выхода BUFGCE, т.е. именно для этого сигнала нужно устранить clock skew.

 

В общем я в сомнениях... Может кто сталкивался с подобной проблемой? Какие варианты?

[Gorby 6]

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

 

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

 

Мне в голову пришла идея, что можно реализовать схему сброса DCM, которая будет тактироваться от внешнего тактового сигнала и будет производить сброс DCM в самом начале (после конфигурации) и при пропадании сигнала LOCKED. При этом для того, чтобы избежать неизвестного состояния выходных тактовых сигналов DCM можно с помощью LOCKED управлять буферами BUFGMUX (например BUFGCE). Это теоретически должно позволить остановить на требуемое время ту часть схемы, которая тактируется от DCM.

 

Но при этом возникает один маленький вопрос - для DCM нужен сигнал обратной связи. Брать его с выхода BUFGCE нельзя, т.к. этот сигнал нужен еще до того, как будет LOCKED, но в то же время нужно его брать с выхода BUFGCE, т.е. именно для этого сигнала нужно устранить clock skew.

 

В общем я в сомнениях... Может кто сталкивался с подобной проблемой? Какие варианты?

 

Вообще говоря, потеря LOCKED - это аварийная ситуация. При этом на выходе есть клок с непредсказуемыми параметрами (как правило, наезжает фаза, что меняет скважность от нуля до максимума). При этом говорить о каких-то определенных состояниях ваших драгоценных регистров не приходится - туда МОГ записаться мусор.

 

Хорошо, вы занулили выходной клок, обнаружив не-LOCKED. Как вы гарантируете, что в момент выключения не нарушился какой-либо setup-hold и это не были именно ТЕ регистры?

 

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

 

Я бы предложил ТЕ регистры сделать без ресета. А саму схему управления ими - как обычно, с ресетом от DCM. Так мы гарантируем сохранение регистров при состоянии Ресет, а наличие ресета для всей схемы от DCM гарантирует отсутствие неопределенного ее поведения в случае потери LOCKED.

[makc 207]

Вообще говоря, потеря LOCKED - это аварийная ситуация. При этом на выходе есть клок с непредсказуемыми параметрами (как правило, наезжает фаза, что меняет скважность от нуля до максимума). При этом говорить о каких-то определенных состояниях ваших драгоценных регистров не приходится - туда МОГ записаться мусор.

 

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

 

В регистры действительно МОГ записаться мусор, но вероятность этого не так уж просто посчитать. И если она не равна 1, то есть не нулевая вероятность успешного выхода из аварийной ситуации.

 

Хорошо, вы занулили выходной клок, обнаружив не-LOCKED. Как вы гарантируете, что в момент выключения не нарушился какой-либо setup-hold и это не были именно ТЕ регистры?

 

Опять же согласен, есть и такая проблема. Но у меня есть маленькая надежда, что LOCKED пропадет раньше, чем нарушатся параметры выходного клока, т.к. его удастся успешно отключить на некоторое время.

 

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

 

Пока что задача прямо противоположная - защититься от редко возникающих и труднообнаруживаемых глюков по причине пропадания LOCKED. :)

 

Я бы предложил ТЕ регистры сделать без ресета. А саму схему управления ими - как обычно, с ресетом от DCM. Так мы гарантируем сохранение регистров при состоянии Ресет, а наличие ресета для всей схемы от DCM гарантирует отсутствие неопределенного ее поведения в случае потери LOCKED.

 

Я это все понимаю, но подобные решения сложны в применении и не всегда допустим ресет для схемы управления, который может придти в процессе работы. Остановить можно, сбрасывать - крайне не желательно.

 

В общем пока получается, что нужно уповать на надежность работы DCM и крайне малую вероятность возникновения проблем. :unsure:

[Victor 0]

Задача была немного другая, но суть не меняется: почему бы вам не взять 2 BUFGMUXа на один выход DCMа? Один - feedback, второй рабочий.

[makc 207]

Задача была немного другая, но суть не меняется: почему бы вам не взять 2 BUFGMUXа на один выход DCMа? Один - feedback, второй рабочий.

 

Да я собственно пока так и сделал. Единственно что меня смущает, так это различие в характеристиках глобальных цепей, идущих от разных BUFG. Хотя, думаю, это различие не так страшно и сказываться на работе не должно.

[Gorby 6]

А вообще, врачи сами себя не лечат.

 

Это к тому, что над FPGA c DCMом, которое может сбойнуть, нужна надстройка.

Вочдог, или другая какая маленькая аппаратная приблуда.

И неплохо бы иметь внешний механизм фиксации события сбоя DCM.

А там при необходимиости можно и битовый поток перезалить....

 

И если у вас нет паранойи, это вовсе не значит, что ОНИ за вами не следят

[makc 207]

А вообще, врачи сами себя не лечат.

 

Слышал, что были случаи самостоятельного удаления аппендикса. :)

Но это, конечно, не повод для повторения опыта.

 

Это к тому, что над FPGA c DCMом, которое может сбойнуть, нужна надстройка.

Вочдог, или другая какая маленькая аппаратная приблуда.

И неплохо бы иметь внешний механизм фиксации события сбоя DCM.

А там при необходимиости можно и битовый поток перезалить....

 

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

 

И если у вас нет паранойи, это вовсе не значит, что ОНИ за вами не следят

 

[leevv 0]

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

 

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

 

Ja obychno delaju interface block otdel'no i pitaju ego kakim nibud' drugim stabil'nym clockom ili voobshe async signalami ot processora. Togda system clk mogno resetit' skol'ko ugodno i prietom sodergimoe registrov ostanetsja neizmennym. Krome togo sushestvuet reshenie kogda registrovyj massive realizuetsja na SRL (xilinx, smotri naprimer GSRD ref design). Togda po svoej suti reset ne smoget sbrosit' sodergimoe.

Ny eto esli eshe ne pozdno menjat' design.

 

Po povodu DCM ja v svoe vrema silno naelsja s nimi osobenno s VirtexE, u kotoryh sboj moget proizojty, no pri etom Lock stoit kak geroj. Chashe dage ne sboj, a ne pravilnyj setup (posle configuracii i nachal'nogo reset-a ). Prishlos' ispolzovat' druguju, kosvennuju informaciju v dopolnenii s LOCK o tom chto DCM pora resetit'.

V Virtex2 DCM chutochku podpravili. No vse ravno plohaja situacija moget proizojty.

 

V moem sluchae pomog imenno timeout (watchdog), kotoryj legko sdelat' s pomoshju pseudo schetchika.

Recomenduju. Ochen' kompactno poluchaetsja. Vyhod shetchika - pulse raz v skolko-to ms. Ego potom nugno ob'edinit' po AND s nLOCK signalom.

 

 

 

 

---------------------------------------------------------------------------

-- 22 bit LFSR counter. With XNOR feedback the lock-up state is "all-ones".

-- TC is based on a zero_cnt, which cnts consecutive zeros.

-- When it comes to zero, that means we have "all-zeros" state, which is the TC state.

PROCESS (clk10)

variable v: std_logic_vector(21 downto 0):=(others=> '0');

variable d: std_logic;

constant cLFSR_LENGTH :std_logic_vector(4 downto 0) := conv_std_logic_vector(21,5);

variable zero_cnt: std_logic_vector(4 downto 0):=cLFSR_LENGTH;

BEGIN

if rising_edge(clk10) then

if zero_cnt=conv_std_logic_vector(0,5) then -- check for TC pulse

iRstCntPulse <= '1'; -- set terminal count pulse for 1 clk

iRst_toggle <= not iRst_toggle;

else

iRstCntPulse <= '0';

end if;

---------

if v(v'high)='1' then -- count zeros

zero_cnt := cLFSR_LENGTH;

else

zero_cnt := zero_cnt - 1;

end if;

------------

d:= v(v'high) xnor v(v'high-1); -- feedback

v:= v(v'high -1 downto 0) & d; -- shift reg

end if;

end process ;