RobFPGA

Какой именно адрес по которому вы читаете? И каков тип и размер читаемого?

В таком случае вы больше времени потратите на Ethernet начинку чем на PCIe.

Проблема в том что в доках на ILA пишут "... тактирование ILA должно быть тем же клоком что и клок на котором генерируются сигналы которые вы хотите увидеть" ...

Конфигурация параметров сети для HW стека (кроме стандартных DHCP, ARP) может быть выполнена разными способами как с использованием сторонних каналов, так и чисто по сети, например магическим пакетом с удалённого PC на жёстко заданный адрес. И для этого совсем необязательно имеет MB в железке.

На уровне стека выше PHY все одно что 1G что 100M.

А с другой стороны городить целый soft-CPU вместо пары-тройки простых автоматов. UDP с сопутствующими сервисами (ARP, ICMP) поднимается в HW несложно. Причём сложность и ресурсы зависит в основном от на сколько правильно и полно вы хотите все это делать. Для примера реализации можно посмотреть на стек у Аlex Forencich, где все сделано по классике, с чётким разделением по уровням стека.

В ISE IMPACT есть JTAG debugger с визуальной катринкой состояний автомата TAP. Позволяет в ручном режиме посылать команды и отлаживать JTAG цепочку.

А это еще смешнее ...

Смешно читать такие фантазии на инженерном форуме ...

Данные могут быть переписанны до/в момент установки SS=0. Можно вообще не переносить данные в выходной регистр для сдвига, а напрямую муксить на выход SPI из регистра в системном клоке.

Да нормально все - передача идет на клоке SPI

Понятие "правильно" относитльно, зависит от конкретных условий вашей системы, напримеро от соотношения Fsys/Fspi. В общем случае SPI можно делать по 3 схемам 1. Делаем логику приема/передачи на системном клоке, входы SPI синхронизируем (CDC) на системный клок (простой вариант, для соотношения Fsys/Fspi > ~3 ) 2. Делаем логику приема/передачи на клоке SPI, на системный клок синхронизируем (CDC) уже принятые данные (вариант сложнее, для соотношений Fsys/Fspi < ~3) 3. Микс - предача и прием на на разных клоках Handshake based CDC так и работает - через классический битовый CDC на 2-3 регистрах вы передаете признак того что на стороне записи данные записанны и стабильны чтобы без проблем с метастабильностью считать их на стороне чтения. Как бы третье противоречит первому ...

А что вы сможите выбросить из PCIe? PHY Layer? - так он должен рулить трансиверами. Data Link Layer? - так он отвечает за - обеспечение надежности передачи данных, поток данных, переупорядочение пакетов, управление и исправление ошибок ... Transport Layer? - так без него нет различных типов пакетов (Configuration, Memory, IO, Read/Write, Message), адресации и роутинга в PCIe, ... Application Layer? - так его в Hard PCIe и нет, но его вам его все одно придется писать (как и выше перечисленное) чтобы рулить каждым из этих "много NvME дисков"

Тогда чем вы будете формировать протокол PCIe для управления этими "много NvME дисков"? Много Soft PCIe в недорогом чипе? ... Да и "довольно много" трансиверов в "недорогих чипах" это как то странно. Если уж нашелся такой "недорогой чип" с десятком-другим трансиверов то тогда не NvME а обычные SATA лучше уж подключвать. А для "много NvME дисков" проще использовать готовый недорогой PCIe свитч.

А смысл такого неправильного "бутерброда"? NvME по любому подключается к трансиверам (со стороны serial), а вот с другой строны трансиверов (parallel) что вы предполагаете ставить вместо PCIe?