Лидеры

Как считать Rogers-like материалы с предельной точностью, когда у них анизотропия по эпсилон самого материала и сама технология pcb изготовления оставляет желать лучшего? На разных структурах разные эффективные параметры от диэл. проницаемости до tan потерь. У воздушных линий измеряют только геометрию. Поэтому керамика с напылением значительно интересней в т.ч. и по другим физическим параметрам.

Разъемы считаются, переход тоже. Неизвестных потерь в известных материалах не наблюдается. Линии с разъемами также можно задать в виде data-based или математической моделью. Кристаллы же успешно обмеряют.

Разве? Где сигнал ready? А вот когда он появится, тогда не получится. Через строковый параметр parameter RAM_TYPE = "block" ... localparam L_RAM_TYPE = (RAM_TYPE == "block") ? "block" : "distributed"; (* RAM_STYLE = L_RAM_TYPE *) reg [DATA_WIDTH-1:0] buffer [0:BUFFER_DEPTH-1]; // Кольцевой буфер предыдущих отсчетов

Прежде чем беспокоить DSP или зазря переписывать always есть смысл посмотреть логи и понять что же является узким место в плане времянки. Из приведенного куска кода вопрос может вызывать только assign last_out = (read_ptr == write_ptr - 1) ? 1'b1 : 1'b0; Так как сравнении идет с не с регистром, а с разностью - и это может влиять на времянку.

я в свое время написал аналогичный модуль library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; entity delay_line is generic( W : integer := 8; -- data width L : integer := 1200); -- delay length, shall be > 3 port( i_clk : in std_logic; i_sync_reset : in std_logic; i_data : in std_logic_vector(W-1 downto 0); o_data : out std_logic_vector(W-1 downto 0)); end delay_line; architecture rtl of delay_line is type t_ram is array (L-2 downto 0) of std_logic_vector(W-1 downto 0); signal m_ram : t_ram; signal r_addr_wr : integer range 0 to L-2; signal r_addr_rd : integer range 0 to L-2; signal r_enable_read : std_logic; begin p_write : process (i_clk) begin if rising_edge(i_clk) then if(i_sync_reset='1') then r_addr_wr <= 0; r_enable_read <= '0'; else m_ram(r_addr_wr) <= i_data; if(r_addr_wr<L-2) then r_addr_wr <= r_addr_wr + 1; else r_addr_wr <= 0; r_enable_read <= '1'; -- enable reading section end if; end if; end if; end process p_write; p_read : process (i_clk) begin if rising_edge(i_clk) then if(i_sync_reset='1') then r_addr_rd <= 0; else if(r_enable_read='1') then o_data <= m_ram(r_addr_rd) ; -- additional delay if(r_addr_rd<L-2) then r_addr_rd <= r_addr_rd + 1; else r_addr_rd <= 0; end if; end if; end if; end if; end process p_read; end rtl; тоже по кольцу пишет, но может обеспечить задержку... PS все предложенное варианты реализации фифо... Вам предложу рассмотреть реализацию счетчика на базе конвеера из более мелких счетчиков, должно повысить тактовую частоту...

Я не специалист в ПЛИС, но... почему так? Зачем запрещать запись?

Просто оставлю это здесь ) https://git-scm.com/book/ru/v2 Вчера обновил резюме на hh.ru и вдруг обнаружил, что по тегу Git можно пройти тестирование. Так что переходить на Git или нет - пойми, даже вопрос так не стоит )) Это маст хэв скилл

Раз такой открытый обмен мнениями, то позволю себе. Оценка будет жёсткая (любителям svn не понравится), но зато правдивая: если сравнивать git vs svn в контексте именно управления версиями, то git является системой управления версиями как таковой, а svn нет. svn, cvs, Perforce и все подобные системы с центральным репозиторием являются скорее системами инкрементального архивирования с функциями менджмента кода (особенно Perforce). Главное, что отличает git от перечисленных и делает его эффективным имеено как систему управления версиями -- это способность лёгкого, быстрого создания веток и их эффективного слиния хоть методами merge, хоть rebase. Именно такие ветки (которые по сути ветками и не являются -- это традиционное, устоявшееся название, а по сути это просто перемещаемые вместе с "головой" (HEAD) метками) и позволяют бесплатно (ничего не внося в код, не плодя копий) вести отслеживание изменений кода. git позволяет делать реально атомарные комиты -- т.е. когда в комит входят изменения, касающиеся только чего-то одного. Это очень важная штука: такие комиты можно легко таскать между ветками, их можно отменять, не ломая других фич. Вот эта схема с индексом (stage) именно для этого и предназначена (когда в начале не понимал этого, тоже раздражало, что вместо просто commit надо ещё в add в индекс делать, хорошо, что хоть опция -a там была 🙂) : нередко бывает, что изменения кода в одном файле относятся к разным по смыслу фичам/фиксам, и пихать это в один комит неправильно -- потом его ни отменить (нечасто это надо, но бывает), ни перетащить изменения в другую ветку, где они актуальны уже сейчас (а другие изменения и этой ветки, где комит, пока не нужны, они ждут своего слияния в общую ветку). Так вот, git позволяет добавить в индекс выборочно правки из файла, не трогая другие. И так, накидав в индекс, изменения, связанные по смыслу, из разных файлов, можно получить, закомитив, тот самый атомарный комит. Делается это командой git add -i. Существует вполне удобный GUI инструмент для этого -- git-cola, в ней можно прямо выделять в файле нужные строки изменений и добавлять в индекс (или удалять из индекса добавленное по ошибке). Push после каждого комита тоже делать совершенно не нужно. git -- это система с локальным репозиторием, самый главный реп -- это тот, с которым вы работаете, который лежит у вас рабочем проекте. Push -- это просто способ опубликовать ваши изменения (серверов для публикации может быть сильно больше, чем один 🙂 ). Публиковать надо тогда, когда это необходимо, и не ранее. Пока всё лежит локально, можно менять историю изменений, устраняя ошибки при комитах. Это позволяет легко держать историю проекта красивой и удобной для ретроспективы. Это крайне важная штука -- по такой истории можно быстро эффективно найти практически всё (пример такой истории можно посмотреть по ссылке ниже), по ней легко разобраться, когда что происходило и быстро "вспомнить" нюансы ушедшего в прошлое процесса разработки. К сожалению, тот же svn не позволяет ничего из вышеперечисленного. Ветвление в нём -- это боль. Поэтому типовая история проекта в svn (cvs или Perforce) -- это ровная цепочка комитов, глядя на которую, не понятно, где когда что делалось -- нужно ползать по всем звеньям цепочки и искать, вчитвываясь в комментарии. И комиты там редко бывают атомарными, обычно комит в svn -- это целый список несвязанных между собой изменений. Да, конечно, и в svn можно стараться делать короткие атомарные комиты, но это технически непросто делать, когда разные по смыслу изменения присутствуют в одном файле. Есть пара моментов, где системы svn/Perfoce сильнее, чем git: связь с внешними репозиториями; работа с нетекстовыми файлами большого размера. Оба преимущества проистекают из того, что svn/Perforce основаны на нативной файловой системе: единицы слежения за изменениями -- это файлы, ветки -- это директории. Это позволяет легко цеплять сторонние репозитории как директории (хоть целиком, хоть фрагменты) через svn:externals в svn или mapping в Perforce (этот в этом вопросе вообще очень крут). В git же единицей слежения является не файл, а слепок проекта, т.к. совокупность файлов. Директории в нём вообще ничего не значат и учитываются просто в путях файлов, за счёт чего и поддерживается файловая структура с директорими (но закомитить пустую директорию не получится, т.к. для git директория не является ценностной единицей). А submodules в git -- это не самая приятная штука, особенно, когда дело доходит до того, чтобы их удалять/переносить. Уже не впервые высказываюсь на эту тему. Вот тут подробнее про использование: Исходя из вышесказанного, можно сделать определённый вывод: если требуется гибкое и удобное версионирование, то git тут вне конкуренции. Это относится в первую очередь к разработке кода. А вот, например, для схематики/PCB отлично подходит svn, т.к. там обычно никакого ветвления (и слияния, которое в случае с нетекствыми файлами очень затруднительно) не требуется, а нужно инкрементально сохранять последовательные изменения проекта.

Да Вы, батенька, либерал! Подобное "брожение в массах" негативно сказывается на рабочем процессе. Когда одни приходят к 9, другие к полудню, а то и к обеду, получается жуткий "рассинхон". Это "да и к 10 норм", работает только со взрослыми мотивированными людьми, коих не так много. В остальных случаях как раз и получается "брак", в голове работника в первую очередь.

Типичный образец творений "эффективного менеджера - дитя перестройки": много лозунгов, общих рассуждений и прочей воды. Как всегда, ответственного нет. Спросить за белибердовый материал (в том числя за новомодный "контур управления") не с кого: ни имени, ни фамилии того балбеса, скромно обозначенного как "директор по качеству". Know-how, видимо сводится к тому, что к хорошо известному набору служб "ОТК-испытали-метрологи", контролирующих рабочий процесс предприятия, добавили охрану труда, но убрали нормоконтроль?! Понятно, что о контроле по существу самих работ, анализе принимаемых технических и конструкторских решений, речи нет. Могли бы приёмку заказчика упоминуть, ради приличия что ли...

Вообще пины CFG_CLK/MISO_SO/MOSI_SI/FCSI_N предназначены для загрузки прошивки ПЛИС по Slave SPI или Master SPI. Они точно связаны с SPI hard core? (если пропустил, то где это написано?) Чтобы эти пины использования как обычные IO, необходимо запретить функцию загрузки прошивки по Slave SPI как минимум в User Mode в Features CPLD (а если не используете загрузку прошивки по этому интерфейсу, то можно и в Configuration Mode). У Вас оно запрещено? (в последних PDS это есть настройках проекта в Generate Bitstream -> Feature Control, раньше надо было вручную в программе конфигурации делать) А в рабочем варианте Вы какие пины используете? У Вас указанных предупреждений при использовании других пинов не выдает? UG030007 я как-то начинал переводить на английский, как раз SPI-часть тогда перевел, ниже прикрепил. Если нужно будет, могу и до конца перевести... UG030007_Compact_Series_CPLD_Embedded_Hard_Core_User_Guide_v1.2_spi_borisov.pdf

А почему не Моцарта или Бетховена? Это ж были реальные пацаны, которые специально писали музыку для "пищалок"! Если для кодирования нот возьмете структуру MIDI, то сможете брать готовые midi-файлы и играть любую музыку, хоть третий концерт Рахманинова.

Даташит на Logos DS02001 Logos Series FPGA Device Data Sheet 2.6_innek.pdf

Скоро будет даташит на первый Logos User guide - Physical Constraint Editor Physical_Constraint_Editor_User_Guide_innek.pdf

Pango Power Planner user manual Pango_Power_Planner_User_Guide_innek.pdf

Ipcompiler user guide IP_Compiler_User_Guide_innek.pdf Power calculator user guide Pango_Power_Calculator_User_Guide_innek .pdf

Fabric Inserter user manual Fabric_Inserter_User_Guide_innek.pdf

Перевод или оригинал? Оригиналы во вложении. Часть первая: Compa_Pgc1_Pgc2_Packages_and_Pinouts.zip Часть вторая: Compa_Pgc4_Pgc7_Packages_and_Pinouts.zip

User manual по конфигурированию ПЛИС https://disk.yandex.ru/i/K0oeCJtLt4xzMg

User manual на Design Editor Design_Editor_User_Guide_innek.pdf

Описание поддержки языка в ADS ADS_Language_Support_Reference_Manual_innek.pdf

Добавлю свои 5 коп. на тему svn vs. git. На svn сидел довольно долго - порядка 12 лет. Перешёл в своё время на svn с cvs. По сравнению с cvs svn - это был, конечно, прорыв! Ушли в небытие геморрои с неатомарными комитами, липкими метками и прочими анахронизмами, процесс фиксации стал предсказуемым и стабильным. Но на протяжении всего этого времени не покидало чувство, что чего-то не хватает, что нет какой-то свободы, что-ли, что каждый комит - это как штамп, высечка в граните... В итоге года 4 назад начал пошупать git/mercurial. Остановился на git. Не скажу, что сразу всё стало хорошо - потребовалось некоторое время (где-то с полгода), чтобы прочувствовать, понять его концепцию - достаточно сильно мешали стереотипы, выращенные на svn. На основании личного опыта могу сказать, что svn по сравнению с git - это не система управления версиями, это скорее система автоматизированного архивирования. svn позволяет делать фиксации с комментариями, хранит это инкрементально в централизованном хранилище (репозитории). Она хорошо подходит для линейного процесса фиксации изменений - сделали что-то, зафиксировали. Но она очень плохо подходит для работы в стиле "а ну-ка попробую-ка я это или это". Для такого стиля очень нужна возможность легко создавать и сливать ветки. И она в git есть, а в svn нет. В svn все комиты летят в центральный реп и нет никакой возможности ими пилотировать - ни откатить, ни изменить. Типовой пример. Всякий разработчик сталкивается с ситуацией, когда его проект достиг какого-то промежуточного итога: код стабильно собирается, предсказуемо работает. Можно двигаться дальше - добавлять новые фичи, но очень не хочется сломать то, что уже есть. Самый простой способ - делать архивы таких промежуточных точек, но это есть ни что иное, как попытка вести контроль версий вручную. Архивы плодятся, комментарии к ним теряются, сравнить две зафиксированные точки является довольно обременительной задачей... Собственно, с этого и начались системы управления версиями - та же древняя cvs поначалу представляла собой набор скриптов, который автоматизировал эти операции. svn довела реализацию этой модели до совершенства - фиксировать промежуточные состояния проекта стало удобно, безопасно и эффективно (благодаря дельтам). К сожалению, модель с центральным репозиторием не очень хорошо подходит именно для версионирования кода, т.е. когда хочется легко и быстро создавать альтернативные ветки развития, не ломая и не теряя уже полученного. И с этой задачей хорошо справляется git. Например, вот достиг я такого вот промежуточного результата, теперь мне надо двигаться дальше - добавить какую-то фичу. Я не пилю код в стабильной ветке - в ней все комиты всегда рабочие (да, в них могут быть баги, как и везде, но они ненамеренные), код всегда собирается и фичи все допиленные, никаких полуразобранных состояний там не бывает - они только в фичебранчах (feature-branch). Фичебранчи, когда требуемый функционал достигнут, сливаются в стабильную ветку и удаляются. Стабильная ветка у нас называется develop. Так вот, для новой фичи я завожу фичебранч: git co -b fb-newfeature (fb- означает feature branch) и спокойно кромсаю код "по живому", не боясь ничего сломать или потерять. Если вдруг срочно понадобился стабильный вариант, просто откатываюсь на него: git co develop Если допилил код в фичебранче, то сливаю его в стабильную (символ # - это типа комментарий, в реальной работе этого нет): git co develop # переключаемся на требуемую ветку git merge --no-ff -e fb-newfeature # --no-ff - создать комит слияния, -e - открыть редактор для ввода комментария После этого имеем красивую историю - чётко видна этапность: все комиты в ветке develop обозначают добавление той или иной фичи (или багфикс), а процесс разработки фичи хорошо виден как "отросток" слитый в стабильную ветку (по комментариям в комитах слияния видно, из какой ветки и какую фичу слили): Отчётливо видно, что делалось (правую часть я для экономии обрезал, там даты и авторы комитов, т.ч. видно кто и когда внёс изменения). Самое главное - это ощущение лёгкости процесса. Абсолютное отсутствие страха что-то сломать или потерять. Например, искромсал код на экспериментах до невосстановимого состояния - не беда: git co <branch-name>/<commit-hash> Если эксперимент затягивается и хочется в его процессе тоже фиксировать - то создаём просто ещё ветку прямо на текущей: git co -b fb-mad-experiment и продолжаем хулиганить. Если результат оказался неудовлетворительным, просто откатываемся на предыдущую ветку: git co fb-<branch-name> не заботясь о мусорном коде - гит всё вернёт в нужное состояние. Именно на гите я впервые прочувствовал совет делать т.н. "атомарные" комиты - т.е. такие, которые содержат набор изменений, касающихся только чего-то одного. Если в коде в результате правок появилось два и более логически развязанных изменения, то лучше фиксировать их разными комитами. В этом есть большой смысл. Например, возвращаясь к предыдущему примеру с экспериментальной веткой - вот наворотили там кода, поняли, что в общем-то тупик, но кое-что оказалось полезным и это кое-что неплохо бы взять с собой. Поскольку мы делали все комиты атомарными, то это кое-что оказалось зафиксированным отдельно от остальных правок. Теперь нам достаточно, откатившись на базовую ветку, выдернуть нужный комит в эту ветку: git cherry-pick <commit-hash> Кстати, этот же подход неоднократно проявлял себя и полезной стороны и при коллективной работе. Реальный случай: мы с товарищем работали над прибором, я отвечал за железку, а он за хостовую часть. Доведя дивайс до рабочей кондиции, я передал его товарищу и продолжил работать над очередной фичей, а товарищ писал протокол управления прибором. В какой-то момент, он обнаружил баг со стороны дивайса - что-то там с таймаутом не срасталось. Потребовалось моё участие, а я уже в разгаре работы над новой фичей. Но ведь ему-то ведь меня ждать, когда я закончу с этой фичей, не с руки, приходится переключаться. Действия такие: git stash # прячем незафиксированные изменения во временный комит, чтобы не плодить мусорных комитов git co develop # переключаемся на ветку, в которой обнаружен баг git co -b bfix-timeout # создаём ветку для работы над багфиксом Работаем над багом, попутно находится ещё кое-что, что нуждается в правке, итого несколько комитов в этой багфиксной ветке. Закончили, потестировали - работает. Сливаем git co develop # переключаемся на основную рабочую ветку git merge --no-ff -e bfix-timeout # сливаем правки бага После этого товарищ продолжает работать, я возвращаюсь к своей прерванной работе: git co fb-<new-feature> # переключаемся на ветку, с которой ушли на правку бага git stash pop # вытаскиваем спрятанные незафиксированные правки и продолжаю работать как ни в чём не бывало. В этот момент осознаю, что в той багфиксой ветке была одна правка (не связанная напрямую с багом), которая актуальна мне и в этой текущей ветке. Можно, конечно, по горячим следам поправить руками, но зачем, когда есть замечательная возможность сделать это автоматизировано: git cherry-pick <commit-hash> # <commit-hash> - хэш того комита, где зафиксированы нужные мне изменения В результате на текущую ветку как бы накатывается набор зафиксированных в другом комите изменений. Это может быть один файл или хоть десяток файлов, а так же тащится и комментарий комита. В общем, ничего тут не теряется и не забывается. В дальнейшем, когда буду сливать эту свою фичебранч в стабильную ветку, в которой вышеупомянутый комит уже есть, умный гит учтёт это и дублирования данных не произойдёт. Вот всего этого нет в системах с центральным репозиторием. Там даже откатить комит уже проблема. Вести такую вольную работу с кодом тоже не получается. Любая фиксация оставляет неизгладимый след в репозитории. В гите очень просто можно поддерживать красивую историю развития проекта, когда видно, когда, что и кем делалось, видна этапность. Для этого помимо описанного выше есть другие способы влиять на вид - например git rebase (хотя тут надо пользоваться осторожнее). Красивая история - не фетиш, это один из способов поддерживать сопровождаемость проекта, когда сразу видны этапы работы. Гит по духу напоминает язык программирования С. И в том, и в другом при неправильном использовании можно наворотить безобразий, но при правильном использовании это мощный инструмент. Есть ещё немало очень "вкусных" возможностей гита - как, например, возможность поправить сделанный по ошибке комит или возможности по формированию данных комита - это когда, к примеру, текущее состояние проекта содержит несколько логически развязанных изменений, и можно их добавлять, отделяя друг от друга, создавая логически законченные целостные "атомарные" комиты. На svn комит нередко содержал в себе целый набор разнообразных правок и некоторые комментарии к комитам напоминали приличный по размеру changelog. Но там и смысла делать атомарные комиты немного, там вообще лёгкое версионирование практически нереально.