Перейти к содержанию
    

Roberto_Tolas

Участник
  • Постов

    58
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о Roberto_Tolas

  • Звание
    Участник
    Участник

Посетители профиля

1 860 просмотров профиля
  • Staf

  1. Добавлю вывод выполнения команды dtc ./dt-spl.dtb (в первый вариант добавил еще usdhc) <stdout>: Warning (reg_format): /soc/aips-bus@2000000/iomuxc@20e0000:reg: property has invalid length (8 bytes) (#address-cells == 2, #size-cells == 1) <stdout>: Warning (reg_format): /soc/aips-bus@2100000/usdhc@2190000:reg: property has invalid length (8 bytes) (#address-cells == 2, #size-cells == 1) <stdout>: Warning (reg_format): /soc/aips-bus@2100000/serial@21ec000:reg: property has invalid length (8 bytes) (#address-cells == 2, #size-cells == 1) <stdout>: Warning (unit_address_vs_reg): /soc/aips-bus@2000000: node has a unit name, but no reg property <stdout>: Warning (unit_address_vs_reg): /soc/aips-bus@2100000: node has a unit name, but no reg property <stdout>: Warning (pci_device_reg): Failed prerequisite 'reg_format' <stdout>: Warning (pci_device_bus_num): Failed prerequisite 'reg_format' <stdout>: Warning (simple_bus_reg): Failed prerequisite 'reg_format' <stdout>: Warning (i2c_bus_reg): Failed prerequisite 'reg_format' <stdout>: Warning (spi_bus_reg): Failed prerequisite 'reg_format' <stdout>: Warning (avoid_default_addr_size): /soc/aips-bus@2000000/iomuxc@20e0000: Relying on default #address-cells value <stdout>: Warning (avoid_default_addr_size): /soc/aips-bus@2000000/iomuxc@20e0000: Relying on default #size-cells value <stdout>: Warning (avoid_default_addr_size): /soc/aips-bus@2100000/usdhc@2190000: Relying on default #address-cells value <stdout>: Warning (avoid_default_addr_size): /soc/aips-bus@2100000/usdhc@2190000: Relying on default #size-cells value <stdout>: Warning (avoid_default_addr_size): /soc/aips-bus@2100000/serial@21ec000: Relying on default #address-cells value <stdout>: Warning (avoid_default_addr_size): /soc/aips-bus@2100000/serial@21ec000: Relying on default #size-cells value <stdout>: Warning (avoid_unnecessary_addr_size): Failed prerequisite 'avoid_default_addr_size' <stdout>: Warning (unique_unit_address): Failed prerequisite 'avoid_default_addr_size' <stdout>: Warning (dmas_property): /soc/aips-bus@2100000/serial@21ec000:dmas: Could not get phandle node for (cell 0) <stdout>: Warning (gpios_property): /soc/aips-bus@2100000/usdhc@2190000:cd-gpios: Could not get phandle node for (cell 0) /dts-v1/; / { #address-cells = <0x01>; #size-cells = <0x01>; model = "Freescale i.MX6 SoloX MY Board"; compatible = "fsl,imx6sx"; chosen { stdout-path = "/soc/aips-bus@2100000/serial@21ec000"; }; aliases { mmc0 = "/soc/aips-bus@2100000/usdhc@2190000"; serial2 = "/soc/aips-bus@2100000/serial@21ec000"; }; soc { aips-bus@2000000 { iomuxc@20e0000 { compatible = "fsl,imx6sx-iomuxc"; reg = <0x20e0000 0x4000>; phandle = <0x0e>; imx6x-mypins { uart3grp { fsl,pins = <0x1b4 0x4fc 0x840 0x01 0x04 0x1b0b1 0x1b8 0x500 0x00 0x01 0x00 0x1b0b1>; phandle = <0x1d>; }; }; }; }; aips-bus@2100000 { usdhc@2190000 { compatible = "fsl,imx6sx-usdhc\0fsl,imx6sl-usdhc"; reg = <0x2190000 0x4000>; bus-width = <0x04>; status = "okay"; cd-gpios = <0x1c 0x02 0x01>; no-1-8-v; keep-power-in-suspend; wakeup-source; }; serial@21ec000 { compatible = "fsl,imx6sx-uart\0fsl,imx6q-uart\0fsl,imx21-uart"; reg = <0x21ec000 0x4000>; dmas = <0x0c 0x1d 0x04 0x00 0x0c 0x1e 0x04 0x00>; dma-names = "rx\0tx"; status = "okay"; }; }; }; };
  2. Продолжаю попытки запустить плату с использованием дерева устройств. Добавил в .config: CONFIG_SPL_SEPARATE_BSS=y После чего получил в вывод следующее: Вывод в консоль сейчас использую без DM для Serial Port. Мне кажется какая-то проблема с памятью, а именно с областью bss. Я добавил строку printf("pointer to bss = 0x%08X, size bss = 0x%08X\n", (unsigned int)__bss_start, (unsigned int)(__bss_end - __bss_start)); перед очисткой области bss в файле spl.c в функции board_init_f. И получил следующий вывод: pointer to bss = 0x00000000, size bss = 0x00000000 Содержимое файла u-boot-spl.lds: MEMORY { .sram : ORIGIN = 0x00908000, LENGTH = 0x10000 } MEMORY { .sdram : ORIGIN = 0x88200000, LENGTH = 0x100000 } OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm") OUTPUT_ARCH(arm) ENTRY(_start) SECTIONS { .text : { __start = .; *(.vectors) arch/arm/cpu/armv7/start.o (.text*) *(.text*) } >.sram . = ALIGN(4); .rodata : { *(SORT_BY_ALIGNMENT(.rodata*)) } >.sram . = ALIGN(4); .data : { *(SORT_BY_ALIGNMENT(.data*)) } >.sram . = ALIGN(4); .u_boot_list : { KEEP(*(SORT(.u_boot_list*))); } >.sram . = ALIGN(4); __image_copy_end = .; .end : { *(.__end) } _image_binary_end = .; .bss : { . = ALIGN(4); __bss_start = .; *(.bss*) . = ALIGN(4); __bss_end = .; } >.sdram } Правильно ли я понимаю, что pointer to bss должен был быть равен 0x88200000? Почему мог обнулиться данный адрес? И, теперь, как я понимаю, все глобальные переменные указывают на null, что может привести (и скорее всего приводит) к странной работе программы SPL?
  3. Я отключил использование DM для SERIAL_PORT, появился консольный вывод. И вот что он мне сообщает: Получается он не видит дререво устройств вообще? Я проверил, собирается ли SPL с деревом устройств - после сборки в папке spl два файла: u-boot-spl-nodtb.bin и u-boot-spl-dtb.bin, отличающиеся размером как раз на размер файла dt-spl.dtb из папки spl\dts. Для формирования файла SPL, исходя из .SPL.cmd, используется файл u-boot-spl.bin. Файл u-boot-spl.bin и u-boot-spl-dtb.bin одинаковые. Следовательно, я сделал вывод, что SPL собирается с деревом устройств. Может быть проблема заключается в том, что я гружу SPL через usb? Содержимое конфигурационных файлов программы imx_usb_loader не менял. Может быть там что-то надо поменять? Вывод процесса загрузки: config file <.//imx_usb.conf> vid=0x066f pid=0x3780 file_name=mx23_usb_work.conf vid=0x15a2 pid=0x004f file_name=mx28_usb_work.conf vid=0x15a2 pid=0x0052 file_name=mx50_usb_work.conf vid=0x15a2 pid=0x0054 file_name=mx6_usb_work.conf vid=0x15a2 pid=0x0061 file_name=mx6_usb_work.conf vid=0x15a2 pid=0x0063 file_name=mx6_usb_work.conf vid=0x15a2 pid=0x0071 file_name=mx6_usb_work.conf vid=0x15a2 pid=0x007d file_name=mx6_usb_work.conf vid=0x15a2 pid=0x0080 file_name=mx6_usb_work.conf vid=0x1fc9 pid=0x0128 file_name=mx6_usb_work.conf vid=0x15a2 pid=0x0076 file_name=mx7_usb_work.conf vid=0x1fc9 pid=0x0126 file_name=mx7ulp_usb_work.conf vid=0x15a2 pid=0x0041 file_name=mx51_usb_work.conf vid=0x15a2 pid=0x004e file_name=mx53_usb_work.conf vid=0x15a2 pid=0x006a file_name=vybrid_usb_work.conf vid=0x066f pid=0x37ff file_name=linux_gadget.conf vid=0x1b67 pid=0x4fff file_name=mx6_usb_sdp_spl.conf vid=0x0525 pid=0xb4a4 file_name=mx6_usb_sdp_spl.conf config file <.//mx6_usb_work.conf> parse .//mx6_usb_work.conf Trying to open device vid=0x15a2 pid=0x0071 Interface 0 claimed HAB security state: development mode (0x56787856) == work item filename ./SPL load_size 0 bytes load_addr 0x00000000 dcd 1 clear_dcd 0 plug 1 jump_mode 2 jump_addr 0x00000000 == end work item No dcd table, barker=402000d1 loading binary file(./SPL) to 00907400, skip=0, fsize=8c00 type=aa <<<35840, 35840 bytes>>> succeeded (security 0x56787856, status 0x88888888) jumping to 0x00907400
  4. Здравствуйте! Спасибо за отклик! Я прошёл по вызываемым функциям в preloader_console_init, одной из последних функций там вызывается serial_find_console_or_panic, дойдя до конца которой (в случае, если не было найдено ни одного порта), вызывается функция panic_str, которая вызывает do_reset. Думаю здесь он и сбрасывается. Сейчас пробую не создавать новый код для платы, а взял уже готовый для платы udoo_neo_basic. Удалил все оттуда лишнее, привёл к тому же виду, что и у меня. Результат получше, хотя бы есть вывод в консоль (правда в чем отличие от моего кода я пока не понял, сейчас буду более детально сверять default_config). Не подскажите как мне лучше сделать дальше: необходимо продолжить загрузку - перейти к загрузке U-Boot. Думал продолжить загрузку через SD-карту, но опять не понимаю что происходит с деревом устройств. Добавил описание пинов, разрешил интерфейс, к которому подведена SD-карта, все это указал чтобы можно было использовать в SPL, но каких либо попыток загрузиться с SD-карты я не наблюдаю. Кроме вывода в консоль: Trying to boot from MMC1. Такое ощущение, что не инициализируется тактовая для интерфейса usdhc1. В коде для некоторых плат находил функцию board_mmc_init(struct bd_info *bis) (функция вызывается из mmc_probe) с кодом: usdhc_cfg[0].sdhc_clk = mxc_get_clock(MXC_ESDHC_CLK); ret = fsl_esdhc_initialize(bis, &usdhc_cfg[0]); if (ret) { printf("Warning: failed to initialize mmc dev %d\n", 0); return ret; } Но, как я понял, она вызывается только при отключенном DM_MMC. Не подскажите, как мне убедиться, что то, что я описываю в дереве устройств используется в SPL и используется правильно? У меня ощущение что я что-то не до конца понимаю, не подскажите что можно почитать про SPL?
  5. Здравствуйте, уважаемые форумчане! Возникла проблема при инициализации консольного UART в SPL. Имеется плата собственной разработки, основанная на процессоре NXP i.MX6 SoloX. Произвожу сборку U-boot с SPL, полученный файл гружу через USB с помощью программы imx_usb_loader. Но плата после попытки инициализации консольного UART сбрасывается. Код функции board_init_f файла spl.c для моей платы: void board_init_f(ulong dummy) { ccgr_init(); /* setup AIPS and disable watchdog */ arch_cpu_init(); /* setup GP timer */ timer_init(); /* UART clocks enabled and gd valid - init serial console */ preloader_console_init(); // <--- после вызова этой функции плата сбрасывается /* DDR initialization */ spl_dram_init(); /* Clear the BSS. */ memset(__bss_start, 0, __bss_end - __bss_start); /* load/boot image from boot device */ board_init_r(NULL, 0); } Как я понимаю, сброс происходит из-за того, что не получается найти UART для консольного вывода. В дереве устройств я определяю UART3 как порт для консоли (stdout-path), разрешаю его работу (status = okay), и указываю что он мне пригодится в SPL (u-boot, dm-spl). Вот моё дерево устройств: /dts-v1/; #include <dt-bindings/gpio/gpio.h> #include <dt-bindings/input/input.h> #include "imx6sx.dtsi" / { model = "Freescale i.MX6 SoloX MY Board"; compatible = "fsl,imx6sx-myboard", "fsl,imx6sx"; chosen { stdout-path = &uart3; }; memory@80000000 { device_type = "memory"; reg = <0x80000000 0x40000000>; }; }; &uart3 { u-boot,dm-spl; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_uart3>; status = "okay"; }; &iomuxc { imx6x-mypins { pinctrl_uart3: uart3grp { u-boot,dm-spl; fsl,pins = < MX6SX_PAD_QSPI1B_SCLK__UART3_DCE_RX 0x1b0b1 MX6SX_PAD_QSPI1B_SS0_B__UART3_DCE_TX 0x1b0b1 >; }; }; }; В default config для платы разрешаю SPL и SPL_DM (OF_CONTROL). Вот полный код конфига: CONFIG_ARM=y CONFIG_ARCH_MX6=y CONFIG_SYS_TEXT_BASE=0x87800000 CONFIG_SPL_GPIO=y CONFIG_SPL_LIBCOMMON_SUPPORT=y CONFIG_SPL_LIBGENERIC_SUPPORT=y CONFIG_NR_DRAM_BANKS=8 CONFIG_ENV_SIZE=0x2000 CONFIG_ENV_OFFSET=0xE0000 CONFIG_MX6SX=y CONFIG_TARGET_MYBOARD_IMX6SOLOX=y CONFIG_DM_GPIO=y CONFIG_DEFAULT_DEVICE_TREE="imx6sx-myboard" CONFIG_SPL_TEXT_BASE=0x00909000 CONFIG_SPL_MMC_SUPPORT=y CONFIG_SPL_SERIAL_SUPPORT=y CONFIG_SPL=y # CONFIG_CMD_BMODE is not set # CONFIG_LEGACY_IMAGE_FORMAT is not set CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg" CONFIG_BOOTDELAY=20 CONFIG_BOARD_EARLY_INIT_F=y CONFIG_SPL_SHOW_ERRORS=y CONFIG_SPL_WATCHDOG=y CONFIG_HUSH_PARSER=y CONFIG_CMD_BOOTZ=y # CONFIG_CMD_FLASH is not set CONFIG_CMD_GPIO=y CONFIG_CMD_MMC=y CONFIG_CMD_PART=y # CONFIG_CMD_SETEXPR is not set CONFIG_CMD_CACHE=y CONFIG_CMD_TIME=y CONFIG_CMD_EXT2=y CONFIG_CMD_EXT4=y CONFIG_CMD_EXT4_WRITE=y CONFIG_CMD_FAT=y CONFIG_CMD_FS_GENERIC=y CONFIG_OF_CONTROL=y CONFIG_SPL_OF_CONTROL=y CONFIG_ENV_OVERWRITE=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_SYS_MMC_ENV_DEV=2 CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y # CONFIG_NET is not set CONFIG_SPL_DM=y CONFIG_DM_DEBUG=y CONFIG_BOUNCE_BUFFER=y # CONFIG_I2C is not set CONFIG_SUPPORT_EMMC_BOOT=y CONFIG_MMC_TRACE=y CONFIG_FSL_USDHC=y CONFIG_MTD=y CONFIG_PINCTRL=y CONFIG_PINCONF=y CONFIG_PINCTRL_IMX6=y CONFIG_IMX_THERMAL=y CONFIG_SPLASH_SCREEN=y CONFIG_SPLASH_SCREEN_ALIGN=y CONFIG_SHA1=y CONFIG_SHA256=y CONFIG_MD5=y Если через make menuconfig отключить опцию "Provide a serial driver in SPL", то плата не сбрасывается, но и вывод в консоль на данный UART я не наблюдаю. Что я упустил или не правильно понял из документации и примеров кода для других плат?
  6. Благодарю пользователя BackEnd за развернутый ответ. Сейчас борюсь с временными констрейнами для гигабитного Ethernet. Очень уж они "жесткие" получаются. Создал маленький проект, в котором используются только сигналы RxD, TxD, RxCLK, TxCLK с PHY микросхемы. В качестве эксперимента завернул данные с приема на передачу через внутренние сигналы. Примерно так: IBUFG_000: IBUFG port map (O => eth_rx_clk, I => rx_clk); rx_proc : process(eth_rx_clk) begin if (rising_edge(eth_rx_clk)) then data <= rx_data_delayed; end if; end process; BUFG_000: BUFG port map(I => eth_rx_clk, O => eth_tx_clk); tx_proc : process(eth_tx_clk) begin if (rising_edge(eth_tx_clk)) then tx_data <= data; end if; end process; tx_clk <= eth_tx_clk; Задал следующие констрейны: NET "rx_clk" TNM_NET = "rx_clk"; TIMESPEC "TS_rx_clk" = PERIOD "rx_clk" 7500 ps HIGH 50 %; OFFSET = IN 2500 ps VALID 3000 ps BEFORE "rx_clk"; В таком виде избежать проблем с констрейнами не удалось. Но, используя IODELAY2 на сигналы RxD удалось удовлетворить констрейнам. Но в основном проекте уже так не прокатило, так как там проект большой, задержки больше и уже не удалось найти такой параметр IDELAY_VALUE чтобы все констрейны были удовлетворены. Вопросы, которые у меня появились в процессе этих манипуляций: 1) Что можно еще предпринять для удовлетворения констрейнам? 2) Когда создавал маленький проект, сначала в ucf файле указал только констрейны, без Location для выводов. Он раскидал все выводы так, как считает нужным. И, в принципе, проект удовлетворил констрейнам даже без IODELAY2. Может быть тогда следует сначала писать проект для FPGA, задавая все констрейны, потом смотреть куда ISE раскидает выводы и потом разводить плату?
  7. Скажите, пожалуйста, а нельзя ли задать в моем случае констрейны для выходных сигналов TXD используя входную тактовую RX_CLK? Напоминаю код: RX_CLKG <= RX_CLK; TX_CLKG <= RX_CLK;
  8. Итак, пока я переписываю проект и упрощаю его чтобы легче было искать ошибки, у меня возникают общие вопросы. 1) Получается, что все тактовые сигналы, которые идут из вне на ПЛИС и синхронизируют логику процессов обмена данными должны быть заведены на GCLK пины ПЛИС. А в проекте на VHDL они должны приниматься во внутренний сигнал через IBUFG. Дополнительно должны быть обконстрейнены данные на выход и на вход (с помощью OFFSET IN и OFFSET OUT), которые зависят от этих тактовых. Возникает следующий вопрос: "Как быть, если входных тактовых слишком много, ведь ресурсы ПЛИС ограничены в плане глобальных тактовых буферов?" 2) У меня стоит задача разделить частоту 32.768 МГц на 16 и получить частоту 2.048 МГц. Чем же плох делитель частоты с помощью счетчика? Попробовал поработать через clock enable и переписал код вот так: IBUFG_001: IBUFG port map (O => tclk, I => clk_32768); clock_enable_32768KHz : process (tclk) is variable cnt : integer range 0 to 7; begin if (rising_edge(tclk)) then if (rstn = '0') then cnt := 0; CLKOUT_E1_EN <= '0'; else if cnt=7 then CLKOUT_E1_EN <= '1'; cnt:=0; else CLKOUT_E1_EN <= '0'; cnt:=cnt + 1; end if; end if; end if; end process; out_2048KHz : process (tclk) is begin if (rising_edge(tclk)) then if (rstn = '0') then CLKOUT_E1 <= '0'; else if (CLKOUT_E1_EN = '1') then CLKOUT_E1 <= not CLKOUT_E1; end if; end if; end if; end process; Правда пока его не проверял, но я не понимаю разницы с делителем, реализованном на счетчике. Может тыкнете меня носом в информацию где можно понять в чем разница? 3) В п.1 я говорил про входные тактовые сигналы. А как быть с выходными тактовыми сигналами? В п.2 я как раз такой сигнал формирую, он служит для синхронизации выходных данных. Нужно ли его как-то обконстрейнить? И, если данный сигнал участвует в процессах формирования и обработки выходных данных, то нужно ли его вешать на глобальный тактовый буфер: BUFG_002: BUFG port map(I => CLKOUT_E1, O => e1_tx_clk); ?
  9. Изменил констрейн, добавил слово FALLING в конце, так как данные считываются по заднему фронту сигнала. Вроде прошел Place & Route быстренько.
  10. Сделал вот так: e1t1_mclk0 <= CLKOUT_E1; e1t1_tclk0 <= CLKOUT_E1; В параметрах Map процесса стоит Pack I/O Registers/Latches into IOBs: For Inputs and Outputs. Этого достаточно чтобы "триггеры CLKOUT_E1 расположить в IOB"? Или следует написать констрейн вида INST "CLKOUT_E1" IOB =TRUE; Я так понимаю что после сборки можно посмотреть лежат ли в IOB эти триггеры в FPGA Editor'e. Только вот я не нашел где... После добавления строки OFFSET = IN 122070 ps VALID 200 ns BEFORE "e1t1_rclk0"; процесс Place & Route стал очень долгим и выводится следующее сообщение: Unusually high hold time violation detected among 24 connections. The top 20 such instances are printed below. The router will continue and try to fix it e1t1_rpos0:I -> ethmac/e1_1_rx/TR_FLAG:A6 -165406 e1t1_rpos0:I -> ethmac/e1_1_rx/hdlc_bit_get.byte<6>:B6 -165117 e1t1_rpos0:I -> ethmac/e1_1_rx/hdlc_bit_get.byte<6>:D6 -165030 e1t1_rpos0:I -> ethmac/e1_1_rx/hdlc_bit_get.one_cnt<1>:D2 -165025 e1t1_rpos0:I -> ethmac/e1_1_rx/hdlc_bit_get.byte<6>:C6 -164960 e1t1_rpos0:I -> ethmac/e1_1_rx/hdlc_bit_get.byte<6>:A6 -164895 e1t1_rpos0:I -> ethmac/e1_1_rx/hdlc_bit_get.byte<2>:C6 -164845 ethmac/e1_1_rx/SIZE_TO_READ<10>:C -> ethmac/e1_1_rx/SIZE_TO_READ<10>:CE -164835 e1t1_rpos0:I -> ethmac/e1_1_rx/SIZE_TO_READ<10>:C4 -164835 e1t1_rpos0:I -> ethmac/e1_1_rx/hdlc_bit_get.byte<2>:D6 -164824 e1t1_rpos0:I -> ethmac/e1_1_rx/hdlc_bit_get.byte<7>:A6 -164818 e1t1_rpos0:I -> lut11048_1737:D1 -164809 ethmac/e1_1_rx/hdlc_bit_get.byte<6>:B -> ethmac/e1_1_rx/Mram_REC_DATA:DIA4 -164767 ethmac/e1_1_rx/hdlc_bit_get.byte<6>:D -> ethmac/e1_1_rx/Mram_REC_DATA:DIA6 -164745 e1t1_rpos0:I -> ethmac/e1_1_rx/hdlc_bit_get.byte<2>:A1 -164709 ethmac/e1_1_rx/hdlc_bit_get.byte<2>:AMUX -> ethmac/e1_1_rx/Mram_REC_DATA:DIA0 -164709 e1t1_rpos0:I -> ethmac/e1_1_rx/SYNC_LOCAL:A5 -164704 ethmac/e1_1_rx/hdlc_bit_get.byte<6>:C -> ethmac/e1_1_rx/Mram_REC_DATA:DIA5 -164663 ethmac/e1_1_rx/hdlc_bit_get.byte<2>:C -> ethmac/e1_1_rx/Mram_REC_DATA:DIA1 -164638 ethmac/e1_1_rx/hdlc_bit_get.byte<2>:AMUX -> ethmac/e1_1_rx/hdlc_bit_get.byte<2>:AX -164632 Из-за чего это может происходить?
  11. Для входной тактовой 32.768 МГц был определен тактовый буфер: IBUFG_002: IBUFG port map (O => tclk, I => clk_32768); Делю входную тактовую счетчиком: div16_32768KHz : process (tclk, rstn) is variable cnt : integer range 0 to 7; begin if rstn = '0' then cnt := 0; CLKOUT_E1 <= '0'; else if tclk'event and tclk='1' then if cnt=7 then CLKOUT_E1 <= not CLKOUT_E1; cnt:=0; else cnt:=cnt +1; end if; end if; end if; end process; Сейчас добавил еще строчки для выходных тактовых и входной тактовой принимаемых данных: OBUFG_000: BUFG port map (O => e1t1_mclk0, I => CLKOUT_E1); OBUFG_001: BUFG port map (O => e1t1_tclk0, I => CLKOUT_E1); IBUFG_003: IBUFG port map (O => e1t1_rclk0_local, I => e1t1_rclk0); Вот только все эти входы и выходы на ПЛИС подключены к обычным портам ввода/вывода (не GCLK). Это плохо?
  12. Да, для Marvell нужна частота 125 МГц для работы на скорости 1 Гб/с, а частота 125 МГц или более нужна для МАС уровня, который обрабатывает данные с PHY.
  13. В стандартной xilinx'овской библиотеке я не нашел делителя тактовой на 16, а счетчик Вы говорите лучше не использовать. Неужели даже для деления на 16 входной тактовой нужно использовать целый блок PLL или DCM? И еще вопрос про тактовые: "Как быть с тактовыми, частота которых не очень высока, например тактовая на интерфейсе I2C?". Неужели даже для таких тактовых нужно использовать глобальные буфера (BUFG) и писать констрейны для них? Просто я Е1 причислял к интерфейсам с низкой тактовой, поэтому не задумывался об констрейнах на Е1. Я попытался обконстрейнить все, что связано с Е1: NET "clk_32768" LOC = "C1" | IOSTANDARD = LVTTL; NET "clk_32768" TNM_NET = "clk_32768"; TIMESPEC "TS_clk_32768" = PERIOD "clk_32768" 30517 ps HIGH 50.00%; NET "e1t1_rclk0" TNM_NET = "e1t1_rclk0"; TIMESPEC "TS_e1t1_rclk0" = PERIOD "e1t1_rclk0" 488281 ps HIGH 50.00%; OFFSET = IN 122070 ps VALID 244100 ps BEFORE "e1t1_rclk0"; Это для тактовой 32.768 МГц и для входных данных. А как быть с передаваемыми данными, если тактовую для передаваемых данных вырабатываю я, из 32.768 МГц?
  14. Проблемы с времянками имеются. Для гигабитного интерфейса МАС требуется входная тактовая 125 МГц или более. У меня основная тактовая идет от генератора на 48 МГц. С помощью блока PLL_BASE я формирую частоты 64 МГц (для периферии и процессора, которые выращены на этой ПЛИС) и 128 МГц для данного блока. Вот что после сборки мне говорит Timing Analizer про частоту 64 МГц: Timing constraint: TS_CLKOUT1 = PERIOD TIMEGRP "CLKOUT1" TS_clk / 1.33333333 HIGH 50%; For more information, see Period Analysis in the Timing Closure User Guide (UG612). 23378864 paths analyzed, 16675 endpoints analyzed, 63 failing endpoints 63 timing errors detected. (63 setup errors, 0 hold errors, 0 component switching limit errors) Minimum period is 17.606ns. Я так понимаю, что данная проблема возникает из-за того, что много блоков (процессор, SPI, пара UART, контроллер памяти) подключено к этой частоте. Есть ли какие-нибудь способы исправить данную ситуацию?
  15. Здравствуйте! Являюсь начинающим разработчиком на FPGA. Работаю с ПЛИС Xilinx Spartan 6. Среда разработки ISE 14.7. Стоит задача: переброс данных из МАС уровня Ethernet в Е1. Имеется ПЛИС Spartan6 xc6slx150t-2fgg900, PHY Marvell 88E1111, сконфигурированный на работу по оптическому каналу на скорости 1 Gbs, E1 микросхема ds21348, сконфигурированная с NRZE = 1 (не биполярные данные на RPOS и RNEG (TPOS, TNEG), а используются только ноги RPOS и TPOS). Обмен информацией по Е1 организован с помощью HDLC протокола. Алгоритм работы: 1) полностью принимается пакет с МАС уровня (в буфер), убирается флаг готовности приема данных с МАС уровня; 2) этот пакет передается по Е1 удаленному абоненту, в конце передачи выставляется флаг готовности приема данных с МАС уровня; 3) удаленный абонент, принимая данные по Е1 кладет, их в буфер для передачи в МАС уровень; 4) сразу после окончания приема по Е1 удаленный абонент выдает в МАС уровень принятый пакет. Используемом соединение: точка-точка, поэтому количество пакетов не очень большое и время между пакетами не превышает времени передачи одного пакета по Е1, следовательно буфер приема данных с МАС уровня не должен переполняться (пока писал, подумал что не плохо было бы все-таки поставить флаг попытки положить данные из МАС уровня в буфер во время передачи по Е1). Суть вопроса: так как я являюсь начинающим разработчиком на FPGA, я не могу понять почему у меня при разных попытках сборки при малых исправлениях кода (или даже если вовсе код не править) все ведет себя абсолютно непредсказуемо? Пример: собрал проект, загрузил на плату, смотрю в Wireshark пакеты, приходящие от другого устройства - они абсолютно битые, вовсе не похожи на то, что надо. Запускаю SmartXplorer, выбираю один из вариантов сборки, загружаю на плату, получаю пакеты с битым широковещательным МАС адресом (заместо FF:FF:FF:FF:FF:FF принимается FF:7F:FF:FF:FF:FF или FE:FF:FF:FF:FF:FF), выбираю какой-нибудь другой вариант сборки в результатах SmartXplorer, получаю боле-менее стабильный результат, но есть потери пакетов (каждые 5 секунд высылаю пакет, но, примерно каждые 50 секунд 1-3 пакета теряются). Части кода, связанные с HDLC и МАС тестировались отдельно, в том числе создавались testbanches. Может что-то в настройках проекта следует указывать или как-то задавать какие-то параметры и флаги портам? Может как-то надо более правильно относиться к тактовым? (Тактовую 2.048 МГц для Е1 получаю простым счетчиком из 32.768 МГц). В общем, хотелось бы получить какие либо рекомендации по разработке устройств на ПЛИС чтобы не получать непредсказуемого поведения)
×
×
  • Создать...