Jump to content

    

GAYVER

Свой
  • Content Count

    181
  • Joined

  • Last visited

Community Reputation

0 Обычный

About GAYVER

  • Rank
    Частый гость

Старые поля

  • skype
    Array

Контакты

  • Сайт
    Array
  • ICQ
    Array

Recent Profile Visitors

1960 profile views
  1. upd вместе с опытным системщиком пришли к выводу что эти выбросы дает фильтр, стоящий на плате между ДДС и ПЛИС
  2. вроде тема по смыслу в эту ветку подходит. если нет - перенесите. ситуация - в системник на ПСИ вставляется плата с плисиной. плисина периодически стучится в память в ДМА режиме. передача идет пакетами по 64 данных. в процессе передачи периодически происходит дисконнект "цели". не задержка в выделении шины по запросу, а именно "дисконнект с данными" в процессе передачи пакета. собственно вопрос - почему и куда копать? есть предположение что это более приоритетное системное устройство стучится в шину и арбитр нас отключает. но это только гипотеза. как работает арбитр - пока понятия не имеем. как и в целом за тонкости организации ПСИ :). пока только начали разбираться
  3. Нет, коллеги не с времянками столкнулись. Они работали через профили. При старте системы контроллер заполнял все настроечные регистры (в том числе и регистры профилей) через последовательный интерфейс. Потом в процессе работы нужный профиль выбирали через отдельные пины ДДСки. И параллельный интерфейс и режим модуляции с параллельного порта - это разные вещи, не связанные между собой никак. Кроме того что используют параллельный порт
  4. Они не связаны. По крайней мере логически. PARALLEL PORT TIMING это про режим доступа к внутренним регистрам х00-1В (CFR1? CFR2, итд). При этом с параллельной шины используется только часть бит (адрес/данные/стробы). А параллельная модуляция - все биты параллельной шины идут напрямую в регистры ядра - амплитуды-частоты-фазы. Не совсем понял что тут имеется в виду под плавностью. В свете первого предложения - то что по параллельной шине идет несколько передач (1 значение - 2 или 4 передачи, в зависимости от настройки) с новым значением, но применяются они не когда будет принято последнее, а после окончания каждой передачи?
  5. не знаю. сегодня попробую закинуть счетчик. правда не соображу что это может дать... на амплитуду подаются значения масштабного коэффициента относительно максимального значения этой самой амплитуды. под него отводится 12 бит. если давать счетчик, начиная с минимального значения, то в скольки знаках от запятой будут изменения? отследить... это ж какая должна быть развертка на осциле, чтобы визульно увидеть переход )). хотя... выведу стробы на моменты переключения и от них засинхрюсь
  6. Стоит задача запустить модуляцию с параллельного порта на данной ДДСке. Она управляется с ПЛИСины. Контроллер в ПЛИСине на старте заполняет настроечные регистры и регистры ядра - амплитуды-частоты-фазы. Частота 756МГц, фаза нулевая, а амплитуда в процессе работы изменялась - через параллельный порт насовывались то синусоида, то ступенчатые переключения. и в процессе работы появляются периодические тычки. Допустим на границе 2 соседних уровней амплитуды - плавное, на несколько периодов, увеличение амплитуды ВЫШЕ уровня, на который переключаемся, и такое же плавное опускание до этого нового уровня (см. рис). Тычки появляются не на каждом переключении. На синусоиде тоже бывают подобные выбросы посреди синусоиды. Появление от прошивки к прошивке в разных местах (в разные моменты переключения). Но в пределах одной прошивки стабильно в одном и том же месте (на синусоиде - в одном месте в рамках периода, на ступенчатом переключении - на одних и тех же переходах) собственно вопрос - что это, и как с этим бороться? зы при работе с профилями, в данной ДДСке, старшие товарищи столкнулись с тем, что в момент переключения профиля (выставление кода профиля на 4 пина), ДДСка переключалась с лагом. Допустим был выставлен код "0011". ДДСка сначала видела его как "0010", переключалсь на 2 профиль и только потом добегал нулевой бит и код воспринимался как "0011". Т.е. имел место некий рассинхрон бит на шине. Собственно мое предположение касательно параллельной шины был такое же - имеет место разбежка бит. В момент переключения где то в старших разрядах приходят единицы от нового значения, наслаиваются на старое и дают выброс, который больше нового значения. Которое, в свою очередь, больше чем было старое. На следующем такте шина выравнивается, на ней стабильное новое значение и диаграмма приходит в соответствие новому значению. Только не совсем понятно - почему изменение плавное, на несколько периодов несущей... ззы опора ДДСки 2ГГц, соответственно внутренняя рабочая частота - опора/16 - 125Мгц. ДДСка настроена на работу по фронту рабочей частоты (а не по ИО_апдейт). Т.е. значения с шины передаются в регистры на каждом такте
  7. это понятно что mcs это не mb 11.0. но хотя бы направление поиска задано. может быть в очередном ПГ наткнусь и на требования к чистому МБ. ну или в даташите на него дочитаюсь до нужной строчки. а пока метод научного тыка показывает что и в чистом МБ есть аналог ИО_модуля, в котором что-то жестко прописано
  8. вы оказались правы. в ПГ116 (MicroBlaze MCS v3.0) был такой пунктик: I/O ModuleThe I/O Module core is a light-weight implementation of a set of standard I/O functions commonly used in a MicroBlaze processor sub-system. Detailed information about the I/O Module core can be found in the I/O Module Product Guide (PG111) [Ref 5]. The I/O Module core registers are mapped at address 0x80000000, and the I/O Bus is mapped at address 0xC0000000-0xFFFFFFFF in the MicroBlaze memory space. The fixed I/O Module parameter values can be found in Table 4-3. Получил запрос на аксёвой шине, сейчас буду подгонять адреса. Спасибо за заданное направление поиска :)
  9. поставил адрес 0xA000_0000, результат тот же - запрос идет на LMB. а где можно посмотреть за выделяемые диапазоны? насколько я помню оговаривалось только что есть кэшируемая и не кэшируемая области. причем без конкретики - что с какого адреса начинается
  10. Микроблейз из тестового примера был добавлен в бОльший проект. Для связи с нашими местными акси устройствами наружу с интерконнекта был вытащен один мастер инфтерфейс, который замаплен на адрес 0x20000000. Задача - достучаться до внешней памяти через этот интерфейс. В сишную тестовую программу вставил команду чтения с этого адреса (адрес взят как дефайн базового адреса этого мастер интерфеса из "xparameters.h"). Результат - на выходе микроблейза появляется чтение по этому адресу ("внешнее" акси) но не на порту акси-данных, а на порту внутренней памяти, висящей на LMB шине. При этом, несмотря на несовпадение адресов, стоящий внутри блока памяти декодера-"маскировщика" и в целом вылета адреса за доступный диапазон памяти данных микроблейза, ответ оттуда приходит #include "xparameters.h" //Библиотека с параметрами IP-блоков #include "xgpio.h" //Библиотека с функциями GPIO #include "xil_io.h" #include "xil_testio.h" XGpio gpio; //Создаем "программную" модель GPIO int main(){ u32 i = 0; //используем для задержки u32 led = 0; //состояние светодиода u32 pr=XPAR_M02_AXI_0_BASEADDR; //+0x10000000 u32 pr2; u32 cons=6; int err=3; XGpio_Initialize(&gpio, XPAR_GPIO_0_DEVICE_ID);//Находим и инициализируем GPIO xil_printf("Hello, world!!!");//Автоматически цепляется Uartlite и выводит сообщение err=Xil_TestIO32(XPAR_M02_AXI_0_BASEADDR, 4, cons, 0, 0); while(1==1){ //Бесконечный цикл мигания i++; //увеличиваем счётчик if(i == 1000){//Если достигнуто значение 1_000_000 led = !led;//Инвертируем состояние светодиода i = 0;//Сбрасываем сётчик XGpio_DiscreteWrite(&gpio, 1, led);//Записываем состояние светодиода в GPIO pr2=Xil_In32(pr); pr=pr+4; //xil_printf(pr2); } } return 0; } Плюс еще запользовал команду тестирования ввода-вывода. Результат тот же - вместо внешнего акси запросы уходят на внутреннюю память данных. Вопрос - где я не прав?
  11. вопросы вроде задал - как отдебажить С-код без платы, почему не идет моделирование. цели - научиться работать с МБ. статья шикарна - более подробных и четких описаний я еще не видел. косяк в том, что HW часть и так не проблема, а SW часть не вполне соответствует исходным задачам
  12. делаю пример по описанию. ввиду полного отсутствия понимания принципов работы сдк, софт часть выполнялась в режиме обезьяны. платы для отладки нет. после всех манипуляций надо запустить моделирование. собственно вопрос - как правильно портировать назад в виваду все для этого необходимое? как я понимаю это должен быть элф-файл, в котором будет лежать все что нужно, включая содержимое внутренней памяти (подключенной по ЛМВ). сейчас при запуске моделирования из вивады, в памяти микроблейза лежит одна константа по нулевому адресу. сам микроблейз шарашит по кругу чтение инструкций по адресам 0-4-8. поиском по папке проекта находится несколкьо элф-файлов . из папки .sdk: Section Data: .vectors.reset [00000000] 00 00 00 b0 50 00 08 b8 .vectors.sw_exception [00000000] 00 00 00 b0 00 0e 08 b8 .vectors.interrupt [00000000] 00 00 00 b0 ac 11 08 b8 .vectors.hw_exception [00000000] 00 00 00 b0 7c 03 08 b8 .text [00000000] 00 00 00 b0 60 23 a0 31 00 00 00 b0 b8 20 40 30 [00000010] 00 00 00 b0 78 2f 20 30 00 00 00 b0 60 02 f4 b9 [00000020] 00 00 00 80 00 00 00 b0 6c 04 f4 b9 00 00 a3 30 [00000030] 00 00 00 b8 00 00 00 b0 60 23 a0 30 00 00 00 b0 .init [00000000] f0 ff 21 30 00 08 e0 d9 ff ff 60 31 02 c8 0b 94 [00000010] 00 00 60 31 00 c8 0b 94 ff ff 00 b0 50 e6 f4 b9 [00000020] 00 00 00 80 ff ff 00 b0 d0 f1 f4 b9 00 00 00 80 [00000030] 00 08 e0 c9 08 00 0f b6 10 00 21 30 .fini [00000000] f0 ff 21 30 00 08 e0 d9 ff ff 00 b0 44 e5 f4 b9 [00000010] 00 00 00 80 00 08 e0 c9 08 00 0f b6 10 00 21 30 .ctors [00000000] ff ff ff ff 00 00 00 00 .dtors [00000000] ff ff ff ff 00 00 00 00 .rodata [00000000] 48 65 6c 6c 6f 2c 20 77 6f 72 6c 64 21 21 21 0a [00000010] 0d 00 00 00 78 67 70 69 6f 2e 63 00 78 67 70 69 [00000020] 6f 5f 73 69 6e 69 74 2e 63 00 00 00 30 31 32 33 [00000030] 34 35 36 37 38 39 41 42 43 44 45 46 00 00 00 00 .data [00000000] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [00000010] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [00000020] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [00000030] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .sdata .sbss .debug_frame [00000000] 0c 00 00 00 ff ff ff ff 03 00 01 7f 0f 0c 01 00 [00000010] 24 00 00 00 00 00 00 00 5c 0e 00 00 24 01 00 00 [00000020] 04 04 00 00 00 0e 28 04 08 00 00 00 8f 28 93 04 [00000030] 04 04 00 00 00 0d 13 00 .debug_info [00000000] 48 0a 00 00 04 00 00 00 00 00 04 01 54 aa 00 00 [00000010] 0c 58 8e 00 00 79 76 00 00 00 00 00 00 00 00 00 [00000020] 00 00 00 00 00 00 00 00 00 02 01 06 ce c0 00 00 [00000030] 02 01 08 87 1d 00 00 02 02 05 76 53 00 00 02 02 .debug_abbrev [00000000] 01 11 01 25 0e 13 0b 03 0e 1b 0e 55 17 11 01 10 [00000010] 17 99 42 17 00 00 02 24 00 0b 0b 3e 0b 03 0e 00 [00000020] 00 03 16 00 03 0e 3a 0b 3b 0b 39 0b 49 13 00 00 [00000030] 04 24 00 0b 0b 3e 0b 03 08 00 00 05 16 00 03 08 .debug_aranges [00000000] 1c 00 00 00 02 00 00 00 00 00 04 00 00 00 00 00 [00000010] 5c 0e 00 00 24 01 00 00 00 00 00 00 00 00 00 00 [00000020] 1c 00 00 00 02 00 4c 0a 00 00 04 00 00 00 00 00 [00000030] 80 03 00 00 a8 00 00 00 00 00 00 00 00 00 00 00 .debug_ranges [00000000] 5c 0e 00 00 80 0f 00 00 00 00 00 00 00 00 00 00 .debug_macro [00000000] 04 00 02 00 00 00 00 07 c5 01 00 00 03 00 01 03 [00000010] 01 0c 07 4d 08 00 00 04 03 02 0b 05 7a 5c 2c 00 [00000020] 00 03 82 01 04 05 36 66 81 00 00 03 3c 0d 03 09 [00000030] 0e 05 0a 0f 62 00 00 03 0c 02 05 06 2e ad 00 00 .debug_line [00000000] 5b 04 00 00 04 00 d3 03 00 00 01 01 01 f6 f2 0d [00000010] 00 01 01 01 01 00 00 00 01 00 00 01 2e 2e 2f 2e [00000020] 2e 2f 6d 69 63 72 6f 62 6c 61 7a 65 5f 6c 65 73 [00000030] 73 6f 6e 5f 31 5f 62 73 70 2f 6d 69 63 72 6f 62 .debug_str [00000000] 5f 6f 6e 5f 65 78 69 74 5f 61 72 67 73 5f 70 74 [00000010] 72 00 58 50 41 52 5f 4d 49 43 52 4f 42 4c 41 5a [00000020] 45 5f 4d 5f 41 58 49 5f 44 43 5f 45 58 43 4c 55 [00000030] 53 49 56 45 5f 41 43 43 45 53 53 20 30 00 49 6e .symtab [00000000] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [00000010] 00 00 00 00 00 00 00 00 00 00 00 00 03 00 01 00 [00000020] 00 00 00 00 08 00 00 00 00 00 00 00 03 00 02 00 [00000030] 00 00 00 00 10 00 00 00 00 00 00 00 03 00 03 00 .strtab [00000000] 00 64 3a 2f 77 6f 72 6b 2f 73 6f 66 74 2f 76 69 [00000010] 76 61 64 6f 2f 32 30 31 39 2e 31 2f 73 64 6b 2f [00000020] 32 30 31 39 2e 31 2f 67 6e 75 2f 6d 69 63 72 6f [00000030] 62 6c 61 7a 65 2f 6e 74 2f 62 69 6e 2f 2e 2e 2f .shstrtab [00000000] 00 2e 73 79 6d 74 61 62 00 2e 73 74 72 74 61 62 [00000010] 00 2e 73 68 73 74 72 74 61 62 00 2e 76 65 63 74 [00000020] 6f 72 73 2e 72 65 73 65 74 00 2e 76 65 63 74 6f [00000030] 72 73 2e 73 77 5f 65 78 63 65 70 74 69 6f 6e 00 Segment Data: Segment # 0 [00000000] 00 00 00 b0 50 00 08 b8 00 00 00 b0 00 0e 08 b8 [00000010] 00 00 00 b0 ac 11 08 b8 00 00 00 00 00 00 00 00 [00000020] 00 00 00 b0 7c 03 08 b8 Segment # 1 [00000000] 00 00 00 b0 60 23 a0 31 00 00 00 b0 b8 20 40 30 [00000010] 00 00 00 b0 78 2f 20 30 00 00 00 b0 60 02 f4 b9 [00000020] 00 00 00 80 00 00 00 b0 6c 04 f4 b9 00 00 a3 30 [00000030] 00 00 00 b8 00 00 00 b0 60 23 a0 30 00 00 00 b0 Segment # 2 [00000000] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [00000010] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [00000020] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [00000030] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 из папки .src: Section Data: .boot [00000000] 00 00 00 b8 .text .data .shstrtab [00000000] 00 2e 73 79 6d 74 61 62 00 2e 73 74 72 74 61 62 [00000010] 00 2e 73 68 73 74 72 74 61 62 00 2e 62 6f 6f 74 [00000020] 00 2e 74 65 78 74 00 2e 64 61 74 61 00 2e 62 73 [00000030] 73 00 .symtab [00000000] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [00000010] 00 00 00 00 00 00 00 00 00 00 00 00 03 00 01 00 [00000020] 00 00 00 00 00 00 00 00 00 00 00 00 03 00 02 00 [00000030] 00 00 00 00 00 00 00 00 00 00 00 00 03 00 03 00 .strtab [00000000] 00 5f 62 6f 6f 74 00 Segment Data: Segment # 0 Segment # 1 Segment # 2 [00000000] 00 00 00 b8 собственно при моделировании по нулевому адресу в памяти лежит только значение "b8000000", остальное нули и как я понимаю - подсосался не тот файл... зы есть ли в природе русскоязычные обучалки по СДК? сейчас стоит вопрос по последовательности действий при дебаге без платы, и интересно посмотреть на сишный код, сконвертированный в команды микроблейза
  13. 1 - в каком конкретно разделе обозначена связь RLAST-RVALID-RREADY? конкретно по тактам - "этот сигнал может выставляться раньше/позже этого сигнала" или "должны выставляться одновременно", итд. я не нашел. 2 - оба модуля - ИП ядра хилинха, что исключает какую-либо МОЮ вольную трактовку
  14. Поэтому при соединении интерконнекта и мастеров-слэйвов, соответствующие входы/выходы этого канала были заземлены. Неопределенку рожает сам интерконнект. От транзакции к транзакции в пределах одного слэйва, при этом, он переходит. Влиять на арбитраж, повторюсь, BRESP не должен был. И пока меня эта неопределенка не касалась, и все функционировало как и должно было - я в нее не влазил :). Сейчас буду ковырять - кто ее там делает... зы таки да, тупанул - надо было сразу делать все как надо, а не постепенно наращивая функционал, по мере отладки предыдущего ззы еще было замечено интересное в связке интерконнект/конвертер протокола акси лайт (хилинховые корки). В качестве слэйва для интерконнекта выступает конвертер, за которым стоит конЕчный слэйв. В последней передаче по чтению, конвертер выставляет сначала RLAST, и на следующем такте данные и RVALID. А интерконнект заканчивает передачу увидев RLAST. И то ли интерконнект не ловит связку RLAST=1 && RVALID=1, то ли конвертер не одновременно их выставляет... Кто некорректно работает - не понятно. В спецификации не вспомню явных требований на этот счет
  15. Какая разница отвечает или нет слэйв, если ни в мастере ни в слэйве не предусмотрена эта логика. И при заданных настройках интерконнект должен только ретранслировать его, никак не обрабатывая - арбитраж происходит по каналу адреса, и канал ответа в нем участия принимать не должен Спецификация разделяет мастер/слэйв интерфейсы. Хилинх дает определения мастер/слэйв интрфейсам интерконнекта, мастер/слэйв слотам, итд