en-valb
-
Постов
91 -
Зарегистрирован
-
Посещение
Сообщения, опубликованные en-valb
-
-
30 minutes ago, Yuri124 said:
Думаю, можно подсказать, какой действительно фронт нужно брать для анализа - через set_multicycle... Или покрутить фазу.
set_multicycle_path -end -from {get_clocks {inst|altpll|sd1|pll7|clk[0]}} -to {get_clocks {inst|altpll|sd1|pll7|clk[1]}} -setup 2
-
3 hours ago, Yuri124 said:23 hours ago, en-valb said:
с Data Required Path темный лес
Вот тоже - долго думал над Вашей диаграммой. Физический смысл этого раздела понятен, но минусовые числа в столбце Incr (Инкремент) - непонятны. Или это из-за какой-то ошибки в sdc - выглядит так, как будто идет путь не "вперед" от точки возникновения клока, а "назад"...
Да я думаю, что он анализирует предыдущие данные, а Latch берет текущий.
-
После того как я попытался добавить в sdc create_generated_clock для SDRAM_CLK, TimeQuest высыпал слаками. Судя по диаграмме когда я передвинул Latch на +30 deg (0,833 нс) это было не правильно, странно конечно, что я не увидел слаков тогда.
-
Опубликовано · Изменено пользователем en-valb · Пожаловаться
Забыл обновленный sdc вложить.
В нем пока нет create_generated_clock для SDRAM_CLK
-
18 minutes ago, Yuri124 said:
clk1 - это выход клока из блока PLL на его выходе, я правильно понял?
Да, правильно.
-
Обконстрейнил все, что можно, появились вопросы:
1. Что делать с tdi, tms и tdo?
2. Что делать с SDRAM_CLK это ведь по сути clk1 в проекте, может сгенерировать клок SDRAM_CLK из clk1 с помощью create_generated_clock и переписать все констрейны set_input_delay и set_output_delay заменив {inst|altpll|sd1|pll7|clk[1]} на SDRAM_CLK?
3. Еще он пишет, что необконстрейнин один клок.
Но ведь это же не клок, на просторах интернета есть где то информация, что это quartus ошибается и в следующих версиях Quartus баг будет исправлен. Что с ним делать сейчас, погасить через set_false_path или как то по другому????
-
1 hour ago, en-valb said:
т.е. мне необходимо поставить Latch слева от слака, левее Output Delay?
Сработало, в PLL на clk1 изменил сдвиг фазы вместо -60 deg поставил +30 deg (0,833 нс) перекомпилировал слаки исчезли!!! Буду дальше разбираться с set_input_delay и set_output_delay
-
Опубликовано · Изменено пользователем en-valb · Пожаловаться
Убрал из sdc set_clock_groups. Скомпилировал.
Для анализа выбрал первый слак SDRAM_WE. Во вложении диаграмма слака из TimeQuest.
На вкладке Data Path с Data Arrival Path разобрался у Дениса это хорошо расписано, но вот с Data Required Path темный лес могу предположить что -5,134 это задержка клока Latch (clk1), и она все портит, т.е. мне необходимо поставить Latch слева от слака, левее Output Delay?
-
19 minutes ago, Yuri124 said:55 minutes ago, en-valb said:
TimeQuest до этого брал в качестве Launch clk0 а в качестве Latch clk1 и это было верно?
TimeQuest считает временные соотношения между сигналами при передаче данных reg1 -> reg2.
Соответственно, launch - тот клок, по которому данные записываются в reg1, а latch - по которому записываются в reg2.
В моем случае reg1 это выходной регистр контроллера SDRAM, а reg2 это входной регистр во внешней микросхеме памяти, я правильно понял?
-
Опубликовано · Изменено пользователем en-valb · Пожаловаться
55 minutes ago, Yuri124 said:Этим Вы добились, что клоки якобы стали независимыми и якобы стартуют одновременно с времени 0 нс. Но так ли это на самом деле?
Да я это понял, пытаюсь рассуждать:
SDRAM контроллер выставляет очередные данные на шине DQ по фронту clk0. По thold выходных регистров ПЛИС они защелкиваются на ее выходных пинах SDRAM_DQ[15..0]. Требования по tsetup микросхемы памяти по документации 1,5 нс. Так-как clk1 сдвинут относительно clk0 на -60 deg или тоже самое, что он сдвинут на +300 deg = 8,334 нс (clk0 и clk1 = 10 нс) то в моем случае это и есть tsetup и он с большим запасом. Через 8,334 нс пришедший фронт клока clk1 начнет защелкивать выставленные данные в регистры внешней SDRAM'ки и защелкнуться они по thold = +0,8 нс, т.е. через 8,334 + 0,8 = 9,134 нс они будут уже сохранены в памяти. И цикл записи очередных данных начнется через примерно 1 нс.
От сюда вопросы:
Когда я добавил команду set_clock_groups -exclusive -group [get_clocks {inst3|altpll|sd1|pll7|clk[0]}] -group [get_clocks {inst3|altpll|sd1|pll7|clk[1]}] я сказал TimeQuest, что сигналы clk0 и clk1 синхронны и синфазны?
В результате он начал все анализировать от clk1, но ведь это не правильно?
TimeQuest до этого брал в качестве Launch clk0 а в качестве Latch clk1 и это было верно?
Нужна ли все таки команда set_clock_groups или нет и правильно ли я ее понимаю? -
Нашел откуда этот слак, я случайно сделал это...
set_output_delay -add_delay -rise -max -clock [get_clocks {inst3|altpll|sd1|pll7|clk[1]}] 1.500 [get_ports {SDRAM_CLK}] set_output_delay -add_delay -rise -min -clock [get_clocks {inst3|altpll|sd1|pll7|clk[1]}] 0.800 [get_ports {SDRAM_CLK}]Убрал эти строки из файла и :)
-
Добавил в sdc
set_clock_groups -exclusive -group [get_clocks {inst3|altpll|sd1|pll7|clk[0]}] -group [get_clocks {inst3|altpll|sd1|pll7|clk[1]}]Остался один слак по пути от выхода pll|clk[1] до порта SDRAM_CLK
задержка на IO буфере 2,809 нс
Получается, что SDRAM_CLK и так в худшем случае при температуре кристалла +100 С сдвинут на -2,273 нс + -2,809 нс = -5,082 нс (-183 deg)???
-
Опубликовано · Изменено пользователем en-valb · Пожаловаться
2 hours ago, warrior-2001 said:Тайминги на память есть. Из документации посмотреть, как они выглядят - открыть TimeQuest и указать необходимые параметры. Это самый действенный способ понять всё самому.
Сделал, получил кучу слаков, я так понимаю по диаграмме на втором рисунке, я сдвинул clk1 на -60 deg т.е. на - 1,6666 нс относительно периода 10 нс. Там как раз между Launch и Latch 8.334 нс получилось (10 - 1,666 = 8.334), учитывая, что данные приходят на 4,122 нс позже чем необходимо, то надо сдвинуть Latch на 4,122 - 1,666 = 2,456 нс примерно на +90 deg? Или тут как то учесть в констрейнах сдвиг фазы надо? И еще я не уверен, что правильно указал set_input_delay. SDRAM использую MT48LC16M16A2P-6AIT ф.Micron, ссылка на pdf. Обновленный sdc тоже в приложении.
-
4 minutes ago, Yuri124 said:
тогда - добавьте derive_pll_clocks, как уже подсказали постом выше,
да, сделал так.
-
Опубликовано · Изменено пользователем en-valb · Пожаловаться
1 hour ago, Yuri124 said:Если же генерируется внутренним pll - то create_generated_clock сам это сделает.
Да у меня внутренний PLL.
-
Опубликовано · Изменено пользователем en-valb · Пожаловаться
Коллеги, добрый день!
Пытаюсь въехать во временной анализ. Проект разрастается, времянка начинает нагибаться, а понимание в этом вопросе пока рассеяное. Хочу обконстрейнить NIOS II + SDRAM, но пока нет понимания с чего начать, точнее из TimeQuest сделал create_clock, create_generated_clock, set_clock_uncertainty, а дальше вроде необходимо задать set_input_delay и set_output_delay. Если для выводов подключенных к UART и к PIO вроде как понятно, а вот для SDRAM не очень, так-как есть две тактовые частоты, clk0 и clk1. clk0 тактирует всю систему и SDRAM контроллер, а clk1 это clk0 сдвинутый по фазе на -60 deg для тактирования микросхемы SDRAM. Несколько раз перечитывал статью Шехалева Дениса, но пока нет очень понял как тут быть, считать эти клоки асинхронными? Сигналы по DQ идущие из контроллера в микросхему выставляются по clk0, а из микросхемы в контроллер выставляются по clk1, это путает и я не могу понять как тут быть? Если для выходов контроллера применяем set_output_delay, для входов контроллера set_input_delay, то для inout и set_input_delay и set_output_delay? Проект во вложении. Буду очень благодарен за помощь!!!
-
On 2/6/2019 at 3:51 PM, Constantin said:
Первый раз такое вижу... Altium 17.0.11 под руками нету, но схем напечатано много и никогда не было видно сетки и не приходилось ее делать белой.
Ну и чаще я делаю Smart PDF - хоть в цвете, и печатаю его, управление печатью в Acrobat много гибче и результаты предсказуемые.
А какую версию Altium используете?
-
24 minutes ago, Constantin said:
Если установить в "Document Options" "Sheet Color" белым - пелены не будет.
Не помогло. Прикладываю фото. Сетку то же белой сделал.
-
Мне тоже можно!
-
Всем доброго времени суток!
Пытаюсь распечатать схему на которой есть залитый (Draw Solid) черной заливкой (Fill Color) эллипс (Place->Drawing Tools->Ellipse). При печати на принтер или в pdf если указать в свойствах страницы Mono, исчезает заливка эллипса, а в схематике все в порядке. Через Job то же самое. Если печатать в Gray то вся схема заливается пеленой в виде прозрачной сетки. Фону придается слегка серый цвет, что не годиться при печати документации. Не могу ни как добиться заливки эллипса при печати в монохромном режиме. Все что можно перегуглил. И здесь на форуме искал. Ответа не нашел или не увидел. Буду очень благодарен за помощь в данном вопросе. Версия Altium 17.0.11 (Build 656), Windows 10 Pro.
-
_Anatoliy, в общем сделал еще два батника
my_script.bat
"C:\altera\15.1\nios2eds\Nios II Command Shell.bat" sh D:/Projects/Quartus/Q15_1/Test_DEL/script/my_script.sh
и
download.bat
set name_prj=test @set name_jic=%name_prj%.jic @set full_path="D:\Projects\Quartus\Q15_1\Test_DEL" @c:\altera\15.1\quartus\bin64\quartus_cpf -c output_file.cof @c:\altera\15.1\quartus\bin64\quartus_pgm -m JTAG -o pvbi;"%full_path%\%name_jic%"
Еще создал *.cof файл с помощью Convert Programing File.
output_file.cof
<?xml version="1.0" encoding="US-ASCII" standalone="yes"?> <cof> <eprom_name>EPCS64</eprom_name> <flash_loader_device>EP4CE22</flash_loader_device> <output_filename>test.jic</output_filename> <n_pages>0</n_pages> <width>1</width> <mode>7</mode> <hex_block> <hex_filename>D:/Projects/Quartus/Q15_1/Test_DEL/flash/new.hex</hex_filename> <hex_addressing>absolute</hex_addressing> </hex_block> <hex_block> <hex_filename>D:/Projects/Quartus/Q15_1/Test_DEL/flash/test_sof.hex</hex_filename> <hex_addressing>absolute</hex_addressing> </hex_block> <version>9</version> <create_cvp_file>0</create_cvp_file> <create_hps_iocsr>0</create_hps_iocsr> <auto_create_rpd>1</auto_create_rpd> <create_fif_file>0</create_fif_file> <options> <map_file>1</map_file> </options> <advanced_options> <ignore_epcs_id_check>2</ignore_epcs_id_check> <ignore_condone_check>2</ignore_condone_check> <plc_adjustment>0</plc_adjustment> <post_chain_bitstream_pad_bytes>-1</post_chain_bitstream_pad_bytes> <post_device_bitstream_pad_bytes>-1</post_device_bitstream_pad_bytes> <bitslice_pre_padding>1</bitslice_pre_padding> </advanced_options> </cof>
Первый батник запускает на выполнение скрипт my_script.sh, который создает из *.sof и *.elf файлов *.hex файлы.
Второй создает с помощью команды quartus_cpf *.jic файл из *.hex и *.cof файлов и команда quartus_pgm программирует ПЛИС.
Объединить оба батника в один файл не получается т.к. после запуска и выполнения Nios II Command Shell последующие команды не выполняются. Буду думать дальше. Еще надо будет с путями и именами файлов продумать так чтобы эти батники можно было с минимальными телодвижениями из проекта в проект таскать. Но в любом случае запустил два батника и все готово и работает. _Anatoly, спасибо за подсказку!
-
А какие проблемы?
set CFG_DEV_NAME="EPCS128" set SFL_DEV_NAME="5AGXBA3D4" set name_prj=my @set name_sof=%name_prj%.sof @set name_jic=%name_prj%.jic @set full_path="d:\MyDesigns\2017\111\Quartus2\222\output_files" @c:\altera\16.0\quartus\bin64\quartus_cdb %name_prj% -c %name_prj% --update_mif @c:\altera\16.0\quartus\bin64\quartus_asm --read_settings_files=on --write_settings_files=off %name_prj% -c %name_prj% @c:\altera\16.0\quartus\bin64\quartus_cpf -o "param_convert.opt" -c -d %CFG_DEV_NAME% -s %SFL_DEV_NAME% "%full_path%\%name_sof%" "%full_path%\%name_jic%" @c:\altera\16.0\quartus\bin64\quartus_pgm -m JTAG -o pvbi;"%full_path%\%name_jic%"
Этим батником сразу и прошивайте.
p.s.
Ещё нужно выполнить Make targets/build/mem_init_generate
Интересный вариант, а я через свой скрипт делал
#сменить директорию на директорию проекта cd D:/Projects/Quartus/Q15_1/Test_DEL #Ввести имя проекта аппаратной части .sof HW_SOF_NAME="test" #Ввести имя файла програмной части (основного ядра) .elf SW_ELF_NAME_MAIN_CPU="new" #Ввести имя файла програмной части (второстепенное ядро).elf SW_ELF_NAME_SLAVE_CPU="new" #Cмещение для программы второго ядра. #Т.к. epcs у нас 128Мбит=16Мбайт, решили аппаратную часть и програму основного ядра располагать #с нулевого адреса последовательно друг за другом. #Решили дать им совместно 6Мбайт, а после этого уже располагать программу для второго ядра. #ETHERNET_OFFSET=0x600000 #преобразуем .sof в .flash sof2flash --input=output_files/"$HW_SOF_NAME".sof --output=flash/"$HW_SOF_NAME"_sof.flash --epcs #Основной проект. преобразуем из .elf в .flash elf2flash --input=software/"$SW_ELF_NAME_MAIN_CPU"/"$SW_ELF_NAME_MAIN_CPU".elf --output=flash/"$SW_ELF_NAME_MAIN_CPU".flash --epcs --after=flash/"$HW_SOF_NAME"_sof.flash #Второй проект. преобразуем из .elf в .flash #elf2flash --input=software/"$SW_ELF_NAME_SLAVE_CPU"/"$SW_ELF_NAME_SLAVE_CPU".elf --output=flash/"$SW_ELF_NAME_SLAVE_CPU"_elf_with_offset.flash --epcs --#offset=$ETHERNET_OFFSET #конвертация программного фйла .flash в .hex nios2-elf-objcopy -I srec -O ihex flash/"$HW_SOF_NAME"_sof.flash flash/"$HW_SOF_NAME"_sof.hex nios2-elf-objcopy -I srec -O ihex flash/"$SW_ELF_NAME_MAIN_CPU".flash flash/"$SW_ELF_NAME_MAIN_CPU".hex #nios2-elf-objcopy -I srec -O ihex flash/"$SW_ELF_NAME_SLAVE_CPU"_elf_with_offset.flash flash/"$SW_ELF_NAME_SLAVE_CPU"_elf_with_offset.hex
так все работает.
Но мне для программиста хочется как можно удобнее сделать чтобы он не парился со всем этим.
-
Перегоните *.sof в *.jic и заливайте с помощью QII Programmer.
Этого не достаточно, нужно кроме *.sof во флешку еще и *.elf уложить. А в качестве проверки *.jic делал и прошивал, все нормально.
-
Опубликовано · Изменено пользователем en-valb · Пожаловаться
Да, забыл указать, использую Quartus II 15.1 Update 2. Подозреваю, что в строке "Info: Info: Command: quartus_cpf --no_banner --convert --device=EPCS128 --option......" не правильно указана флешка т.к. в DE0nano стоит EPCS64, а flash programer думает что EPCS128. Может есть какой то скрипт где настраивается тип флешпамяти. На моей плате все работает наверно потому, что там установлена EPCS128? Может кто даст ссылочку на похожую проблему, самостоятельно по этому поводу нагуглить ни чего не удалось, есть похожие темы да все не то.
TimeQuest + NIOS II+ SDRAM как обконстрейнить?
в Работаем с ПЛИС, области применения, выбор
Опубликовано · Пожаловаться
Добавил set_multicycle_path слаки уменьшились, наихудшее значение стало -0,557 нс, добавил сдвиг фазы еще на 22,5 deg и того получилось +52,5 deg. Откомпилировал получил слаки -1,542 нс, увеличил сдвиг фазы до +108 deg слаки исчезли полностью, но запас по SDRAM_BA[0] маловат будет, попробую подвинуть еще немного.
clk1 +108 deg.bmp
BA[0].bmp