Введение (можно не читать ):

к ПЛИС подключено статическое асинхронное ОЗУ 32 кБ (имена выводов начинаются с MEM_)
имеется два счётчика адреса addr1 и addr2. По первому адресу при наступлении некоторых условий нужно читать данные из ОЗУ (после чего адрес инкрементировать), при наступлении другого условия нужно записывать
данные в ОЗУ по второму адресу.
сигнал write_MEM управляет тристабильным буфером и когда он равен '1' MEM_D настроена на запись (т.е. вывод данных из ПЛИС)


Суть вопроса (желательно ознакомиться перед ответом):

После компиляции в Quartus получаю, что MEM_A, MEM_CS, MEM_RD, MEM_WR
являются выходами защёлок и, соотвественно, предупреждение об этом от design Assistant: "Design should not contain combinational loops". Как побороть эту неприятность (на форуме неоднократно слышал высказывания, что люди умудряются делать проекты вообще без защёлок).

Собственно, кусок кода с пояснениями:

Схему описываю как автомат, изменение состояний которого происходит по положительному фронту синхросигнала CLK.
Ниже приводится часть кода процесса, формирующего значение выходов автомата, в зависимости от его текущего состояния.
if (CLR = '1') then
MEM_CS <= '1';
MEM_RD <= '1';
MEM_WR <= '1';
inc_addr1 <= '0';
write_MEM <= '1';
else
case CurState is
when sStartReadMem =>
write_MEM <= '0';
MEM_A(14 downto 0) <= addr1 (14 downto 0);
MEM_CS <= '0';
MEM_RD <= '0';
when sEndReadMem =>
MEM_CS <= '1';
MEM_RD <= '1';
data(7 downto 0) <= MEM_D(7 downto 0);
inc_addr1 <= '1';
when sSaveData =>
write_MEM <= '0';
inc_addr1 <= '0';
-------

when sStartWriteMem =>
MEM_A(14 downto 0) <= addr2(14 downto 0);
MEM_CS <= '0';
MEM_WR <= '0';
when sEndWriteMem =>
MEM_CS <= '1';
MEM_WR <= '1';

Сопутствующий вопрос:
Как наиболее глюкобезопасно сделать инкрементацию addr1 после чтения? Сейчас для этого (см. выше) я изменяю состояние сигнала inc_addr1, который подан на вход разрешения счёта счётчика, реализованного на базе lpm_counter. Синхросигналом для счётчика является инвертированная частота CLK. Т.е. всё построено на том, что изменение состояния автомата (а значит и inc_addr1) происходит по положительному фронту CLK, а инкремент счётчика addr1 по отрицательному.
Существуют опасения, что при некоторых вариантах разводки кристалла установление значения inc_addr1 может произойти позднее, чем через пол-такта CLK=60MГц, и соотвественно инкремент не произойдёт.

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

Спасибо

По поводу защелок.

В Xilinx XST User Guide есть такой пример:

FSM with 2 Processes

To eliminate a register from the "outputs", you can remove all assignments “outp <=…” from the Clock synchronization section.
This can be done by introducing two processes as shown in the following figure.

Following is VHDL code for an FSM with two processes.

library IEEE;
use IEEE.std_logic_1164.all;
entity fsm is
port (
clk, reset, x1 : IN std_logic;
outp : OUT std_logic
);
end entity;
architecture beh1 of fsm is
type state_type is (s1,s2,s3,s4);
signal state: state_type;
begin
process1: process (clk, reset)
begin
if (reset =’1’) then
state <=s1;
elsif (clk=’1’ and clk’Event) then
case state is
when s1 =>
if x1=’1’ then
state <= s2;
else
state <= s3;
end if;
when s2 => state <= s4;
when s3 => state <= s4;
when s4 => state <= s1;
end case;
end if;
end process process1;

process2 : process (state)
begin
case state is
when s1 => outp <= ’1’;
when s2 => outp <= ’1’;
when s3 => outp <= ’0’;
when s4 => outp <= ’0’;
end case;
end process process2;
end beh1;

http://www.xilinx.com/support/sw_manuals/xilinx6/download/

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

По всей видимости имеет место недопределенная логика, определите ее до конца и не будет латчей.

Если нужна фиксация сигналов, то используйте Dff:

if (clk'event and clk='1') then
... user logic area...
end if;

не совсем понятно, что такое "неопределённая логика"

вообще говоря, что получится, если написать

if (clk'event and clk='1') then
... user logic area...
end if;

я примерно представляю. Интересует как это применить к конкретному примеру (см.выше). В чём в данном случае должно заключаться это "доопределение логики"? (Пример-то вроде простой.)

Насколько я понял , "доопределить логику ", значит просто сразу после
else все остальное закрыть в
if(clk'event and clk='1' )
.....
end if
Вот это самое clk'event и заставляет выполнять все дальнейшие операции по
фронту, а не по уровню. Кстати об этом хорошо пишет Cummings, он же кстати настоятельно рекомендует избавляться от лэтчей везде, где только можно.

if(clk'event and clk='1' )
.......
case CurState is
when sStartReadMem =>
write_MEM <= '0';
MEM_A(14 downto 0) <= addr1 (14 downto 0);
MEM_CS <= '0';
when .....
--самое главное при case не забыть добавить
when others => и то что нужно сделать по умолчанию
без этого others схема может встать в ступор

end case ;
end if;
Мне кажется так.

Определить логику до конца - описать вае возможные ее комбинации.
Один из выходов - поставить нечто вроде "MEM_CS<='0'" или "MEM_A(14 downto 0)<=(others=>'-')", для всех сикналов срвзу после "process (..)\n\tbegin\n\t\t", и это будут значения принимаемые логикой, если она не описана. Желательно в каждом case->when описывать все сигналы и переменные используемые в process'е(это расширение указанного выше). настоятельно рекомендую устранить все латчи(приведенная конструкция с клоком просто заменит латчи на синхронные триггеры), т.к. рано или поздно они вас укусят.
В вашем примере достадочно будет сделать асинхронные выходы автомата, и не плодить регистры, для этого можно исролизовать -
MEM_CS<= '1' when state=sEndReadMem else '0';. естественно вне процесса, это пожалуй будет самый простой для вас вариант.

ХМм глупый вопрос, почему этот выход будет асинхронным ? если кодирование one hot и состояния храняться на регистрах, то класический Мур с синхронным по клоку выходом.
Конечно это нужно учесть при таймингах блока.

Для начала, как образуются защелки: допустим, мы хотим сформировать некоторый сигнал B, состояние которого изменяется в зависимости от сигнала A следующим образом, к примеру, пусть когда A высокий, то инвертируем B. Это описывается так:

Дальше все просто: мы не указываем, какое значение присвоить B, если A не равен '1', то есть если A не равен '1', то состояние сигнала B изменять не требуется, и требуется сохранение его ( текущего состояния, это и образует защелку.
В вашем случае, при формировании выходных сигналов автомата состояний, чтобы избежать образования защелок, требуется назначать значение каждого выходного сигнала в каждой ветви условий, либо, как обычно делают, чтобы не забыть, при входе в процесс назначают каждому сигналу значение по умолчанию. Попробую продемонстрировать:

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

Второй, широко используемый вариант. Его и рекомендую.

Относительно инкремента счетчика адреса: по тому фронту, по которому защелкиваете прочитанные из памяти данные, по нему же и инкрементируете адрес. Здесь ничего выдумывать не надо.

Удачи!

P.S. Не особо заморачивался, возможны опечатки

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

in __|``|______________
out_1 ______|``|___________
out_2 __________|``|_______
out_3 ______________|``|___

например по out_1 меняешь состояние автомата, по out_2 - инкрементируешь счетчик. Работает железно - проверенно.

Не думаю, что подобная идея подойдет для данной конкретной задачи, ибо, как минимум, растянется цикл доступа к памяти. Что, если мы не имеем возможности разнести операции по последовательным тактам? Что, если этих операций 100? Чем повышается надежность работы схемы при таком подходе? Модуль, который после прихода управляющего сигнала выдает последовательные импульсы, это тот же автомат состояний. Идея понятна, но на мой взгляд, никакой надежности не добавит.

P.S. Господа, при проектировании автоматов "не опускайтесь" до уровня импульсов, думайте "выше", на уровне действий, операций. Про управляющие сигналы, конечно, не забывайте.

Как раз в данной конкретной задаче не 100 операций а две - изменение состояния и инкремент адреса. Бало бы 100, никто не предлагал бы вариант с последовательными импульсами...
А надежность будет выше, тк не надо будет думать - успеет ли счетчик посчитать, потому что со слов автора: "Т.е. всё построено на том, что изменение состояния автомата (а значит и inc_addr1) происходит по положительному фронту CLK, а инкремент счётчика addr1 по отрицательному." А так все будет разнесено по отдельным тактам. Что может быть надежней? Если схема позволяет по времени растянуть операцию на два такта - то это будет хороший вариант.