alexadmin

Можно предположить, что это нужно сделать когда bufg кончились ;) И самому решить где убрать, чтобы за вас это не сделал синтезатор.

Вообще говоря если сигналы синфазны, то все должно нормально работать если выставлены констрейны для каждого клока (возможно, что они сами генерятся из конфигурации PLL). С квартусом я общался меньше, а в xilinx с этим проблем не возникало. Если опираться на ваш пример то для пути a->b должен выдерживаться констрейн 100 Мгц, для b->c - 200 МГц. И все будет ок.

Двунаправленные шины в квартусе, если мне не изменяет память, отображаются в виде двух независимыъ шин - то что подано на вход и то, что формируется на выходе. Соответственно надо анализировать состояние обеих

ieee.org Если надо - могу поделиться, вроде валялся где-то скачаный

Кто знаком с DSP Builder - посоветуйте можно ли реализовать переменный sampling rate (коэффициент децимации)? Ситуация такова - стоит управляемый децимирующий фильтр. В зависимоти от режима в котором он работает необходимо sampling rate данных на его выходе уменьшить в 2-4-8-..-128 раза. Пока я вижу решение только вручную генерить сигнал разрешения и подавать его на все синхронные компоненты, которые есть в схеме далее (дясятки, если не сотни - очень не хочется). Подошло бы и промежуточное решение - генерить enable вручную, а далее подавать его только на верхний уровень подсистем в иерархии, сделав enable subsystem, выражаясь языком Simulink. Но не уверен, что так можно сделать. PS Пытался сделать набор блоков Tsamp с кратными значениями сэмплирования и коммутировать их мультиплексором (с Xilinx это работает), но на выходе мультиплексора наследуется наименьший из всех sampling rate :(

Спасибо. А не подскажите источник информации, если таковой сохранился? С этим плохо. Там очков надо набрать для даунлоада. Причем набор начинается не раньше чем через неделю после регистрации. С этим еще хуже - post removed Ну и сюда доступа нет ;-)

Пытаюсь создать цифровую реализацию ФАПЧ. Используется классический ПИ-регулятор. Среди требований к фильтру есть loop bandwidth (как я понимаю, по русски это эквивалентная шумовая полоса). Возникли проблемы с расчетом коэффициентов фильтра. В некой книги нашел следующие формулы, однако в книге много ошибок-опечаток и есть мнение, что формулы не правильные: $B_l$ - noise loop bandwidth $T_s$ - период сэмплирования фильтра $w_n=2*B_l/(\theta+1/(4*\theta))$, где $\theta$ - dampling factor, принятый равным 0.707. $K_i=4*(w_n*T_s/2)^2$ - интегральный коэф-т $K_p=4*\theta*(w_n*T_s/2)$ - пропорциональный коэф-т - на счет этой формулы основные подозрения. Не встречал ли кто-нибудь аналогичных формул для расчета или литературы, в которой они есть (желательно доступной для скачивания). Рекомендовали книгу Шахгильдяна по фазовой подстройке, однако найти ее не удалось. В большинстве литературы, которая встречалась производятся лишь теоретические преобразования в z-области, применить которые на практике затруднительно...

Все хорошо, но по-мойму для c хватит (32 downto 0) ;-)

Поделить триггерами до нужного значения, проинвертировать логикой, поставить еще один ряд триггеров. Триггеры разместить в IOB. разбег будет равен разбегу прихода клока в эти иобы.

Поиски по инету выявили организацию PREP (Programmable Electronics Performance Corp), основанную в 91 году и заимавшуюся как раз подобной задачей. Однако на сегодняшний момент все уже померло и на их сайте учат негров с китайцами английскому (www.prep.org).

Скажите, а существуют ли какие-нибудь общепринятые стандартные проекты, основываясь на которых можно оценивать эффективность СБИС? Так, чтобы разработчик FPGA или библиотек для ASIC мог, сославшись на определенный тестовый проект сказать, что вот он будет занимать такой-то объем логических элементов (вентилей) и работать на такой-то максмимальной скорости.

Это начиная с какой версии ISE?

Да, прошу прощения, давно дело было...

Плохо помню, но это еще зависит от режима в котором включен bufgmux. Когда я делал клоковый мультиплексор, который не должен давать сбоев получалось (да и в доке про это говорится), что для корректного переключения необходимо чтобы после смены управления исходный клок как минимум еще раз клокнул, иначе на выходе будет пусто. Что-то в таком духе.

Насколько я понимаю, в буквальном смысле - цепь дорутилась до куда-то и дальше никуда не пошла, т.е. у нее нет нагрузки. В общем не развелась ;) 1. Попробовать переразвести с другими настройками мэпера-рутера. Может быть и разведется. 2. Посмотреть какой собственно путь не развелся. Возможно его физически невозможно развести в виду самой конструкции кристалла. Например клок с регионального буфера в какую-нибудь другую часть кристалла и т.п.

Смотрите на кострукцию FOR... Generate. Сами сигналы объявить векторами и через индекс обращаться.

Насколько я помню, там задаются не конкретные пути а группы. А в группах можно использовать вилдкарды, насколько я понимаю. По крайней мере "*". Вот как поступает System Generator в подобных случаях. Кусок .vhd (здесь a,b,c - данные, ce_2 - enable (каждый второй), clk_2 - clock): test_x0: entity work.test port map ( a => a_net, b => b_net, ce_2 => ce_2_sg_x0, clk_2 => clk_2_sg_x0, c => c_net Констрейн: Net "ce_2_sg_x0*" TNM_NET = "ce_2_cfd58ecb_group"; TIMESPEC "TS_ce_2_cfd58ecb_group_to_ce_2_cfd58ecb_group" = FROM "ce_2_cfd58ecb_group" TO "ce_2_cfd58ecb_group" 20.0 ns; Вместо абсолютного значения можно подставить отностительное через объявленный ранее констрейн.

Кто б мне объяснил почему банальнейшую конструкция вида if RISING_EDGE(clk) then data_out <= not data; end if; Xilinx порождает в триггер на вход которого подает GLOBAL1, а на сброс data? При этом стоит оптимизация по скорости и в констрейн по клоку он не укладывается, т.к. время предустановки астрономическое ;) по масштабам констрейна. Если вручную его заставить пропустить data через инвертор и подать на триггер, то все хорошо. ISE 8.2

Именно потому DCM и не используется ;-) Предполагаемый джиттер с генератора порядка 20-30 пик. На самом деле 10 ps - редкая удача. Я почти уже было остановился на 50-70 в процессе разводки. Дело за малым - повторить процедуру на реальном проекте :-)

Увы, если бы был еще и MINDELAY ;-), то можно бы было, наверное, подобрать подходящие значения, зажав его в узком интервале, на которых разводка даст удовлетворительные результаты, а так получается, что он что-то разводит лучше, что-то хуже, в итоге менее 150 ps не выходит Надо будет про RLOC еще подробней почитать, а пока так примерно и решил сделать. Только на уровне схемы. На тестовом дизайне разложил все это вручную и зафиксировал разводку. В итоге удалось добиться разбега не более 10 ps :-) Тут уже джиттер клока больше будет, я думаю.

Подскажите, как можно сделать такую штуку: несколько сигналов (точнее два по 4) выходят с разных триггеров, синхронизируемых одним клоком. Надо, чтобы они пришли на некий LUT с одинаковой задержкой, пусть не минимальной самой по себе, но очень близкой друг по отношению к другу. Плюс желательно учесть clock skew с которым приходят клоки на те триггеры (или опять таки выровнять clock skew для них). Возможно ли реализовать подобный механизм с помощью констрейнов или надо разводить вручную? На данный момент знаю только как задать абсолютный констрейн на рутинг отдельного сигнала, но это не совсем то...

Еще можно таблицу отсортировать (или в ней самой по себе уже по возрастанию/убыванию значения идут?), разбить на диапазоны (анализировать сколько-то старших бит) и вести итеративный поиск внутри полученного диаразона. Это будет некая комбинация двух ранее описанных подходов.

Будем рассуждать логически ;) Если транспонировать таблицу, то в ней будет не 2^48 элементов, а те же 601(602), просто таблица будет разряженной. Если используется LUT4, то для декодирования потребуется 12+3+1=16 элементов *48=1024 LUT + шифратор 150+38+10+3+1=202. Т.е. всего 1230 LUT. Это верхняя оценка. В реальности оно, наверное, ужмется сильнее за счет оптимизации. Плюс надо навставлять триггеров для конвееризации. Если крутить в цикле, то хорошо подумав можно сделать алгоритм, который даст латентность 600, но позволит подавать данные на каждом такте. Правда есть сомнение, что он окажется компактнее чем предыдущий. Скорее даже наоборот ;)

Подключить SRL в явном виде? Мне с трудом представляется ситуация, когда синтезатор создаст SRL с задержкой 1 вместо обычного триггера...

С BUFR можно вытащить на BUFG. Впрочем о синфазности клоков в этом случае придется забыть.