ТЕМА:

Ynicky пишет: ...загрузочный монитор, с помощью которого можно было бы загружать программы через СОМ порт компьютера, не перезашивая конфигурацию. ...Загрузка программ происходит по аналогии с загрузкой BMP файлов в одном из проектов для марсохода...

Загрузочный монитор, это начальная программа (bootloader), зашитая в битстрим, с которой стартует SoC, и потом ждет данных из COM-порта? Или это аппаратный блок?

Загрузочный монитор, это начальная программа (bootloader), зашитая в битстрим, с которой стартует SoC, и потом ждет данных из COM-порта?

Именно так. Монитор находится в конце памяти, а программы грузятся с 0 адреса.
При выходе из программы, управление опять передается монитору.

Николай.

Ynicky пишет: При выходе из программы, управление опять передается монитору.

А если программа зависла (или просто надо прервать выполнение программы со стороны ПК)?
С аппаратным загрузчиком тоже проблемы, если нужно не только программы загружать, но и данные гонять ПК <--> ПЛИС... Думаю, меньше всего проблем будет, если сделать аппаратную обработку специальных управляющих последовательностей. Ресурсов займет немного - следить за 2-мя последовательными байтами, и управляющие удалять из потока. Тут важно выбрать управляющий символ, который реже всего встречается в потоках данных. Но ведь данные м/б самые разные... Ломаю голову, есть какое другое решение?

Тут одним управляющим байтом не обойтись.
Нужна преамбула, т.е. некая последовательность байтов.
Пример - запись во флеш память.

Николай.

Например, нужно реализовать несколько виртуальных последовательных каналов:
ПК <--> UART в ПЛИС <-->|
|<--> канал1, прямой доступ к памяти софт-ядра;
|<--> канал2, прямой доступ к EPCS;
|<--> канал3, программный обмен данными с софт-ядром;
|<--> ...
Управление каждым устройством - по индивидуальному протоколу, данные любые, и нужен _невидимый_ устройствам механизм переключения виртуальных каналов (со стороны ПК). Думаю так: 2х-байтовая управляющая последовательность, первый байт - ключ, второй - команда (переключение канала, и тд). Такие 2 байта вырезаются из потока, и в конечные устройства не попадают (либо попадает один байт-ключ, как обычный байт). В качестве ключа пока выбрал 0х79, такой байт очень редко встречается в сжатом битстриме Циклонов.

Простите что встреваю в разговор, но управляющие последовательности делаются легко - например, 0x1b это префикс. Любое вхождение 0x1b в потоке замещается на два 0x1b 0x1b (два вхождения), а любой другой байт после 0x1b будет означать управляющую команду.

alman пишет: ...Любое вхождение 0x1b в потоке замещается на два 0x1b 0x1b...

Это частный случай, причем неоптимальный, тк при некоторой выбранной системе команд 0x1b может оказаться внутри какой-либо подгруппы, и портить всю малину. Кроме того, распределение байт в потоке м/б неравномерным - вдруг конкретно выбранный префикс окажется самым частым символом в потоке данных...

Самым плохим случаем является поток состоящий из одних 0x1b - размер увеличится в два раза. При равномерном распределении +1/256

alman пишет: в два раза

Для рассмотренного выше случая - в четыре раза, тк конечные устройства тоже могут использовать тот-же префикс управления.

Ynicky пишет: Есть опыт в написании компилятора на основе LCC для 2-х процессоров.

Беглое ознакомление с LCC вызвало у меня подозрение, что он ориентирован только на регистровые архитектуры (с операциями типа Rdst += Rsrc), и не приспособлен для аккумуляторных (с операциями типа A += Rsrc, с отдельной командой сохранения Rdst=A). Это так, или ошибаюсь?
У меня тут вырисовывается аккумуляторный софт-процессор с 8-разрядными командами, и с АЛУ произвольной разрядности (не привязанной к разрядности команд). Для 16-разрядного получается ~200 ЛЕ. 1 такт на операции типа A += Rsrc, 2 такта на A += imm(Rsrc), 2 такта на условные переходы вида if(A>Rsrc)goto label, и тд. Проект будет открытым, если будет возможность сделать Си-компилятор.