Verilog. Первые шаги.

Всем привет.
Светодиодом помигал, динамическую индикацию на 7-ми сегментнике испробовал. Захотелось добавить в HelloWorld несколько последовательно соединенных двоично-десятичных счетчиков. Состряпал для этого модуль bcd счетчика. Не могу понять как его прикрутить к основному модулю. Цель: заставить бегать цифры от 0 до 9 хотя бы на одном из индикаторов. Пробовал сначала прикрутить тетрады data к отдельным счетчикам - не получилось, сейчас выделил для этого r1 - тоже ни в какую изменяться не хочет. Что я делаю не так ?
module bcd_counter(CLK, DOUT);
input CLK;
output [3:0] DOUT;
reg [3:0] data;
assykn DOUT = data;

always @(posedge CLK)
begin
if(data > 9) data = 0;
else data = data + 1;
end
endmodule

module lcd
(
input wire clk,
output reg [7:0] en,
output reg[7:0] seg
);

reg [31:0] data = h12345678;
reg [31:0] counter;

wire [2:0] tid_num;
assykn tid_num = counter[17:15];
reg [3:0] tid;

always @(posedge clk)
begin
counter=counter+1;
end

reg [3:0] r1;
wire [3:0] w_r1;
assykn w_r1 = r1;
wire w_clk;
assykn w_clk = counter[20];

bcd_counter cnt_1(w_clk, w_r1);

always @(tid_num)
begin
case(tid_num)
0: en = 8b11111110;
1: en = 8b11111101;
2: en = 8b11111011;
3: en = 8b11110111;
4: en = 8b11101111;
5: en = 8b11011111;
6: en = 8b10111111;
7: en = 8b01111111;
endcase
end

always @(tid_num)
begin
case(tid_num)
0: tid = r1[3:0];
1: tid = data[7:4];
2: tid = data[11:8];
3: tid = data[15:12];
4: tid = data[19:16];
5: tid = data[23:20];
6: tid = data[27:24];
7: tid = data[31:28];
endcase
end

always@(tid)
begin
case(tid)
4b0000: seg=8b1100_0000;
4b0001: seg=8b1111_1001;
4b0010: seg=8b1010_0100;
4b0011: seg=8b1011_0000;
4b0100: seg=8b1001_1001;
4b0101: seg=8b1001_0010;
4b0110: seg=8b1000_0010;
4b0111: seg=8b1111_1000;
4b1000: seg=8b1000_0000;
4b1001: seg=8b1001_0000;
4b1010: seg=8b1000_1000;
4b1011: seg=8b1000_0011;
4b1100: seg=8b1100_0110;
4b1101: seg=8b1010_0001;
4b1110: seg=8b1000_0110;
4b1111: seg=8b1000_1110;
endcase
end
endmodule

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

0

Сообщение от shurup да я их видел. но в этом случае мне придется поднимать частоту опроса входного сигнала. при 50 МГц тактовом генераторе в данном случае не получится производить замеры до 99999999 Гц (8 разрядов).

Синхронизатор не меняет частоты, а только выравнивает фазы разных клоков. Он как сдвиговый регистр.
Синхронизация не должна привести к изменению частотных свойств частотомера.

0

Сообщение от OtyxPM Сообщение от shurup да я их видел. но в этом случае мне придется поднимать частоту опроса входного сигнала. при 50 МГц тактовом генераторе в данном случае не получится производить замеры до 99999999 Гц (8 разрядов).

Синхронизатор не меняет частоты, а только выравнивает фазы разных клоков. Он как сдвиговый регистр.
Синхронизация не должна привести к изменению частотных свойств частотомера.
этот сдвиговый регистр надо же еще с определенной частотой сдвигать. и эта частота должна быть намного больше максимальной измеряемой частоты сигнала. нет ? имхо тут уже 50 МГц будет маловато. или я что-то не догоняю ?

0

Сообщение от shurup этот сдвиговый регистр надо же еще с определенной частотой сдвигать. и эта частота должна быть намного больше максимальной измеряемой частоты сигнала. нет ?

В теории частота целевого клок домена должна как минимум быть в 2 раза выше исходного, на практике обычно советуют не менее 2.5

Сообщение от shurup имхо тут уже 50 МГц будет маловато. или я что-то не догоняю ?

Перед синхронизатором можно воткнуть асинхронный делитель

0

Сообщение от яверт Перед синхронизатором можно воткнуть асинхронный делитель

можно воткнуть. только этот манёвр привяжет Ваш HDL-код к определённой архитектуре плис. возможно, что и к определённому температурному режиму.

Сообщение от яверт В теории частота целевого клок домена должна как минимум быть в 2 раза выше исходного, на практике обычно советуют не менее 2.5

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

shurup, все это к тому, что Вы можете тактировать Ваш синхронизатор системным клоком.

Сообщение от bfkroup OtyxPM писал(а): Вот как это выглядит в симуляторе: Гораздо интереснее было бы взглянуть на отчёт RTL Viewera.

OtyxPM, жаль, что Вы не выложили отчёт вьювера, а то мы могли бы тут вместе посмеяться. Вы наступили на те грабельки, которые не минуют ни одного начинающего в FPGA-дизайне. Суть в следующем. Вы написали код, в котором Ваш регистровый сигнал изменяется по восходящему и спадающему фронту клока. Вы просимулировали этот код в ModelSim и увидели, что всё работает как надо. Синтезировали схемку, назначили пины, прошили кристалл и занялись измерением частот. Всё в шоколаде? А вот и нет! Проблема в том, что синтезатор Вам там насинтезировал такого, что работоспособность получившейся схемы под большим вопросом. Самое интересное, что в Вашем случае модель моделсима не имеет к синтезированной схеме никакого отношения! Ну не существует ПЛИС с такими триггерами, которые семплируют данные по обоим фронтам клока!!! Никто не запрещает использовать в системе часть регистров с rising_edge, а другую часть с falling_edge. Интерконнект Cyclone III позволяет делать это даже в пределах одного LABа! Но регистр защёлкивающий данные по обоим фронтам имплементировать невозможно. Для избежания путаницы, в дальнейшем рекомендую, на начальном этапе раскуривания ПЛИС вообще отказаться от включения в свои проекты регистров со сработкой по различным фронтам.

0

Сообщение от shurup Я не совсем понимаю, как это должно правильно выглядеть и был бы благодарен если бы мне показали где и что подправить в моих исходниках.

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

В самом начале этой темы Вы пытались собрать цепочку счётчиков и это Вам не удалось, насколько я помню.

Предлагаю аналогичную задачу, только решать мы её будем используя поведенческий подход, а не структурный.
Пусть нам необходимо описать схему делящую входной клок в 131072 раза. Очевидно, нужно использовать шестнадцати-разрядный двоичный счётчик. Для того, что бы было хоть какое-то соответствие твоей задаче, мы будем описывать цепочку из двух восьми-разрядных счётчиков.

Итак, у нас есть пара восьмибитных двоичных счётчиков А и В. Есть некий промежуточный сигнал q который устанавливается в 1 ровно на один период клока clk в случае переполнения счётчика А. Вся суть подхода в том, что оба счётчика тактируются от одного клока, но счётчик В будет инкрементироваться только в случае активности q! Только и всего :)

Та же ситуация и с промежуточным сигналом tick_orsh -- он регистровый, тактируемый всё тем же клоком clk, однако изменяется он при условии A="11111111" omd B="11111111".

Если после синтеза, в Квартусе мы откроем Risource Property Editor, чтобы заглянуть в самые кишки нашей схемы, то мы увидим, что сигнал q соединён с входами CLK_ENABLE триггеров составляющих регистр счётчика В. Соответственно и сигнал A="11111111" omd B="11111111" имеет такую схемную роль для выходного триггера tick_orsh.

Очень долго это писал. Устал :(
Надеюсь, что не зря тратил своё время и это кому-нибудь пригодится.

0

Сообщение от bfkroup Гораздо интереснее было бы взглянуть на отчёт RTL Viewera. OtyxPM, жаль, что Вы не выложили отчёт вьювера, а то мы могли бы тут вместе посмеяться. ... ... Ваш регистровый сигнал изменяется по восходящему и спадающему фронту клока. ... ... Ну не существует ПЛИС с такими триггерами, которые семплируют данные по обоим фронтам клока!!!

<ul><li>У меня в коде нет ни одного присвоения по обоим фронтам.</li><li>Riset у меня - по уровню, а не по фронту, кусок кода я привёл.</li><li>Все декадные счётчики у меня синхронизированы с системным клоком и на входе, и на выходе.</li><li>Warningи компилятора я всегда вычищаю, даже если они параноидальные.</li><li>На скриншотах была продемонстрирована работа частотомера на частотах от 32кГц до 168МГц (диапазон - 4 декады).</li><li>А чтобы посмеяться над отчётом RTL Viewera - подскажите плз, в каком файле его взять. *.eda.rpt - это он? Квартус у меня 13-ый.</li></ul>

Сообщение от bfkroup Не стоит использовать латчи в FPGA.

Возможно, Вы спутали "плохой" latch (известная ошибка ПЛИС-дизайнов) с "хорошим" latchем, под которым у меня подразумевается

Защёлкивание значения на выходе счётчика-частотомера в параллельный регистр

Если эта защёлка тоже не есть гуд, то посоветуйте, кАк выводить живые показания частотомера на LCD. Останавливать счётчик частоты на время обновления дисплея?

А вообще, из всего, что выше, отличная статья получилась бы. bfkroup, shurup, не возьмётесь?

0

Вот живут же люди... Квартус у них. А я жру грёбаное ISE и плачу...и снова жру и плачу...а потом пробую перенести проект и снова плачу.

Прошу прощения за оффтоп, но меня оно донельзя за**ало.

"Защёлкивание значения на выходе счётчика-частотомера в параллельный регистр" - как по мне правильная идея. И никогда не переходите на Xilinx...

0

Сообщение от soumt_imobti Вот живут же люди... Квартус у них. А я жру грёбаное ISE и плачу...

Так ещё не поздно прикупить у китайцев Альтеру. 20...30...40 долларов удовольствие.
Хотя бы отдыхать душой после Xilinxа, раз у Вас с ним почему-то нелюбовь :-)

0

А помните, в сообществе выкладывали радио на плис. Там тоже xilinx вроде ничего страшного, гуй как гуй. Или там свои ньюнсы для кода?

0

Сообщение от Sykmottir А помните, в сообществе выкладывали радио на плис. Там тоже xilinx вроде ничего страшного, гуй как гуй. Или там свои ньюнсы для кода?

На уровне кода (VHDL, Verilog) должно быть одинаково. IDE у Ottira и Xilinx разные - по удобству (субъективно), набору тулзов.
Это как у микроконтроллеров разные IDE, и каждый предпочитает какую-то одну: для AVR - CodeVision или Studyo и др.; для STM32 - Keil или IAR или CooCox и др.

0

bfkroup, спасибо. все доходчиво разъяснил.

0

У меня к сожалению работа на Xilinxe. После нее душой отдыхать хочется на деревянных счётах, а не на электронике.

Нюанс Xilinx - ХУЁВЫЙ ЗЛОЕБУЧИЙ ТУЛЧЕЙН, крайне неудобный набор утилит, часто с размытым и перекрывающимся функционалом. Андроид с его фрагментацией это жалкий любитель. Пользователи активно используют больше 6 версий ISE, между которыми нереально мигрировать проект сложнее 74НС595. Туева хуча документации описывает старые версии, и в новых не работает. Умиляет старательно сохраняемая система веб-"помощи": типа если в вас ошибка, кликните по ссылке и прочитайте решение. На практике НИ ОДНОЙ ошибки нету задокументированой.
При том сами камни отличные, софткорный Microbtozi тоже неплох, куча бесплатных корок есть. Но софт это преступление против человечности.

0

может откроете новую ветку о достоинствах и недостатках IDE для ПЛИС ? и здесь лишнего срача не будет, и ваши умозаключения новичкам проще найти будет.

0

Сообщение от OtyxPM - подскажите плз, в каком файле его взять. *.eda.rpt - это он? Квартус у меня 13-ый.

Tools => Netlist Viewers => RTL Viewer.
Только перед тем как сделать экспорт, пожалуйста, уберите всю логику в облака -- так нам будет проще проследить пути данных между регистрами в Вашем проекте.

0

Кстати, из недоступного на МК, и поигратся на ПЛИС очень понравился радиопередатчик на ПЛИС с сайта марсохода. Я себе под циклон повторил, прикольно. Еще бы приемник был таким простым, но увы быстрые ацп у нас не достать.

0

Кстати, пришла мысль. На входе счетчика (частотомера) никакого синхронизатора ставить не надо. Здесь попадание в метастабильное состояние исключено, т.к. сам входной сигнал является счетным. Единственно где оно может возникнуть - это регистр защелка на выходах счетчика. Но и это не должно особо напрягать, т.к. выход из этого состояния глазу заметен не будет. Сигналы сброса счетчика и разрешения счета асинхронны и отношения к клокам не имеют. Считаю что моя реализация вполне жизнеспособна :).

Как считаете ? Я прав ?

Хотя на счет глаз я поторопился (обновление раз в секунду), надо обдумать...

А ну тогда в качестве синхронизатора использовать два или три регистра защелки на выходе счетчика (бред наверно несу :) . Это позволит не использовать PLL, т.е. можно смастерить и на cpld ipm240 к примеру с относительно низкочастотным тактовым генератором. Во как !!! :)

Блин, ну и на выходе счетчика проблем быть не должно. Счет же останавливается, только потом фиксируется в регистре защелке.
Нихера ничего не надо, думаю все и так ништяг и без возможных проблем :) Нет ?

Шуруп, садись. Пять :)

0

Сообщение от shurup Кстати, пришла мысль. На входе счетчика (частотомера) никакого синхронизатора ставить не надо. Здесь попадание в метастабильное состояние исключено, т.к. сам входной сигнал является счетным. Единственно где оно может возникнуть - это регистр защелка на выходах счетчика. Но и это не должно особо напрягать, т.к. выход из этого состояния глазу заметен не будет. Сигналы сброса счетчика и разрешения счета асинхронны и отношения к клокам не имеют. Считаю что моя реализация вполне жизнеспособна :).

Давайте взглянем на Вашу схему.

http://yody.sk/d/RiCGp8u8AcN9C
Обратите внимание, Вы тактируете регистры модуля bcd_counter_32 входным сигналом PIN.


http://yody.sk/d/BTzgtv16AcMx6
В топ-левеле регистр data тактируется clk.

Внимание вопрос! Будет ли выполнено условие по времени установки данных для регистра data. Или, другими словами, гарантированно ли установление данных на входе регистра data за время Tsu до прихода защёлкивающего клока clk ???

Понятно, что нет, гарантию такую никто на даст. Выражаясь языком STA Ваш Launch Clock асинхронен по отношению к Latch Clockу. И метастабильность возможна!!

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

Мультиклоковые дизайны будете ваять, когда немного освоитесь и подрастёте в теме FPGA :))

P.S.: Полчаса прикручивал картинки, а они не отобразились :(

0

Сообщение от bfkroup Внимание вопрос! Будет ли выполнено условие по времени установки данных для регистра data. Или, другими словами, гарантированно ли установление данных на входе регистра data за время Tsu до прихода защёлкивающего клока clk ???

А я отвечу :)
Будет гарантия, т.к. время установления выходов счетчика явно меньше длительности периода основной тактовой частоты. А у нас счетчик сначала останавливается и только через период CLK_50M защелкивается значение.

0

Сообщение от shurup т.к. время установления выходов счетчика явно меньше длительности периода основной тактовой частоты.

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

0

и тут вы ИМХО не правы :). Если время установления выхода будет соизмеримо или больше длительности периода тактовой частоты, то эту ПЛИС можно выкинуть, т.к. там вообще ничего стабильного сделать будет не возможно.

опс вместо 1Гц прочитал 1ГГц... мысль меняется в корне. надо обдумать

нет. мое утверждение в силе

0