Добрый день.

Не то чтобы требуется - скорее для собственного интереса:
1. Есть генератор данных, который складывает их в большое фифо.
2. К фифо с другой стороны подключена NIOS-система, которая, когда ей надо, это фифо читает и дальше отсылает данные в сеть.
3. Видится вероятная в будущем проблема: если поток генерируемых данных сильно увеличится, а NIOS будет по каким-то причинам долго занят, то фифо может переполняться и, следовательно, будут потери данных, что не очень-то приемлемо.
4. В NIOS задействована DDR2-память (CIII dev kit), которая сейчас как-то используется (в основном для предварительной буферизации прочитанных из фифо данных перед отправкой в сеть).
5. А теперь вопрос: возможно ли построить архитектуру таким образом, чтобы из DDR2-памяти получилась двухпортовая память? При этом хотелось бы, чтобы генератор мог писать в этот DDR2-буфер напрямую, а NIOS мог этот буфер когда ему надо читать (возможно, одновременно с записью).

Как я это вижу сейчас:
1. DDR2-ядро выводится за пределы QSys-системы.
2. Для Qsys-системы пишется прокладка-интерфейс к арбитру.
3. Пишется прокладка для генератора к арбитру.
4. Пишется арбитр, который будет как-то разруливать совместный доступ - кто когда пишет и читает в DDR2-память (используя маленькие буферочки на случаи коллизий).
5. В совсем отдаленном будущем хотелось бы вообще избавиться от NIOS и софта, оставив только хардварную цепочку [генератор]--[DDR2-буфер]--[сеть (UDP)].

То есть конечная цель - сделать двухпортовый DDR2-буфер.

Насколько будет адекватной такая архитектура? Или я упоролся в своих фантазиях?

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

Или я что-то не понял, или Вы описываете банальное FIFO на внешней памяти. Если я правильно понял, вопрос решается небольшим модулем-прокладкой, в котором есть два небольших FIFO (на запись и на чтение) подключенных одной стороной во внешний мир, и простейший автомат, который поочерёдно смотрит на количество данных во входном буфере и количество свободного места в выходном буфере, и производит соответствующую операцию по записи во внешнюю память или чтению из неё со второй стороны этих FIFO. Естественно, что средняя скорость чтения данных NIOS-ом должна быть не меньше скорости записи данных генератором, иначе FIFO переполнится несмотря на внешнюю память. Приоритет между записью/чтением внешней памяти выбирается исходя из того, какая сторона (NIOS или генератор) может подождать в случае неготовности.

Andrew Su, спасибо за документ. Изучаю.

o_khavin, не совсем фифо - скорее именно адресуемую память, т.к. необходимо иметь возможность при необходимости NIOS'ом повторно прочитать некоторые ячейки из памяти (глобально хочу сделать что-то типа UDP с гарантией доставки, поэтому нужно иметь память, из которой при потерях нужно перечитывать и отсылать нужные данные повторно), соответственно, удалять данные из памяти нельзя.

Возможность повторно прочитать сколько-то там последних данных FIFO, это просто частный случай FIFO. IMHO, не стоит пытаться решить этот частный случай путём реализации намного более сложного общего варианта с полной адресацией. Достаточно сделать чтение из FIFO пакетным, т.е. указатель инкрементится сразу на N слов, а некий адрес со стороны NIOS-а адресует в пределах этих N слов. Понятно, что размер буферного FIFO (на чтение) должен быть как минимум N*2, а само N должно перекрывать интервал подтверждения этого "что-то типа UDP" и быть степенью двойки.

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

Добрались руки снова взяться за это дело. Наваял модуль на основе Авалон ММ-мастера (который разделяет доступ читалки/писалки к внешней памяти). Сейчас, когда пытаюсь его встроить в Qsys-систему, возник вопрос: при создании компонента в списке сигналов у мастера отсутствует сигнал beginbursttransfer, хотя в слэйве у DDR2-контроллера он вроде как есть. Что с ним делать? Я его, конечно, дергаю в начале каждого берста, но может он не нужен?

Из этих источников получается что сигнал не актуален, либо его надо через кондуиты выводить-вводить. Но насколько это все правильно?
Источники:
http://www.altera.com/support/kdb/solution...262013_942.html
http://www.alteraforum.com/forum/showthread.php?t=25303
http://cubiccyclonium.net/support/kdb/solu...112006_773.html

UPD:
Avalon Interface Specifications, page 3-5: "beginbursttransfer is optional. A slave can always internally calculate the start of the next write burst transaction by counting data transfers. Altera recommends that you do not use this signal. This signal exists to support legacy memory controllers."