Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: LVDS DDR данные из АЦП в ПЛИС
Форум разработчиков электроники ELECTRONIX.ru > Программируемая логика ПЛИС (FPGA,CPLD, PLD) > Системы на ПЛИС - System on a Programmable Chip (SoPC)
Страницы: 1, 2
Golikov A.
Цитата
Подвигать фазу PLL скорее всего не получится, если не ошибаюсь, то клок был заведён на неправильную ногу

Ну тогда можно немного задержать данные, чтобы на клок успели.

У вас прописаны констрайны, за сколько данные до фронта клока должны стоять и сколько после? Это весьма полезные констрайны!
doom13
Цитата(Golikov A. @ Jul 7 2014, 23:22) *
Ну тогда можно немного задержать данные, чтобы на клок успели.

Да, но для каждой линии может быть своя задержка, подбирать каждую, не зная правильно ли подобраны все остальные (только по результату можем определить), будет сложновато.


Цитата(Ar-han @ Jul 7 2014, 17:32) *
Как мне лучше флаг заполнения памяти передать процессору? Сейчас его завожу на ногу внешнего прерывания. А как правильно? Тоже через корку какую делать обмен флагами?

Я так же делал, с приёмом данных сначала разберитесь, потом будете искать более оптимальные пути.
Ar-han
Цитата(Ar-han @ Jul 7 2014, 18:32) *
синус на входе


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

На входе синус, 2 МГц.
Нажмите для просмотра прикрепленного файла
Ar-han
Цитата(doom13 @ Jul 5 2014, 10:58) *
в варианте с двумя буферами памяти, которые переключаются поочереди чтение и запись независимы. Записывающая и вычитывающая стороны работают самостоятельно никак не оказывая влияния друг на друга.


Правильно ли я понимаю, что память с двумя буферами, это две одинаковые корки BRAM, с разными адресами, на одной шине (PLB) ?
Кстати, интересно, можно ли двухпортовую BRAM повесить на LMB шину? У меня, вроде бы, получалось, но были проблемы, и не удалось её корректно использовать.


Цитата(doom13 @ Jul 8 2014, 01:29) *
С приёмом данных сначала разберитесь, потом будете искать более оптимальные пути.

Приём данных, кажется, удалось победить.

Теперь вопрос по флагам, флаг процессору - по внешнему прерыванию. Ок. Это сделал. Измеренная wireshark -ом скорость получилась 2940 пакетов в сек по 1 кБайту.
Теперь как мне передать от процессора флаг, что память прочитана? Первое, что приходит в голову - это GPIO, но подозреваю, что это не оптимально.
Сейчас использую microblaze на частоте 100 Мгц, интересно, что даст повышение частоты?
Хочу перейти на powerPC, только не соображу как на PowerPC запустить UDP пакеты. Под PowerPC тестовое приложение с эхо сервером организовано через TCP протокол.
Насколько я понял, если сделать большие UDP пакеты, то lwip сама их разрежет, и отошлет кусками.
Но кажется, UDP не поддерживает нумерацию пакетов, значит, рассчитывать, что они склеятся на стороны компа не приходится. Значит самому нужно их резать кусками, нумеровать, и склеивать на компе?

Цитата(Golikov A. @ Jul 8 2014, 00:22) *
У вас прописаны констрайны, за сколько данные до фронта клока должны стоять и сколько после? Это весьма полезные констрайны!


Нет, не прописаны, буду рад подсказке, с констрейнами еще не успел разобраться.
Если, можно, ткните где почитать про констрейны.
Правильно ли я понимаю, что констрейны пишутся руками в UCF файле, рядом с распиновкой ног?
Где-то я слышал, что они удобно прописываются в PlanAhead, только с ходу не нашел.

У меня есть пример констрейна для входного сигнала:
Код
NET "CLOCK_110" TNM_NET = CLOCK_110;
TIMESPEC TS_CLOCK_110 = PERIOD "CLOCK_110" 110 MHz HIGH 50% INPUT_JITTER 100 ps;
OFFSET = IN 9.09091 ns VALID 9.09091 ns BEFORE "CLOCK_110" RISING;


Можно ли таким же образом указать ограничения на тактовый сигнал, который рождается после диф. приёмников - USER_CLK?
Из каких соображений выбирается JITTER ?

Код
     IBUFGDS_1 : IBUFGDS
        port map (I=>SMA_DIFF_CLK_IN_P,
               IB=>SMA_DIFF_CLK_IN_N,
               O=>USER_CLK);

   IBUFDS_6 : IBUFDS
      port map (I=>HDR2_64_SM_9_P,
                IB=>HDR2_62_SM_9_N,
                O=>DDR_6);
  
   IDDR_6 : IDDR    
      port map (C=>USER_CLK,
                CE=>VPP,
                D=>DDR_6,    
                R=>GRND,
                S=>GRND,
                Q1=>out12,
                Q2=>out13);


Спасибо!

Цитата(Ar-han @ Jul 8 2014, 11:07) *
Ура, всё заработало! Нашел еще одну дурацкую ошибку, пихал данные в память по совершенно другой частоте, не по той, на которой они защелкивались в диф. приемниках.

Только не понятно, откуда брался шум при отсутствии входного сигнала.
doom13
Цитата(Ar-han @ Jul 9 2014, 08:45) *
Правильно ли я понимаю, что память с двумя буферами, это две одинаковые корки BRAM, с разными адресами, на одной шине (PLB) ?

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


Цитата(Ar-han @ Jul 9 2014, 08:45) *
Приём данных, кажется, удалось победить.

Ну да, всё оказалось намного проще, чем я полагал.


Цитата(Ar-han @ Jul 9 2014, 08:45) *
Теперь как мне передать от процессора флаг, что память прочитана? Первое, что приходит в голову - это GPIO, но подозреваю, что это не оптимально.

Сделайте, как я советовал и никакого флага со стороны процессора не нужно, но можно и GPIO - что-то типа сброса запрета записи в память.
Golikov A.
Перейдите уже на FIFO в конце концов...
Брать 2 корки памяти, городить к их шине мультиплексор, да еще поддерживающий на одном из концов PLB или AXI шину, городить модуль переключения мультиплексора, ответный сигнал запрета записи в память.

Мне одному кажется это мраком?

Взяли FIFO, с одного конца АЦП пихает данные, с другого процессор их забирает. Нет никакой надобности следить заполнен первый буфер или второй, запрещать переключения и прочее... Появились данные на выходе, вычитали их и отправили. Пошли свои дела делать, вернулись опять поглядели, есть данные? считали и отправили. Все! Внутри FIFO будут те же блоки BRAM + весьма эффективная обвязка

UDP - если вы бирете большой пакет, больше чем лезет через сеть, стэк его порежет и отправить, на другом конце стэк его склеит и вернет. Пакет UDP придет либо целиком, либо не придет вообще. Отсутствие нумерации относится к тому что если вы пошлете 2 пакета UDP никто не знает как они придут и никто не гарантирует что они придут в той же последовательности как вы их отправляли, могут поменяться местами. Более того нет гарантии что один пакет не придет 2 раза (если потеряется что-то в обмене и отправляющий узел продублирует пакет).

То есть другими словами если вы хотите слать байтовый поток через UDP - вы обламаетесь, данные должны быть промаркированы внутри, иметь заголовки и прочую фигню. Если же хотите поток с гарантией отсутствия повторений и потерь, то это ТСР.





Цитата
Сейчас использую microblaze на частоте 100 Мгц, интересно, что даст повышение частоты?

трудности с разводкой и очевидно прирост производительности. Доступ микроблайза к данным AXI шины далеко не 1 такт. А доступ к акси-лайт ваще блокирующий. Так что обмен данными по шине - самый тормозящий момент работы микроблайза.

doom13
Цитата(Ar-han @ Jul 9 2014, 08:45) *
Насколько я понял, если сделать большие UDP пакеты, то lwip сама их разрежет, и отошлет кусками.
Но кажется, UDP не поддерживает нумерацию пакетов, значит, рассчитывать, что они склеятся на стороны компа не приходится. Значит самому нужно их резать кусками, нумеровать, и склеивать на компе?

Да, так и есть, если UDP пакет большой (больше порядка 1500 байт), то LwIP пошлёт его за несколько IP-фрагментов, wireshark-ом Вы увидите эти фрагменты, если написать приёмник в любой среде, то там всё склеится автоматом, указываете только длинну данных, которую передаёте. Правда, для LwIP чтоб заработала фрагментация мне пришлось добавить задержку в цикле, где и происходит разделение на фрагменты, без неё как-то криво работало, часть фрагментов терялось. Пример того, что нужно для отправки UDP:
CODE

void main()
{
unsigned char pucMACArray[8];

....

pucMACArray[0] = ((ulUser0 >> 0) & 0xff);
pucMACArray[1] = ((ulUser0 >> 8) & 0xff);
pucMACArray[2] = ((ulUser0 >> 16) & 0xff);
pucMACArray[3] = ((ulUser1 >> 0) & 0xff);
pucMACArray[4] = ((ulUser1 >> 8) & 0xff);
pucMACArray[5] = ((ulUser1 >> 16) & 0xff);

unsigned long board_ip = 0xC0A80110;
unsigned long net_mask = 0xFFFFFF00;

lwIPInit(pucMACArray, board_ip, net_mask, 0, IPADDR_USE_STATIC);

int i;
for(i = 0; i < 16384; i++)
{
buffer[i] = i;
}

// UDP

struct udp_pcb *pcb;
pcb = udp_new();

unsigned short port_rmt, port_local;
struct ip_addr ip_rmt, ip_local;

IP4_ADDR(&ip_rmt, 192, 168, 1, 66);
IP4_ADDR(&ip_local, 192, 168, 1, 16);
port_rmt = 12000;
port_local = 11000;

udp_bind(pcb, &ip_local, port_local);
udp_connect(pcb, &ip_rmt, port_rmt);


unsigned short len = 16384;
struct pbuf * pb;

int tx_en = 0;
err_t error = 55;

while(1)
{
if(tx_en)
{
pb = pbuf_alloc(PBUF_TRANSPORT, len, PBUF_RAM);
//memcpy(pb->payload, buffer, len);
pb->payload = buffer;
error = udp_send(pcb, pb);
pbuf_free(pb);
tx_en = 0;
}
}
}

Golikov A.
Цитата
У меня есть пример констрейна для входного сигнала:


ну вот и правильный констраин

Цитата
TIMESPEC TS_CLOCK_110 = PERIOD "CLOCK_110" 110 MHz HIGH 50% INPUT_JITTER 100 ps;


это говорит что фронты сигнала идут на частоте 110 МГц, 50% скважности и плавают на 100 пикосекунд. Откуда эти параметры? Не знаю, наверное какие то справочные данные. Главное что после разводки схема проверит все ли данные будут успевать вставать к фронтам (которые могут плавать на 100 пикосек).

и дополнительно проверит
Цитата
OFFSET = IN 9.09091 ns VALID 9.09091 ns BEFORE "CLOCK_110" RISING;

что за 9.09 наносек до восходящего фронта данные на входах будут готовы, и будут неизменны еще 9.09 наносек...

есть такой же OFFSET = OUT для выходных ножек.

Так же кроме BEFORE есть AFTER.

про констраины надо читать UG625 (не знаю может есть уже более свежие)


Смысл в том что вы должны по мануалу вашего АЦП описать когда у вас будут появляться данные на входных ножка относительно сигнала клок. И тогда разводя сигнал внутри ПЛИС синтезатор будет учитывать задержки распространения и понимать все ли данные верно доходят к моменту защелкивания или нет (пути то у всех разные), а также проверять хватает ли времени между фронтами.
doom13
Цитата(Ar-han @ Jul 9 2014, 08:45) *
Только не понятно, откуда брался шум при отсутствии входного сигнала.

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


Цитата(Golikov A. @ Jul 9 2014, 10:03) *
Брать 2 корки памяти, городить к их шине мультиплексор, да еще поддерживающий на одном из концов PLB или AXI шину, городить модуль переключения мультиплексора, ответный сигнал запрета записи в память.

Мультиплексор нужен только для шины данных, ничего сложного в этом нет, никакой модуль переключения мультиплексора не нужен.
Цитата(Golikov A. @ Jul 9 2014, 10:03) *
Мне одному кажется это мраком?

Вы так и не разобрались в предложенном варианте, просмотрите, что советовалось, ещё раз и это не будет мраком. Нормальный вариант решения поставленной задачи, единственный недостаток - двойной объём памяти для хранения текущего и предыдущего пакета, но для FIFO, думаю получится примерно также (если делать, чтоб ничего не переполнялось и не перезатиралось).
Цитата(Golikov A. @ Jul 9 2014, 10:03) *
Взяли FIFO, с одного конца АЦП пихает данные, с другого процессор их забирает. Нет никакой надобности следить заполнен первый буфер или второй, запрещать переключения и прочее... Появились данные на выходе, вычитали их и отправили. Пошли свои дела делать, вернулись опять поглядели, есть данные? считали и отправили. Все! Внутри FIFO будут те же блоки BRAM + весьма эффективная обвязка

Ещё раз разберитесь в предлагаемой реализации, а потом утверждайте в необходимости отслеживать заполненность буферов, "запрещать переключения и прочее..."


Цитата(Golikov A. @ Jul 9 2014, 10:03) *
UDP - если вы бирете большой пакет, больше чем лезет через сеть, стэк его порежет и отправить, на другом конце стэк его склеит и вернет. Пакет UDP придет либо целиком, либо не придет вообще. Отсутствие нумерации относится к тому что если вы пошлете 2 пакета UDP никто не знает как они придут и никто не гарантирует что они придут в той же последовательности как вы их отправляли, могут поменяться местами. Более того нет гарантии что один пакет не придет 2 раза (если потеряется что-то в обмене и отправляющий узел продублирует пакет).

Писал уже, если передача данных происходит не между континентами, то всё будет нормально с UDP даже при отправке фрагментированных IP-пакетов, никаких потерь и путаницы пакетов и фрагментов пакета не будет.

Цитата(Golikov A. @ Jul 9 2014, 10:03) *
То есть другими словами если вы хотите слать байтовый поток через UDP - вы обламаетесь, данные должны быть промаркированы внутри, иметь заголовки и прочую фигню. Если же хотите поток с гарантией отсутствия повторений и потерь, то это ТСР.

Не обломаетесь, всё будет работать. Под передачу данных от АЦП (более-менее скоростных) использовать TCP никто не будет.
Из собственного опыта - используется UDP, поток данных 655.36 Mbit/s, длина данных в UDP-пакете 32 kB, это всё отправляется с использованием фрагментации IP по 1024 байта в каждом фрагменте. Всё нормально работает без всяких потерь, есть проблемы с приёмом под Windows, но комп с Linux всё нормально принимает и обрабатывает.

Да, кстати, при реализации, для сбора данных с АЦП использовалась именно память с двойной буферизацией.
Golikov A.
У меня нет времени и желания разбираться в предложенном варианте по 2 причинам
1. Вариант понятен и прост, сделать его тяп ляп просто, сделать его правильно с защитой и диагностикой сложно
2. Я не вижу преимуществ этого вариант перед вариантом с FIFO, ни в реализации ни в использовании.

Также я хочу заметить что подход
Цитата
Из собственного опыта ... есть проблемы с приёмом под Windows, но комп с Linux всё нормально принимает и обрабатывает.

Весьма детский и непрофессиональный
Утверждения вида
Цитата
Писал уже, если передача данных происходит не между континентами, то всё будет нормально с UDP даже при отправке фрагментированных IP-пакетов, никаких потерь и путаницы пакетов и фрагментов пакета не будет.

Допустимы только на студенческих курсовых да и то претендующих на зачет не более...

Есть стандарт, в стандарте указано что гарантий нет, значит их нет! Если вы в одних идеальных условиях что-то проверили, и сегодня оно работает - это не дает вам права делать такие утверждения! Откуда вы знаете какие и где будут условия? По передавайте через вайфай на границе сигнала. Понаделают таких поделок, а потом у нас ракеты падают, говорят саботаж... Да я согласен - такой подход САБОТАЖ!

Простите, наболело... это на самом деле 0 и главная причина почему я не хочу разбираться в вашем варианте...

doom13
Цитата(Golikov A. @ Jul 9 2014, 12:05) *
У меня нет времени и желания разбираться в предложенном варианте по 2 причинам
1. Вариант понятен и прост, сделать его тяп ляп просто, сделать его правильно с защитой и диагностикой сложно
2. Я не вижу преимуществ этого вариант перед вариантом с FIFO, ни в реализации ни в использовании.

Так проще всего не разобравшись (стоило только более внимательно прочитать все предыдущие посты, чтобы понять - о чём идёт речь) сказать, что это "мрак". Оба варианта примерно одинаковы и просты в реализации, Вам нравится Ваш, мне - мой.

Цитата(Golikov A. @ Jul 9 2014, 12:05) *
Также я хочу заметить что подход
Цитата(doom13 @ Jul 9 2014, 10:52) *

Из собственного опыта .... есть проблемы с приёмом под Windows, но комп с Linux всё нормально принимает и обрабатывает.

Весьма детский и непрофессиональный

В чем собственно непрофессионализм - в использовании Linux? Вы сначала попробуйте принять примерный поток на ПК под управлением Windows - потом будете говорить о непрофессионализме.


Цитата(Golikov A. @ Jul 9 2014, 12:05) *
Утверждения вида
Цитата(doom13 @ Jul 9 2014, 10:52) *

Писал уже, если передача данных происходит не между континентами, то всё будет нормально с UDP даже при отправке фрагментированных IP-пакетов, никаких потерь и путаницы пакетов и фрагментов пакета не будет.

Допустимы только на студенческих курсовых да и то претендующих на зачет не более...

На данный момент никак не связан со студенческими курсовыми, поэтому не могу знать что именно может претендовать на зачёт и т.д., говорил только о том, что знаю и что работает в реальных системах. Это допустимо даже в очень нестуденческих проектах. Нет необходимости использования TCP для передачи данных от АЦП для дальнейшей обработки.

Цитата(Golikov A. @ Jul 9 2014, 12:05) *
Есть стандарт, в стандарте указано что гарантий нет, значит их нет! Если вы в одних идеальных условиях что-то проверили, и сегодня оно работает - это не дает вам права делать такие утверждения! Откуда вы знаете какие и где будут условия? По передавайте через вайфай на границе сигнала. Понаделают таких поделок, а потом у нас ракеты падают, говорят саботаж... Да я согласен - такой подход САБОТАЖ!

Если Вы так опираетесь на стандарт, с которым никто и не спорит, тогда посмотрите ещё и на длины соединений между отдельными узлами сети для которых этот стандарт выполняется, на прохождение данных через всевозможные сетевые устройства. Я точно могу сказать на каком расстоянии друг от друга находятся блоки системы (это не киллометры и даже не сотни метров), через какое количество коммутаторов должны пройти данные, могу проверить работоспособность системы, процент потери пакетов и на основании всего этого сделать заключение - UDP вполне подходит для данных целей.
Golikov A.
FIFO
1. Размер отправляемого пакета - любой задается через порог фифо не пусто. В любой момент можно изменить, даже на лету.
2. Число буферизуемых пакетов без потерь - ограничен только объемом памяти, число пакетов меняется на лету с их размером
3. Потери памяти (используемая физически, но не используемая для хранения данных) 0. Все пакеты лежат друг за другом байт в байт, выравнивания не требуется
4. Адрес чтения данных - один
5. Автомат управления адресом чтения - отсутствует

Вариант с 2 буферами
1. Размер отправляемого пакета - минимум ограничен заполняемостью буфера, если поставите 1 байт то оба буфера будут забиты. Второе ограничение ширина шины адреса, она определяет максимальную длину пакета
2. Число буферизуемых пакетов без потерь - 1. Чтобы их стало больше необходимо ставить еще блоки памяти. Усложнять мультиплексор выбор блока. На лету изменить с изменением размера пакета невозможно.
3. На каждый буфер вы используете один брам 18К, весь хвост 18К - размер пакета у вас не используется.
4. Адрес чтения пакета сменный, и зависит от размера пакета, с изменением размера пакета необходимо менять диапазон адресов
5. Необходим автомат управления адресом при чтении очередью, либо программные циклы с инкрементом

Достаточно или есть еще вопросы почему FIFO однозначно лучше? 2 буфера - решение для простоты, но если есть готовое FIFO надо брать его и использовать.


Цитата
В чем собственно непрофессионализм - в использовании Linux

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


Цитата
Это допустимо даже в очень нестуденческих проектах.

В очень не студенческих, но крайне плохих проектах. Проблема не в использовании UDP, проблема в неправильном его использовании. Кто мешает в UDP пакет вместе с данными положить заголовок с определяющий положение данных? Нет необходимости крутить тяжелый ТСР, но считать что UDP пакеты всегда будут идти друг за другом и никогда не потеряются - преступно!


Потому можете сколько угодно трясти готовыми проектами которые так работают. Я не изменю своего мнения. Проект построенный на таких допущениях - барахло!


doom13
Цитата(Golikov A. @ Jul 9 2014, 13:15) *
Нет, непрофессионализм - это на основе своего частного мнения и конечного числа экспериментов выдвигать нарушающие стандарт утверждения.

Вы, как всегда, не так поняли, я не выдвигал нарушающих стандарт утверждений, я всего лишь сказал, что для решения поставленной задачи UDP будет вполне достаточно и качество передачи данных будет достаточно надёжным. Сама система приёма/передачи данных реализовывалась с помощью советов знающих людей с данного форума (за что им и спасибо), которые уже проходили этот путь. Так что утверждать о субъективном мнении и ограниченном числе экспериментов не стоит.
Цитата(Golikov A. @ Jul 9 2014, 13:15) *
В очень не студенческих, но крайне плохих проектах. Проблема не в использовании UDP, проблема в неправильном его использовании. Кто мешает в UDP пакет вместе с данными положить заголовок с определяющий положение данных? Нет необходимости крутить тяжелый ТСР, но считать что UDP пакеты всегда будут идти друг за другом и никогда не потеряются - преступно!

Ваша оценка здесь неуместна, другие люди решают хорошо оно сделано или плохо. Заголовок для данных используется, но он не помогает восстановить данные, просто используется как информация о потере данных и всё.
Цитата(Golikov A. @ Jul 9 2014, 13:15) *
Потому можете сколько угодно трясти готовыми проектами которые так работают. Я не изменю своего мнения. Проект построенный на таких допущениях - барахло!

Про допущения я уже всё пояснил, читайте пожалуйста внимательней. Мне кажется, лучше "трясти" готовым, что работает и проверено, чем голословно без всякой проверки утверждать - всё очень плохо (замечал такое за Вами).
doom13
Цитата(Golikov A. @ Jul 9 2014, 13:15) *
FIFO
1. Размер отправляемого пакета - любой задается через порог фифо не пусто. В любой момент можно изменить, даже на лету.
Вариант с 2 буферами
1. Размер отправляемого пакета - минимум ограничен заполняемостью буфера, если поставите 1 байт то оба буфера будут забиты. Второе ограничение ширина шины адреса, она определяет максимальную длину пакета

Размер отправляемого пакета известен заранее, можно выбрать необходимый размер RAM или FIFO для хранения необходимого количества данных. Менять размер накапливаемых данных в сторону уменьшения возможно в обоих случаях,
в сторону увеличения везде столкнёмся с ограничением, которое задали при создании IP-ядра. Но в изменении длины накапливаемых данных и нет необходимости. По поводу того, что два буфера памяти могут заполниться одновременно,
объяснять Вам не буду, читайте выше. С шиной адреса тоже проблем не вижу, естественно, закладываем такую, чтоб обеспечить адресацию всех накопленных данных.
Цитата(Golikov A. @ Jul 9 2014, 13:15) *
FIFO
2. Число буферизуемых пакетов без потерь - ограничен только объемом памяти, число пакетов меняется на лету с их размером
Вариант с 2 буферами
2. Число буферизуемых пакетов без потерь - 1. Чтобы их стало больше необходимо ставить еще блоки памяти. Усложнять мультиплексор выбор блока. На лету изменить с изменением размера пакета невозможно.

Хранение/передачу данных в обоих случаях можно организовать без потерь, объяснять как Вам не буду, смотрите выше.
Цитата(Golikov A. @ Jul 9 2014, 13:15) *
FIFO
3. Потери памяти (используемая физически, но не используемая для хранения данных) 0. Все пакеты лежат друг за другом байт в байт, выравнивания не требуется
Вариант с 2 буферами
3. На каждый буфер вы используете один брам 18К, весь хвост 18К - размер пакета у вас не используется.

Что мешает выбрать оптимальный размер данных, чтобы и работать было удобно и память максимально эффективно использовалась, потери памяти были по нулям. Всё реализуемо.
Цитата(Golikov A. @ Jul 9 2014, 13:15) *
FIFO
4. Адрес чтения данных - один
Вариант с 2 буферами
4. Адрес чтения пакета сменный, и зависит от размера пакета, с изменением размера пакета необходимо менять диапазон адресов

Один раз выбирается длина данных с которой хотим работать и больше ничего менять не надо.
Цитата(Golikov A. @ Jul 9 2014, 13:15) *
FIFO
5. Автомат управления адресом чтения - отсутствует
Вариант с 2 буферами
5. Необходим автомат управления адресом при чтении очередью, либо программные циклы с инкрементом

Вы опять о чём-то своём. Говорим DMA адрес буфера данных и на этом наше участие в формировании адресов заканчивается, для FIFO DMA не инкреметирует адрес, для RAM - инкремитирует. Всё просто в обеих случаях.
Если процессор использовать то цикл чтения будет и для FIFO и для RAM, для вычитки RAM ещё можно memcpy использовать и тогда совсем никаких циклов не видно и адрес инкреметировать не нужно.
Цитата(Golikov A. @ Jul 9 2014, 13:15) *
Достаточно или есть еще вопросы почему FIFO однозначно лучше? 2 буфера - решение для простоты, но если есть готовое FIFO надо брать его и использовать.

Все Ваши доводы неубедительны.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.