Суть вопроса. Имеется мною написнный компонент для Nios II Cyclone III. Интегрирую его в SoPC-Builder'е в систему через Avalon. Мне выделяется диапазон адресов размером 7ff. В самом компоненте имеется блок под память, управляющие регистры. Где найти информации какие регистры моего по какому адресу сейчас находятся? Потому что есть необходимость как читать, так и писать в блок паямти, так и отслеживать состояние компонента через управлющие регистры.

Расположение по адресам внутри компонента Вам известно? Они будут там же, только учитываете базовый адрес (написан в SOPC Builder, при генерации также создается .h в котором он указан, допустим у вас это h1000) и учитываете смещение адресов (то есть, если мастер и компонента 32-битные, смещение 2 бита , то регистры по адресам внутри компонента 0,1,2,3 будут доступны по адресам 1000,1004,1008,100С...)
Грубо говоря, смещение - это сколько младших бит адреса мастера выкидываются. Остальные поступают внутрь компонента.

Про базовый адрес и смещение я понял - так и предполагал. Проблема в том, что внутри самого компонента не знаю как узнать расположение адресов. Как оно там строится? Сам компонент состоит из нескольки модулей, связанных между собой - и как там оно расположено, не понятно.
Если кто-нибудь поможет - буду благодарен. Прикрепляю исходники компонента.

так Вы сами же порт адреса должны декодировать, и ессно тогда знаете - где что и как.

наружу выведен только интерфейс памяти 512x32бита или 2048(0..7ff)байт, никаких регистров извне не видно

Сейчас пока да - только память. Но буду добавлять еще один модуль с памятью (для TX части) и регистры управдения для MDIO. И тут станет актуальна очень. Как вывести регистры, чтобы они были доступны из вне? Просто я этот момент не понимаю немного. И как между регистрами, как потом между ними адресацию задать?

Сами внутри должны декодировать, например, в таком духе:

То есть получается у меня имется блок памяти и я только в рамках него могу адресацию выполнять?
А как быть если например у меня есть mem1[512], в другом модуле mem2[512], а еще хочу пару регистров из третьего модуля (тот что eth_rx_sm.v) вывести. (например регистр ready)?

А Вы сами как думаете?


Если у Вас, к примеру, внутри модуля есть память [...] mem1 [7:0] и память [...] mem2 [7:0] (по 8 слов), а снаружи приходит сигнал address[2:0].

И равен этот сигнал, к примеру, 3'd5.


К какой памяти в итоге будет обращение, к mem1 или к mem2?

И как это должно работать?

Сделайте 2 Avalon-MM Slave интерфейса, один для памяти, другой для регистров. такое разделение удобно тем, что можно, например, к интерфейсу памяти прикрутить DMA, а управлением через регистры займется CPU. я так понял, что вы делаете ethernet MAC? чем готовые не устраивают, тот же опенкоровский от Igor Mohor?
upd: сколько блоков памяти, столько и интерфейсов авалоновских делайте + 1 для регистров. посмотрите также Avalon Naming Conventions, для автоматического распознавания типов сигналов по именам, не помешает также сделать прерывание.

Спасибо за совет! Да, вы правильно поняли. Цель - написать прототип контроллера MAC. Это пишу в рамках своей дипломной работы в Универе, поэтому нужно свой реализовать. Немного нt понял про разделение управления между DMA и NIOS CPU. Какова идеология и как это организовать? Если есть ссылка на литературу, скиньте плиз.
А можно ли в рамках одного интерфейса Avalon Slave выводить просто регистры? Или обязательно они должны быть как блок памяти?
А пока всем управляет CPU и суть в том что когда приходит пакет, должно срабатывать прерывание и программа с помощью HAL считывает содержимое памяти. ТАк же требуются управляемые регистры для контроля контроллера процессором. Пока сейчас отлаживаю на симуляции в ModelSim считывание данных программой через драйвер, без прерываний - нужна просто группа регистров по состоянию которых буду судить о том что и как было принято.

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

С литературой это верно подмечено. Руководитель уже начинает докучать, почему так медленно. Да потому что тут не поймешь с какого бока подходить и что читать.
Это хорошо что можно всё. Вопрос в том как добавить то что я хочу в адресное пространство компонента, которое выделяется SOPC-Bulder'ом (0x00000800..0x00000fff - как сечас уменя) другие регистры. И как потом разобрать в этой каше потом где и что SOPC-builder разместил?

Так Вам же посоветовали - ДВА слейва ! А SOPC никакую кашу не делает - адреса ПОЛНОСТЬЮ определяются Вашим декодером адреса

А какая конкретно тема диплома, если не секрет?

С двумя слейвами поэкспрементирую, сообщу об успехах или вопросах. В целои понял вроде идею работы через Avalon-MM.
А по поводу DMA ссылкой никто не поделится?
Тема не секрет - разработка програмно/аппаратного контроллера MAC для Fast Ethernet

приемная часть MAC (это же справедливо и для передающей) обычно состоит из моста между шинами MII и Avalon (по сути буфер FIFO) и контроллера DMA. DMA нужен чтобы разгрузить процессор от тупого копирования. работа примерно выглядит так: проц выделяет сегмент памяти, отдает указатель на этот сегмент контроллеру DMA и разрешает прием. MAC принимает пакет, пишет его в память, проверяет контрольную сумму и генерит прерывание. все, пакет целиком загружен, процессор может его обрабатывать, а контроллеру DMA дает следующий кусок памяти. примеры реализации: альтеровский www.altera.com/literature/ug/ug_ethernet.pdf и опенкоровский http://www.opencores.org/project,ethmac. есть модификация последнего под Avalon http://www.alteraforum.com/forum/showthread.php?t=21005 исходники 2 последних открыты и неплохо документированы. мне опенкоровский вариант больше нравится, т.к. контроллер DMA интегрирован в компонент, а в альтеровском надо внешний цеплять, возни больше.

собственно, вся периферия memory mapped, не вижу проблемы. доступ ко всем регистрам i/o осуществляется как к памяти

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

делайте минимум 2 интерфейса, для регистров отдельный.
читайте тут, особенно главу 6 (Naming Signals for Automatic Type and Interface Recognition) http://www.altera.com/literature/hb/qts/qts_qii5v4.pdf
это тоже читайте www.altera.com/literature/manual/mnl_avalon_spec.pdf

разве MII это не шина между MAC и PHY уже ?

ну да, у MAC с одной стороны MII, с другой Avalon или другая системная шина. входная часть MAC использует сигналы rxd[3..0], rxer, и т.д, но главное тактируется от rxclk (25МГц для Fast Ethernet)

С адресным пространством компонента и как оно формируется разобрался. Всё завязано на интерфейсе Avalon-MM. Главное в компоненте обеспечить совместимость с шиной и обеспечить адресацию. Спасибо кто подсказывал, очень помогли.
Как тут советовали - сделал два итерфейса Avalon MM Slave. Теперь осталось компонент переписать немного. Задумался вообще об общей идеологии контроллера. СЕйчас он работает по принципу из интерфейса MII поступают данные, склеиваются в 4 байтные слова и записыватся в встроенный в компонент блок памяти (просто пока изучаю инструментарий и софт - так что пытаюсь на таком примитиве хотя бы пройти все стадии от RTL модели -> к SOPC системе на FPGA принимающей пакеты)
Вопрос - как в такую схему можно встроить DMA контроллер Alter'овский? И нужен ли он?
P.S. Диплом сдавать в июне месяце, поэтому приходиться сейчас очень активизироваться ))

если все правильно сделать, то одним из портов Avalon-MM MAC будет вылядеть как обычная память. DMA умеет копировать из одной памяти в другую, надо только гарантировать неизменность данных на время проведения DMA-транзакции (прием запретить).

То есть фактически, как я понял. Модуль MAC принимает весь пакет себе во внутреннюю память.Когда пакет принялся, генерирует прерывание процессору, который в свою очередь дает команду DMA то что принято положить ему в тот участок памяти, который он выделяет програмно. Так? То есть фактически сейчас надо реализовать обработку прерывания по получению всего пакета. И програмно реализовать взаимодействие NIOS-DMA.
Cейчас ближайшая задача от руководителя - считать полученный пакет из памяти, отсимулировав это на ModelSim'e. Для этого не нужно DMA, но в дальнейшем эотпроблема будет актуальной. А считывать процессором принятый пакет по 4 байта - дело будет неблагодарное.

я вобщем-то так и делаю сейчас... по-моему все правильно