egorman44

нет таких кейсов , ессно надо удалить (просто копипастил откуда-то) : set all_rams [get_cells -hier -filter {IS_PRIMITIVE && REF_NAME =~ RAMB*}]

Если вы работает в батче то заворачиваете все то, что написал Роб в скрипт file_name.tcl (можно добававить, чтобы скрипт писал в файл): set bram_file [open "your_directory/bram_file.log" "w"] set all_rams [get_cells -hier -filter {IS_PRIMITIVE && ((REF_NAME =~ RAMB*) || (REF_NAME =~ FIFO*))}] foreach ram $all_rams { puts $bram_file "Ram $ram is in location [get_property LOC $ram]\n" } close $bram_file И последней строчкой в вашем скрипте по имплементу исполняйте file_name.tcl: source file_name.tcl

А еще при особом желании и острой необходимости можно замутить переинициализацию вашей блочной памяти прямо в bit файл. Для этого надо найти географическое положении памяти после имплемента, вынуть его и положить в mmi файл , скормить все утилитке updatemem от Xilinx и радоваться жизни. ООоочень помогает если билд процесс длиться безобразно долгое количество времени.

В качестве такого seed можно взять текущий момент запуска теста , преобразованный в необходимый формат .

Похоже я поборол этот глюк, по умолчанию разделитель в иерархическом имени в Synplify является точка "." и я предполагаю , что задав констрейн на выход BUFG через t:xilinx_1gig_pcs_pma_inst.inst.core_clocking_i.bufg_userclk2.O синтезатор не смог понять что "bufg_userclk2.O" - это выход "O" у "буфера bufg_userclk2". Пришлось отказаться от использования SCOPE и использовать "/" в качестве разделителя:

Всем здравствуйте подскажите пожалуйста , как мне задать create_clock для выходного пина клокового буфера BUFG. Тут появилась какая-то гуйня под названием SCOPE я в ней обзываю клок и указываю объект откуда он зарождается, путь к объекту взял в Technology View. Нажимаю Check Constraints в репорте получаю следующее: create_clock -name { TXUSRCLK2 } { t:xilinx_1gig_pcs_pma_inst.inst.core_clocking_i.bufg_userclk2.O } -period { 16 } @E:"/u/esmirnov/wa_B0/atlanticB0_three/Logic/fpga/synplify_run/dig_fpga_top/dig_fpga_top.fdc":28:0:28:0|object "t:xilinx_1gig_pcs_pma_inst.inst.core_clocking_i.bufg_userclk2.O" does not exist Кто может подсказать чего ему не нравиться ?

Ему же можно влепить 10Gbase - X/R. А модулю SFP - ещё и SGMII можно совместно с 1000base-x, чем же RXAUI будет хуже ?! То что тут 2 лэйна , и будут траблы с синхронизацией, или это все я глупости говорю какие-то я писал: Чип на борде такой http://www.aquantia.com/products/data-center/aq2402/

Здравствуйте многоуважаемые форумчане. Есть задача подключить борду с 10G PHY к MAC'y реализованном на отладке ПЛИС. Из скудной информации на PHY понял, что со стороны MAC можно использовать XFI / RXAUI интерфейсы. Полазив в стандартных корках Xilinx я нашел RXAUI IP core, успех ! Смотрю на PHY вижу, что у него со стороны MAC - 8 SFP+ модулей. У меня накопилось несколько вопросов, на которые я затрудняюсь найти ответы спрашивая это у Интернета. 1. Я всегда думал, что sfp это просто конвертер электрического диф. сигнала в оптический , и соответственно sfp модулю по барабану какой протокол по дифф паре в него поступает , будь то 10Gbase-R или RXAUI. Во втором случае, просто будет необходимо использовать два sfp кабеля для подключения, т.к. у RXAUI на выходе 2 лэйна по 6.25 Мbs? 2. Что такое XFI ? Загуглив я наткнулся на оптические модули конкурентов SFP , но какое отношение это имеет к протокольным делам я не понял. Господа помогите разобраться в этом сложном оптическом мире ?

Эм... нашел вкладку Design Optimization , там стоит Enable Most Optimization(o4) , т.е. как я понял, оптимизации очень много :) Выше только О5. Но когда захотел поменять , то кнопка ОК не активна оказалась. Че он ? В консоль скидывает грозную красную надпись типа оптимизация отменена. # Optimization canceled upd. Черт, все работает , все сигналы отображаются. Но я был готов поклясться , что в прошлый раз этого не было :laughing:

Добрый день ! :santa2: Имеются пару-тройку сигналов, которые пересекают клоковый домен, объявлены типа: reg [ADDR_WIDTH_par : 0] gray_rd_ptr_in_wr_domain[1:0]; И что-то modelsim не хочет выводить их содержимое в окно wave, сразу располагает на вкладку Memory List. Ну собственно ребяты подскажите как отобразить такие сигналы , если конечно имеется возможность ?

Огромное спасибо за ответы. :) Эта версия кажется мне правдоподобной.

Здравствуйте многоуважаемые форумчане. Сегодня занялся переносом проекта со Spartan'a 3 на 6-ой. Выкинул некоторые примитивы, поменял назначения пинов и т.д. и т.п. Начал собирать проект и во время "Place and Route" мне вывалилось сообщение: ERROR:Place:1136 - This design contains a global buffer instance, <i2c_module/word_control/fsm/wr_rd_derived_clock_cb>, driving the net, <mpi_rw>, that is driving the following (first 30) non-clock load pins. < PIN: tss_module/tss_module/connect_mem/BU2/U0/blk_mem_generator/valid.cstr/ramloop [0].ram.r/s3a_noinit.ram/dpram.ram.WEA3; > < PIN: tss_module/tss_module/connect_mem/BU2/U0/blk_mem_generator/valid.cstr/ramloop [0].ram.r/s3a_noinit.ram/dpram.ram.WEA2; > < PIN: tss_module/tss_module/connect_mem/BU2/U0/blk_mem_generator/valid.cstr/ramloop [0].ram.r/s3a_noinit.ram/dpram.ram.WEA1; > < PIN: tss_module/tss_module/connect_mem/BU2/U0/blk_mem_generator/valid.cstr/ramloop [0].ram.r/s3a_noinit.ram/dpram.ram.WEA0; > This is not a recommended design practice in Spartan-6 due to limitations in the global routing that may cause excessive delay, skew or unroutable situations. It is recommended to only use a BUFG resource to drive clock loads. If you wish to override this recommendation, you may use the CLOCK_DEDICATED_ROUTE constraint (given below) in the .ucf file to demote this message to a WARNING and allow your design to continue. < PIN "i2c_module/word_control/fsm/wr_rd_derived_clock_cb.O" CLOCK_DEDICATED_ROUTE = FALSE; > Все что написал он мне, я понял. Но извините, почему сигнал <mpi_rw> с выхода автомата состояний, который управляет записью в BLOCK RAM, был заведен в глобальный клоковый буфер?! Я сбит с толку, господа прошу разъяснить что не так и кто в этом виноват . И понятно, что можно использовать CLOCK_DEDICATED_ROUTE дабы перемолоть все вышеупомянутое, но это не по фэншую вроде бы как.

Writing Testbenches_2nd_Edition Janick Bergeron http://www.testbench.in/TB_00_INDEX.html

Извините конечно, но мне кажется, что Вы на тактовый вход триггера, хотите подать сигнал с кнопки ?! В то время как надо подавать тактовый сигнал :)

Управляемый и даже подключен к процессору, но софт для процессора не написан :) Так что switch просто устанавливается при включении по дефолту и вперед. Про flow control ответить затрудняюсь. На отладке проц с тем же софтом, но подключенный напрямую к PHY не теряет пакетов . Есть предположение, что MII через PLD разъемы и общей трассой протяженностью примерно 20 см, может много чего поймать. Интересно, есть какая-нибудь бумажка, по поводу этого дела ? Например , длина проводников не должна превышать столько-то столько-то для MII. Или это ересь ?! :)

Генерирую трафик UDP, утилитой iperf. Во время теста мониторю вход RX_ERR на наличие ошибок, но событие не наступает .

Всем здравствуйте ! :) На устройстве используем 100 Мб Ethernet. На плате №1 имеется микросхема PHY которая принимает пакеты, далее передает их по MII к FPGA. FPGA осуществляет простой проброс MII интерфейса и через PLD коннекторы все это дело передается на плату №2. На плате №2 MII далее идет на switch к которому подключен процессор. В таком подключении сеть на процессоре присутствует. Но при проверке, допустим генерируя 2 Мб/с трафика, теряется 2% пакетов, приходящих к процессору. По поводу длины линий, на плате №1, RX_CLK длиннее остальных на 50мм (полная длина линии от FPGA до PLD коннекторов 152 мм), между остальными линиями (RXD<0..3>, RX_DV, ... ) разбег не превышает 2.5 мм. На плате № 2 длины проводников согласованны. Я занялся расчетами и получил что RX_CLK опаздывает (очень) примерно на 0,35 нс, период MII = 40 нс. Я так полагаю это не критично ?! Пробовал пропускать сигналы RX линии MII через D триггеры тактируемые на частоте 150 МГц, пробовал задерживать сигнал RX_CLK на величину кратную 1/6 периода ничего не помогло . :( Господа прошу помощи в разрешении вопроса. Куда примерно посмотреть, что попробовать, чтобы исчезли потери пакетов. ?! :)

Можно инициализировать регистр в initial блоке reg[3:0] rom [0:7]; initial begin rom[0] = 4'b1011; rom[1] = 4'b0001; rom[2] = 4'b0011; rom[3] = 4'b0010; rom[4] = 4'b1110; rom[5] = 4'b0111; rom[6] = 4'b0101; rom[7] = 4'b0100; end UPD: ну только если в дальнейшем вы обязуетесь нигде не присваивать новых значений двумерному массиву rom :) UPD2: да и в правду чего жадничать , есть такой документ под названием 1364.1 IEEE Standard for Verilog ® Register Transfer Level Synthesis там в параграфе 5.6 Modeling read-only memories (ROM) собственно можно посмотреть примеры моделирования ROM памяти при помощи Verilog

Ну и какой момент показался Вам самым интересным в этой статье ? :)

always @(posedge handshake) begin got_handshake <= 1; end Не уверен, что сигнал с названием handshake является тактовым. Вы в клоковое дерево вашей ПЛИС пытаетесь завести сигнал handshake так делать нельзя. Такое ощущение, что здесь вы хотите синтезировать защелку по сигналу handshake, так и синтезируйте, если очень конечно нужно: always @(*) if(handshake) got_handshake = 1; always @(*) begin if (counter_next > 1024) begin counter_next <= 0; end else counter_next <= counter + 1'b1; end reg [0:0] state, next_state; always@(*) begin if (rst) begin out <= 0; out2 <= 0; counter <= 0; state <= S1; end else case (state) S1 : begin out <= DA1[counter]; out2 <= 1'h1; next_state = got_handshake ? S2 : S1; counter <= counter_next; end S2 : begin out <= frame[counter]; out2 <= 1'h1; next_state = S1; counter <= 0; end endcase end очень странно, что вы пытаетесь сделать автомат и счетчик асинхронными, у Вас отсутствует кварц на плате ? :) Такой автомат работать не будет. Посмотрели бы пример от Altera хотяб: always @(posedge clk or posedge reset) begin if (reset) state = zero; else case (state) zero: state = one; one: if (in) state = zero; else state = two; two: state = three; three: state = zero; endcase end Откуда видно, что автомат из состояния в состояние переходит по переднему фронту clk, ну еще и асинхронно сбрасывается по reset. Я так думал что когда описываешь комбинаторную логику пользуешься блокирующим присваиванием (=). И собственно использовать оба типа присваивания в одном always блоке , тоже не особо приветствуется: S2 : begin out <= frame[counter]; out2 <= 1'h1; next_state = S1; counter <= 0; end Я так полагаю Вы не особо тщательно смотрели ваши книги по верилогу :) Для начала бы Вам разобраться в синтезе комбинаторной и последовательной логики (combinational and sequential logic) ну и с блокирующим и неблокирующим присвоением соответственно.

Я бы Вам рекомендовал почитать что-нибудь от Sunburst Design - у этих ребят много рассуждений по поводу реализации конечного автомата на Verilog и SV, конечно если с английским хорошо. У Iosifk на сайте есть краткий курс , там тоже описаны FSM'ки. Да собственно по первому же запросу в Google на тему "fsm verilog" вывалился пример от Altera. Я думаю лучше самому понять как это работает, потому что конечный автомат - есть очень важный момент в цифровой схемотехнике. :)

А чего тут такого сложного ? Берете карандаш ,листок , бумагу ... Рисуете состояния и правила перехода из них, затем плавно переносите на HDL. Тема fsm verilog/VHDL гуглится хорошо. Я же вроде бы писал : Или Вам еще не доводилось описывать конечные автоматы ? Вы на каком языке собрались это делать ?

можно написать конечный автомат, который будет висеть в состояние до того момента как придет emacclienttxack, и находясь в новом состоянии будет выдавать новые данные на clientemactxd. Опять же настоятельно рекомендую посмотреть пример. В примере между MAC контроллером и модулем client_side вставлен FIFO, и соблюдение всех рукопожатий ложится на этот модуль, Вам же остается просто кидать данные в FIFO и следить чтобы он не переполнился, если вы работаете на передачу. Для верификации сколько хош :) UPD: я может чего не так понял , если вы пользуете ядро под номером 4.6 то в папке куда у вас сгенирировалась корка есть папка example_design в ней и смотрите пример

очень верный способ, на мой взгляд. Плюс ко всему там тестбенч написан, который можете запустить даже в Isim и посмотреть что к чему. Так же есть дока официальная на корку UG138 "LogiCORE IP Tri-Mode Ethernet MAC v4.5" там все ответы на интересующие Вас вопросы.

Как я понял у вас есть 1500 байт данных, которыми вы инициализируете массив и вам надо их выдать наружу, коль хотите использовать parameter ? Не проще ли будет использовать RAM блоки на 1500 байт, и формируя адрес читать содержимое, выдавая по 8 бит. Предварительно проинициализируйте RAM блок командой $readmemb. Да и как у Вас счетчик то работает ? Может он по какой-то внешней команде начинает считать и останавливается , или же постоянно молотит переполняясь на значении 1500 ?