[des00 25]

И еще проще берем пикоблейз и ставим из штук 100.

 

что есть пикоблейзер? и почему не проще делить в ДСП сразу?

 

http://www.xilinx.com/ipcenter/processor_c...r_resources.htm

[snedelko 0]

Раньше было 6 датчиков. Стояло 3 кодека AD73322(по два АЦП/ЦАП в каждом). У кодеков есть последовательный интерфейс SPORT. Они были каскадно включены(выход первого-->вход второго и т.д.). Последний кодек подключен к ДСП(ADSP2185), у которого тоже есть SPORT.

Я щас думаю, можно ли организовать что-то типа этого SPORT на ПЛИС.

А Ваши советы по делению я буду переваривать, трудно сходу(новичек).

 

P.S. Устройство делал не я, по-этому еще плохо ориентируюсь и путаюсь в задаче.

[Golikov 0]

Раньше было 6 датчиков. Стояло 3 кодека AD73322(по два АЦП/ЦАП в каждом). У кодеков есть последовательный интерфейс SPORT. Они были каскадно включены(выход первого-->вход второго и т.д.). Последний кодек подключен к ДСП(ADSP2185), у которого тоже есть SPORT.

Я щас думаю, можно ли организовать что-то типа этого SPORT на ПЛИС.

А Ваши советы по делению я буду переваривать, трудно сходу(новичек).

 

P.S. Устройство делал не я, по-этому еще плохо ориентируюсь и путаюсь в задаче.

 

Эм...

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

Далее эти микрухи, в вашем случае, я так понимаю просто АЦП. Значит точно не могли на выход выдавать действительные числа, поэтому уточняйте форматы, подбирайте частоты и можно будет даже умудрится все реализовать так, что вообще не придется менять программу ДСП, то есть ДСП даже не поймет что к нему теперь подключена ПЛИС и датчики не аналоговые... Хотя шим цифровым сигналом я бы не назвал:)…

[snedelko 0]

Звучит обнадеживающе. Единственное, о чем я еще даже не имею представления, так это как ДСП определит где какой датчик, еще почитаю, надеюсь найду ответ.

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

[Golikov 0]

Звучит обнадеживающе. Единственное, о чем я еще даже не имею представления, так это как ДСП определит где какой датчик, еще почитаю, надеюсь найду ответ.

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

 

 

когда то мне на подобные вопросы сказали боже мой какой ты зеленый...

 

 

Смысл такой.

 

Про АЦП...

АЦП всегда требуется рефернц, то напряжение с каким будет сравниваться входное (преобразуемое) напряжение. Ваша микруха имеет встроенный рефернц 3 или 5 вольт (выбирается), допустим вы работает на 3. И у вас допустим не полярный режим (то есть вы не можете мерить отрицательное напряжение). тогда ваша АЦП может измерять сигнал от 0 до 3 вольт. АЦП является 16 битной, значит сигнал у нее от 0 до 2^16-1=65535. Если вы на вход подадите сигнал 1.5 вольта, то на выходе АЦП будет код == Vin/Vref*Code, где Vin - сигнал на входе, Vref - референц, Code - максимальный код выдаваемый АЦП что в вашем случае 1.5/3*65535=32767 (АЦП не выдает действительные числа). Это общий принцип аналогов цифрового преобразования. Если АЦП полярные то они соответственно работают от -Vref до +Vref, что соответствует цифровому коду -2^(n-1) ... 2^(n-1)-1 , где n разрядность АЦП.

 

Про то как ДСП понимает с кем говорит

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

 

При каскадном соединении ваши микрухи получая слова смотрят на адрес в них, если он 0, то считают что это обращаются к ним, если там не ноль, то они этот адрес уменьшают на 1 и передают дальше по цепочке. Таким образом, если Адрес == 2 то его получит третья микросхема в цепочке, первая сделает из него 1 и передаст второй, вторая сделает 0 и передаст третей, третья уже среагирует и обработает команду. Вот так ДСП всегда знает с кем говорит, посылая адреса 2 1 0, он обращается к 3 2 и 1 микросхеме. А указывая еще канал который его интересует, ДСП всегда знает датчик который он опрашивает.

 

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

 

Если вы хотите обмануть ДСП и не менять программы в нем, то вам надо будет в плис реализовать правильную реакцию на все входящие командные слова, за одним исключением, вам не надо реализовывать каскадность, можно обрабатывать адрес сразу, хотя ПЛИС и позволяет сделать один блок, точную копию и каскадно их соединить.

 

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

[snedelko 0]

Да...прочитав слова КОНЕЧНЫЙ АВТОМАТ, я понял, что без переделки проги ДСП не обойтись.

Проще наверно на ПЛИСе сделать какой-нибудь мультиплексор, чтоб ДСП указывал адрес(разряда 4), а ПЛИСа в это время выдавала ему сигнал с НУЖНОГО датчика.

[Golikov 0]

Да...прочитав слова КОНЕЧНЫЙ АВТОМАТ, я понял, что без переделки проги ДСП не обойтись.

Проще наверно на ПЛИСе сделать какой-нибудь мультиплексор, чтоб ДСП указывал адрес(разряда 4), а ПЛИСа в это время выдавала ему сигнал с НУЖНОГО датчика.

 

естественно, причем еще проще если это будет не последовательная а параллельная шина, хотя реализаций последовательных интерфейсов и так как грязи. Я бы кинул 3-4 ножки плис на шину адреса ДСП, и на чип селект, а еще 16 или сколько надо ножек на шину данных. И тогда внутри ДСП надо будет просто читать и писать по нужному адресу, просто командой загрузить данные по адресу или Data=*pointer в С, и все. Просто и сердито:)...

 

 

К слову преобразование параллельный - последовательный интерфейс тоже конечный автомат).

[snedelko 0]

На первый взгляд, с выходом ПЛИС разобрались. А вот с делением - так тут идея с подбором клока, что как я понял превратит деление/умножение в обычный сдвиг, мне понравилась.

[Golikov 0]

На первый взгляд, с выходом ПЛИС разобрались. А вот с делением - так тут идея с подбором клока, что как я понял превратит деление/умножение в обычный сдвиг, мне понравилась.

 

 

любое деление превращается в умножение на обратное, что певращается в сдвиг, но это целочисленное деление и будет страдать точность, нужен проц хотябы с фиксированной точностью. А с подбором частоты это я про то что сейчас у вас сигнал 0-9000, а хорошо бы 0-8192, так удобнее, но деление не пропадет...

 

 

идея состоит в том что 1 и 0.01 можно превратить в 100 и 1, то есть как бы сразу считать что у вас все на 100 умножено.

[Golikov 0]

Что-то я быстро писал, и сейчас понял что не особенно понятно да и немного ошибся.

Еще раз.

Вам требуется иметь вычисления в действительных числах. Для этого можно использовать float IEEE754, но это достаточно геморно реализовать в ПЛИС, да и смысла не имеет. Можно использовать не плавающую, а фиксированную точку.

У вас число записано всегда как целое, но вы для себя решаете что допустим 3 последних разряда - это у вас десятичная часть.

то есть допустим 1000 == 1.000, 1001=1.001 и так далее. Это легко реализовать, но для бинарной по принципу системы лучше умножать не на 1000, а на степень двойки. то есть на 1024.

 

У вас период ШИМ получился 9000 тактов, что не есть степень двойки, вот я и говорю хорошо бы подобрать частоту так, чтобы была степень двойки. Это нужно вот для чего

 

у вас как следует из формулы диапазон числе -12.5 до 12.5, что в кодах ненормируя показание датчика от -4500 до 4500, то есть сейчас у вас на единицу показания приходится 360 кодов. Если вы захотите полученный сигнал сравнить допустим с 6, вы можете либо код полученный разделить на 360, либо что тоже самое для результат 6 умножить на 360, а умножать на 360 как вы понимаете не удобно, хотя встроенные умножители и могут. А вот если бы на единицу приходилось бы 256 кодов (степень двойки), то есть диапазон был бы -3200 до +3200 или -6400 до 6400, то умножать надо было бы на 256 или 512 соответственно, что делать очень просто и без умножителя. Подобрав частоту так чтобы период ШИМа стал 6400 или 12800, вы легко обойдетесь без деления, просто помножив все ваши пороги, с которыми вы сравниваете или числа, с которыми проводите операции, на 256 или 512, вот к чему я это все.

 

Понятно, что это для счета с точностью 1, если надо считать с точностью 0.1, то и полученный код с датчика и пороги надо умножить еще на 10, ну или как мы говорили на 8 или 16, на степень двойки, и так далее. Заменяя нормировочное деление умножением, что почти всегда работает быстрее. Вот надеюсь теперь понятно о чем я...

Изменено 10 мая, 2006 пользователем Golikov A.

[snedelko 0]

Понятно, что числа степени двойки для ПЛИС как бальзам на душу.

Когда я делал свой диплом на ПЛИС, то умножение я реализовывал в подпрограмме(суммировал в цикле). Также делал и деление(правда по модулю). Так вот получилось ~71000 LUTS. Диплом то стерпит, а вот реальный проект врядли.

[snedelko 0]

Скажите еще пожалуйста, как поступать с числами integer. Я так понял что грамотнее оперировать с STD_LOGIC_VECTOR. Это из-за того, что последний имеет больше "состояний"?

[Golikov 0]

Понятно, что числа степени двойки для ПЛИС как бальзам на душу.

Когда я делал свой диплом на ПЛИС, то умножение я реализовывал в подпрограмме(суммировал в цикле). Также делал и деление(правда по модулю). Так вот получилось ~71000 LUTS. Диплом то стерпит, а вот реальный проект врядли.

 

особенно учитывая отсутствие циклов в плисах:)...

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

Изменено 11 мая, 2006 пользователем Golikov A.

[Golikov 0]

Скажите еще пожалуйста, как поступать с числами integer. Я так понял что грамотнее оперировать с STD_LOGIC_VECTOR. Это из-за того, что последний имеет больше "состояний"?

 

я в этом не гуро, но!

стд_логик_вестор - это просто набор битов, причем фиксированной вами длинной.

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

 

коренное отличие 3 битного инта от 3 битного стд_логик_вектора

что для стд_логик_вектора по умолчанию 100 - это 4,

а для инта это -4

соответственно

111 - это для стд_логик_вектора 7

а для инта это -1.

 

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

 

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

Изменено 11 мая, 2006 пользователем Golikov A.

[andrew_b 15]

коренное отличие 3 битного инта от 3 битного стд_логик_вектора

что для стд_логик_вектора по умолчанию 100 - это 4,

а для инта это -4

соответственно

111 - это для стд_логик_вектора 7

а для инта это -1.

Это не совсем так. std_logic_vector --- это просто массив бит. Все дело в его интерпетации. Интерпетация как знаковое число в двоично-дополнительном коде --- одна из возможных.