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

Делал тут я недавно периферийку - и решил её запхнуть в NIOSII систему.
Чтобы не муксить клоки, решил чтение синхронизовать с входным клоком для периферии.И потом выдавать флаг.
Значится про WaitRequest нашёл такое:
Нажмите для просмотра прикрепленного файла
Потом сварганил враппер чтоб он работал как на вышеприведённой картинке, просимулил его.
Нажмите для просмотра прикрепленного файла
Как видно из рисунка, WaitRequest взводится как раз до начала rising_edge(основной клок - 25МГц).
Но в результате тестов в железе - имеем чтение только 1-го символа с фифо - остальные - идентичны(что 10 что 20 символов)
Вчера клок даже до 10 МГц опускал - всё равно все символы одинаковые (чтение остальных регистров, что без WaitRequest - нормально)...
Файлы прицепил.
Нажмите для просмотра прикрепленного файла
Есть у кого идеи отчего так может быть ?


Если кто-то раньше дизайнил периферию с 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 - та понял уже.
Начинаю хелпы читать по этой страшной шняге , а то не сильно знаком с этой страшной штукой .......