Timmy

Флаг наличия более одного максимума можно вычислить деревом параллельно индексу максимума, он попадёт в max[8]: max0_0 = { sum_0000==sum_0001, sum_0000 > sum_0001 ? {sum_0000, 4'h0} : {sum_0001, 4'h1}}; max1_0 = { sum_0010==sum_0011, sum_0010 > sum_0011 ? {sum_0010, 4'h2} : {sum_0011, 4'h3}}; max2_0 = { sum_0100==sum_0101, sum_0100 > sum_0101 ? {sum_0100, 4'h4} : {sum_0101, 4'h5}}; max3_0 = { sum_0110==sum_0111, sum_0110 > sum_0111 ? {sum_0110, 4'h6} : {sum_0111, 4'h7}}; max0_1 = { max0_0[7:4]==max1_0[7:4], 8'b0} | (max0_0[7:4] > max1_0[7:4] ? max0_0 : max1_0); max1_1 = { max3_0[7:4]==max2_0[7:4], 8'b0} | (max2_0[7:4] > max3_0[7:4] ? max2_0 : max3_0); max = { max0_1[7:4]==max1_1[7:4], 8'b0} | (max0_1[7:4] > max1_1[7:4] ? max0_1 : max1_1);

Выход ПЛИС нужно сконфигурировать обычным пушпульным дифференциальным и использовать резистивные делители примерно 68Ом/330Ом. Линию - к средней точке делителя, 3.3В - к 68, пушпул- к 330. Получится почти точная эмуляция уровней и импеданса CML, и умеренная нагрузка для ПЛИС. Хотя нет, я забыл про второй конец, тогда потребуется делитель где-то 80Ом/200Ом. Насчёт MachXO2 не знаю, а ECP2 нормально работает с дифференциальной нагрузкой 200Ом/3.3В

В Верилоге, чтобы надёжно ссылаться на "глобальный" сигнал, требуется знать полный абсолютный путь, а это невозможно для стандартных компонетов, которые могут быть включены куда угодно. То есть возможно, но для этого потребовалось создать модуль glbl, голову абсолютного пути, который приходится ставить вторым топом, что неудобно. А в Латтисе сделали ещё хуже. Примерчик использования - выше я указал имя файла, открываем его и сразу вверху видим пример декларации глобальных сигналов. Далее открываем какой-нибудь файл компонента, например ISE_DS\ISE\vhdl\src\simprims\primitive\mti\X_BUFR.vhd, и видим в заголовке директиву use simprim.Vcomponents.all , которая открывает короткие ссылки на глобальные сигналы. И далее есть строчка GSR_dly <= GSR, которая забирает глобальный сигнал внутрь. Устанавливаться GSR должен в модулях X_SIM_CONFIG_*, и тут обнаружился сюрприз: в этих модулях есть директива use simprim.Vcomponents.all, однако GSR декларируется также и локально(это, похоже, ошибка), и по правилам по короткому имени будет устанавливаться локальный сигнал, который вообще нигде не используется. Таким образом, очень похоже, что GSR в VHDL тупо не моделируется, он всегда остаётся '0', как был инициализирован в глобальной декларации.

В рабочей копии создаётся полноценный клон всего репозитория и это правильно. Коммиты делаются только в этот клон, в удалённый репозиторий коммиты в принципе не делаются(это вам не SVN ), а делается PUSH, который можно выполнять параллельно редактированию рабочей копии. Чтобы коммиты выполнялись быстро, просто не надо добавлять в репозиторий всякий мусор.

У Гита есть существенный недостаток: при переносе/переименовании/клонировании файла(или хотя бы родительской папки) его клон не связывается с родителем и цепочка истории изменений прерывается и начинается с нуля. Я попробовал прочитать статью Линуса, почему он так сделал, но нисколько не проникся. Большие проекты Ртуть может и не очень тянет, но, подозреваю, большинству и не требуется поддерживать проекты масштаба ядра Линукса. На всякий случай сделал тестовый репозитарий с 17000 коммитов с добавлением по новой строчке в один файл. Ртуть ведёт себя вполне пристойно(кстати, гораздо лучше SVN), а больше коммитов в моих проектах в обозримом будущем не ожидается. Конкретно, в Workbench, хвост истории открывается почти сразу, общий фильтр по истории с условием tagged() и одним тегом в истории перевычисляется около секунды, другие варианты фильтра 7 секунд, история файла(с 17000 дополнений по 50 байт) открывается примерно полсекунды.

Если подсмотреть в Википедии формулу для обратного DFT(eq2), то можно видеть, что инверсии частоты там нет, и фунции exp(i/16) должны соответствовать бины в окрестности 1024/(2pi*16) => 10, что и наблюдается в Матлабе. Вопрос только, следует ли считать Википедию авторитетным источником?:) Например, в Математике обратное преобразование делается с инверсией частоты. Похоже, математики не сошлись во мнениях, как "правильно" :).

А я не понимаю. Идеологически Avalon достаточно близок к AXI, только у Avalon общий канал записи/чтения, а в AXI раздельные. Ну и в AXI предусмотрено много всяких дополнительных сигналов для серьёзных систем, которые в FPGA можно и не реализовывать. Может быть, в кросс напихали кучу FIFO буферов с памятью на LE(поскольку распределённой нема)? Кстати, в Q11 SOPC и QSYS дают почти одинаковый размер, но там ещё AXI вроде как нет.

Лучше в данном случае писать так: process (x) case x is when "00" => y <='0'; when "01" => y <='0'; when "10" => y <='0'; when "11" => y <='1'; when others => y <='X'; end case; end process; Это чтобы при функциональной симуляции процесс выдавал на выход неопределённое состояние в ответ на неопределённое состояние на входе. Иначе возникнет существенное несоответствие между функциональной и послесинтезной моделями. В послесинтезной модели "X" всегда будет передаваться на выход, даже если это не было явно указано в исходном коде.

В package vcomponents(файл ISE_DS\ISE\vhdl\src\simprims\simprim_Vcomponents.vhd) объявляется глобальный сигнал GSR, и все модули могут свободно на него ссылаться. Удобнее, чем в Верилоге:).

С помощью двух(если устроит синфазное 1650мВ) или четырёх резисторов можно привести напряжение к LVDS уровню.

Пробовали отключать -advdataflow ? вдруг поможет:). Кстати, его надо обязательно отключить, если не пользуетесь, так как иначе блокируется SLP, ускоряющий симуляцию Верилога примерно в 5 раз.

Создаём на внутренней логике двухбитный счётчик-делитель на 4(выходная частота будет 50МГц), его выход подаём на SDR триггер в IOB, инверсированный выход подаём на SDR триггер во втором IOB и всё. Будет работать от 200МГц по одному фронту без инверсий клока, сдвигов фаз, DDR-ов и обратной связи через IOB.

Сверху они в декларации компонента, а не entity, так что не входы, так можно. Меня, как и компилятор, больше беспокоит несоответствие типов формальных и фактических параметров:).

Может быть, вы сломали функцию смены адреса. Она происходит как раз после энумерации, и если адрес не сменить, то протокол работать дальше не будет.

Да, это такая багофича в ActiveHDL - в индексах агрегатов нельзя использовать дженерики и производные от дженериков константы, а только локальные константы. А ещё нельзя использовать "others=>" совместно с unconstrained ports и производными от них:). При этом без агрегатов можно сделать то же самое без проблем...

По-моему в символьном виде описать преобразования описать гораздо проще. Исходные с добавленной задержкой на такт по всем входам: outA = Z(Z(inA)+outD) outB = Z(Z(inA)+Z(inB)+outD) outC = Z(Z(inA)+Z(inB)+Z(inC)+outD) outD = Z(Z(inA)+Z(inB)+Z(inC)+Z(inD)+outD) И перегруппировать outC и outD, исходя из того, что Xilinx 6+ серии умеет складывать тройки в одной цепи переноса: outC = Z(Z(inA+inB+inC)+outD) outD = Z(Z(inA+inB+inC)+Z(inD)+outD) Можно и по двойкам перегруппировать, но получится больше сумматоров и задержка ещё на такт, например, для outD: outD = Z(Z(Z(inA+inB)+Z(inC+inD))+outD)

Применительно к сетевой транзакции правильный перевод - начатая, но ещё незавершённая, выполняемая на текущий момент, транзакция. Вот мастер выставил в канале адреса запрос, и с этого момента транзакция будет считаться outstanding, пока мастер не получит подтвержение завершения данной транзацкии по каналу чтения/подтверждения записи. multiple outstanding предполагает, что мастер выставит конвейером кучу запросов на транзакции, не дожидаясь последовательно подтверждения ранее начатых, а если сказано only one otstanding, значит, мастер, выставив запрос, должен ждать его подтверждения, и только потом может выставлять следующий. Например, на шине Wishbone в принципе нельзя сделать multiple outstanding transactions, какое безобразие;).

Проблема, вероятно, в пустых кавычках. Можно написать так: unsigned'("")&carryIn

В r запишутся единицы.

Проверил на следующем коде: library IEEE; use IEEE.STD_LOGIC_1164.all; entity mult_drv is -- port(clk:std_logic); end mult_drv; architecture tb of mult_drv is signal clk:std_logic:='1'; type r_t is record a,b:std_ulogic; end record; signal r:r_t:=('1','0'); begin a:process(clk) is begin if rising_edge(clk) then r.a <= not r.a; -- r.b <= 'Z'; end if; end process a; b:process(clk) is begin if rising_edge(clk) then r.b <= not r.b; end if; end process b; clk <= not clk after 0.5 ns; end tb; Всё работает чисто в modelsim 10.2 и Active hdl 9.1. Если раскомментировать строчку r.b<= 'Z', то не работает, именно по причине unresolved multiple drivers. А с типом std_logic работает и так. Заглянул в стандарт, там очень сложный английский, но как я понял, в случае композитных сигналов процесс создаёт драйверы только для тех элементов композитного сигнала, которые использовались в операторах присваивания, а не для всего композитного сигнала. Сам активно использую управление структурами из разных процессов и таких проблем никогда не было.

И ещё одна(и, похоже, главная) причина неправильной перестановки файлов проекта - в VHDL комментариях, расположенных выше последней заголовочной директивы USE, не должно быть русских букв. Какая прелесть!

Отваливается JTAG - это надо понимать, как отваливается JTAG Debugger? Вероятная причина - блокировка шины Avalon. Так что стоит посмотреть на шины данных и команд в SignalTap, а лучше в симуляторе, если там проблема будет воспроизводиться.

Такая идея у меня тоже была, но реально разбивку приходится делать не так часто, чтобы писать для этого кучу процедур. Причём для out сигналов и переменных нужны отдельные процедуры:). И для всех возможных сочетаний сигналов и переменных . Для автоматической разбивки я использую многократный вызов процедуры с передвижением индекса: procedure get_bits_s(signal v:out std_logic_vector;s:std_logic_vector;i:inout integer) is begin v <= s(i+v'length-1 downto i); i := i+v'length; end procedure; ... i := 0; get_bits_s(strobe_out, s, i); get_bits_s(addsub_sel, s, i); get_bits_s(const_adr, s, i); get_bits_s(regs_wa, s, i); get_bits_s(regs_ra, s, i); В функциях использовать out параметры, к сожалению, нельзя, а то можно было бы лучше сделать.

В VHDL 2008 можно легко разобрать сигнал на части, примерно как в Верилоге, с помощью агрегата. Однако это нельзя сделать прямо в порт мэппинге, требуется использовать промежуточный сигнал. Разработчики стандарта явно не знакомы с принципом бритвы Оккама.

Если дженерик соотвествует ширине какого-нибудь порта, то такой дженерик вообще не нужен, достаточно сделать этот порт unconstrained, и узнавать его фактическую размерность через стандартные атрибуты. В этом VHDL даже удобнее Верилога.