Комментарии 16
Было бы интереснее посмотреть на реализацию дробного делителя с произвольным коэффициентом деления. Да еще на MASH структуре порядка этак третьего.
Я бы еще отметил изящный стиль комментариев, не все так делают, а надо бы. Это стандарт компании или собственные наработки?
Примеры не показательны. Просто комбинируете сигнал пониженной частоты за счет переднего/заднего фронтов входного сигнала. Как из 48МГц получить 3.6864МГц с такой моделью?
Рассмотрены модели делителей с коэффициентами 1,5; 2,5; 3; 5.
48 МГц / 1.5 = 32 МГц
48 МГц / 2.5 = 19.2 МГц
48 МГц / 3 = 16 МГц
48 МГц / 5 = 9.6 МГц
Ответ — «никак». Не кратную частоту хотите.
48 МГц / 1.5 = 32 МГц
48 МГц / 2.5 = 19.2 МГц
48 МГц / 3 = 16 МГц
48 МГц / 5 = 9.6 МГц
Ответ — «никак». Не кратную частоту хотите.
48 МГц — обычно несущая USB, 3.6864 МГц, также как 1.8432 МГц — частота UART для COM-порта.
Вообще для таких нужд обычно берут два независимых генератора.
На материнских платах используют специальные микросхемы ФАПЧ типа PLL, которые заточены под определённый чипсет и генерят все нужне частоты.
Вообще для таких нужд обычно берут два независимых генератора.
На материнских платах используют специальные микросхемы ФАПЧ типа PLL, которые заточены под определённый чипсет и генерят все нужне частоты.
Почему для DL_STATE_1 делается latch?
Это ограничивает максимальную частоту CLK. Потому что сигнал CNTR_STATE[1] должен установиться пока CLK=1.
Если переходные процессы CNTR_STATE «залезут» в фазу когда CLK=0, а это может быть, так как они должны закончится с неким tsetup (при этом tsetup много меньше 1/2 периода CLK) перед следующим положительным фронтом CLK.
И если переключение CNTR_STATE будут когда CLK уже стал нулевым, то эти переключения появятся и на DL_STATE_1. А это уже приведет к «фаршу» в этом месте
// Delay for CNTR_STATE[1]:
always @ (CLK, RST, CNTR_STATE[1])
if(RST)
DL_STATE_1 <= 0;
else if(!CLK)
DL_STATE_1 <= CNTR_STATE[1];
Это ограничивает максимальную частоту CLK. Потому что сигнал CNTR_STATE[1] должен установиться пока CLK=1.
Если переходные процессы CNTR_STATE «залезут» в фазу когда CLK=0, а это может быть, так как они должны закончится с неким tsetup (при этом tsetup много меньше 1/2 периода CLK) перед следующим положительным фронтом CLK.
И если переключение CNTR_STATE будут когда CLK уже стал нулевым, то эти переключения появятся и на DL_STATE_1. А это уже приведет к «фаршу» в этом месте
assign CLKDV1X5 = (~CLK & CNTR_STATE[0]) | (CLK & DL_STATE_1);
CNTR_STATE — выход регистра Flip-Flop. Между ним и защёлкой-Latch нет никаких комбинационных схем, так что «фарша» быть не должно, только монотонный переходный процесс, ибо сигнал сформирован выходом регистра.
Вот касательно задержки — согласен. Задержка может возникнуть на длинных трассировочных ресурсах, тогда CNTR_STATE придёт на вход защёлки с опозданием, после заднего фронта CLK, что сломает алгоритм. Но, во-первых, для рассмотренной модели Duty Cycle для CLK должен быть 50%, поэтому «коротких единиц» относительно периода на CLK быть не должно. Во вторых, эту схему следует раскладывать в FPGA вручную, либо задать тесную область в кристалле для её Place&Route. Тогда длинных трассировок не будет.
Возможно, следовало в этом месте поставить Flip-Flop вместо Latch, работающий по negedge, но в старой альтере FLEX, такой зверь становится макросом с инвертором на клоке, так что не везде такой подход прокатил бы.
Вот касательно задержки — согласен. Задержка может возникнуть на длинных трассировочных ресурсах, тогда CNTR_STATE придёт на вход защёлки с опозданием, после заднего фронта CLK, что сломает алгоритм. Но, во-первых, для рассмотренной модели Duty Cycle для CLK должен быть 50%, поэтому «коротких единиц» относительно периода на CLK быть не должно. Во вторых, эту схему следует раскладывать в FPGA вручную, либо задать тесную область в кристалле для её Place&Route. Тогда длинных трассировок не будет.
Возможно, следовало в этом месте поставить Flip-Flop вместо Latch, работающий по negedge, но в старой альтере FLEX, такой зверь становится макросом с инвертором на клоке, так что не везде такой подход прокатил бы.
IMHO, количество подводных камней в использовании логических ресурсов для генерации тактового сигнала слишком велико. Не проще ли свести задачу к кратности целому числу и воспользоваться сигналом разрешения? Например, удвоить опорные 100 МГц и получать нужные 66 МГц путём разрешения раз в три такта? Такой метод для все x.5 вариантов подходит.
Если выбранный чип не способен обеспечить работу логики на удвоенной частоте (даже с условием multicycle constraint-а для всех путей кроме сигнала разрешения), то можно сделать удвоение только для i/o (там ещё и DDR-примитивы могут помочь в формировании), а саму логику поставить работать с сигналом разрешения вида 2 такта через 1 и тому подобное. При этом остаётся только внимательно выполнить сопряжение работы внутренней логики и i/o, но это достаточно простая задача.
Главное преимущество таких решений в том, что мы переходим из области аналоговой неопределённости (при использовании логических ресурсов для формирования тактовых сигналов) в область чистой «цифры», когда достаточно отладить модель в симуляторе и убедиться что нет ошибок тайминга после P&R.
Если выбранный чип не способен обеспечить работу логики на удвоенной частоте (даже с условием multicycle constraint-а для всех путей кроме сигнала разрешения), то можно сделать удвоение только для i/o (там ещё и DDR-примитивы могут помочь в формировании), а саму логику поставить работать с сигналом разрешения вида 2 такта через 1 и тому подобное. При этом остаётся только внимательно выполнить сопряжение работы внутренней логики и i/o, но это достаточно простая задача.
Главное преимущество таких решений в том, что мы переходим из области аналоговой неопределённости (при использовании логических ресурсов для формирования тактовых сигналов) в область чистой «цифры», когда достаточно отладить модель в симуляторе и убедиться что нет ошибок тайминга после P&R.
Очевидно, что генерация клока комбинационными ресурсами — решение не грамотное и не рекомендуемое в силу той же неопределённости задержек комбинационных цепей после PAR (P&R), вероятности гонок и «дребезга» веходного сигнала и т.п.
Рассмотренный пример под канонические правила проектирования не подходит. Но из всего бывают исключения.
Задача была такая: на CPLD разделить тактовую частоту на 2.5 и выдать «на улицу» для синхронизации другой микросхемы.
Другая задача в Spartan-2 из несущей 64МГц получить 42.7 при условии занятости всех DLL.
Ваш вариант — заставить работать все регистры на вдвое большей частоте и рулить их переключением раз в три такта для CPLD вообще нереален, ибо нет умножителя частоты, а для старых FPGA тоже крайне затруднителен, ибо упрёмся в предел работы самих регистров и глобальной сети синхросигнала.
Касательно ошибок тайминга после PAR — следует задать Timing Constraint по сгенерированному клоку — выходу описанной схемы. Я так и делал.
Рассмотренный пример под канонические правила проектирования не подходит. Но из всего бывают исключения.
Задача была такая: на CPLD разделить тактовую частоту на 2.5 и выдать «на улицу» для синхронизации другой микросхемы.
Другая задача в Spartan-2 из несущей 64МГц получить 42.7 при условии занятости всех DLL.
Ваш вариант — заставить работать все регистры на вдвое большей частоте и рулить их переключением раз в три такта для CPLD вообще нереален, ибо нет умножителя частоты, а для старых FPGA тоже крайне затруднителен, ибо упрёмся в предел работы самих регистров и глобальной сети синхросигнала.
Касательно ошибок тайминга после PAR — следует задать Timing Constraint по сгенерированному клоку — выходу описанной схемы. Я так и делал.
Я упоминал и второй вариант помимо всеобщего удвоения частоты. Для случая «выдать на улицу» он как раз подходит. Жаль, что вы его не заметили. ;)
Кстати, в первом из описываемых вами случаев вы производили измерения параметров полученного результата? Ведь «другая микросхема» вероятнее всего имела определённые требования к поступающему тактовому сигналу (я имею ввиду не только частоту). Конечно, довольно часто «всё работает и так», но, например, может перестать работать на другой партии устройств или, что хуже, сбоить время от времени с неявными симптомами.
Если не секрет, какой именно constraint вы задавали? Я сильно сомневаюсь в способности софта корректно применять constraint-ы, предназначенные для тактовых сигналов, к комбинаторной логике. И я не видел у Xilinx-а constraint-ов типа «отсутствие глитчей и гонок на этом отрезке логики». :)
Кстати, в первом из описываемых вами случаев вы производили измерения параметров полученного результата? Ведь «другая микросхема» вероятнее всего имела определённые требования к поступающему тактовому сигналу (я имею ввиду не только частоту). Конечно, довольно часто «всё работает и так», но, например, может перестать работать на другой партии устройств или, что хуже, сбоить время от времени с неявными симптомами.
Если не секрет, какой именно constraint вы задавали? Я сильно сомневаюсь в способности софта корректно применять constraint-ы, предназначенные для тактовых сигналов, к комбинаторной логике. И я не видел у Xilinx-а constraint-ов типа «отсутствие глитчей и гонок на этом отрезке логики». :)
Второй вариант какой-то неочевидный. В старых ПЛИСах DDR триггеров в IOB нет. Как раз вам повод опубликовать этот вариант.
В первом случае (CPLD серии XC9500) результат был проверен на осциллографе. Глитчей не было. И комбинационка там работает по принципу «изменение входной комбинации только по одному входу», как в коде Грея, так что гонок быть не должно. Синхросигнал на выходе не выровненный, Duty Cycyle 40%, согласно рис. 5. Это приемлемо.
Constraint был задан простой, период в нс и Duty Cycyle. Непосредственно в *.ucf прописан по сигналу выхода комбинационки. В Spartan2 все работало как часы.
В первом случае (CPLD серии XC9500) результат был проверен на осциллографе. Глитчей не было. И комбинационка там работает по принципу «изменение входной комбинации только по одному входу», как в коде Грея, так что гонок быть не должно. Синхросигнал на выходе не выровненный, Duty Cycyle 40%, согласно рис. 5. Это приемлемо.
Constraint был задан простой, период в нс и Duty Cycyle. Непосредственно в *.ucf прописан по сигналу выхода комбинационки. В Spartan2 все работало как часы.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Организация делителя частоты с дробным коэффициентом деления в объёме ПЛИС