Разбираюсь с FIFO из Coregen, как его сделать little endian?, Может кто-то уже делал подобное? Опции

[Dimonira]

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

Код

// было:
wire [31:0] tx_fifo_data_in = data_fr_dsp;
// стало:
wire [31:0] tx_fifo_data_in = {data_fr_dsp[7:0], data_fr_dsp[15:8], data_fr_dsp[23:16], data_fr_dsp[31:24]};

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

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

[oval]

На разницу в 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, сказать не могу, не проверял. Естественно, не факт, что эта ошибка проявит себя на Вашем проекте.