Здравствуйте.

Делал тут я недавно периферийку - и решил её запхнуть в NIOSII систему.
Чтобы не муксить клоки, решил чтение синхронизовать с входным клоком для периферии.И потом выдавать флаг.
Значится про WaitRequest нашёл такое:


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


Как видно из рисунка, WaitRequest взводится как раз до начала rising_edge(основной клок - 25МГц).
Но в результате тестов в железе - имеем чтение только 1-го символа с фифо - остальные - идентичны(что 10 что 20 символов)
Вчера клок даже до 10 МГц опускал - всё равно все символы одинаковые (чтение остальных регистров, что без WaitRequest - нормально)...
Файлы прицепил.
 data00.rar ( 7.63 килобайт ) Кол-во скачиваний: 97

Есть у кого идеи отчего так может быть ?


Если кто-то раньше дизайнил периферию с WaitRequest - можете прицепить экзампл - чтоб я посмотрел как оно точно работает.
Спасибо.

чисто от безделия и от интереса к фразе Чтобы не муксить клоки глунял и при..фигел
у вас два клок домена и от одного к другому готовность вы передаёте так вот просто и не затейливо
Avalon_waitrequest <= read_from_data_reg and (not data_now_prepared);
data_now_prepared - это как раз от вашего компонента....
мне вот не кажется что вам срочно нужно почитать про всякую там метасбильность и там синхронность ну и прочую фигню

ну а я бы использовал двух портовое двух клочное озу для таких целей как у вас
Удачи!

2 Postoroniy_V - спрашивал уже... глухо..

А на счёт простого перехода - тут вы правы - без перехода в avalon_clock клоковый домен, но есть примерчик, тоесть вырезка из рабочего прожекта. Там приблизительно такое :


Тут в принципе на одном клоковом домене, но всё же если посмотреть на временную диаграммку всё равно получается что waitrequest поднимается и опускается относительно клока не совсем я бы сказал синхронно..

А вот где кстати про эти ужасы метасбильности, синхронности ну и самое главное прочую фигню где можно прочитать?

загляните в faq

waitreqeust может быть выставлен когда угодно, но он должен быть стабилен до следующего переднего фронта тактовой на авалон шине а не вашей input_clk

глянул ещё раз в код и не понял

Data_prepared <= delay_chain(3);
....
elsif (falling_edge(Input_clk)) then
delay_chain <= delay_chain(2 downto 0) & Read_request;

то есть работает всё верное! как вы и написали! по идее waitreqeust может остаться навечно в 1

Кузмич, извините но, что-то я устал....почему вы не читаете доки или читаете по диагонали?

http://www.sunburst-design.com/papers/
Правда по английски и с примерами на Verilog, но вообще очень не плохо в частности
"Synthesis and Scripting Techniques for Designing Multi-Asynchronous Clock Designs"

2 Asb - спасибо, почитаемс..

2 Postoroniy_V -
спецификации авалона читал, оттуда собно и узнал проWaitRequest и что он должен быть установлен до следующего rising_edge авалоновского клока.
И собственно говоря это я и получаю => даёт нам установленный WaitRequest через 10 с копейками нс после выставления нужной комбинации (пока всё декодится и пройдёт через луты).
Далее, data_now_prepared устанавливается как раз после того как был импульс на clock_enable компонента:
delay_chain <= delay_chain(2 downto 0) & Read_request - это мы подгоняем наш Read_request под Input_clock.
далее, логика

Выставляет нам строб, чтоб до rising_edge Input_clock он уже был установлен.
Ну а как раз после strobe будет идти delay_chain(3) что и будет знаком что данные готовы.
Итого - data_now_prepared привязана как раз к клокам Input_clock - так что пока Input_clock тикает, а оно тикает пока есть питание, то data_now_prepared будет выставлен всегда.
и того вроде как раз всё согласно картинке с спецификации авалона для работы с WaitRequest:

Так что получается что всё вроде сделано согласно тому как написано в документации.
Единственное что я пока заметил с вопиющего - data_now_prepared у меня привязана к Input_clock а не авалоновскому клоку, хотя по правилам нужно было перейти к авалоновском клоковому домену. Сегодня переработаю.. Но не ужели из-за этого оно всё и не работает ????

неужели в самом деле погорели карусели шучу
Раз не работает - значит что то сделано не согласно докам
у вас клок что на инпуте, вы опускали до 10 МГц. так ведь? а ниос на какой частоте работал?
то есть до момента появления вайтреквеста может пройти более 30 нс а скажем у ниос тактовая 50 МГц...
понимаете о чём я?

+1

На счёт 30 нан и 50МГц на ниосе - в симуляции говорится про 12 нан с момента выставления последнего нужного сигнал до установки WaitRequest`а - это ж и получается как раз предел частоты...
А на счёт понижения тактовой ниоса - я заводил NIOSII аж на 10MHz (там варнинги были что дебуг требует минимум 20 , но я как то решил что обойдётся..Может и тут надо было послушаться) - на 10 и получал идентичные...
Input_clock - сварганил тестовый - там около мегагерца.
Вот тут то и загвоздка как раз - вроде бы всё согласно требованиям, но в железе вообсче не ясно какое поведение....

Мне тут кроме правильного перехода на авалоновски клоковый домен больше ничего в голову не приходит.....

мдя..

Значит перевёл data_now_prepared на Avalon-овский клок.
Проверил - симуляция показывает всё то же - что работать должно, а в реальном тесте на железе - всё то же самое => только 1-й байт... Систему заводил на 25 МГц..
Вот теперь точно тупик...Куда рыть ??

Данные с симуляцией и VHDL

да всё туда же
сигнал тап вас рассудит

з.ы. плохо моделировали

2 Postoroniy_V

а можно поточнее ? - вроде ж теперь всё по правилам, с переходами с одного домена на другой, клок 40нс при времени реакции WaitRequest ~12нс ....

ещё раз - воспользуйтесь сигнал тапом!

2 Postoroniy_V - та понял уже.
Начинаю хелпы читать по этой страшной шняге , а то не сильно знаком с этой страшной штукой .......