Golikov

Все, тема переходит в беседу о жизни. я могу только сказать, что профи очень редко читают форумы, если у них есть проблемы решают их сами, а если проблем нет, то что лезть на форум, от скуки только? Я думаю очень мал шанс, что не решаемую для профика проблему ему решат на форуме за разумное время. Потому надо исходить из того, что большая часть нас тут новички по теме, и ищут тут не истины вселенской. Я ввязался в работу с плисами потому что не хватало просто ДСП, и от меня требуют результат а не знание стандартов, потому я иногда говорю глупости, может пишу не оптимальный код, я учусь, но я не могу позволить себе просто все бросить и посвятить год изучению, приходиться делать проект, и набираться опыта одновременно, главное что проблему я свою решаю, хоть и не владею в совершенстве инструментом и стандартом (пока). Это я, а можно представить еще много людей, которым надо решить один вопрос и забыть про плисы навсегда. Студенты с горящим курсовыми, лабами, инженеры которым плис нужна как простой преобразователь интерфейса один раз на миллион проектов, и они не хотят городить на ней сложной обработки. Вот эта часть людей наиболее вероятно задаст вопрос на форуме, и вопрос будет элементарный, и понятно, что уже решенный тысячу раз в литературе, но на форуме тебе на него ответят за полчаса, а в книге будешь искать день. Эта экономия и заставляет людей задавать тут детские вопросы. По мне, вместо того чтобы писать страницу пояснений, почему вас кто то раздражает своей глупостью, вы бы лучше в 2-3 строчки писали бы им ответы, но не такие "читай мануал", а это делается так. Многим не хватает простого толчка, они не знаю как подступиться, прочтут и дальше пойдут вперед иногда так что сами не угонитесь. А если такие ответы писать лень, то может просто стоит игнорировать "тупые" посты. От себя добавлю, что любое объяснение, даже самых простых вещей, всегда немного поднимет и твой уровень, поупражняет тебя, потому полезно, но это мое мнение... Резюме, сам как дурак, написал страницу о жизни, суть которой такова, лучше игнорировать простые посты, или быстро давать на них ответ, чем разводить многостраничные беседы о смысле жизни и уровне разработчиков задающих такие вопросы.

Да я собственно то изучаю все это по ходу проектирования. Вот сейчас на столе лежит модуль ПЛЛ сделанный на спартане 3Е + ДСП. Разбираюсь во всем по ходу дела, и поставленные задачи решаю вполне. Меня вот что беспокоит, написал я чтобы клок период был 10 нСек, синтезатор шуршал шуршал, написал не получается, ну и отчет что там в длинной цепочке 325 элементов натыкано. Но когда я описывал эту логику я имел ввиду все гораздо проще, я даже представить немогу откуда столько элементов, когда там просто все можно было на 3 регистрах сделать... Вот мне интересно как использовать эти отчеты, как можно влиять на времянку, мне почему то кажется что составив схему иначе можно было потерять кучу триггеров но сэкономить время. Синтезатор мне то память впихнет вместо регистра, то еще что... как то же это должно управлять, а в ИСЕ столько инструментов непонятных имеется, наверное же они зачем то нужны:)... хотя это конечно может я хочу от спартана больше чем он может. У меня фазовый дискриминатор на 109-121 МГц работает, остальные части схемы 150-200 МГц. Медленно это когда частота дискриминатора упала до 98 МГц, мне она нужна выше 100, чтобы на 4 клока приходился период АЦП, а лучше чтобы частота была 200 МГц а то я 65 МГц АЦП на полную не использую, и почему то мне кажется что это возможно если бы синтезатор иначе синтезировал схему... Но это так познавательный вопрос был на самом деле, я потихоньку всем этим овладею, просто не могу полностью плисами сейчас заниматься, приходиться целиком проект вести, а там еще ДСП есть. Но думаю у меня не плохо получается для 4 месячного знакомства с плисами%).... Думаю меня сейчас интересует как управлять процессом синтеза в общем, какие инструменты есть для указания критических путей и прочее...

Думаю никто, кроме Xilinx подробнее не напишет :) Using Probes и еще Implementation Strategies using FPGA Editor К симуляции это не имеет никакого отношения, все работает в железе. Раз уж очень нужно и пробников не xватает или неудобно и есть свободные ресурсы, то можно и ChipScope Core с помощью FPGA Editor прямо в разведенный проект вставить, опять таки без изменения уже существующей логики. Премного благодарен, а еще у меня вопрос не по теме, есть в плисах возможность крутить баланс скорость/ресурсы. У меня опыта мало, но чувствуется что что-то такого типа должно быть. А то ресурсов свободных лом остался, а почему то настолько длинные цепочки развелись что скорость низковата. Причем забавно уменьшая число бит в счетчике состояний частота увеличивается, несмотря на то что старшие биты всю дорогу были нулями, сравнение что ли быстрее проходит?

Может их все по andить в цикле с каким нить третим единичным сигналом? Если хоть один ноль, то и весь результат будет ноль... ? Это как идея...

Ну почему же сразу 'руками'? Этот инструмент (probes) как раз позволяет не вмешиваясь в сушествующую разводку вевести сигналы наружу. А то вдруг после добавления триггера и переразводки баг изчезнет? Где его потом искать? :( А в общем согласен, универсальных рецептов нет, да и хозяин - барин. Что-то от него вестей нет, может, нашел уже хомут, а мы тут все гадаем? А если не затруднить чуть поподробнее про пробники. Как это делается на примере плз... В смысле по шагам, допустим я хочу поглядеть как себя сигнал А. что мне надо сделать? и это где будет в симуляторе или и в железе тоже?

ну процесс кривоват, не знаю как там синтезатор разрулил ситуацию, но допустим... я еще посмею предположить, что при настройке ДКМ вы отказались от буферов на входе и выходе клоковых сигналов. Или не выжидаете необходимое время, за которое ДКМ выходит на рабочий режим, не используете управляющие и статусные ножки ДКМ, может быть такое? Может нестабильность клока выдаваемого ДКМом все и портит, потому что не может процесс на одном клоковом сигнале работать, а на другом нет... Хотя! может и это может быть в том случае если не хватает время на установку сигнала перед фронтами клока, это может ввести нестабильность и непонятность в работу схемы, может стоит вывести клок и сигналы счетчика наружу и потыкать осциллографом? или правильно использовать все управляющие ноги? CLKIN_IBUFG_OUT - это входной клок на буфер и с него на ружу, внутри ДКМ он используеться как главный клок, это для синхрона ДКМ и внешних схем. кстати а вы могли просто не включить ножки клоков, например CLKFX_OUT, или поставили что опорный клок внешний и не завели его?

Жестко, но по теме:)... Кстати,… к нянькам, тряпкам… то кажется не Кутузов, а так разыгранный образ, но не суть. Указываю на ошибку, которую человек сам описал, но не проанализировал. допустим счетчик равен 3 и константа по которой он обнуляется тоже 3 далее как вы сами пишите --1) планируется инкрементировать счётчик то есть счетчик должен стать из трех четырьмя по выходу из процесса, но пока счетчик 3 --2) сравнивается значение счётчика с константой и по условию планируется обнулить счётчик три равно трем, то есть счетчик планируется обнуляться, и из 3 должен стать нулем по выходу из процесса. внимание вопрос, чему должен стать равен счетчик по выходу из процесса? Ведь в начале было запланировано что 0, а в конце что 4? в пользу какого числа должна сделать выбор железяка? Не знаете? Так вот и компилятор ваш не знает, о чем вам и сообщает! эту коллизию вам справедливо и предлагает решить Горби, и он тут как всегда абсолютно прав:)... вы же знаете что хотели, и чему хотели чтобы был равен счетчик решение простое если счетчик равен константе, то нулить, а если нет, то увеличивать. тогда все однозначно, если равен будет запланировано обнулить, и на иначе программа не посмотрит, а если не равен, то будет запланировано увеличить, и третьего не дано, и коллизий не будет.. хорошее слово коллизия... мда... ну и успехов вам:)

если честно даже разбираться было лень:). Думаю если бы запустил на синтез вывалился бы варнинг или еррор в месте где сравнение идет с 26, меня только немного смутило отсуствие увеличения col, то есть какой то параметр который ничего не делает был, но подумал что он меняется где то во вне... или это типа тест как написали...

Пока, к сожалению, ничего лучшего у нас нет. Был бы хороший FAQ, разместили бы его. Эта тема, имхо, для новичков лучше, чем ничего. Т.к. хотя бы некоторые полезные ссылки новички смогут из нее почерпнуть, если, конечно, мы не перейдем полностью от ссылок к обсуждению полезности этой темы. ;) Я думаю надо просто жестко делетить все не потеме, и оставлять только ссылки...

Если cols имеет тип std_logic_vector, тогда непонятно, причем тут операция сравнения с целым? Если cols имеет тип целое, то что означает присваивание cols<= "00000"? ;) наверное в этом и была ошибка начальная, которая приводила к тому что условие было всегда труе. сравнение стд_логик_вектора с целым числом... а не проблема бибилотек...

да внутри процесса, но это я о переменных в целом я когда с переменными повозился, решил: "значит правила игры такие, все пишем на битовых векторах". Там автомат тупой, переводил 32 параллельных бита в 2 последовательные посылки по 16 бит с паузами и клоковыми сигналами. Вот когда состояния считал логик_вектор, скорость была типа 100 МГц, а когда я для удобства понимания воткнул переменную типа инт вместо счетчика состояний(он просто декрементируется и сравнивается), стало типа 10 МГц. Я в этом деле новичок, и не очень понял, почему критический путь так удлинился, но время, если честно разбираться нет, потому отметил для себя «переменные не трогаем». Они еще и ошибки время от времени вызывают, синтаксис их применения я еще не чувствую, перекомпиливать много приходилось, а это время... теперь все пишу на логик векторах и не жужу, вот, может я и не прав. что такое RTL-код кстати, я думал это сеть с картинками из логических примитивов, но как то получаеться что нет...

Что значит несинтезируемый код и почему не надо использовать Shared value? Мне кажется что это очень удобно использовать для какого-нибудь служебного счетчика например. а у меня применения инта (варибал) для состояния конечного автомата сократило скорость работы схемы в 10 раз. Хотя может я что то не понимаю, но переменные решил не использовать, использую всегда сигналы...

вот смотрю я на это и думаю что очень большие эти камни могут быть:)... если а>b делать c, у вас я так понимаю "С" происходило всегда, но как тут справедливо заметили у вас "a" всегда было меньше "b", то есть "с" вообще не должно было произойти никогда, а происходило всегда. А то что вы подключив беззнаковые библиотеки изменили ситуацию, говорит о том что лучше как и советуют их вообще не использовать... Хотя я сначала написал проектик с сигнетом и ансигнетом, и просто в схемах сравнения насильно указывал какое сравнение делать, и все вроде работало..., но на вашем примере убеждаюсь что наверное действительно их лучше не использовать

LCELL - это такой стандартный компонент в кварусе, который никакой логики в себе не несет. Просто вход передает на выход, но, так как в железе на прохождение сигнала в любом компоненте требуется какое-то время, то, следовательно, выходной сиганла сдвигается относительно входного на небольшое время (порядка 3нс вроде). В нашем исходном проекте, чтоб организовать большую задержку, используется несколько последовательно соединенных lcell'ов (соответсвенно общая задержка будет равна 3нс*N, N-кол-во lcell'ов). А про ЛУТ я ничего не знаю:) что то мне подсказывает что это хороший стиль разработки...

но это все равно не упрощает поставленной задачи. у меня в малюсеньком фазовом дескриминаторе такая каша проводов была на 3 экрана и с межстраничными соединениями типа U010203030, что схемная реализация меня забавляла только с познавательной цели, «где сумматоры воткнули…, о а тут мультиплексор оказывается…, ого а я и не думал что так можно…», но не более того… Суть работы была описана в тексте, и уж точно была понятнее и имела куда больше смысла для анализа, чем схема. Я думаю по тексту и симуляции работы можно гораздо больше косяков отловить, чем разглядывая схему и соединения, хотя это может быть мое делитанское мнение, так как еще мало схем разглядывал...

В этом вся фишка. За счет применения "synthesis read_comments_as_HDL on/off" этот код видит только квартус. Флаг в руки:). Слов нет : "Сходи туда, не знаю куда. Сделай то, не знаю что." Вам необходимо выделить из схемы необходимые для работы синхронной памяти сигналы. Память обязательно вынести из схемы в самостоятельные единицы для синтеза! Элемент LCELL необходимо использовать только для управления упаковкой логических элементов в LUT, и НИКАКИХ задержек. Т.е LCELL(и ему подобных) в вашей схеме вообще не должно быть. Источником сигналов, используемых в качестве тактовых должны быть триггеры. а вот у меня тут вопрос организовался:)... а что такое ЛЦЕЛЛ в данном контексте? как управлять им упаковкой в ЛУТ, и как на нем организовывать задержки?

да собственно где это нельзя используют другие триггеры и схемы:)... просто сказали, что лучше делать детерминированный триггер, с приоритетом, а я заметил что исходная схема и так была с приоритетом и все, ничего более... Все таки определенность поведения для отладки лучше, если видите смену сигнала, то знаете что произойти это может тогда то или тогда то, проверяете и все получается, а если есть ситуации которые могут выдать любой сигнал, в дебуге можно и закопаться, хотя конечно надо писать сразу правильно, а не придумывать способы поиска ошибок:)...

схема схемой, но у схемы 2 пути первый Р_1=1 второй Р_1 не равно 1 и С_1 = 1. согласитесь что при любой последовательности проверок путей, результат однозначный?! реальный триггер по моему не имеет приоритета, так как есть тупое соединение 2 И-не. И на каком сигнале последним поднялся фронт, тот и обработается... на счет кулонов учту, но если все так пойдет как ща, то с ксалинкса спартана не слезем...

схема схемой, но у схемы 2 пути первый Р_1=1 второй Р_1 не равно 1 и С_1 = 1. согласитесь что при любой последовательности проверок путей, результат однозначный?! реальный триггер по моему не имеет приоритета, так как есть тупое соединение 2 И-не. И на каком сигнале последним поднялся фронт, тот и обработается... на счет кулонов учту, но если все так пойдет как ща, то с ксалинкса спартана не слезем...

Так может настало время свежим взглядом пересмотреть все? Если вы только начали изучать ВХДЛ то вряд ли от вас ждут прорыва за 2 дня. Я бы потихоньку по блокам бы разобрал как работает проект, и написал бы эти блоки заново, нормально понимаю что за что отвечает и зачем сделано. И польза есть, языку наберетесь, да и блоки потом использовать можно будет. А то знаю я одну схемку(железную) на которой уже лет семь стоит блок гашения помех вентилятора охлаждения, который уже лет пять на ней отсутствует(вентилятор), просто никто не разобрался что за блок и тупо его повторяют. Ваш проект за 20 лет я думаю набрал уже с десяток таких мертвых блоков... На счет памяти и библиотечно не зависимого кода. Я что то не очень понимаю, библиотечно независим может быть только элементы "или", "и", "не", то есть стандартные и которые у всех есть. Но если взять спартан 3 с перемножителями, или другое семейство с какими то специальными элементами, то я думаю не подключив их бибилотечное описание вы их вряд ли используете. Я делал описания, которые разводились в блоки РАМ, но малые изменения иногда меняли рам на блок защелок. Написать код и гарантировать, что на любом семействе и любой среде это будет рам который работает как вы хотите, а не как хочет компилятор я думаю можно только если насильно подключить его специальным для данного семейства блоком, причем в одном специальном месте кода, чтобы сразу были видны проблемы при смене платформы. Вот так организованный код я бы сейчас, наверное, назвал более платформа независимым, чем тот, который «скорее всего» разведется средой правильно для любой платформы. Его поведение детерминированно, и ничего не всплывет в середине эксплуатации, я думаю это ценнее чем сомнительное удобство «компиль, зашивай не думай, должно работать».

изначально написанный триггер уже был с приоритетом правильным. if R_1= '1' then ... elseif S_1='1' then ... endif; если Р=1 то одно действие, если Р=0 то другое, но только при условии что С=1. то есть если Р=1 и С=1 то пройдет первая конструкция, по Р, независимо от значения С. а вот это в другом варианте elsif ( S_1 = '0' and R_1 = '0' ) then q_1 <= '1'; не триггер а лажа, так как при обоих сигналах нулевых, тригер не должен менять состояния! кстати, если я точно помню РС триггер как раз отличается от ЖК тем что при обоих 1 имеет недетерминированное состояние в классике, я бы наверное корректировал его в триггер, который не меняет состояния при обоих входах равных 1, чтобы РС все таки отличался от ЖК. И еще я не очень понял про то что он "ведет себя как Т триггер а не как ЖК", Т триггер это по моему и есть ЖК, с двумя единицами на входе, он же просто меняет свое состояние на противоположное с каждым клоком. Так в чем же отличие поведения как Т Триггер, от поведения как ЖК триггера, в случае когда на вход подают 2 единицы?

я первый:)!!!!

В трег записать вектор вида 1 и оставшаяся часть Трег, без младшего разряда, я так понимаю просто сдвиг вправо с заединичивание старшего разряда. & - оператор составления, то есть '1'&"001"&'0' будет вектор "10010"

В присваивании F большая, а в описании портов маленькая r,p,f:out bit F<=W2;

без clk='1' and clk'event then перед конструкцией if b='0' then b<='1' else b<='0' end if; состояние b не будет меняться каждый так и защелкивать по фронту, а ссинтезируется простым инвертером с выходом на вход и то если не выдаст ошибки:), это и есть комбинационный цикл, если я правильно понимаю. А если добавить clk='1' and clk'event, то будет как вы и говорите, каждый такт будет меняться 0 на 1, 1 на 0, и так далее.