Jump to content

    

SDRAM, арбитраж

В ПЛИС поступают данные от внешнего устройства, ПЛИС должна записать эти данные в SDRAM и при определённом событии выставить прерывание внешниму процессору, который через регистры ПЛИС должен считать эти данные из SDRAM. По сути поступление данных ы ПЛИС и чтение их-же процессором - асинхронные события и надо как-то организовать арбитраж SDRAM, чтобы и поступающие данные не потерялись, и процессор считал все хранящиеся данные. ПЛИС лежит в адресном пространстве процессора, а SDRAM - нет. С SDRAM общается только ПЛИС. Может есть типовые решения или примеры? Я что-то не додумался.

Share this post


Link to post
Share on other sites

Так организуйте для входного потока FIFO на борту FPGA - самое что ни на есть стандартное решение.

Share this post


Link to post
Share on other sites
Может есть типовые решения или примеры? Я что-то не додумался.

вы до чего именно не додумались? в чём именно вопрос? по какому интерфейсу ПЛИС подключена к процессору (если у этого интерфейса есть линяя прерываний, то ПЛИС просто выставит флаг по готовности данных, если нет, то назначьте какой-нибудь регистр или адрес в пространстве адресов проца ответственным за сигнализацию и осуществляйте поллинг периодически)

кстати, вы веткой немного ошиблись - нужно было в "область применения ПЛИС" постить

Share this post


Link to post
Share on other sites
вы до чего именно не додумались? в чём именно вопрос? по какому интерфейсу ПЛИС подключена к процессору (если у этого интерфейса есть линяя прерываний, то ПЛИС просто выставит флаг по готовности данных, если нет, то назначьте какой-нибудь регистр или адрес в пространстве адресов проца ответственным за сигнализацию и осуществляйте поллинг периодически)

кстати, вы веткой немного ошиблись - нужно было в "область применения ПЛИС" постить

За замечание по ветке спасибо, учту :)

А проблема такая, видимо в предыдущем посте я не достаточно пролно её описал, ПЛИС выставит прерывание процессору, а тот, в свою очередь, будет должен считать данные из SDRAM, последовательно читая регистр ПЛИС, НО данные то от другого устройства не перестанут поступать, и их надо тоже писать в SDRAM. SDRAM - не 2-х портовая память, по-этому и надо делать какой-то арбитраж между записью и чтением. Я вот и спрашиваю про типовое решение подобной проблемы, по-тому, что не знаю как это делается.

Share this post


Link to post
Share on other sites

Вы бы озвучили, для большей ясности скорости поступления и выдачи данных относительно частоты работы памяти. А то получается обсуждение сферического коня в вакууме. Как данные идут в процессор, непрерывно или пакетами, если пакетами, то какого размера? Может он равен или кратен блоку данных с которым работает память в burst-режиме.

Вообще, по идее, все сводится к двум фифо - один на запись в память, второй - на чтение. В итоге со стороны источника данных и процессора, как приемника данных, Ваша СДРАМ будет выглядеть как банальная двух-портовая память.

Share this post


Link to post
Share on other sites
Вы бы озвучили, для большей ясности скорости поступления и выдачи данных относительно частоты работы памяти. А то получается обсуждение сферического коня в вакууме. Как данные идут в процессор, непрерывно или пакетами, если пакетами, то какого размера? Может он равен или кратен блоку данных с которым работает память в burst-режиме.

Вообще, по идее, все сводится к двум фифо - один на запись в память, второй - на чтение. В итоге со стороны источника данных и процессора, как приемника данных, Ваша СДРАМ будет выглядеть как банальная двух-портовая память.

Частота FPGA - 50 МГц, частота SDRAM - 100 МГц, данные на FPGA приходят от камеры с частотой 25 МГц, прерывание на процессор будет возникать при наличии в SDRAM хотябы одного полного кадра. Всего максимальное количество кадров 3, после чего FPGA перестаёт делать захват кадров пока не вычитается хотябы 1 накопленный кадр.

Share this post


Link to post
Share on other sites

думаю какого-то особого стандартного решения искать здесь смысла нет, потому что вопрос не слишком мудрёный. само собой, что помимо 2 ведущих контроллеров шины камеры и процессора и контроллера СДРАМ нужен коммутатор 2 канала к одному с определённой дисциплиной облуживания соответствующей вашему ТЗ (там, чтоб не читал, то чего ещё не было записано, не писал то чего не было прочитано и общением по протоколу прикладного уровня; вообще вся задача общения с процом выходит на прикладной уровень:(для проца) не дали почитать память, залезь в регистр и посмотри почему, обратитесь через некоторое время; задача коммутатора, делать разрешать делать, что можно, и сообщать в регистры, о том что делать нельзя; задача при данной постановки условий достаточно широко-творческая, думаю лучше спрашивать конкретнее; кстати вы так и не ответили, что за протоколы используются - со стороны камеры я так понимаю CameraLink, а со стороны проца?)

кстати, по стандартным решениям можно обратиться и в раздел пониже - там как раз любители корок обитают, только всёже с более конкретной постановкой задачи

Share this post


Link to post
Share on other sites
В ПЛИС поступают данные от внешнего устройства, ПЛИС должна записать эти данные в SDRAM и при определённом событии выставить прерывание внешниму процессору, который через регистры ПЛИС должен считать эти данные из SDRAM. По сути поступление данных ы ПЛИС и чтение их-же процессором - асинхронные события и надо как-то организовать арбитраж SDRAM, чтобы и поступающие данные не потерялись, и процессор считал все хранящиеся данные. ПЛИС лежит в адресном пространстве процессора, а SDRAM - нет. С SDRAM общается только ПЛИС. Может есть типовые решения или примеры? Я что-то не додумался.

 

что тут думать то, SDRAM на самый широкий burst (именно burst а не full page access), контроллеры пишут/читают именно этими бурстами + Round-Robin-Arbiter (RRA) на 3 порта который не рвет burst транзакции. 3 ий порт удобно будет использовать для непрерываемого Refresh. Можно сделать подобное и с full-page access, но в этом случае размер буферов потребуется сделать больше, но теоретически вы получите больший процент утилизации полосы.

 

Контроллер в этом случае можно делать очень простым act-write/read-nops-pre.

Share this post


Link to post
Share on other sites
думаю какого-то особого стандартного решения искать здесь смысла нет, потому что вопрос не слишком мудрёный. само собой, что помимо 2 ведущих контроллеров шины камеры и процессора и контроллера СДРАМ нужен коммутатор 2 канала к одному с определённой дисциплиной облуживания соответствующей вашему ТЗ (там, чтоб не читал, то чего ещё не было записано, не писал то чего не было прочитано и общением по протоколу прикладного уровня; вообще вся задача общения с процом выходит на прикладной уровень:(для проца) не дали почитать память, залезь в регистр и посмотри почему, обратитесь через некоторое время; задача коммутатора, делать разрешать делать, что можно, и сообщать в регистры, о том что делать нельзя; задача при данной постановки условий достаточно широко-творческая, думаю лучше спрашивать конкретнее; кстати вы так и не ответили, что за протоколы используются - со стороны камеры я так понимаю CameraLink, а со стороны проца?)

кстати, по стандартным решениям можно обратиться и в раздел пониже - там как раз любители корок обитают, только всёже с более конкретной постановкой задачи

Нет, не Camera Link, просто 8 бит данных, вертикальная и горизонтальная синхронизация и клок. А со стороны проца это просто внешняя SRAM.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this