Пишу софт для Ethernet обмена для своей платы с ядром 1Г-МАК от ксайлинкса (см. тут). Проект матрицы сделан на ISE 8.2.
В матрице на приём у меня стоит два ФИФО байтовой ширины по записи и по чтению, а на передачу стоит 4-байтовое на входе (по записи с процессора), а на выходе байтовое (в ядро 1Г-МАК). Все ФИФО с разным тактом по чтению и записи, сгенерированы coregen-ом.
С приёмом всё пучком, а с передачей выяснилось, что ФИФО передаёт в МАК первым байтом старший байт 32-битного слова. Т.е. по факту можно сказать big-endian.
А мне надо бы little-endian, т.к. процессор тоже little-endian (Tiger Shark 201).
Казалось бы ерунда, чего там, взял в проекте матрицы переконнектил байты с шины процессора на вход передающего ФИФО. Однако не так всё просто - после компилляции проект "поплыл", перестал работать не только в части МАКа, но и ещё кое-что накрылось. И это несмотря на то, что согласно репорту par-а всё вроде бы Ок. Странно только, то что в новом проекте используемых слайсов оказалось на 10 меньше чем в старом проекте (1989 против 1999).
Изменения были всего в одной строчке:


Вот теперь не знаю как быть. Ну не в софте же переставлять байты, это ж такой гимор и убивание времени, а оно важно.
Начинаю склоняться к тому, чтобы взять исходняки ФИФО, засунуть их в проект (вместо coregen-а) и поправить там последовательность выдачи байтов на обратную. Но посмотрел, там такая каша этих исходняков...

Может кто-то уже это делал?
Или есть другие идеи?

вообще стандартным для всех сетевых протоколов (по крайней мере в стеке tcp/ip и канальном ethernet) принята передача данных с так называемым сетевым порядком байт (по сути big-endian)
подробнее на википедии
так что логичнее все-таки на уровне софта менять порядок байт в заголовках. в posix есть вызовы htons/ntohs, htonl/ntohl для таких вещей.

Зачем же мне время терять на софтовых перестановках?
Да и ФИФО само по себе никакого отношения к сетевым протоколам не имеет.
А у самого ядра МАКа вообще байтовый интерфейс, ему по барабану. Первый байт пришёл, первым и ушёл.
Так что никакой логики мучаться перестановками я тут не вижу.

Ну еще такой вопрос, вы собираетесь по эзернет передавать свои raw-пакеты и какого рода данные? Потому что например для передачи четырехбайтового необходимо все байты поменять местами, для двух подряд идущих 2хбайтовых целых - необходимо только свопнуть соседние байты, если передается просто "data" =) ну например текстовые данные в этом случае перестановка байт и вовсе не нужна. т.е. в случае смешанного характера передаваемых данных реализация перестановки байт в железе не будет подходящим вариантом

Перестановка байт мне нужна только потому, что я пишу в передающее ФИФО словами по 32 бита. Мне это нужно для скорости. У меня передаваться будет поток (32-битными словами) около 90 МБ/с. А приниматься будет минимум. Поэтому я на приём поставил ФИФО шириной в байт (вернее потому, что принимаемый пакет может быть длинной не кратной 4 байтам, а ФИФО не даёт читать слово, если не все байты в нём записаны с другого конца).
А на передачу я буду формировать пакеты кратные 4 байтам принудительно.

Я извиняюсь, но я так и не понял из ваших постов, перестановка байт вообще возымела эффект?) В смысле, вы проверяли что получилось после синтеза именно в этом месте? Или не работает даже в исходниках?

Проверял итоговый проект - он перестал нормально работать.
В части МАКа и в части чтения датчика температуры по SPI интерфейсу. Может ещё что-то не работало, да я не доглядел. Доступ в ОЗУ 256х32, что внутри матрицы, например, остался работающим.
Поскольку шина от процессора работает на 100 МГц-ах, т.е. быстро, то вставлять на этом пути (до ФИФО) перестановку байтов, нехорошо. Вот я и склоняюсь к тому, чтобы эту перестановку сделать на выходе ФИФО, где будет как раз место для этого.

Я вообще не пойму, с какого перепоя товарищи решили, что именно так должны "выходить" байты. Не всем же так подойдёт. Посмотрел мануал на ФИФО, там действительно всё так и написано, даже картинки приведены чтоб понятнее было. Но почему сделано именно так, не написано. Почему нельзя было сделать это опциональным параметром?
А как с этим в 9-й версии ISE никто не знает?

Если не очень критично, попробуйте вставить регистр между шиной процессора и ФИФО и на нем перекоммутировать провода. То что проект у вас получился несколько меньше при том, что вы ничего кроме порядка подключения байт не меняли, наводит на мысль, что при синтезе что-то нужное убилось. ) В любом случае очень хорошо бы посмотреть в симуляторе именно это место. Или найти его в RTL-view после синтеза и убедиться, что всё подключено верно. Но это конечно при условии, что вы уверены в том, что проблема именно из-за неверной коммутации, а не дальше по устройству.

Конечно критично, ведь регистр - это задержка на такт, а значит все управляющие сигналы надо тоже задерживать. Что из этого получится не знаю. Может и попробую.

Порылся в исходняках. Нашёл нужное место в файле as\output_block_as.vhd (мой случай - асинхронное ФИФО):


Константа C_DOUT_DIRECTION задана равной 1. Блин, ведь заложена возможность менять порядок байтов! Но не выведена наверх! Константа C_DOUT_DIRECTION присваивается только в этом файле. А константа C_RATIO_W равна отношению ширины данных по записи к ширине по чтению, если оно больше единицы и равна 1 если меньше. В моём случае для передающего ФИФО получается C_RATIO_W = 4.
Тут-то байты и перевёртываются.
Буду пробовать менять - надо поставить C_DOUT_DIRECTION = 0 и всё.

Чем рылись? В смысле, как получить нормальные VHDL-исходники из тех vhd-файлов, что лежат в coregen'е?

Ну как чем?! Вы же тут на форуме бываете, а такие вопросы задаёте.
Где-то должен лежать x l d e c o m p (к с а л и н к с д е к о м п р е с с о р).
Не найдёте - могу заслать.

Меня другое опечалило - там столько файлов завязано, причём ещё из трёх мест дополнительно. Я почти со всеми разобрался, а вот с ядрышком двухпортовой памяти проблемы - кое-чего нет. Сейчас названия точно не помню, завтра с работы напишу. Пока не удалось нужные файлы найти, вернее они есть, причём в незашифрованном виде, но они в поддиректории simulation, а посему я не уверен, что они подойдут. Да я ещё и в VHDL не силён, потому доптрудности имеются. Я то всё в верилоге делаю. Засношала VHDL - ская пристыковка библиотечных фалов, создай библиотеку, да туда перенеси и т.д. А тут такая куча файлов. В общем начал с топового файла и пол дня сидел с формированием проекта. Да ещё ИСЕ ругался на отсутствие какого-то куска в библиотеке IEEE (что-то там в названии начиналось с Vital...). Где это искать пока не понимаю. Особо ещё не разбирался, пошёл домой.

Пока не удалось собрать все исходняки и скомпиллить проект с только одним ФИФО.
Ну не спец я с этим VHDL. Поэтому прошу знатоков VHDL разобраться.
Для этого я выкладываю проект тут. Пароль архива - имя этого сайта по-русски (без точки ру и типа протокола в начале, т.е. одно слово).
Проблема возникает с элементом b l k m e m d p, в котором часть файлов (все кроме одного) исходняков вроде как для симуляции и в них компиллер ругается на строчку USE IEEE.V I T A L _ T i m i n g . A L L;, говоря, что такого в библиотеке IEEE нету. В тоже время как я понял, V I T A L _ T i m i n g вроде нужен только для симуляции. Непонятно тогда где брать нормальные исходняки.
В директории \X i l i n x\I S E\c o r e g e n\i p\x i l i n x\p r i m a r y\c o m\x i l i n x\i p\b l k m e m d p_ v6 _2\, где лежит эта байда, только зашифрованный файл b l k m e m d p_v 6_2 _x s t_c o m p . v h d, остальные в поддиректории s i m u l a t i o n (незашифрованные). Причём все они же в незашифрованном виде лежат в директории \X i l i n x\I S E\v h d l\s r c\X i l i n x C o r e L i b\.
Возможно, что нужное лежит в файлах с расширением class, но я не знаю чем их открыть. Может кто знает? Вроде это java, но я в ней не спец.

Пояснения по прилагаемому проекту.
Все исходняки лежат в поддиректории проекта FIFO. Дополнительно к исходнякам самого ФИФО я туда положил то, что ещё нужно дополнительно:

\b l k _ m e m _ g e n
\b l k m e m d p
\i p u t i l s
\u l

Причём некоторые файлы (которые PKG) при включении в проект почему-то попадали в закладку исходняков. Поэтому я их удалял из проекта (например, i p u t i l s _ s l v . v h d).
За топовый файл проекта я пока взял файл из директория AS\ (это асинхронное ФИФО): f i f o _ g e n e r a t o r _ v 3 _ 2 _ a s . v h d. А вообще там пять вариантов ФИФО, которые расположены в поддиректориях:

\a s
\f i f o 1 6 _ p a t c h
\f i f o _ 1 8 _ 3 6
\s s
\s s h f t

В поддиректории g o l d e n\ лежат совместно используемые файлы.
Ну, и файлы в директории s i m u l a t i o n\ я добавил на всякий случай.

Начал рассматривать другой вариант выхода из положения.
Хочу просто подменить один файл в директории coregen-а на подправленный как мне надо и перегенерить ядро ФИФО.
Т.е. я расшифровываю файл, правлю его, зашифровываю и кладу на место прежнего.
Первые две операции получились, а вот зашифровать никак.
Создал тему по этому вопросу тут.
Надеюсь, кто-нибудь поможет.

Изначально, столкнувшись с проблемой последовательности следования байтов, Вы стали решать ее совершенно правильно. А теперь зачем-то полезли в "дебри". Зачем??? Нужно попытаться разобраться в причинах того, почему проект "разрушился". Возможно, ошибка кроется в средстве синтеза, которым синтезируется проект. Поробуйте использовать другой синтезатор. Убедитесь, что проект собирается правильно, что используются нужные версии файлов и т. п. Вообщем, ищите причину, а не занимайтесь расшифровкой и т. п.

oval
Жаль что раньше не написали. Написали бы, что от этого всего ничего не изменится, я бы и не заморачивался...
Целых два дня коту под хвост.

Да, шифрование не понадобилось, coregen и так съел правленный файл не поперхнувшись.
Но изменение порядка следования байтов внутри ядра (вместо снаружи, как я сначала делал) ничего не изменило: проект так же точно не работает - нет приёма, неправильно читается датчик температуры и м.б. что-то ещё. И количество слайсов тоже так же меньше на десять штук - 1989 против 1999 в работающем проекте. Можно поздравить Xilinx с успехом! Результат стабильный. А это пирзнак класса.
В принципе, оглядываясь назад, можно сказать, что по-другому и не должно было быть.
Ведь правка файла корки, как оказалось, должна была делаться на входе данных, т.е. где шина шире.
А раз на входе, то без разницы где это описывать, толи на входе внутри ядра, толи на входе снаружи. Один хрен.
Кстати, они в ядре сами порядок байтов меняют (т.е. DIN_I(7 DOWNTO 0) <= DIN(31 DOWNTO 24) и т.д.), а я как раз пытался "выправить".

Но самое плохое в том, что я пока не знаю что делать дальше. Куда копать? Где смотреть?
Похоже надо сначала поискать куда пропадают эти 10 долбаных слайсов и почему? Куда сунутся за этим? В репорты синтезатора? Что посоветуете?

Что-то в голове каша, сегодня уже с меня хватит, домой пойду.

Вернул ядро ФИФО в оригинальное состояние.
Скомпиллировал два раза проект, один (работающий), у которого в исходняке написано:

И другой (неработающий) с желаемой мной перестановкой байтов путём такой строки:

Начал искать потерянные 10 слайсов во втором варианте.
Сравнил репорты синтезатора, коим у меня сейчас XST (в файлах top.syr).
Никакой принципиальной разницы не увидел. Результаты по использованию ресурсов таковы (у обоих вариантов):


Есть отличия в таблицах Clock Information и Asynchronous Control Signals Information в названиях связей соответственно Clock buffer(FF name) и Buffer(FF name), однако в графе Load у обоих вариантов одни и те же числа. Так что имхо это не принципиально.

Смотрю дальше отличия в репортах маппера (в файлах top_map.mrp). И тут сразу вижу отличия.
Вот для работающего варианта 1:

А вот для неработающего варианта 2:


Как видно, недостача 10 слайсов. Куда они делись? Непонятно.
В остальном файлы репорта маппера отличаются только в секции 11 (Timing Report).
Там разные времена, причём в варианте 1 один констрейнт не выполнен - на клок передачи Эзернета, а во втором два - на клок передачи Эзернета и на клок приёма Эзернета.
Вот тут и вопрос - может из-за этого и не работает?
Правда после PAR-а все констрейнты выполняются.
Короче, не знаю где искать причину неработы нужного мне варианта 2.

Кто подскажет как быть?

Попробовал использовать другой синтезатор. У меня стоял Sinplify 8.2 pro.
Но Translate сразу заругался на неполные имена цепей в ucf-файле типа такого:

Я так понял, что * он не переваривает.
Это как-то можно преодолеть?

Пока поставил качать версию 8.8.04. Вдруг там будет с этим нормально.
Пока попытаюсь поправить имена цепей.

На разницу в 10 слайсов не стоит обращать внимания. Если посмотреть и разобраться в том, что представляет из себя слайс, то можно выяснить, что слайс - это объединенные определенным образом несколько LUT и несколько FF, а также элементы некоторой специальной логики. Так вот, и в первом варианте и во втором количество логики в Вашем проекте абсолютно одинаково,

Logic Utilization:
Number of Slice Flip Flops: 1,705 out of 15,360 11%
Number of 4 input LUTs: 2,541 out of 15,360 16%

чего и следовало ожидать. А вот расположение этой логики внутри слайсов, как контейнеров LUT и FF, оказалось разным,

Logic Distribution:
Number of occupied Slices: 1,999 out of 7,680 26%
Number of Slices containing only related logic: 1,999 out of 1,999 100%
Number of Slices containing unrelated logic: 0 out of 1,999 0%
*See NOTES below for an explanation of the effects of unrelated logic

Logic Distribution:
Number of occupied Slices: 1,989 out of 7,680 25%
Number of Slices containing only related logic: 1,989 out of 1,989 100%
Number of Slices containing unrelated logic: 0 out of 1,989 0%
*See NOTES below for an explanation of the effects of unrelated logic

что вполне закономерно, и ничего странного тут нет. Ключевым словом в отчете здесь является Logic Distribution, ведь может использоваться лишь часть слайса, то есть он может быть задействован не полностью.

Таким образом, предполагаю, что ошибка кроется не здесь.

Попробуйте описать перестановку байт любым другим эквивалентным способом или способами. Посмотрите на результат.

По поводу синтеза в Synplify: попробуйте не включать .ucf файл, подключите его уже после синтеза в Synplify, в проекте ISE. Если все же требуются ограничения на этапе синтеза, то создайте файл ограничений в самом Synplify.

И еще, средства синтеза не лишены ошибок, причем влияющих на функциональность схемы (хотя встречается такое крайне редко). Здесь на форуме я писал об ошибке, обнаруженной в Synplify 8.8.0. По сему, используем 8.6.2. Исправлена ли ошибка синтеза в версиях 8.8.0.2 и 8.8.0.4, сказать не могу, не проверял. Естественно, не факт, что эта ошибка проявит себя на Вашем проекте.

Я вообще-то проект так в ISE и делаю, т.е. не отдельно в Sinplify.
ISE сам запускает Sinplify в качестве синтезатора, а дальше как обычно транслятор/мапер/разводчик.
Так что ucf файл, как я понимаю, после синтеза и подключается.
Вот я и не понимаю, почему транслятор перестал понимать ucf?
Ведь всё осталось как и было.
Вообще в исходняках корки есть аттрибуты для синтезатора XST типа таких:

Sinplify, видимо, их не понимает. Но я пытался вставить вроде как аналогичные такие же аттрибуты для Sinplify так:

Но это ничего не изменило. Или это не то?
Вот теперь и не знаю что ещё ему предложить.

Да, я уже понял, что, видимо, просто временная диаграмма стала другой и что-то из-за этого уползло.
Хоть репорт ПАРа и ничего плохого не сообщает (Timing score = 0).
Возможно надо описать временной констрейн по входной шине.
У меня сейчас только есть только для входных сигналов адреса (помимо клока):

Видимо надо и для DATA указать. Щас я уже не помню, вроде раньше я так делал и проект кажись не собирался (Timing score был большой).

Во-первых, Oval справедливо заметил, что нужно попробовать переписать переставку байт при помощи иных конструкций. Во-вторых, не очень понятно из-за чего отказывает проект. Если PAR говорит что все ОК, то это еще не гарантирует устойчивую работу в динамике, я обычно включаю в симуляторе проверку таймингов на гейтах, сразу видны нестыковки.

Всё заработало!!!
Причём похоже и раньше работало, просто я не допёр, что проверяю не так как раньше.
Видимо были странности с loopback режимом (в котором я проверял) в физическом уровне.
А раньше я приём (фазу DCM) настраивал совместно с компом, по той инфе что он мне присылает.

Если по порядку, то я действовал так.
Сначала меня достало уговаривать Sinplify не портить иерархию связей.
Так что я на него плюнул и вернулся к XST. Проект с перестановкой байтов, как и раньше, не заработал (сейчас уже думаю, что я просто недопёр, надо было внимательнее посмотреть).
Тогда я решил добавить в ucf файл строки, которые призывают соблюдать времена по шине процессора. Подумал сначала, что это заставит плакать MAP и PAR горькими слезами. Но нет! Наоборот, проекту полегчало! Вот, например, таблица репорта многопроходной компилляции для старого варианта (без перестановки байт):

А вот она же для нового проекта (с перестановками байт) с добавлением констрейнтов по шине процессора:

Я было думал, что меня ждёт всё тот же неработающий результат, но что-то меня толкнуло включить плату по обмену с компом вместо loopback. Смотрю, приём-то есть! Проверил передачу - и она есть! И остальное работает. Настроил фазу приёма, после чего и loopback заработал почему-то. Опечалило только то, что в программе МАК-адрес записывался в регистр ГМАК-а нулевой, а д.б. быть заданным (он у меня в платформ-флеше лежит сразу за проектом матрицы после сигнатуры для поиска). Думаю - опять что-то не работает, но теперь уже стал не на проект кидаться, а стал выяснять в чём дело. Оказалось, что вкралась ошибка в функцию поиска МАК-адреса в платформ-флеше - она была настроена на меньший размер проекта, а он, как выяснилось, чуть увеличился. Я всё исправил (сделал с запасом) и эта чать заработала. Вот и всё! УРА!
Запустил стек протоколов (портированный OpenTCP), смотрю - работает, ARP-шками меняется.
Буду программить дальше.
Всем спасибо!