gin

Max V - это всё же CPLD, там даже блочной памяти нет. Наверное, это не лучший вариант для работы по Ethernet. Но при желании, ее можно подключить по GMII, т.е. 8 битная шина без DDR. Кстати, это еще один момент, почему для MAC-ядра не обязательны констрейнты. Ведь один и тот же gigabit MAC можно подключать как по RGMII, так и просто по GMII, если такое PHY позволяет. То есть MAC - это уже про логику работы, а входы/выходы - это тонкости архитектуры конкретной ПЛИС. Они описываются и констрейнтятся отдельно. А ведь есть еще и последовательный SGMII. Он вообще по-другому подключается. Там даже служебные слова, такие как преамбула и идлы - они другие. Конечно же это мой субъективный взгляд. Не для спора, а для обсуждения и обмена опытом.

Понятно, спасибо. Значит это не универсальный вариант. Как быть с Альтерой, или вообще со специфическими 'китайцами'?

Если я правильно понял, ваш подход в следующем: 1. Регистры в ножках не используете, все регистры внутри. 2. Констрейнтами задаете требуемое положение данных относительно клоков. 3. Исходя из требований, разводчик сам пробрасывает пути данных внутри ПЛИС от входов до регистров (и обратно), следя за выполнением констрейнтов. Пожалуй, это более универсальный поход. Он не зависит от внешних микросхем И тогда вопрос, насколько точно у разводчика получается выполнять констрейнты?

Я в своей практике сталкивался с возникновением проблем при передаче данных от FPGA на PHY; по приему от PHY на FPGA никогда проблем не было. Если двигаем выходной клок на PLL, то да, констрейнты лучше писать, в этом полностью согласен. Ведь до конца нам не известно как будет проведен сигнал с PLL на ножку. Вполне возможно, что если не обконстрейнтить, то уедет фаза. В последнем проекте я это поленился сделать, скажу честно. Но это был макет на столе, просто для тестирования. Там у меня стабильно всё работало. Чем удобно двигать клоки на самом PHY. Я могу ему указать, что у меня данные на выходе ПЛИС переключаются строго по фронту клока. И на выходных DDR регистрах я это обеспечу (с точностью до нескольких десятков пикосекунд). А дальше сам PHY сдвинет внутри себя клок на 180 градусов. То же самое и для приема на FPGA. Указываю PHY, чтобы он сдвинул свой выходной клок относительно данных на 180 градусов. На приеме на стороне FPGA в ножках регистры, задержки минимальны. Мне лично такой подход кажется удобным. Каких то проблем с ним никогда не было на практике. p.s. поправка - конечно же сдвиг на 90, а не на 180

вот небольшой пример как я в тестбенче задавал случайную паузу: rd_pause_proc : process --uniform variable seed1 : positive := 951; -- seed1 values for random generator variable seed2 : positive := 532; -- seed2 values for random generator variable rand : real; -- random real-number value in range 0 to 1.0 -- variable p : natural := 0; begin . . . UNIFORM(seed1, seed2, rand); p := integer(rand*real(4)); wait for per_rd*p; req_pause <= '1'; wait for per_rd; . . . end process; процедура UNIFORM описана в пакете ieee.math_real use IEEE.math_real.all; В этом примере пауза была от 0 до 3 тактов клока периодом per_rd

Как уже выше написали, констрейнты на RGMII не обязательны. Если все триггеры расположены в ножках, то задержка будет минимальная и в основном зависящая уже от разводки платы. А смещение клока относительно данных (по RX и по TX) задается настоечными регистрами PHY по MDIO. Хотя не все микросхемы PHY это позволяют. Marvell 88e1111 - может внутри себя двигать клок. А вот например, недавно работал с такой микросхемой как DM9119INP (DAVICOM Semiconductor) - она не позволяет. Двигал клок внутри ПЛИС на PLL. Что касается самой сути поста - продукт или пример. То скорей всего пример. Ведь никто не гарантирует сто процентную работоспособность бесплатного кода, по доброй воле выложенного в интернете. Такие вещи можно использовать для прототипирования или макетирования. Для коммерческих изделий лучше писать самому. ИМХО

Заказчик - это представитель сторонней организации? Если сторонней, то как вообще он может быть руководителем вашего разработчика? Ведь для разработчика есть должностная инструкция, в ней указано кому он подчиняется. И это явно должен быть человек не сторонний. И если ко мне как разработчику придет с претензиями какой то левый человек - то я вполне имею право с ним вообще ничего не обсуждать и прямо послать его к своему руководителю. Пущай они друг дружке мозг выносят, а не мне)

Ваше ТЗ - это документ? С номером и датой, с подписями исполнителя и заказчика? С подписью утверждающего? Как ваше ТЗ при работе по скраму выглядит? Можете здесь пример вашего ТЗ привести, хотя бы шаблон?

И еще одно замечание - по поводу ТЗ. Почему скрам-мастера и прочие аджайл-коучи его так не любят и всячески избегают. Ведь ТЗ - это не какая то бумажка, которой можно подтереться. Нет, это документ, причем юридически значимый документ, который и в судебных спорах может использоваться если что. И вот, дорогой скрам-мастер, если ты поставил свою подпись под требованиями ТЗ - буде ласка исполняй. Это ответственность, от которой вся эта 'эффективная братия' бежит как от огня. Тут уже не прокатят разговоры про командную ответственность, не получится свалить свои косяки на Васю-программиста или Петю-тестировщика. Поставил свою подпись - тебе и отвечать за косяки! Я уж и не говорю, что самостоятельно написать ТЗ они никогда и не смогут, хотя это вполне нормальная работа для главного конструктора или главного инженера. Опыта и знаний у них нет, только общие слова. А общие слова в документе не нужны, конкретика нужна.

В большинстве случаев, все эти скрамы и аджайлы - это просто имитация бурной деятельности различными 'рукамиводителями' и прочими 'эффективными манагерами'. Это люди которые не программисты, не схемотехники и не конструкторы. Своими руками никогда ничего не делали. Код не писали, схемы не чертили и паяльником пальцы себе не обжигали. То есть это люди, которые не имеют практических навыков и знаний в инженерном деле. Но кушать то им хочется, и кушать вкусно. Потому они и выдумывают разную псевдоинженерную мурню, прикрывая ее большим количеством непонятных, но умно звучащих слов, втираясь в доверие к высокому начальству. Скажу может быть даже грубо - это очковтиратели и приспособленцы. А если посмотреть назад в историю, то Туполеву не нужны были аджайлы при работе над ТУ-4. Курчатов не пользовался скрамом при разработке своей РДС-1 (а эти изделия были уж точно посложнее очередного сайтика в Интернете). Причем свои задачи они успешно выполнили в достаточно сжатые сроки. Просто они сами инженерами были, потому и другими инженерами руководить могли. На одном языке с ними говорили. Так что и нам надо брать с них пример. P.S. Это конечно же всё моё сугубо личное мнение, на истину в последней инстанции не претендующее.

Софт конечно своеобразный, я бы сказал несколько сырой. Но работать можно. По быстродействию - Ефиниксовский Trion примерно на 30% медленнее чем Альтера. Сравниваю с MAX10. Quartus 20 одни и те же алгоритмы разводит лучше, чем Efinity

По идее, если использовать триггер, расположенный в пине, то от этого триггера до физического выхода - там совсем копеечная задержка выйдет? Посмотрел пример, который дает Terasic для своей отладочной платы. Так там они выходной клок двигают именно на PLL. Причем для частоты 100 МГц сдвиг - минус 3 нс. Т.е. клок как бы опережает данные. Любопытно. Очень похоже просто на некое магическое число, экспериментально подобранное для конкретной электрической схемы. Констрейнты у такие: set_output_delay -max -clock clk_dram_ext 1.6 [get_ports {DRAM_DQ* DRAM_*DQM}] set_output_delay -min -clock clk_dram_ext -0.9 [get_ports {DRAM_DQ* DRAM_*DQM}] Судя по всему, без PLL в такой задаче не обойтись. Смещение выходного клока - на нем, а констрейнты - только для контроля правильности разводки. Причем, видимо, сдвиг на PLL нужно отдельно рассчитывать исходя из тактовой частоты. Для 100 МГц - один, для 200 - другой. Эх, а как хотелось бы сделать универсально...

Да, я так когда то и делал, двигал фазу выходного клока. Но там была опытная разработка и нужно было проверить на стенде работу алгоритма. Потому обмен с SDRAM делал на скорую руку. И мне тогда такое решение со сдвигом клока не очень понравилось. Подумал, может быть есть какие то более элегантные варианты. Почему мне еще не хочется сам клок двигать: например, при чтении из памяти, ответные данные тоже будут сдвинуты относительно моего внутреннего клока. Как то это всё к усложнению на приеме на ПЛИС приведет. Хотелось бы уйти от этих усложнений, если такое возможно.

Добрый день, коллеги! Давно я не работал с синхронной памятью, и немного стал подзабывать тонкости. Непосредственно сам вопрос в заголовке. Но если рассмотреть более подробно, то пусть имеется вот такая упрощенная диаграмма, ее нужно реализовать на выходе ПЛИС: Имеется выходной клок CLK и выходные данные DQ (на самом деле это двунаправленная шина, но сейчас не важно). Есть ограничения на 'data setup' и 'data hold', пусть для примера Tds = 1.5 ns, Tdh = 0.8 1. Как правильно написать констрейт? Например так будет корректно? set_output_delay -max -clock clk -1.5 [get_ports {DQ}] set_output_delay -min -clock clk +0.8 [get_ports DQ}] 2. Как правильно вывести выходной клок CLK относительно внутреннего. Будет ли достаточно сформировать его на PLL без смещения фазы? Или здесь тоже нужны констрейты? 3. Нужно ли для сигнала DQ устанавливать выходной триггер в ножке? Или в данном случае это неправильно и синтезатор не сможет так обеспечить требуемые Tds и Tdh 4. Ну и последний вопрос. Следует ли учитывать в контрейтах задержки при распространении сигналов на плате? Где то в примерах видел, что добавляют погрешность +/- 100 ps Получается, что Tds = 1.5+0.1 = 1.6 ns; Tdh = 0.8+0.1 = 0.9 ns

Мне кажется, что человеку еще рано за языки браться пока нет понимания цифровой схемотехники. Ему нужно начать с самых базовых вещей. Понять что такое комбинационная логика, триггеры (RS, D); мультиплексоры, счетчики, памяти. Зачем нужен тактовый сигнал. Без этой базы вряд ли что то дельное получится. Пока видно, что человек плавает в самых простых вещах. Найти какой-нибудь хороший институтский курс по цифровой схемотехнике.