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

[Dimonira]

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

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

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

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

[Dimonira]

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

Код

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]};

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

Код

Device utilization summary:
---------------------------

Selected Device : 3s1000lfg320-4

Number of Slices:                    1678  out of   7680    21%  
Number of Slice Flip Flops:          1758  out of  15360    11%  
Number of 4 input LUTs:              3032  out of  15360    19%  
    Number used as logic:             3017
    Number used as Shift registers:     15
Number of IOs:                        106
Number of bonded IOBs:                106  out of    221    47%  
    IOB Flip Flops:                      3
Number of BRAMs:                       13  out of     24    54%  
Number of GCLKs:                        8  out of      8   100%  
Number of DCMs:                         3  out of      4    75%

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

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

Код

Design Summary
--------------
Number of errors:      0
Number of warnings:  438
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%
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
Total Number 4 input LUTs:          2,730 out of  15,360   17%
  Number used as logic:              2,541
  Number used as a route-thru:         176
  Number used as Shift registers:       13
  Number of bonded IOBs:               95 out of     221   42%
    IOB Flip Flops:                    13
    IOB Dual-Data Rate Flops:           6
  Number of Block RAMs:               13 out of      24   54%
  Number of GCLKs:                     8 out of       8  100%
  Number of DCMs:                      3 out of       4   75%

   Number of RPM macros:            1
Total equivalent gate count for design:  906,874
Additional JTAG gate count for IOBs:  4,560

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

Код

Design Summary
--------------
Number of errors:      0
Number of warnings:  438
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%
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
Total Number 4 input LUTs:          2,730 out of  15,360   17%
  Number used as logic:              2,541
  Number used as a route-thru:         176
  Number used as Shift registers:       13
  Number of bonded IOBs:               95 out of     221   42%
    IOB Flip Flops:                    13
    IOB Dual-Data Rate Flops:           6
  Number of Block RAMs:               13 out of      24   54%
  Number of GCLKs:                     8 out of       8  100%
  Number of DCMs:                      3 out of       4   75%

   Number of RPM macros:            1
Total equivalent gate count for design:  906,874
Additional JTAG gate count for IOBs:  4,560

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

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

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

Код

Could not find net(s) '*gmac_core/SYNC_TX_RESET_I/RESET_OUT*' in the design.

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

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

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

[Dimonira]

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

Код

  // Preserve clock names in back annotated netlist
  // synthesis attribute keep of rgmii_rx_clk_bufg is true;
  // synthesis attribute keep of not_rgmii_rx_clk_bufg is true;

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

Код

  wire       rgmii_rx_clk_bufg /* synthesis syn_keep=1 */;

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

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

Код

NET "ADDR<*>" OFFSET = IN 6500 ps BEFORE "HOST_CLK";

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

[Evil Archer]

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

[Dimonira]

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

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

Код

Level/      Design      Timing      Number      Run         NCD
Cost [ncd]  Score       Score       Unrouted    Time        Status
----------  ------      --------    --------    -----       ------------
H_H_8   *   302         0           0           01:21       Complete        
H_H_4   *   306         0           0           01:20       Complete        
H_H_2   *   307         0           0           01:23       Complete        
H_H_5   *   311         0           0           01:34       Complete        
H_H_1   *   340         0           0           01:29       Complete        
H_H_3   *   3317        454         0           03:24       Complete        
H_H_7   *   3320        530         0           02:37       Complete        
H_H_6   *   5321        688         0           03:49       Complete

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

Код

Level/      Design      Timing      Number      Run         NCD
Cost [ncd]  Score       Score       Unrouted    Time        Status
----------  ------      --------    --------    -----       ------------
H_H_8   *   271         0           0           02:49       Complete        
H_H_3   *   274         0           0           04:41       Complete        
H_H_1   *   294         0           0           01:31       Complete        
H_H_7   *   295         0           0           02:57       Complete        
H_H_4   *   298         0           0           01:41       Complete        
H_H_6   *   1283        308         0           02:08       Complete        
H_H_2   *   1292        306         0           03:19       Complete        
H_H_5   *   1308        306         0           02:31       Complete

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