Jump to content

    

BSACPLD

Свой
  • Content Count

    518
  • Joined

  • Last visited

Community Reputation

0 Обычный

About BSACPLD

  • Rank
    Знающий
  • Birthday 06/16/1986

Контакты

  • Сайт
    http://www.mcu-cpld.narod.ru
  • ICQ
    0

Информация

  • Город
    Москва

Recent Profile Visitors

4053 profile views
  1. Не помогло :( Пробовал и в CMakeList.txt и в CMake configuration.
  2. Добрый день, коллеги! Сейчас я занимаюсь тем, что пробую разобраться с настройкой компилятора и отладчика для SCR1 от Syntacore. https://syntacore.com/page/products/processor-ip/scr1 GCC и GDB собрал и настроил. Из командной строки работает. Теперь хочу прикрутить к этому делу QtCreator в качестве IDE. Делаю как по мануалу, но при создании проекта вылезает ошибка: /usr/share/cmake-3.10/Modules/CMakeTestCCompiler.cmake:52: error: The C compiler "/home/sergey/riscv-gcc/bin/riscv64-unknown-elf-gcc" is not able to compile a simple test program. It fails with the following output: Change Dir: /tmp/QtCreator-EcKky4/qtc-cmake-XXfkJdCv/CMakeFiles/CMakeTmp Run Build Command:"/usr/bin/make" "cmTC_820e2/fast" /usr/bin/make -f CMakeFiles/cmTC_820e2.dir/build.make CMakeFiles/cmTC_820e2.dir/build make[1]: вход в каталог «/tmp/QtCreator-EcKky4/qtc-cmake-XXfkJdCv/CMakeFiles/CMakeTmp» Building C object CMakeFiles/cmTC_820e2.dir/testCCompiler.c.o /home/sergey/riscv-gcc/bin/riscv64-unknown-elf-gcc -o CMakeFiles/cmTC_820e2.dir/testCCompiler.c.o -c /tmp/QtCreator-EcKky4/qtc-cmake-XXfkJdCv/CMakeFiles/CMakeTmp/testCCompiler.c Linking C executable cmTC_820e2 /usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_820e2.dir/link.txt --verbose=1 /home/sergey/riscv-gcc/bin/riscv64-unknown-elf-gcc -rdynamic CMakeFiles/cmTC_820e2.dir/testCCompiler.c.o -o cmTC_820e2 riscv64-unknown-elf-gcc: error: unrecognized command line option '-rdynamic' CMakeFiles/cmTC_820e2.dir/build.make:97: recipe for target 'cmTC_820e2' failed make[1]: *** [cmTC_820e2] Error 1 make[1]: выход из каталога «/tmp/QtCreator-EcKky4/qtc-cmake-XXfkJdCv/CMakeFiles/CMakeTmp» Makefile:126: recipe for target 'cmTC_820e2/fast' failed make: *** [cmTC_820e2/fast] Error 2 Помогите, пожалуйста, разобраться в чем проблема. Мануал: https://doc.qt.io/qtcreator/creator-developing-baremetal.html Настройки QtCreator:
  3. Я использую в своих проектах. Ошибок не обнаружено. stable поставлю если наберется статистика успешного использования другими разработчиками
  4. Только сейчас дошли руки выложить :( Обновленная версия. https://yadi.sk/d/ghSD883uiIS5cw Для Xilinx сделан вариант с использованием xpm макросов. Теперь содержимое памяти можно обновлять через tcl скрипт. Примечание: В Vivado 2018.3 updatemem не умеет обновлять память больше 32768 бит. В 2019.2 эта проблема уже исправлена.
  5. Нашел. Во вложении пример работающий с Avalon от Xilinx. Проверено на железе в Vivado 2018.3. av_adapter.sv
  6. Я решил эту проблему, только уже не помню как :( Надо поискать в архиве проектов. Помню, только то, что у Xilinx Avalon сделан немного не по спецификации.
  7. Откуда берется ошибка разобрался. UG898 Although bit-lane parity is defined in the MMI file, it is not supported by UpdateMEM. Теперь вопрос как заставить vivado не использовать parity при синтезе BRAM.
  8. Сделал память через макрос, теперь *.mmi файл создается на этапе имплементации. Но возникла вторая проблема. После выполнения updatemem я получаю некорректные данные в случае если память задаваемая через макрос занимает более чем один BRAM (32768 бит). Причем применить updatemem к памяти размером более 32768 мне удалось только в 2019.2. В 2018.3 выдавалась ошибка о превышении размера 32768 бит. Если память задаваемая через макрос меньше одного BRAM, то обновление происходит корректно. Может быть можно как-то сконвертировать *.mmi в *.bmm и воспользоваться data2mem?
  9. С TCL скриптом понятно. Я не понимаю, откуда брать *.mmi файл. В скомпилированном проекте его нет. Память я задаю через Verilog, а не через IP. `timescale 1 ns / 1 ps module avr_cpu_prog_ram #( parameter DATA_SIZE = 4096, parameter DATA_WIDTH = 16, parameter INIT_FILE = "", parameter SIM_INIT = "FALSE" ) ( input clock_a, input clock_b, input addressstall_a, input addressstall_b, input [$clog2(DATA_SIZE)-1:0] address_a, input [$clog2(DATA_SIZE)-1:0] address_b, input [DATA_WIDTH-1:0] data_a, input [DATA_WIDTH-1:0] data_b, input wren_a, input wren_b, input enable_out_a, input enable_out_b, input aclr_out_a, input aclr_out_b, output reg [DATA_WIDTH-1:0] q_a, output reg [DATA_WIDTH-1:0] q_b ) ; reg [$clog2(DATA_SIZE)-1:0] address_reg_a ; wire [$clog2(DATA_SIZE)-1:0] address_mux_a ; reg [$clog2(DATA_SIZE)-1:0] address_reg_b ; wire [$clog2(DATA_SIZE)-1:0] address_mux_b ; reg [DATA_WIDTH-1:0] mem [DATA_SIZE-1:0] /* synthesis syn_ramstyle = "no_rw_check" */ ; initial begin #0.01 ; if (INIT_FILE != "") begin $readmemh (INIT_FILE, mem) ; end if (SIM_INIT == "TRUE") begin address_reg_a <= 0 ; address_reg_b <= 0 ; q_a <= 0 ; q_b <= 0 ; end end assign address_mux_a = (addressstall_a)? address_reg_a : address_a ; always @(posedge clock_a) begin address_reg_a <= address_mux_a ; if (wren_a) mem[address_mux_a] <= data_a ; end always @(posedge clock_a or posedge aclr_out_a) begin if (aclr_out_a) q_a <= 0 ; else if (enable_out_a) q_a <= mem[address_reg_a] ; end assign address_mux_b = (addressstall_b)? address_reg_b : address_b ; always @(posedge clock_b) begin address_reg_b <= address_mux_b ; if (wren_b) mem[address_mux_b] <= data_b ; end always @(posedge clock_b or posedge aclr_out_b) begin if (aclr_out_b) q_b <= 0 ; else if (enable_out_b) q_b <= mem[address_reg_b] ; end endmodule
  10. Я правильно понял, что данный вариант работает только с microblaze и его нельзя применить для обычной памяти?
  11. Народ, подскажите, пожалуйста, как обновлять содержимое BRAM (ROM) без перекомпиляции проекта в Vivado. В ISE я это делал через BMM и TCL скрипт, а как это делать в Vivado? Особенно если память синтезируется из Verilog, а не через IP core.
  12. Я работал с GOWIN (GW1NR9, GW2A18), могу сказать следующее. Сама IDE не без глюков, нет иерархии файлов/модулей, лог. анализатор дикий тормоз, может глючить и отваливаться. Синтез идет через Synplify или собственный синтезатор. Последний полный отстой. Валится на элементарных конструкциях. Но Synplify работает вполне достойно. Время сборки проекта довольно мало. Там больше проблемы с самими ПЛИС. Главный и очень серьезный баг, который я обнаружил, это некорректная работа BRAM. Во всех режимах, кроме True Dual Port, данные могут писаться или читаться некорректно. Это официально признанный баг и он даже описан в последних версиях документации. Проблема в том, что если Ваш код синтезируется не в True Dual Port, нужно принудительно включать этот режим путем вставки памяти не как HDL, а как IP сгенеренное их кодогенератором. Что соответственно делает невозможным сделать полную параметризуемость Ваших блоков. Ну и быстродействие это вообще грусть и печаль. Самый быстрый кристалл в два раза медленнее Cyclone IV E с самым медленным спидгрейдом. Хотя у данных ПЛИС помимо цены есть еще существенный плюс в том, что в отличии от Altera и Xilinx они выпускаются в QFN корпусах.
  13. Так из консоли и с моим скриптом работает :) Проблема как раз с запуском из Vivado. Проблему с лаунчером на рабочем столе я решил установкой галочки Launch in Terminal при создании кнопки запуска.
  14. При попытке запустить QuestaSim 10.7c из Vivado 2018.3 на Linux Mint 19.2, QuestaSim не запускается. # Loading work.test(fast) # Loading work.glbl(fast) # 1 # 1 # # <EOF> Из Quartus и из консоли запускается без проблем, но если запустить из файлового менеджера, то так же не стартует. Для самостоятельного запуска использую вот такой скрипт: #!/bin/bash '/home/user/questasim/linux_x86_64/vsim' Что я делаю не так?