[aprox 0]

Просто логически неправильно подавать один и тот же сигнал rx_locked и на тактовый вход триггера, и на вход данных.

В AHDL "такую глупость" тоже никто не мешает сделать :)

Такая глупость маловерятна потому, что пишущий на AHDL уже имеет в голове образ D-триггера, который надо конкретно обыграть примитивами dff, dffe, tff, srff. А в представленном фрагменте на Verilog никакой внутренней аржитектуры FPGA разглядеть неозможно. Отсюда и простор для глупостей, типа работу триггера писать вручную и, естественно, ошибиться и "описаться" лишний раз.

[bogaev_roman 0]

Такая глупость маловерятна потому, что пишущий на AHDL уже имеет в голове образ D-триггера, который надо конкретно обыграть примитивами dff, dffe, tff, srff. А в представленном фрагменте на Verilog никакой внутренней аржитектуры FPGA разглядеть неозможно. Отсюда и простор для глупостей, типа работу триггера писать вручную и, естественно, ошибиться и "описаться" лишний раз.

:bb-offtopic:

Я вот такую глупость даже на схематике реализовать могу, уже имея изображение D-триггера

Edited May 28, 2010 by bogaev_roman

[aprox 0]

Я вот такую глупость даже на схематике реализовать могу, уже имея изображение D-триггера

Охотно верю. Hо это будет осознанная с вашей стороны глупость. А у программиста, про которого вы писали мол "описался", глупость была естественной. Языки VHDL/Verilog созданы для чистых программистов, которые ничерта не понимают в схемотехнике. Отсюда и все глупости.

[ViKo 1]

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

always @(posedge rx_outclock or negedge rst_)

из которой не очевидно, что один вход работает по фронту, а другой по уровню.

А написать так

always @(posedge rx_outclock or rst_)

увы, нельзя!

[Des333 0]

always @(posedge rx_outclock or negedge rst_)

 

Может Вам будет легче воспринимать этот блок таким образом:

 

Запускать каждый раз при выполнении следующих условий: положительного перепада rx_outclock или отрицательного перепада rst_

 

если rst_ равняется 0 (а он после отрицательного перепада равняется)

 

  делать ...

 

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

 

 делать ...

 

 

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

А, если это не до конца понятно, наверное, стоит еще пописать простые примеры и понять, как работает синтезатор.

[Mahagam 0]

Такая глупость маловерятна потому, что пишущий на AHDL уже имеет в голове образ D-триггера, который надо конкретно обыграть примитивами dff, dffe, tff, srff. А в представленном фрагменте на Verilog никакой внутренней аржитектуры FPGA разглядеть неозможно. Отсюда и простор для глупостей, типа работу триггера писать вручную и, естественно, ошибиться и "описаться" лишний раз.

бред.

 

// FDRSE: Single Data Rate D Flip-Flop with Synchronous Clear, Set and

// Clock Enable (posedge clk).

// Spartan-3

// Xilinx HDL Language Template, version 11.4

 

FDRSE #(

.INIT(1'b0) // Initial value of register (1'b0 or 1'b1)

) FDRSE_inst (

.Q(Q), // Data output

.C©, // Clock input

.CE(CE), // Clock enable input

.D(D), // Data input

.R®, // Synchronous reset input

.S(S) // Synchronous set input

);

 

вот вам Verilog, с которым не ошибёшся. такое же идиотское описание каждого триггера. а что делать когда нужно быстренько описать две сотни триггеров? вспоминать как описать каждый? как dff, dffe, tff, srff? описывалка не опухнет?

 

 

Языки VHDL/Verilog созданы для чистых программистов, которые ничерта не понимают в схемотехнике. Отсюда и все глупости.

это вот самая большая глупость.

[bogaev_roman 0]

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

always @(posedge rx_outclock or negedge rst_)

из которой не очевидно, что один вход работает по фронту, а другой по уровню.

А написать так

always @(posedge rx_outclock or rst_)

увы, нельзя!

Абсолютно никакого основания

always @(posedge rx_outclock or negedge rst_)

- Д-Триггер, работающий по фронту с асинхронным сбросом по срезу

always @(posedge clk)
if (~rst)

- Д-триггер, работающий по фронту с синхронным сбросом.

Какой триггер Вы хотите реализовать записью

always @(posedge rx_outclock or rst_)

мне не понятно.

Языки VHDL/Verilog созданы для чистых программистов

Может с этим кто-то и согласится, но мое мнение такого:

Verilog, VHDL - это не языки программирования, а языки описания аппаратуры и сравнивать его с СИ++ например может только человек, незнакомый с ними или знающий поверхностно. Я на том же верилоге могу все хоть повентильно описать, используя примитивы. Другое дело, что в нем заложено некое "дополнение", есть нечто от СИ++ для удобства и если ентим кто-то пользуется неумело - то это его проблемы.

[Putnik 0]

always @(posedge rx_outclock or negedge rst_)

- Д-Триггер, работающий по фронту с асинхронным сбросом по срезу

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

другое дело, как сказал des333, быстро привыкаешь к такому описанию,

так что запись

always @(posedge rx_outclock or rst_)

была бы конечно понятней

Edited May 28, 2010 by Putnik

[ViKo 1]

Абсолютно никакого основания

always @(posedge rx_outclock or negedge rst_)

- Д-Триггер, работающий по фронту с асинхронным сбросом по срезу

Хотите, я после этого заголовка напишу такое, что rst_ заведется на тактовый вход, а rx_outclock на сброс?

 

Может Вам будет легче воспринимать этот блок таким образом:

А, если это не до конца понятно, наверное, стоит еще пописать простые примеры и понять, как работает синтезатор.

Обидеть меня хотите:)?

[x736C 1]

Чтоб не плодить дополнительные темы, заодно тут сразу спрошу.

Привык пользоваться триггером с синхронным сбросом. После синтеза занимает больше ресурсов, нежели применение асинхронного сброса.

Как предпочтительнее?

О существовании CummingsSNUG2002SJ_Resets.pdf знаю, но пока не осилил.

 

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

[Des333 0]

Обидеть меня хотите :) ?

 

Нет, что Вы.  :)

Просто написал вариант объяснения конструкции always, который оправдывает спорное использование слова posedge для сигнала сброса.

 

 

А фраза:

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

А, если это не до конца понятно, наверное, стоит еще пописать простые примеры и понять, как работает синтезатор.

Это уже не Вам, а тем, кто действительно не понимает конструкций HDL.

[ViKo 1]

2 bogaev_roman

module  Locker2 (input clk, rst, in, output out);
  always @(posedge clk, negedge rst)
    if (clk) out = 0;
    else out = in;
endmodule

[aprox 0]

Чтоб не плодить дополнительные темы, заодно тут сразу спрошу.

Привык пользоваться триггером с синхронным сбросом. После синтеза занимает больше ресурсов, нежели применение асинхронного сброса.

Странно. Наверное пишете на Verilog? В AHDL количество использованных лог.элементов получается одинаковым, что при синхронном сбросе триггера, что при асинхронном. Причем в AHDL результат синтеза, какой же все-таки сброс получится, всегда стопроцентно предсказуем. Hе то, что в Verilog.

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

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

[Putnik 0]

Странно. Наверное пишете на Verilog? В AHDL количество использованных лог.элементов получается одинаковым, что при синхронном сбросе триггера, что при асинхронном. Причем в AHDL результат синтеза, какой же все-таки сброс получится, всегда стопроцентно предсказуем. Hе то, что в Verilog.

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

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

[aprox 0]

вот вам Verilog, с которым не ошибёшся. такое же идиотское описание каждого триггера. а что делать когда нужно быстренько описать две сотни триггеров? вспоминать как описать каждый? как dff, dffe, tff, srff? описывалка не опухнет?

Проблемы с двумя сотней триггеров в AHDL не понял. Сформулируйте понятнее и я вам тут же выдам простейший вариант. А в целом очень характерно, что отстаивают преимущества VHDL/Verilog большей частию разработчики на Xilinx. Им просто больше некуда деваться.