[Konst_777 0]

Все, буду писать код...

Уверен, что Вам очень помогут книги Pong P. Chu:

"FPGA prototyping by VHDL examples (2008)"

"Embedded SoPC Design with Nios II Processor and VHDL Examples (2011)"

"RTL Hardware Design Using VHDL - Coding for Efficiency, Portability, and Scalability (2006)"

или

"Embedded SoPC Design with Nios II Processor and Verilog Examples"

"FPGA Prototyping by Verilog Examples_Xilinx Spartan-3 Version"

[kuchynski 0]

А по моему схема синхронная...

Если конечно описать выход каждого флопа как generated_clock....

Имелся ввиду вход CLRN триггеров. Случайное состояние (в момент переключения триггеров) входов элемента И, сгенирируеи импульс на его выходе, импульс получится коротенький, но сбросит всё к чертям на ноль. Это очень вероятный сценарий на этой схеме.

[topor_topor 0]

Имелся ввиду вход CLRN триггеров. Случайное состояние (в момент переключения триггеров) входов элемента И, сгенирируеи импульс на его выходе, импульс получится коротенький, но сбросит всё к чертям на ноль. Это очень вероятный сценарий на этой схеме.

ок. таким образом проблема не в синхронности схемы...

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

Выход одного тригера на асинхронный сбросс другого - можна.

----------

Как вариант решения в нашем случае, предлагаю счётчик сделать не двоичным а в Коде Грея или в коде OneHot (бегущая единица) чтобы менялось состояние только одного тригера за такт.

Тогда можно выходы всех флопов завести через комбинаторику в ресет, при условии что схема синхронна., а чтобы получить обычный двоичный выход счётчика - просто устанавить декодер Грея в Двоичный :)

 

[kuchynski 0]

ок. таким образом проблема не в синхронности схемы...

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

Выход одного тригера на асинхронный сбросс другого - можна.

Можно заводить сколько угодно сигналов на сброс тригера, но только через элемент ИЛИ, через элемент И нельзя! Ибо в первом случае мы говорим сигналам (синкронные они там или ассинхронные, не суть): "а ну, давай, любой из вас, сбрось триггер", и эти сигналы могут его сбросить независимо друг от друга. А во втором случае, посредством элемента И мы сообщаем сигналам: "соберитесь-ка вместе в такую-то комбинацию и совместно сбросте триггер", а сигнальчики буть они хоть сто раз синхронизированные, они как люди, а люди как тучи, как тучи они одиноки, и переключаются в разное время. Вот случайно и возникнет "комбинация сбросса".

Как вариант решения в нашем случае, предлагаю счётчик сделать не двоичным а в Коде Грея или в коде OneHot (бегущая единица) чтобы менялось состояние только одного тригера за такт.

Тогда можно выходы всех флопов завести через комбинаторику в ресет, при условии что схема синхронна., а чтобы получить обычный двоичный выход счётчика - просто устанавить декодер Грея в Двоичный :)

А, чтобы не усложнять схему кодом Грея, достаточно сигнал сброса фиксировать в отдельном тригерре и переключать во время гарантированного состояния, например сигналом CLOCK

[topor_topor 0]

Можно заводить сколько угодно сигналов на сброс тригера, но только через элемент ИЛИ, через элемент И нельзя!

Это не верное утверждение.

Ибо ИЛИ ибо И элементы пропускают гличи на асинхроннй сброс что может привести к неожиданному обнулению тригеров, а-то и хуже того - поставит схему в метастабилтное состояние (из-за того что глитч короткий и сетап\ремув тайм не выполнится для асинхронного входа).

Асинхронный сброс должен происходить в контролируемое время, а не пока гонки проходят в комбинаторике

 

[dima_spb 0]

:laughing: Товарищи?! А в чем проблема?

Вопросчик уже согласился использовать VHDL или Verilog для описания своего достаточно простенького устойства.

 

Просто можно все JK-триггера разрисовать на логике и дискутировать до бесконечности=)) Не подумайте Я не против....такого развития ситуации=)

Но может пусть он напишет этот счетчик несчастный=) и простеньким компоратором его сбросит=) А то что там понарисовано..пущай оставит себе для истории

[topor_topor 0]

:laughing: Товарищи?! А в чем проблема?

так интересно-же заставить исходную схему работать... чисто для розминки моска :)

а-то набросились на человека - пиши на верилоге и чисто синхронно описывай... так все могут...

[dima_spb 0]

так интересно-же заставить исходную схему работать... чисто для розминки моска :)

а-то набросились на человека - пиши на верилоге и чисто синхронно описывай... так все могут...

 

Ааа....все, моя поняла=) Меня просто чуть-чуть вымораживает схемотехнический подход=)))

Просто некогда я устроился на работу,а там мой предшественник (дедушка 60-70 лет) в течении

10 последних лет понакрутил таких проектов под кристаллы Xilinx, что то время когда я в этих

дебрях разбирался вспоминаю с ужасом=)))

 

[kuchynski 0]

Это не верное утверждение.

Ибо ИЛИ ибо И элементы пропускают гличи на асинхроннй сброс что может привести к неожиданному обнулению тригеров, а-то и хуже того - поставит схему в метастабилтное состояние (из-за того что глитч короткий и сетап\ремув тайм не выполнится для асинхронного входа).

Асинхронный сброс должен происходить в контролируемое время, а не пока гонки проходят в комбинаторике

Не знаю что такое гли, и как эта болезнь протекает в ИЛИ. Но логика элемента ИЛИ проста: если хотябы один вход желает установить выход, он это сделает и сделает без участия других сигналов.

 

:laughing: Товарищи?! А в чем проблема?

Вопросчик уже согласился использовать VHDL или Verilog для описания своего достаточно простенького устойства.

А как переход из схематика на печатный язык решает данную проблему? Какая разница схему рисовать или схему писать?

Скажем вышеозначенная проблема легко переносится на verilog:

 

assign rst = tr1 & tr2 & !tr3 & tr4;
always@(posedge rst, posedge clk) begin
    tr1 <= (rst)? 0 : in_tr;
end

Для Torpeda. Здесь нет проблемы:

assign rst = tra1 | tra2 | !tra3 | tra4;
always@(posedge rst, posedge clk) begin
    tr1 <= (rst)? 0 : in_tr;
end

 

Просто можно все JK-триггера разрисовать на логике и дискутировать до бесконечности=)) Не подумайте Я не против....такого развития ситуации=)

Но может пусть он напишет этот счетчик несчастный=) и простеньким компоратором его сбросит=) А то что там понарисовано..пущай оставит себе для истории

А простенький копаратор - это часом не тот же злосчастный элемент И, прорисованный в верхнем левом углу? Всё-таки полезно сначала схему прорисовать, а потом написать.

Изменено 15 ноября, 2013 пользователем kuchynski

[Golikov 0]

замечу все же что

A&B == not(A|B)

 

поэтому то что ваш элемент или пропускает хотя бы одну единицу на выход

равнозначно тому что наш элемент и пропускает хотя бы один ноль на выход

 

так что как бы делить на или - хорошо и на и - плохо не верно....

[dima_spb 0]

А как переход из схематика на печатный язык решает данную проблему? Какая разница схему рисовать или схему писать?

Скажем вышеозначенная проблема легко переносится на verilog:

 

А простенький копаратор - это часом не тот же злосчастный элемент И, прорисованный в верхнем левом углу? Всё-таки полезно сначала схему прорисовать, а потом написать.

 

Дело все в том, что если речь идет о простом проекте на базе ПЛИС...

- поморгать лампочками

- обработать кнопочки

- и т.д. и т.п.

еще наверное схемотехническая реализация уместна, но вот если рець идет о ЦОС,

не приметивных КОНЕЧНЫХ АВТОМАТАХ то искусство которое получится на выходе

(я про ту многоэтажную схему) она будет сложна к восприятию и больна на коррективы.

 

В схеме можно нарисовать все тоже,что и написать....НО на языке это делается гораздо комфортнее

и зачастую удобнее для восприятия......И ТАМ ЕСТЬ КОММЕНТАРИИ (в языках описания аппаратуры)

 

 

 

Какая разница схему рисовать или схему писать?

Об этом я уже упоминал

 

Хотелось бы посоветовать! Вы когда создаете устройства в схемотехническом редакторе - Вы мыслите триггерами, логическими элементами и т.д. и т.п. А когда Вы описываете принцип работы устройства используя языки описания аппаратуры было бы правельней если Вы абстрагируйтесь от классических модулей счетчиков, триггеров.

Просто дело в том, что есть категория людей которая описывает не принцип работы, а СХЕМУ....просто повторяют нарисованное при помощи конструкция языка. Наверное это бесмысленно. Подумайте, возможно этот опыт будет Вам полезен.

 

[kuchynski 0]

замечу все же что

A&B == not(A|B)

 

поэтому то что ваш элемент или пропускает хотя бы одну единицу на выход

равнозначно тому что наш элемент и пропускает хотя бы один ноль на выход

 

так что как бы делить на или - хорошо и на и - плохо не верно....

Да, соглашусь.

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

[topor_topor 0]

Не знаю что такое гли, и как эта болезнь протекает в ИЛИ. Но логика элемента ИЛИ проста: если хотябы один вход желает установить выход, он это сделает и сделает без участия других сигналов.

Glitch, spike - это короткие импульсы из-за гонок в комбинаторике....

[Faton_11 0]

Konst_777, спасибо, классные ссылки, вообще спасибо всем!)

Здесь так глобально тема разрослась, что даже уже неловко задавать свой вопросец.. =)Сложность со связыванием 2-х триггеров, никакие комбинации ни к чему хорошему не приводят. В коде просто отдельные 2 триггера, как выход от первого сделать входом для второго?

(output reg Q1,Q2, input K...J...);

wire Q1_;
wire Q2_;

always@(posedge clk) 
  if (!rst) 
  begin
    Q1=0;
    Q2=0;
end
      else
        begin
          Q1=Q1_;
          Q2=Q2_;
end     
      
       assign Q1_=(J1&~Q1)|(~K1&Q1); 
       assign Q2_=(J3&~Q2)|(~K3&Q2);

 

Конструкция assign Q2_=(J2&~Q1)|(~K2&Q1), разумеется, не работает..

Изменено 15 ноября, 2013 пользователем Faton_11

[Golikov 0]

:)

 

любой компонент имеет описание вида

 

Component Name

#(params)

(.signal_in1(in1),

.signal_in2(in2),

.....

.signal_out1(out1),

.signal_out1(out2)

....

)

 

то что в скобках (in1,in2, ....ou1, 0ut2,... )- это ваши сигналы, они же wire, ставя их в скобки в описании, вы тем самым подключаете соотвествующий порт на этот сигнал.

 

так что создаете wire from1_to_2

и создаете триггеры, в скобки ставите это в выход одного и вход другого...

 

 

Как точно задание звучит? создать счетчик или создать счетчик на JK триггерах? потому что в первом случае выбранный подход не верный, и как указывает человек в костюме бетмана - вредный!!!