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

Инициализация блоков памяти идет после на готовый bit-файл через блоки INIT в соответствии с линковщиком по адресам. А готовая корка - целиком bit-файл. Или еще нужен к-л интерфейс к ней...

Насколько я знаю, EDK всегда делает нетлист+BMM, и этот BMM прилепляется после. В принципе ничего предосудительного не вижу в том, чтобы отдавать пользователям корку как нетлист+BMM.

Возникла проблема с передачей проекта как нетлист+BMM. Почему-то инициализация bram выполнялась с ошибкой. То ли разные версии/сервиспаки сказались, пока проблема не решена.

EDK поступает следующим образом - генерит кучу NGC файлов, обертки к ним и BMM-файл с описанием RAM-блоков со ссылками на иерархические имена элементов и адресное пространство процессора.
После формирование полного проекта (в ISE либо сборки Aldec'ом), NGDBuild берет с ключом -bm "имя.BMM" этот файл и передаем его "по цепочке" для MAP и PAR. Последний формирует новый BMM-файл с именем "имя_bd.BMM", где стоят ссылки на конкретные RAM-блоки в кристалле. Получается таблица, где куски адресного пространства привязаны к элементам кристалла. Bitgen работает (начиная с версии 10.1, по-моему) "не зная" о BMM. Получается прошивка с пустыми RAMB.
Параллельно Вы после формирования архитектуры процессора запускаете LibGen и компилируете программу в ELF файл. ELF-файл - это (упрощенно) список блоков памяти (нач. адрес, длина, данные).
После всего этого Вы имеете две вещи - информация о данных с привязкой к адресному пространству - с одной стороны, и ВММ-файл, в котором эти куски адресного пространства привязаны к RAMB - с другой стороны.

Инициализировать RAMB "заранее" Вам едва ли удастся - EDK формирует NGC-файлы, в которые уже не влезть.

Можно утилитой Data2Mem попробовать сделать UCF-файл, переименовать его в NCF и передавать вместе с Вашей коркой клиенту (Вы же ведь EDN или NGC передаете?) - так "делает" ChipScope. К сожалению, в 10.1 UCF с инициализацией RAMB у меня на V5 не получился - Data2Mem выдал внутреннюю ошибку.

Остается только одно - делать, как рекомендует Xilinx :-) - так делать логичнее и существенно гибче - можно будет что-то потом поправить на программном уровне, не заставляя клиента переразводить кристалл (а это - поверьте! - иногда просто слезы!)

Вообще-то очень странно, что возникли проблемы с передачей/использовнием BMM-файла. Скорее всего, клиент вставил Вашу корку не с тем именем, с которым его делали Вы, либо впихнул на уровень иерархии ниже/выше вашего - в BMM прописывается _абсолютный_ путь до блоков.

ServicePack'и тут, скорее всего, ни при чем. Data2Mem работает независимо от версии. В разных версиях софта отличаются только ключи, и, по-моему, список поддерживаемых кристллов.