[Golikov 0]

Тут надо из далека.

 

Это система-модуль управления, управляет одним исполнительным устройством. Таких модулей в системе может быть разное количество с разной программой управления для каждого, в терминах (значение/время). То есть как бы "путь" разный и изменяемый, но при этом все устройства должны быть жестко синхронизированы между собой.

 

Раньше я решал это управлением несколькими устройствами с одной ПЛИС, но это мешало масштабировать систему. Теперь горожу отдельную систему ARM-FPGA-Модуль. На все системы заведен Ethernet как интерфейс с внешним миром а также общий синхронный сигнал 1 МГц. Идея заключается в том чтобы они делали одно и тоже по фронту этого сигнала, и тем самым синхронно выполняли свою работу, не зависимо от того сколько их в группе.

 

Для каждого можно прописать свою микропрограмму, и запустить. Вот такой расклад.

 

Собственно "процессор" или интерпритатор внутри будет выполнять программу по синхронным клокам. И вот тут на сцене появляются 2 интерфейса. Оба интерфейса от компьютера через АРМ в ПЛИС. Один интерфейс асинхронный относительно внешних модулей. Он служит для начальной настройки системы и диагностики ее во время работы. Второй интерфейс синхронный относительно внешних модулей, то есть данные по нему попадают в ПЛИС одновременно по дополнительному сигналу. Собственно он служит для запуска процессора, установка счетчика команд должна произойти синхронно, режимы работы должны меняться синхронно для всех модулей и так далее...

 

Без первого не настроить систему, если не будет синхроимпульсов. Без второго не обеспечить синхронную работу группы модулей. Оба нужны, и оба должны идти в регистры проца... как то так... Мысли, идеи, анализ, мнения все приветствуется, ибо я немного в растерянности...

[o_khavin 0]

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

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

Как то так. :)

Изменено 28 мая, 2014 пользователем o_khavin

[Golikov 0]

синхронность:

Было изначальное такое решение, с буферным регистром, типа по интерфейсу меняется значение асинхронно, потом дергается сигнал и регистр применяется. Но регистров много оказалось, там не только счетчик синхронно меняется, прочие регистры тоже должны уметь и не только в модуле процессора(внутри ПЛИС есть еще некоторые модули), потому в итоге нагородил синхронный интерфейс. Он принимает данные, проверяет контрольную сумму сообщает на базу что все хорошо мы готовы, а потом по внешнему сигналу выставляет RD WR стробы.

 

настройки, отладка:

через них еще планировал сделать также меж модульный обмен если вдруг приспичит. С этим не уверен, но вероятность есть. Этот интерфейс хорош тем что обмен заканчивается за 1 цикл, то есть запрос - ответ или таймаут, и в поток команд всегда можно вклиниться не разорвав никакую команду пополам. Потому тоже трудно им пожертвовать.

 

Скорее всего настройки действительно будут работать через как бы доп периферию. То есть будет заполняться 2 регистра с тем что сделать надо, а проц. в такте свой работы будет применять настройки, сообщать значения регистров, менять их. Потеряю немного в скорости и оперативности, но ничего не поделаешь.

 

Вот думаю возможно и первый интерфейс упаковать туда же.

То есть оба интерфейса будут обращаться в некий регистр, а по синхросигналу из вне, сначала будет обработать 1 интерфейс, потом 2 интерфейс, потом такт процессора. Это, наверное, самое удачное решение, даже отладка останется, достаточно будет приостановить процессор, и можно будет считать все регистры, не мгновенно. но можно...

[o_khavin 0]

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

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

[Golikov 0]

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

 

Это самое ужасное когда делаешь абстрактную универсальную вещь. Будет сделано куча лишнего, а что-то обязательно забудется. Я пытаюсь выполнить некое облако требований которые всплывали чаще всего, и знаю что 60% будет сделано лишних вещей, и очень много чего я не учту...

 

Пока что в целом все сложилось, в очередной раз. Если это влезет по ресурсам будет славно...

 

 

интерфейсы будут заведены на 2 регистра. Адрес и данные. И они будут только выставлять какие данные они хотят записать или считать и по какому адрсеу. Сам процесс чтения и записи будет синхронизирован с работой ядра проца, так обращение в во всю регистровую память будет из одного места. А модули будут висеть с другой стороны 2 портовок. Каждый модуль будет иметь свою 2 портовку, один порт к процу, другой к модулю и вроде как все будет типа хорошо.

 

Буду пробовать.

[o_khavin 0]

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

[Golikov 0]

Спасибо...

 

Ну теперь есть косяк с 2 портовой памятью.

 

1. с удивлением прочел вот что (это для spartan 6, память с общим клоком для обоих портов):

When one port performs a write operation, the write operation succeeds; the other

port can reliably read data from the same location if the write port is in READ_FIRST

mode. DATA_OUT on both ports will then reflect the previously stored data.

If the write port is in either WRITE_FIRST or in NO_CHANGE mode, then the

DATA_OUT on the read port would become invalid (unreliable). The mode setting of

the read-port does not affect this operation.

 

Получается в режиме WRITE_FIRST если писать в ячейку по одному порту, а по другому в этот же момент читать эту же ячейку, считается фигня?

 

2. Конфликт одновременной записи в одну ячейку надо тоже как-то разруливать? У меня возможна ситуация что проц и периферия захотят изменить один регистр, в этом случае проц должен быть просто приоритетней, но как это сделать для памяти? Сделать запись 2 тактовой? или городить какую-то логику запрета записи? Или сразу запустить память по 2 фронтам, порта А по одному, а порт Б по другому, как по уму то делают?

 

 

 

 

 

[o_khavin 0]

Получается в режиме WRITE_FIRST если писать в ячейку по одному порту, а по другому в этот же момент читать эту же ячейку, считается фигня?

 

Да. Используйте READ_FIRST - следующим тактом после записи, с выходного порта считается новое значение.

 

2. Конфликт одновременной записи в одну ячейку надо тоже как-то разруливать? У меня возможна ситуация что проц и периферия захотят изменить один регистр, в этом случае проц должен быть просто приоритетней, но как это сделать для памяти? Сделать запись 2 тактовой? или городить какую-то логику запрета записи? Или сразу запустить память по 2 фронтам, порта А по одному, а порт Б по другому, как по уму то делают?

 

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

 

[Golikov 0]

на самом деле куча проблем с этими БРАМАМИ, к регистрам битовый доступ флаги ставить невозможен... Не 1 тактовые чтения - запись необходимо городить защиту регистров, то есть периферия хочет изменить бит в регистре

1. читает регистр

2. изменяет

3. записывает обратно.

 

если в этот момент параллельно проц захочет изменить регистр, то получается косяк... надо расставлять флаги запретов изменения, чего то все сложнее и сложнее.... Что-то мне говорит что я не в ту сторону упираюсь, проще все как-то должно быть....

[o_khavin 0]

на самом деле куча проблем с этими БРАМАМИ, к регистрам битовый доступ флаги ставить невозможен... Не 1 тактовые чтения - запись необходимо городить защиту регистров, то есть периферия хочет изменить бит в регистре

1. читает регистр

2. изменяет

3. записывает обратно.

Есть ещё такая штука - двух-портовая память на LLUT-ах. ;) Там никто не мешает сделать индивидуальный we для каждого разряда.

 

если в этот момент параллельно проц захочет изменить регистр, то получается косяк... надо расставлять флаги запретов изменения, чего то все сложнее и сложнее.... Что-то мне говорит что я не в ту сторону упираюсь, проще все как-то должно быть....

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

Рекомендую таки думать FPGA-примитивами, а не изобретать схемы, которые на этих примитивах не реализовать. :)

[Golikov 0]

Есть ещё такая штука - двух-портовая память на LLUT-ах.

есть ага. Только проблема в том что она ест ЛУТы... которые пытался сэкономить...

 

 

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

 

есть регистр

его может изменить

1. периферия

2. проц

3. они одновременно, в это случае его меняет проц, а желание периферии игнорируется.

 

но это хорошо если все происходит за 1 такт.

 

А теперь получается что проц и периферия могут захотеть это одновременно, с разницей в 1 такт, а так как изменения не однотактовые, то может быть так

 

периферия взяла значение

в след такте проц его изменил

периферия добавила бит

периферия записала измененное значение обратно

 

в результате изменения проца затерты...

 

 

Нет это все очень неверно по архитектуре, надо все выкинуть и заново придумать.... Спасибо всем за участие...

[o_khavin 0]

есть ага. Только проблема в том что она ест ЛУТы... которые пытался сэкономить...

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

 

Нет это все очень неверно по архитектуре, надо все выкинуть и заново придумать.... Спасибо всем за участие...

[Golikov 0]

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

 

потому что синтезатор уже сказал что он потратил больше чем хочет, и типа начинает оптимизить, и схема по частоте слетать начинает...

 

это кстати интересный момент, после синтеза обычно объявляется частота на которую можно рассчитывать. Но после имплементации все меняется, так вот эта частота что после синтеза объявляется хоть какое значение имеет?

[iosifk 3]

А теперь получается что проц и периферия могут захотеть это одновременно, с разницей в 1 такт, а так как изменения не однотактовые, то может быть так

 

периферия взяла значение

в след такте проц его изменил

периферия добавила бит

периферия записала измененное значение обратно

 

в результате изменения проца затерты...

 

 

Нет это все очень неверно по архитектуре, надо все выкинуть и заново придумать.... Спасибо всем за участие...

Как только вспомните о запрете прерывания при вложенных прерываниях, то сразу успокоитесь...

Есть такая штука - арбитр, который предоставляет доступ к ресурсу. И пока кто-то получил доступ, то другому он закрыт...

 

[o_khavin 0]

Но после имплементации все меняется, так вот эта частота что после синтеза объявляется хоть какое значение имеет?

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