o_khavin

Ну Вы бы хоть почитали что-то для приличия по функционированию динамической памяти. А то Ваши эксперименты напоминают попытку понять работу функции random не читая документацию - исключительно по возвращаемым результатам.

У меня была ситуация, когда на одной МП работало, а на другой - нет. В итоге выяснилось, что во втором случае был слишком грязный клок в PCIe, а я его использовал для внутренней логики (через DCM). После пересадки этого DCM-а на генератор платы всё заработало. При этом сам PCIe блок в FPGA нормально работал на PCIe-клоке.

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

Абсолютно бессмысленное занятие. Да. Для этого придуманы группы. Эти примеры только подтверждают, что не нужно делать работу через нетрадиционное место, извините за прямоту. В переводе на простой язык Ваш начальный пост звучит так:

Возможно, что не посылается инфа для неиспользуемых кусков FPGA (BRAM-ы или блоки логики), если они занимают какое-то количество целых сегментов. Т.е. это не компрессия, а просто выкидывание пустых данных.

Во первых, post-PAR имеет смысл использовать только при возникновении проблем с реальным кристаллом. При корректно заданном и сходящемся тайминге, достаточно behavioral модели. В крайнем случае, post-synth на этапе финальной симуляции (перед заливкой в кристалл). Во вторых, для post-PAR нужно использовать нормальный симулятор, а не затычку от Xilinx-а. Кстати, всеми любимый ModelSim тоже лишь условно относится к "нормальным симуляторам", если речь идёт про post-PAR больших проектов. P.S. Ну да, разработка больших FPGA-проектов - это долго и дорого. А что Вы хотели? :) Да не, 60-кратная разница вполне возможна, особенно в недосимуляторе Xilinx-а.

Это просто грубый ориентир. Смотрите на частоту после P&R.

Всё ест LUTы, но почему бы не использовать некоторое количество на нужное дело?

Есть ещё такая штука - двух-портовая память на LLUT-ах. ;) Там никто не мешает сделать индивидуальный we для каждого разряда. Вроде в предыдущем сообщении шла речь про приоритет записи от процессора в случае коллизий и не было никаких упоминаний про обратную связь во внешний мир в случае этой коллизии. Рекомендую таки думать FPGA-примитивами, а не изобретать схемы, которые на этих примитивах не реализовать. :)

Если что, я не про 65000 строк писал, а про восемь. Но если это для Вас слишком просто - дело Ваше.

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

В таком варианте всё выглядит не так уж и плохо. Удачи в реализации. :)

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

Ну как бы есть такие последовательные конструкции как if ... else if ... else if... :1111493779:

Для синхронизации (помимо тактов) достаточно одного единственного синхросигнала который, к примеру, будет сбрасывать адресный счётчик всех модулей в нужное значение. Единственное условие - выравнивание этого сигнала с опорным клоком и между разными модулями. Так что этот пункт можно смело исключить. Начальная настройка и отладка совершенно не обязана пересекаться с чем то, окромя процессора. Ведь на самом процессоре можно сделать всё остальное взаимодействие между конфигурационным интерфейсом и прочими "устройствами" (речь тут про внутренности FPGA, а не про внешний мир в виде ARM-а). Т.е. этот пункт редуцируется до ещё одного "устройства" с точки зрения "процессора". Разница только в том, что внешняя от "процессора" сторона двух-портовой памяти (или блока регистров) тактируется чем то отдельным, что и обеспечивает асинхронность. Если для целей отладки нужно знать текущее состояние других "устройств" вокруг "процессора", то можно банально завести нужное число битовых флагов напрямую с этих "устройств", минуя "процессор". Как то так. :)