преобразователь КОД-ЧАСТОТА Опции

[Iptash]

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

[Boris_TS]

Как я понимаю, у Вас получается регистр (хранящий код, с которого начинает считать счетчик) и непосредственно сам счетчик. Если это так, то счетчик можно доукомплектовать входом предустановки (во все единицы). Тогда на следующем после предустановки такте, счетчик загрузит новое значение.

Если я правильно понял Вашу проблему, то это Вам должно подойти.

[Iptash]

Как я понимаю, у Вас получается регистр (хранящий код, с которого начинает считать счетчик) и непосредственно сам счетчик. Если это так, то счетчик можно доукомплектовать входом предустановки (во все единицы). Тогда на следующем после предустановки такте, счетчик загрузит новое значение.

Если я правильно понял Вашу проблему, то это Вам должно подойти.

Вы правильно меня поняли. Т.е. как я понял предустановку делать при изменении кода? но
тогда потеряется предыдущее значение? Может их как то суммировать эти кода?

[sazh]

счетчик на вычитание. По своему переносу загружает новое значение из регистра.

[Iptash]

счетчик на вычитание. По своему переносу загружает новое значение из регистра.

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

[sazh]

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

Значит проигнорировал изменение.
По переполнению (прерыванию) код должен меняться и устаканиться к ожидаемому переполнению

[Iptash]

Значит проигнорировал изменение.
По переполнению (прерыванию) код должен меняться и устаканиться к ожидаемому переполнению

Игнорировать нельзя. Устройство реального времени. Запись кода происходит допустим каждую
1мс. и мне кажется, что нужно при записи делать логическое сложение данных в счетчике и
кода. Как вы думаете?.

[sazh]

Игнорировать нельзя. Устройство реального времени. Запись кода происходит допустим каждую
1мс. и мне кажется, что нужно при записи делать логическое сложение данных в счетчике и
кода. Как вы думаете?.

Не понятно, что такое логическое сложение. Возможны наверно два варианта. Первый - это пока заданное не отработает, игнорирует записанный код в регистре. Второй вариант - Снова перезаписывает новое значение кода - и до переполнения. Не понятно что получается.
Вот пример, наверно базисный.

Код

module shim_test
(
input       clk,
input [7:0] period,
input [7:0] interval,
output reg  l_int,
output      shim,
output reg  ochibka
);

reg [7:0] ct_a, ct_b;
reg       enable;


always @(posedge clk)
begin
if (ct_a == 8'd1)         begin
ct_a   <=   (period == 8'd0) ? 8'd1 : period;
ct_b   <= (interval == 8'd0) ? 8'd1 : interval;
enable <= 1'b1;
l_int  <= 1'b1;           end
else                                       begin
                     ct_a <= ct_a - 1'b1;
if (enable)          ct_b <= ct_b - 1'b1;
if (ct_b == 8'd1)  enable <= 1'b0;
                    l_int <= 1'b0;         end

ochibka <= (period <= interval);
end

assign shim = enable;

endmodule

[Boris_TS]

Игнорировать нельзя. Устройство реального времени. Запись кода происходит допустим каждую
1мс. и мне кажется, что нужно при записи делать логическое сложение данных в счетчике и
кода. Как вы думаете?.

Я использую конструкция просто регистр + счетчик, в такой задаче: есть некий подвижный объект, он перемещается с какой-то скоростью, необходимо генерировать импульсы (для запуска чего-то) через равные промежутки расстояния, скорость конечно же меняется... При моих физических ограничениях на возможные ускорения объекта (и !!! заданной минимальной частоты дискретизации) вполне достаточно досчета счетчика по старому значению и по переполнению загрузки нового.
Я вот у Вас как-то до конца не разобрал этот момент...

А вот наверное третий вариант...
Но если Вам необходимо работать так:
1. Если новое значение меньше предыдущего (понижаем частоту) - то можно, чтобы счетчик досчитал до переноса.
2. Если новое значение больше предыдущего (повышаем частоту) - то необходимо, чтобы счетчик с момента обновления считал не дольше нового (свежезаданного периода ожидания).

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

Надеюсь не слишком мутно объяснил

[Iptash]

Не понятно, что такое логическое сложение. Возможны наверно два варианта. Первый - это пока заданное не отработает, игнорирует записанный код в регистре. Второй вариант - Снова перезаписывает новое значение кода - и до переполнения. Не понятно что получается.
Вот пример, наверно базисный.

Код

module shim_test
(
input       clk,
input [7:0] period,
input [7:0] interval,
output reg  l_int,
output      shim,
output reg  ochibka
);

reg [7:0] ct_a, ct_b;
reg       enable;
always @(posedge clk)
begin
if (ct_a == 8'd1)         begin
ct_a   <=   (period == 8'd0) ? 8'd1 : period;
ct_b   <= (interval == 8'd0) ? 8'd1 : interval;
enable <= 1'b1;
l_int  <= 1'b1;           end
else                                       begin
                     ct_a <= ct_a - 1'b1;
if (enable)          ct_b <= ct_b - 1'b1;
if (ct_b == 8'd1)  enable <= 1'b0;
                    l_int <= 1'b0;         end

ochibka <= (period <= interval);
end

assign shim = enable;

endmodule

Спасибо. Я подумаю. Если, что надумаю, выложу.

Я использую конструкция просто регистр + счетчик, в такой задаче: есть некий подвижный объект, он перемещается с какой-то скоростью, необходимо генерировать импульсы (для запуска чего-то) через равные промежутки расстояния, скорость конечно же меняется... При моих физических ограничениях на возможные ускорения объекта (и !!! заданной минимальной частоты дискретизации) вполне достаточно досчета счетчика по старому значению и по переполнению загрузки нового.
Я вот у Вас как-то до конца не разобрал этот момент...

А вот наверное третий вариант...
Но если Вам необходимо работать так:
1. Если новое значение меньше предыдущего (понижаем частоту) - то можно, чтобы счетчик досчитал до переноса.
2. Если новое значение больше предыдущего (повышаем частоту) - то необходимо, чтобы счетчик с момента обновления считал не дольше нового (свежезаданного периода ожидания).

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

Надеюсь не слишком мутно объяснил

У меня тоже для управления неким объектом. ЧПУ выдает код на мое устройство переодом 1мс..
Допустим мое устройство меняет переод от 10мкс. до 1сек.. Вот в случае если записан код для 1сек.
то ЧПУ в этот момент может изменить 1000раз.. Это устройство можно назвать как ЦАП с цифровым
выходом что-ли?. Т.е. мое устройство должно реагировать как ЦАП.

[barabek]

Спасибо. Я подумаю. Если, что надумаю, выложу.
У меня тоже для управления неким объектом. ЧПУ выдает код на мое устройство переодом 1мс..
Допустим мое устройство меняет переод от 10мкс. до 1сек.. Вот в случае если записан код для 1сек.
то ЧПУ в этот момент может изменить 1000раз.. Это устройство можно назвать как ЦАП с цифровым
выходом что-ли?. Т.е. мое устройство должно реагировать как ЦАП.

А в чем заморочка собственно? Пусть счетчик считает от нуля до заданного. Т.е. если содержимое счетчика больше заданного (большеИЛИравно?), счетчик обнулять. Заданное обновлять независимо от счетчика. Почему такой вариант не подходит

Код

     wire clk;                                       //input
     wire reload;                                  //input
     wire [MAXWIDTH:0] newlimit;        //input

     reg [MAXWIDTH:0] counter, limit;
     always@(posedge clk)
            if(counter>limit)counter<='d0;
            else counter<=counter+1'b1

    always@(posedge clk)
           if(reload)limit<=newlimit;

можно оба олвейса объеденить, конечно же

[Iptash]

А в чем заморочка собственно? Пусть счетчик считает от нуля до заданного. Т.е. если содержимое счетчика больше заданного (большеИЛИравно?), счетчик обнулять. Заданное обновлять независимо от счетчика...

Заморочка в том, что мое устройство должно "моментально" реагировать на изминение входного кода
и не терять предыдущего(которое еще не "отработано") А считать лучьше от заданного до нуля,
проще схема сравнения и меньше рессурсов понадобиться.

[Dopler]

А почему бы не сделать следующее:
Максимальное значение счетчика сделать фиксированным (большим), а увеличивать его не на 1, а на требуемый код (не счетчик а сумматор). Выход - старший разряд счетчика (сумматора) Т.е. нужно частоту большую - код большой (счетчик быстро переполняется), нужно маленькую - код маленький. В данном случае реакция мгновенная. По такому принципу построены DDS.

[Iptash]

А почему бы не сделать следующее:
Максимальное значение счетчика сделать фиксированным (большим), а увеличивать его не на 1, а на требуемый код (не счетчик а сумматор). Выход - старший разряд счетчика (сумматора) Т.е. нужно частоту большую - код большой (счетчик быстро переполняется), нужно маленькую - код маленький. В данном случае реакция мгновенная. По такому принципу построены DDS.

Спасибо. Я так тоже думал, это один из вариантов.Но это тоже самое, когда код маленький счетчик
долго переполняется, а в случае пока он не переполнился код допустим поменялся(резко вырос)
нужно соответственно и код менять + тот код который не досчитал, а не ждать пока он досчитает.
Вот это будет наверное более реальное воздействие.

[barabek]

Заморочка в том, что мое устройство должно "моментально" реагировать на изминение входного кода
и не терять предыдущего(которое еще не "отработано") А считать лучьше от заданного до нуля,
проще схема сравнения и меньше рессурсов понадобиться.

Как можно И "моментально" среагировать И "не терять предыдущего". Разве это возможно? Вы привели пример : "Вот в случае если записан код для 1сек. то ЧПУ в этот момент может изменить 1000раз." Допустим такую ситуацию. Записан код на 1с. Прошло допустим 0,011 секунд. Пришел код на 10мс. Теперь возможны 2 ситуации. 1. Т.к. уже отсчитано более 10мс, перегружаемся и считаем заново (мое предложение - один из вариантов). 2. Досчитываем до 1 с, а затем переходим на новую частоту (например, Ваш вариант). Но И то И одновременно другое реализовать нельзя. ИЛИ-ИЛИ. Может я что-то не догоняю?
А на счет ресурсов - так их же много . А если у Вас нужно предусмотреть reset, то у ALTERы, например, рекомендуется все регистры сбрасывать по питанию именно в 0. Можно и в 1, но это требует дополнительных ресурсов. Это так, к слову.

[dvladim]

рекомендуется все регистры сбрасывать по питанию именно в 0. Можно и в 1, но это требует дополнительных ресурсов. Это так, к слову.

Так, к слову, дополнительных ресурсов не требует. Альтера это делает инверсией входа и выхода триггера.

[barabek]

Так, к слову, дополнительных ресурсов не требует. Альтера это делает инверсией входа и выхода триггера.

Да, но это же дополнительные все-таки ресурсы . По крайне мере я так понял. А их фитер мог бы для чего-нибудь другого использовать. Или нет?

Сообщение отредактировал barabek - Nov 16 2008, 14:32

[Iptash]

Как можно И "моментально" среагировать И "не терять предыдущего". Разве это возможно? Вы привели пример : "Вот в случае если записан код для 1сек. то ЧПУ в этот момент может изменить 1000раз." Допустим такую ситуацию. Записан код на 1с. Прошло допустим 0,011 секунд. Пришел код на 10мс. Теперь возможны 2 ситуации. 1. Т.к. уже отсчитано более 10мс, перегружаемся и считаем заново (мое предложение - один из вариантов). 2. Досчитываем до 1 с, а затем переходим на новую частоту (например, Ваш вариант). Но И то И одновременно другое реализовать нельзя. ИЛИ-ИЛИ. Может я что-то не догоняю?
А на счет ресурсов - так их же много . А если у Вас нужно предусмотреть reset, то у ALTERы, например, рекомендуется все регистры сбрасывать по питанию именно в 0. Можно и в 1, но это требует дополнительных ресурсов. Это так, к слову.

Я думал в таком плане. Когда приходит новый код то берется из счетчиков код и логически
складываем с новым кодом и опять в счетчик, а как мы знаем лог. 1+1=1 т.е. получается в счетчике
будет новый код + недосчитанный код. Наверное вот это и будет "моментальное" реагирование. Помоему должно работать, только как это аппаратно более гибко сделать?

[Iptash]

Вот у меня такая блок-схема прорисовывается. Для примера нарисовал 4разрядный преобразователь
код-частота. Я конечно не симулировал эту схему, но вроде должно работать, только надо
выход тоже простробировать входной частотой. Здесь как бы получается "моментальное" реагирование
на входной код не теряя код в счетчике. Ваше мнение?

Эскизы прикрепленных изображений

 

[Ed)]

Согласен с Dopler.

Спасибо. Я так тоже думал, это один из вариантов.Но это тоже самое, когда код маленький счетчик
долго переполняется, а в случае пока он не переполнился код допустим поменялся(резко вырос)
нужно соответственно и код менять + тот код который не досчитал, а не ждать пока он досчитает.
Вот это будет наверное более реальное воздействие.

Это будет не реальное воздействие. Т.к. здесь используется не терминология счётчиков: досчитал и переполнился, а терминология мгновенной фазы и скорости её изменения. Соответственно быстрые изменения частоты (скорости изменения мгновенной фазы) не будут накапливать ошибку результирующей частоты. Выходным сигналом будет служить старший бит регистра сумматора.

[Iptash]

Согласен с Dopler.
Это будет не реальное воздействие. Т.к. здесь используется не терминология счётчиков: досчитал и переполнился, а терминология мгновенной фазы и скорости её изменения. Соответственно быстрые изменения частоты (скорости изменения мгновенной фазы) не будут накапливать ошибку результирующей частоты. Выходным сигналом будет служить старший бит регистра сумматора.

Как я понял, Dopler описал принцип X = X+КОД до какого то максимального значения. Т.е. чем
больше код, тем быстрее досчитает до этого значения. Но мне кажется, что если по ресунку
записать в регистр большой код, то счетчик тоже будет быстро переполнятся и соответственно переполнения будут быстро происходить, а это помоему тоже самое, а аппаратная реализация будет на много проще. Или же я что-то не понемаю?

[Ed)]

Как я понял, Dopler описал принцип X = X+КОД до какого то максимального значения. Т.е. чем
больше код, тем быстрее досчитает до этого значения. Но мне кажется, что если по ресунку
записать в регистр большой код, то счетчик тоже будет быстро переполнятся и соответственно переполнения будут быстро происходить, а это помоему тоже самое, а аппаратная реализация будет на много проще. Или же я что-то не понемаю?

Вы же сами говорили, что преобразователь должен "правильно" себя вести в случае когда скорость изменения частоты намного выше периода выходного сигнала. Для аккумулятора фазы это будет означать лишь быстрые изменения скорости перемещения выходного сигнала из одного состояния в противоположное.
Аппаратная реализация довольно проста: регистр для мгновенной фазы, регистр для кода частоты и сумматор, который синхронно с опорной частотой производит их суммирование, а результат опять сохраняет в регистре мгновенной фазы. Переполнение этого регистра не имеет значения, и эквивалентно переходу фазы с 2*Pi обратно на 0. Старший бит можно интерпретировать как знак косинуса текущей фазы:
от 0 до Pi -> +1 (для лог. "1")
от Pi до 2*Pi -> -1 (для лог. "0")

[Iptash]

Вы же сами говорили, что преобразователь должен "правильно" себя вести в случае когда скорость изменения частоты намного выше периода выходного сигнала. Для аккумулятора фазы это будет означать лишь быстрые изменения скорости перемещения выходного сигнала из одного состояния в противоположное.
Аппаратная реализация довольно проста: регистр для мгновенной фазы, регистр для кода частоты и сумматор, который синхронно с опорной частотой производит их суммирование, а результат опять сохраняет в регистре мгновенной фазы. Переполнение этого регистра не имеет значения, и эквивалентно переходу фазы с 2*Pi обратно на 0. Старший бит можно интерпретировать как знак косинуса текущей фазы:
от 0 до Pi -> +1 (для лог. "1")
от Pi до 2*Pi -> -1 (для лог. "0")

Я всего лишь хочу сделать аналог ЦАПа, только здесь выход КОД-ЧАСТОТА, а в ЦАПе КОД-НАПРЯЖЕНИЕ или ТОК.

[Ed)]

Я всего лишь хочу сделать аналог ЦАПа, только здесь выход КОД-ЧАСТОТА, а в ЦАПе КОД-НАПРЯЖЕНИЕ или ТОК.

Об этом и речь: код->частота.
Погугли Direct Digital Synthesis (DDS).

[Iptash]

Об этом и речь: код->частота.
Погугли Direct Digital Synthesis (DDS).

Хорошо.
А по поводу блок-схемы что скажешь если я понятно нарисовал?

[Ed)]

Хорошо.
А по поводу блок-схемы что скажешь если я понятно нарисовал?

Насчёт OR'ить. Посмотри что получится если производить запись одного и того же кода частоты.
Особо интересен случай, когда периодичность записи кода выше требуемой выходной частоты. В этом случае выход всегда будет в "1", т.е. никакой частоты вообще.
И ещё, что насчёт скваженности?

[Iptash]

Насчёт OR'ить. Посмотри что получится если производить запись одного и того же кода частоты.
Особо интересен случай, когда периодичность записи кода выше требуемой выходной частоты. В этом случае выход всегда будет в "1", т.е. никакой частоты вообще.
И ещё, что насчёт скваженности?

Допустим КОД= 0001(bin) он и будет прописывать в младшем разряде 1 и все.Ну и конечно же
логический + вых. счетчика. Загрузка счетчика происходит стробом, а не статично.
Запись кода в основном будет выше вых. частоты. Я мысленно просимулировал эту схему, вроде накладок не должно быть.А, что на счет скваженности?. Выходной сигнал будет простробирован допустим вх. частотой.

[Iptash]

Все, схемку собрал, просимулировал в QUARTUS, работает должным образом. Схему собрал на макрофункциях.
Сейчас посмотрим что в железе получится.

Сообщение отредактировал Iptash - Nov 21 2008, 16:56