[ecos-rtos.in.ua 0]

Возможна ли такая реализация (сильно не пинайте, я начинающий :) )

АЦП (10 бит, 105МГц)-> FPGA/CPLD (10бит 105Мгц->16 бит 65.625 МГц ) -> BF651 PPI?

[ecos-rtos.in.ua 0]

По ходу возник еще один вопрос

В документации читаю

Supports SDRAMs of 64 Mbit, 128 Mbit, 256 Mbit, and

512 Mbit with configurations of x4, x8, x16, and x32

• Supports up to 512 MB of SDRAM (128 MB in each bank)

• Each external bank is independently programmable in size

• Supports SDRAM page sizes of 1 kbyte, 2 kbyte, 4 kbyte, and 8

kbyte for 32-bit wide SDRAM banks and 512 byte, 1 kbyte, 2

kbyte, and 4 kbyte for 16-bit wide SDRAM banks.

• Supports four internal banks within the SDRAMs

Есть у меня 4 микросхемы V54C3256164vbt7 они с организацией 16М*16 8k refresh 4 banks.

Как я понял, 8k refresh -это page size?

Вроде бы подходит по параметрам, но есть отличие по page size для 16 битной памяти.

Можно ли подключить так как в документации (ADSP-BF561 Blackfin® Processor

Hardware Reference) на стр. 16-34? Заработает как 32 бит с 8k page size?

[bmf 0]

Есть у меня 4 микросхемы V54C3256164vbt7 они с организацией 16М*16 8k refresh 4 banks.

Как я понял, 8k refresh -это page size?

Здесь ошибочка. Размер страницы - это размер "column address" + поправка на разрядность.

например: column address 512(A0-A8) для 16 разрядной SDRAM - размер странийы 1K

[west 0]

Реализация возможна, но не понятно, что вы таким образом делаете. Пытаетесь передать данные с АЦП по PPI, а для того, чтобы хватило быстродействия PPI, вы решили скомпоновать данные в 16-тибитные слова ? В таком случае их ведь и распаковавать надо будет, на что потребуется некоторое процессорное время. Рекомендую сразу оценить его.

[fontp 0]

На AnalogDevice есть такая апликуха AN-813

 

"Interfacing High Speed ADC..."

Там по PPI принимают поток с приёмника AD6652 (ADC+DDC)

Выясняется, что PPI не очень подходит для широкополосных систем,

насчитали максимум 28 мгц (16 бит). Ввиду ограничений на тайминги PPI, и особенно для ВF561 и BF533 (1) (2)

[ecos-rtos.in.ua 0]

На AnalogDevice есть такая апликуха AN-813

 

"Interfacing High Speed ADC..."

Там по PPI принимают поток с приёмника AD6652 (ADC+DDC)

Выясняется, что PPI не очень подходит для широкополосных систем,

насчитали максимум 28 мгц (16 бит). Ввиду ограничений на тайминги PPI, и особенно для ВF561 и BF533 (1) (2)

А если подключить как memory-maped device? Какая при этом скорость достижима?

Изменено 7 августа, 2008 пользователем ecos-rtos_in_ua

[_pv 52]

А если подключить как memory-maped device? Какая при этом скорость достижима?

асинхронная шина 3-4 такта на 133МГц. медленнее чем ppi, но зато 32 разряда. вроде успевает, правда и ppi'ев у 561 тоже 2. и если их не жалко можно задействовать оба.

если очень хочется извращений и данных не сильно много (хватает внутренней памяти), то можно попробовать на FPGA изобразить для blackfin'a SDRAM и во внутренюю память blackfin может и успеет прочитать столько (тем более что у 561 шина 32 разрядная).

проще тогда напрямую из FPGA в SDRAM писать забрав на время у blackfina шину, а потом ему шину отдавать чтобы он спокойно вычитывал и обрабатывал.

 

а сколько всего данных принять надо?

 

На AnalogDevice есть такая апликуха AN-813

Выясняется, что PPI не очень подходит для широкополосных систем,

насчитали максимум 28 мгц (16 бит). Ввиду ограничений на тайминги PPI, и особенно для ВF561 и BF533

я не очень внимательно разглядывал данный appnote, но там скорость ppi, на сколько я понял, ограничивалась задержками внешней логики, которой они ppiclk и fsync добывали из того что выдаёт их ацп.

а если верить даташиту то ppiclk <= sclk/2, т.е. на 66МГц ppi работать обязан.

и если никакой другой активности на шине не будет, то и сразу во внешнюю SDRAM вроде бы должен успевать складывать.

а разобрать 2 16-ти разрядных слова в 3 10-ти разрядных можно и потом, т.к. судя по скоростям никакой обработки в реальном времени не планируется.

хотя с этим blackfin и в реальном времени наверное справится, однако, если сразу же преобразовать в поток 10бит х 105МГц, его будет сложнее пропихнуть во внешнюю память, т.к. тогда придется пропихивать 16бит на 105МГц, а не 16бит на 66МГц...

[fontp 0]

а если верить даташиту то ppiclk <= sclk/2, т.е. на 66МГц ppi работать обязан.

и если никакой другой активности на шине не будет, то и сразу во внешнюю SDRAM вроде бы должен успевать складывать.

 

На 66 мгц он работать обязан, если ему обеспечить времянки по дейташиту. Как он хочет, а не как выдаёт DDC (или АЦП). Т.е. буферизировав как-то данные и обеспечив комфортную работу PPI. Ограничения, действительно, у них возникают потому, что они делают прямое (или почти) подключение своих DDC к PPI без буферизации, используя CLOCK и фрейм синк DDC

 

Процессор обычно не используется для того чтобы устроить через него talk-tgrough, а используется для обработки. Понятно, что на 66 мгц он ничего особенно обрабатывать не сможет. В AN813 рассмотрена более реальная ситуация, когда входная частота АЦП и DDC (CLOCK DDC) высокая, а c выхода DDC на PPI поступает децимированый низкий поток. Но поскольку CLOCK для PPI вырабатывается напрямую из тактовай DDC/АЦП - входная частота АЦП для безглючной работы PPI оказывается ограничена 28 мгц.

 

Если данные буферизировать и выдавать как хочет PPI то можно получить и 66. Соответственно, если данные буферизировать в адресном пространстве BF с одним вэйт -стейтом, то тоже будет sclock/2

[ecos-rtos.in.ua 0]

Если данные буферизировать и выдавать как хочет PPI то можно получить и 66. Соответственно, если данные буферизировать в адресном пространстве BF с одним вэйт -стейтом, то тоже будет sclock/2

Попробую реализовать

А нельзя ли в какой-то программе промоделировать разные варианты до реализации в железе?

[Z0Rk 0]

насчитали максимум 28 мгц (16 бит). Ввиду ограничений на тайминги PPI, и особенно для ВF561 и BF533

эт надо еще постараться... с кривыми руками получится меньше, у меня например 12-14МГц :)

 

ecos-rtos_in_ua

а че за сигнал то такой, с полосой под 50МГц? :07: раскажи задачу может все проще решается

Изменено 14 августа, 2008 пользователем Z0Rk