[Shivers 0]

Человек про асинхронный RS-латч спрашивал, понятно что чисто в общеобразовательных целях. Второй пост наиболее точно будет моделироваться, но необходимо добавить еще режим защиты от запрещенного набора входных сигналов {00} или {11} - в зависмости от типа латча, при котором возможен режим генерации. При подаче запрещенного набора на вход латча лучше всего выходы переводить в Х, чтобы разработчик видел свою ошибку.

 

А ПЛИС здесь вообще не при чем, асинхронных латчей сейчас ни в ПЛИС, ни в эсик не сделать. Разве только извратиться с использвоанием флопов с асинхронными Set и Reset, да где их найдешь?

[nepoch 0]

В большинстве случаев latch - нежелательный результат, поэтому важно знать как его описать. Это позволит не использовать конструкции, приводящие к имплементации латчей. Возможно в некоторых архитектурах и задачах они используются как равноправный элемент дизайна. В обычных ПЛИС их лучше исключить. Если же нужен "логический эквивалент", то ИМХО лучше так сделать (например):

logic a, b, c, y;

assign y = a && b;
always@(posedge clock)
     c <= y;
end

assign q = y || c;

И в итоге, тот же триггер

[serjj1333 0]

И в итоге, тот же триггер

Если в ПЛИС есть только LUT и триггеры, то конечно всё будет реализовано на них. Есть разница в использовании. Сравните

always@(posedge clock) begin
    if (a && b)
          q <= 1'b1;
end

и

always@(*) begin
    if (a && b)
          q = 1'b1;
end

Для реализации этих конструкций синтезатор будет применять одни и теже ресурсы, но функционально это разные схемы (первая - триггер, вторая - латч). Также у них будет разная разводка и разные тайминги. Синтезатор не сможет сделать латч аппаратно, как Shivers сказал, но он попробует его реализовать на тех ресурсах, которые у него есть. Но такая реализация может привести к плохим таймингам.

 

А тот код, который я привёл ранее, реализует защёлку явно на логике и триггерах. Т.о. мы явно говорим синтезатору, что делать.

Edited July 22, 2015 by serjj