juvf

Ну это понятно, я и говорю выходные. Например вот что есть в файле topLevel.map.rpt D:/Work/Quartus/testBoot/db/cmpr_ifc.tdf ; ; D:/Work/Quartus/testBoot/db/cntr_p1j.tdf ; yes ; Auto-Generated Megafunction ; D:/Work/Quartus/testBoot/db/cntr_p1j.tdf ; ; D:/Work/Quartus/testBoot/db/cmpr_efc.tdf ; yes ; Auto-Generated Megafunction ; D:/Work/Quartus/testBoot/db/cmpr_efc.tdf ; ; boot_rom.v ; yes ; Auto-Found Verilog HDL File ; boot_rom.v ; ; D:/Work/Quartus/testBoot/db/altsyncram_7gb1.tdf ; yes ; Auto-Generated Megafunction ; D:/Work/Quartus/testBoot/db/altsyncram_7gb1.tdf ; ; boot_rom.hex ; yes ; Auto-Found Memory Initialization File ; boot_rom.hex Кто-нибудь может из этого понять от куда ноги растут? От куда boot_rom берётся?

Конечно делал. Есть у меня такая строчка. Вот ещё что интересно - сделал поиск по всем файлам проекта текст "boot_rom.hex" .... вот что нашлось (см рис). В epcs_flash_controller.v нет boot_rom.hex, там найден epcs_flash_controller_boot_rom.hex *.rpt - это выходные отчеты. *.qmsg - тоже. Почему квартус их просит? ???

Первым делом туда полез Это я все понимаю. вот мои настройки ончипа. Но почему квартус просит файлы boot_rom.v и boot_rom.hex? Может, чтоб куартус забыл про boot_rom нужно сделать clearProject или rebuildAll? Но не могу такого найти в квартусе.

Да на кошках наверно с полпинка заведется. У меня тяжелый проект, которому нужно сделать ончип загрузчик. Можно сделать кошку и в неё заново проект собирать, все пины переназначать..... Но с этим нужно разобраться. В общем получилось. Как - не могу понять. В прицепе можно на этом остановиться и писать программу дальше. Но..... Сейчас в сопц ончип именуется onchip_memory2_0. Соответственно в проекте есть файл onchip_memory2_0.v и ниос иде делает onchip_memory2_0.hex который скармливаю в sof файл. удалил из проекта файлы boot_rom.v. Удалил с диска файлы boot_rom.v и boot_rom.hex. Но теперь другие ворнинги: Warning: Can't find design file boot_rom.v Warning: Can't find design file boot_rom.hex Не могу понять как в квартусе управлять проектом? Почему квартус ищет файлы boot_rom? Где-то в записях какихто исходников очевидно есть ссылки на них. Но где? Как ими управлять этими ссылками/настройками?

Обратно поставил галочку Use smart compilation - при компиляции снова получаю ворнинги Warning: Can't find design file epcs_flash_controller_boot_rom.hex Warning: Can't find design file onchip_memory2_0.hex Warning: Can't find design file epcs_flash_controller_boot_rom.hex Warning: Can't find design file onchip_memory2_0.hex Warning: Can't find design file epcs_flash_controller_boot_rom.hex Warning: Can't find design file onchip_memory2_0.hex Info: ******************************************************************* Info: Running Quartus II Analysis & Synthesis Info: Version 10.1 Build 197 01/19/2011 Service Pack 1 SJ Full Version Info: Processing started: Mon May 16 10:13:05 2011 Info: Command: quartus_map --read_settings_files=on --write_settings_files=off TestFrontEnd -c topLevel Info: Parallel compilation is enabled and will use 4 of the 4 processors detected Info: Found 1 design units, including 1 entities, in source file boot_rom.v Info: Found entity 1: boot_rom Info: Found 2 design units, including 2 entities, in source file sdram.v Info: Found entity 1: sdram_input_efifo_module Info: Found entity 2: sdram Info: Found 1 design units, including 1 entities, in source file pllsdram.v Info: Found entity 1: pllSdram Info: Found 2 design units, including 2 entities, in source file epcs_flash_controller_0.v Info: Found entity 1: epcs_flash_controller_0_sub Info: Found entity 2: epcs_flash_controller_0 Info: Found 1 design units, including 1 entities, in source file cpu_0_test_bench.v Info: Found entity 1: cpu_0_test_bench Info: Found 7 design units, including 7 entities, in source file uart_0.v Info: Found entity 1: uart_0_log_module Info: Found entity 2: uart_0_tx Info: Found entity 3: uart_0_rx_stimulus_source_character_source_rom_module Info: Found entity 4: uart_0_rx_stimulus_source Info: Found entity 5: uart_0_rx Info: Found entity 6: uart_0_regs Info: Found entity 7: uart_0 От куда этот onchip_memory2_0.hex? Почему квартус его хочет? в sopc билдере ончип раньше именовался onchip_memory2_0, но сейчас именуется boot_rom и инициализируется файлом по умолчанию boot_rom.hex. И при компиляции всегда компиляется весь проект. Поечему? Скомпилял проект, тут же нажал компилять - опять все по новой. А должен вроде смарт понять что не было изменений и не компилять ни чего. naliwator в моем выхлопе нет таких пунктов как у тебя Running Quartus II MIF/HEX Update тоже не понятно почему?

Это я обнаружил. В общем по умолчанию для ончип-а sopc билдер дал имя onchip_memory2_0. Начал урок по своему загрузчику из an458.pdf - переименовал ончип в boot_rom. Потом в квартусе при компиляции среди over 9000 ворнингов не сразу заметил что квартус пытается подцепить onchip_memory2_0.hex. Ни как не мог ему объяснить что теперь нужен boot_rom.hex. Стояла галка Use smart compilation. Снял её и квартус сразу понял что теперь нужен boot_rom.hex. Ну ещё был ворнинг что найден boot_rom.v в разработке, но этот файл не является файлом проекта. Ручками удалил из проекта onchip_memory2_0.v и добавил boot_rom.v. Ворнингов стало на пару меньше, но пока при ресете он чип не инится моим хексом(или хекс кривой). Хотя в инфо вроде все красиво: Info: Instantiated megafunction "cpuNew:inst3|boot_rom:the_boot_rom|altsyncram:the_altsyncram" with the following parameter: Info: Parameter "byte_size" = "8" Info: Parameter "init_file" = "boot_rom.hex" Info: Parameter "lpm_type" = "altsyncram" Info: Parameter "maximum_depth" = "9000" Info: Parameter "numwords_a" = "9000" Info: Parameter "operation_mode" = "SINGLE_PORT" Info: Parameter "outdata_reg_a" = "UNREGISTERED" Info: Parameter "ram_block_type" = "AUTO" Info: Parameter "read_during_write_mode_mixed_ports" = "DONT_CARE" Info: Parameter "width_a" = "32" Info: Parameter "width_byteena_a" = "4" Info: Parameter "widthad_a" = "14"

а в программе printf("hallo wrld") в jtag-uart. поэтому чтоб увидеть выхлоп нужно после заливки соф запустить терминал и нажать ресет. у меня уже проблема не с загрузчиком. Я уже забыл про него. Проблема локализовалась. Проблема в том, что: есть простая программа, хелловорд (или загрузчик, или тестер или мигание диодом - это уже не важно, просто программа). необходимо чтоб ресет был на ончипе и после ресета процессора выполнялась эта программа сразу, без всяких загрузок из флеш, т.е. она должна создаться в плисине при загрузке конфигурации. Не получается. вот это я пропустил. Но сделав компиляции всего проекта после создание хекс файла - непомогло. не запускается программа.

именно к ниосу. с него и начал. an458-ой до дыр перечитал. примеры от туда скачал - не работают они. нашел я как из ниоса делать 7-ой пункт. ??? не понял, а когда hex в ончип попадает? я думал что достаточно залить sof, и во время этой заливки hex подхватится.

Пробую свой загрузчик сделать по an458.pdf. Вроде все элементы танца сделал, всё залил - в итоге при включении борды моя прога не работает. Решил постепенно понять что к чему. Создал простой проект хелловорд. разместил все секции в ончип. ресет ниоса на epcs контроллер (на загрузчик по умолчанию). вектор прерыванию на ончип. все собрал, залил в борду. Работает, т.е. при включении в консоль выхлапывает халоворд. Теперь нужно чтоб этот халоворд был аппаратно вшит в ончип. Т.е. делаю следующее 1 в SOPC билдере вектор ресета на ончип 2 указываю ончип инициализировать файлом boot_rom.hex 3 собираю ниос 4 компилирую проект квартуса 5 генерирую в эклипсе bsp 6 собираю программу халловорд для этого проекта и получаю elf 7 в консоли выполняю "elf2hex name.elf --base=0x1810000 --end=0x181c9f --width=32 --create-lanes=0 boot_rom.hex" и получаю хекс файл. 8 из квартуса заливаю sof в плис 9 запускаю терминал 10 жму кнопку ресет на борде ожидаю увидеть Hallo World! в терминале после 10 по идее ресетится проц, а ресет прерывания на он чип. в ончипе программа хелловрд. но она почему-то не выполняется. прожег этот sof флэшпрограмматором в епцс, борду выкл\вкл\ресет - не помогает, тоже не вижу хэлловорда. что я делаю не так?

Нужно сделать тестовый проект для самопроверки устройства на плис. нужно проверить всю периферию на борде. В том числе и озу (ддр2). Для проверки озу есть алгоритмы которые стирают/пишут/читают каждую ячейку озу. Можно тестовую программу разместить в он-чип и проверить внешнее озу. Но проверка всей остальной периферии не влезит в он-чип. Как тут быть? В голову приходит 2 мысли: 1) разбить программу на 2 части. проверку озу разместить в он-чип. ресет прерывания на он-чип. После ресета из epcs автоматом загрузится конфигурация и кусок программы в ончип. Стартует программа в ончипе. Проверится озу. если все в порядке, то нужно программно из епцс исполняемый код загрузить в озу и сделать jmp ADR_RAM; или что-то подобное. Такое реально сделать с ниосом/CIII/квартусом/IDE NIOS? 2) не делить программу а сразу всю её залить в внешнее озу и от туда стартовать. там же проверить все озу. только как? как-то же подобное делается в тестах типа memTest86. Как в подобных утилитах проверяется озу? Ведь сам исполняемый код находится в этом же озу. Или во время теста мемТест копирует исполняемый код из одного места в другое чтоб проверить всё озу полностью? кто нибудь знает как memTest86 работает?

DE0

У меня CFI_FLASH_NAME, соответственно вызов делаю с именем CFI_FLASH_NAME. пробовал "/dev/cfi_flash" (из тогоже систем.аш) - тозе возвращает 0 выхлоп nios2-flash-programmer на картинке. Это нормальная работа флешки?

да уш не 3-4. А отслежывать перекрытие блоков..... Вызовов может и 3-4, но + к этому целый алгоритм мутить по отслежованию перекрытий. спасибо, все стало понятно. пока у меня новая проблема: alt_flash_open_dev(CFI_FLASH_0_NAME) возвращает 0. Если не правильно распинать флешку, неправильно подключить, или если её физически нет, но в ниосе есть контроллер cfi - то что вернёт alt_flash_open_dev? ноль? ps Есть у алтеры дока "HAL API Reference". В ней говорится о функциях open(), read(), write(), close(). В частности эта open(),,,,,,,, она работает (должна работать) с cfi flash?

Ну это от флеша к флешу. Есть флешки с побайтной записью. Ну и "считали блок->изменили часть данных->записали блок" это какой-то низкоуровневый алгоритм. Я и хочу с этим разобраться. В доках от альтеры написанно, что alt_write_flash() сотрет весь блок. Нужно заботится о том, чтоб не потерять данные. Также альтера предлагает alt_write_flash_block(), якобы в этой функции не надо об этом заботится. Да и вообще, коль есть апи, можно было и более высокоуровневую функцию сделать, типа write(адрессФлэш, указательИсточника, длинна). Причем если данные 1 байт, или данные перекрывают 3 блока (например 1/3 блока 8кб, 1 блок 8 кб и 100 байт из блока в 64 кб), то эта write должна сама сделать все низкоуровневые операции типа "считали блок->изменили часть данных->записали блок". Удевительно что в hal нет такой функции. придёться самому писать ((. Потом, тут есть регион и есть блок. Что такое регион я так и не понял. Что такое блок - понятно. Вся флеш разбита на блоки (по пдф), причем размер блоков разный. А вот что такое регион - ??? смотрю Alt_flash_types.h, структура typedef struct flash_region { int offset; int region_size; int number_of_blocks; int block_size; }flash_region; int region_size - размер региона. Что такое регион? Пока не понятно как работать с alt_flash_cfi_write? Есть у когонибудь демо проект с флешкой cfi? Поделитесь, заранее благодарен.

как же не думать? Вот из документации на апи, стр 6-21 как то не понятно, как эту флеш писать читать?

изночально нписал alt_write_flash(...); // пишу 1234 в адрес 0 alt_write_flash(...); // пишу 5678 в адрес 20 alt_read_flash(...); //читаю из адреса 0, получаю 0xffff alt_read_flash(...); //читаю из адреса 20, получаю то, что записал, т.е. 5678 такое чувство что вторая запись сначала стерла первую запись, а потом записала 5678.

Как писать/читать флешку CFI из ниоса? На борту DE0 стоит флешка. Собрал контроллер. в программе пробовал alt_write_flash() - при вызове второй раз это функции старые данные стираются. Нашел в доках, что эта функция стерает блок. Есть функция alt_write_flash_block() - но про ней мало что понятно. Есть ещё какие то загадочные alt_flash_cfi_init() alt_flash_cfi_read() ... Про них вообще ни чего не нашел. Чем отличаются alt_flash_cfi_write и alt_write_flash_block/ alt_write_flash? ps Вообще хотелось бы получить функцию типа write(alt_u32 addressInFlash, alt_u8 *source, alt_u32 length); Пока видется путь писать свою используя alt_write_flash_block/read/open/close, в которой проверять перекрытие границы блока. Но там адская функция получается. Ещё не понятно что такое регион? С чем его есть и для чего он нужен?

Пока нет. Функциональное и временное моделирование у меня заработало в модулсиме. Платы заказали. Пока плат живых нет. Про реальную работу ни чего сказать не могу. А почему нет? Мне ТЗ когда давали, мне сразу сказали чтоб я плис тактировал сигналом FRAME. В ПП на всякий случай кинул отдельный клок на плис, но думаю он не понадобится. Ни когда железные serdes не использовал. Ну и без FRAME ни как не засинхронизировать кадр.

В алтиуме никак. выравнивание Т-образных цепей делается через таинет-кастыль. я делал так: Например цепь А12. разбивал цепь в схеме на 3 цепи: A12 - на контроллер, A12_A, A12_B - на две микросхемы ОЗУ. Объеденял их с помощью tie net. После этого в редакторе ПП можно посмотреть длинну отдельно каждого плеча Т. Длинна дорожки от процессора до каждого чипа памяти считалась как длинна цепи А12+А12_А и А12+А12_В. :laughing: ps может в 10-ке появится нормальный способ. вычисляется длинна всех дорожек цепи с данным именем, например с А12. все плечи А12 и даже если есть кусочки дорожек, которые не имеют физического контакта с нужной дорожкой, но имеют имя цепи А12 - их длинна тоже прибавится. Более того если неакуратно разводить то может получится что некоторые фрагметы продублировались. На экране видно одну дорожку на слое Тор, но если кликнуть мышкой по дорожке, то редактор предложет выбрать одну из 10 дорожет проложенных под кликом, по одному месту. В длинну цепи войдет сумма всех длинн этих "скрытых" сегментов. А бывает, что дорожку подтянул к паду. Бросил. Визуально все красиво. Но на самом деле редактор ПП создал возле пада с десяток маленьких кусочков, которые взуально не увидеть. Сумма длин этих кусочков так же вольется в общую длинну цепи. Так что разводка с выравниванием длинн - это ювелирная работа. Нужно быть очень аккуратным.

Да, нашел. но не без Вашей помощи. :) стр 76 это глава "Создание бибилиотеки посадочных мест", стр 103 глава "Разработка электических принципиальных схем. : Настройка редактора схемы". Нужно быть либо телепатом, либо автором книги, чтоб найти упоминание про электрическую сетку редактора ПП в этих главах.

Спасибо, всё понятно. Владимир без труда в 2-х словах объяснил. Зачем вообще этот форум? Отослать всех к документации. :laughing: ps А где документация? В книге Сабунина про сетку и про Snap не нашел. В кноледж цэнтре.... не нашел, поиски в такие дебри завели, нашел интересное про Grid Manager и про Snap, но это только в 10-ке.

Shift+E не помогает. на скрине Ок настройки для старого проекта с нормальным притягиванием. На скрине isnotOk для нового проекта. Не могу найти отличия. ((

в редаторе ПП в старых проектах беру разъем мышкой..... мышка притягивается в центру ближайшего пада.... тащю.... подтаскиваю к отверстию.... курсор мышки вместе с центром пада прилипает к центру отверстия. Создал новый проект. Такого свойства в проекте нет. Как его включить. Могу мышкой взять за центр пада разъем, а установит его так, чтоб центр пада совпал с центром отверстия не получается, не прилипает. Где нужно галку поставить?

добрый день Создал плату. Потом решил поменять размер платы. Как это сделать? По книге Сабунина только 1 способ: удалить плату и создать заного с помощью визарда плат. А без визарда как поменять размер у текущей платы?

Да я не силен в *HDL. Ну придется попробовать, изучать. Я его не хочу полностью аппаратный. Функции буду обрабатывать программно. Мне от аппратной части нужен блок, в который проц запишит скорость уарта и адрес слэйва. В ответ получит прерывание, если пришел пакет для этого слэйва, без ошибок и crc совпал. По прерыванию проц дожен считать с блока по какойнить шине SDRAM данные, обработать их, загрузить ответ в блок и дёрнуть у этого блока сигнал "Start Transmit". как-то так... Меня пугает, что в этом блоке придется писать что-то типа своего UART FIFO. Хотя на opencores есть такой блок, но разбираться с ним и дорабатывать его до модбуса - тоже перспектива не радостная.