Я наверно криво сформулировал название, но придумать точнее не могу.
Вопрос по реализации на верилоге, возможно вопрос какой-то глупый, но я в этом направлении начинающий
Есть плис, к ней подключен мост FT600 . Речь идет о передачи данных из плис в мост, чтоб прочитать на компе. Так вот в плис данные лежат в фифо и по готовности FT600 их надо ему закачать. Интерфейс у Ft600 напоминает синхронное фифо, поэтому я и написал что нужно перегнать данные с фифо в фифо.
Я привожу две катинки, чтобы описать временную диаграму Ft600:

CLK - клог генерируемый Ft600
TXE - сигнал готовности Ft600 к приему (выход Ft600)
WR - сигнал валидности данных (вход Ft600)
Остальные сигналы не очень важны.
Цветом я обозначил перепады в конце, на которые буду ссылаться.
В примере на картинке данные я в плис должен выставить по зеленому спаду. По красному фронту Ft600 из залэтчит. Затем поймет что более не хочет/ не может принять и на следующем желтом спаде уберет сигнал готовности приема. На следующем синем фронте он уже проигнорирует то, что стоит на шине. Хотя я зачем-то согласно времянке должен еще один такт держать WR активным.
Теперь о той части, что в плис, но без картинок. В плис фифо, у фифо на входе клок, сигнал разрешения чтения и данные. Читается по фронту (сигнал разрешения чтения я должен выставить по спаду за пол клока до этого).
Вот наконец мы подошли к вопросу номер один.
Как я должен это все организовать? У меня два варианта:
1. Я согласно времянке должен выставить данные на шину Ft600 по спаду, чтоб по фронту он прочитал. Я могу инвертировать клок у себя и подать его на мой фифо, тогда данные будут читаться как бы по спаду входного клока.
2. Никакой клок не инвертировать. Читать из фифо по фронту. Тогда например, по тому фронту, что перед зеленым я данные прочитаю из фифо, выставлю на шину, но Ft600 уже по этому фронту не успеет эти данные увидеть и залэтчит их на следующем фронте. Таким образом он их лэтчить будет как бы с задержкой на клок. И это у меня даже работает.
Как обычно делают??? Я так понимаю первый вариант он более правильный что ли, но при этом сразу же вдвое снижается максимальная частота работы. Так как на все задержки остается пол клока. А во втором случае целый клок.
Я надеюсь хоть что-то понятно в вопросе.
Будет еще вопрос номер два, но лучше после первого.
Спасибо.

Сделать можно и так и так. ИМХО, второй вариант более правильный, т.к. , да, максимальная частота работы для плис в этом случае должна быть выше.
То, что на картинке данные от FIFO master переключаются по спаду, скорее всего нарисовано для наглядности. Главное, чтобы Tsu/Th FT600 удовлетворялись.

На самом деле, вопрос не в клоках и не в проводах. Вопрос в том, как надо проектировать, чтобы дело из художественных промыслов превратилось в формальность.
Давайте я Вам расскажу методику разработки проектов. По скайпу....

Хорошо, спасибо.
Тогда главный вопрос, ради которого и описывал все это.
Вот рассмотрим финальную стадию передачи. Предположим, что во время передачи FT600 решил остановить процесс и поднять TXE - имеет право в любой момент. На картинке у меня это происходит на желтом спаде. Проблемя в том, что к этому моменту я уже вычитал данные из моего фифо на красном фронте, в надежде передать их на синем фронте. Но надеждам не суждено сбыться, на синем фронте ФТ600 уже ничего лэтчить не будет. Как быть? Я же не могу назад запихать данные в фифо. Это уже вопрос именно постоения схемы, как фпгашники поступают в таком случае? Получается заранее фт600 не предупреждает о своей беспомощности в приеме данных.
У меня сейчас имплементация именно от этого и страдает, при окончании, а точнее временном перерыве передачи данных теряется одно слово, которое из фифо вычитывается, но не передается в ФТ600.
Спасибо.


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

Данные прочитанные из плис на красном фронте (назовем их D6) должны остаться на шине данных и ждать, пока FT600 не опустит опять TXE_N. При этом надо перестать читать данные дальше из плис. Например, это можно сделать асинхронно:

assign rd_fifo = ! TXE_N; // это без учёта логики которая у вас может управлять rd_fifo в начале передачи;

Тогда на синем фронте данные считываться дальше уже не будут.

А WR_N нужно задать синхронно:

always @(posedge CLK) // без учёта асинхронного ресета и т.д.
....
WR_N <= TXE_N; // это без учёта логики которая у вас может управлять WR_N в начале передачи;

Во, отлично! Это так же как думал я. Оставить данные на шине до следующего раза. После следующего спада TXE тогда нужно подождать один клок, прежде чем вычитывать данные с локального фифо, так как они вычитаны были в прошлый раз.
Но! Два вопроса.
1. Что делать в самый первый раз? В самом начале после ресета. Получается, что по вышеописанной логике, после спада TXE я должен расчитывать, что у меня на шине фифо данные уже есть с прошлого раза и я должен начать с передачи именно их. Но в самый первый раз их же нету. Мне нужно городить логику, которая позволить отличить самый первый раз от не первого?
2. Меньшая проблема, но все же. Я расчитываю на использование флага empty от моего локального фифо, чтобы узнать есть непереданные или нету. В этом случае если представить, что я не успел передать только оно слово, то флаг empty стоять уже будет, хотя по факту еще одно слово не передано.
Спасибо за ответы.

Да, надо по крайней мере знать, есть ли у вас на шине валидные данные от плис, которые не считал FT600, и если таких данных нет, то надо учитывать задержку на их чтение из плис.



Это конечно сильно зависит от конкретной реализации фифо (какой чип, есть ли доп. выходные регистры, и т.д.), т.е. если вы точно знаете, что empty поднимается, когда вы читаете последнее слово из фифо, и при этом FT600 поднимает TXE_N, то это значит только, что вам надо будет держать это считанное последнее слово на шине данных пока TXE_N не опустится (см. п. 1 выше). Ну и пока empty активно, то из фифо плис не читать.

Спасибо. Ясно.
Да фифо поднимает флаг именно в момент последнего чтения данных тоже по фронту. Фифо не самопальное, а из латиссовского IP. Доп. регистр на выходе опционально имеется, хотя его смысл мне не очень ясен, ну или преимущество его наличия в моем случае.
Мои надежды, что я чего-то не понимаю не оправдались Придется городить огород с валидностью, читай непрочитанностью, данных на выходе моего локального фифо. И все только потому, что ФТ600 неудосуживается чуть заранее проинформировать меня об окончании транзакции...

Посмотрите пожалуйста вложение

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