[Golikov 0]

И это описание все равно превращается в эквивалент "схемы", а не в "поведение"

ну так в этом кажется и вся фишка.

 

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

 

 

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

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

[topor_topor 0]

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

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

Вот правда я никогда невидал синхронный D-тригер с асинхронной загрузкой одновременно....С Сетом\Ресетом асинхронными - да, а вот чтоб с асинхронной загрузкой....

 

 

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

 

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

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

1) "если изначально мыслить схемой нельзя зайти в тупик технологий" - 100%

2) "часто может оказаться что не найдется ПЛИС реализующих желаемое поведение" - ябы сказал, может не найтись синтезаторов на это способных, или что есчё хуже (и чаще) - оно то синтезнёт чёто с вашей VHDL программы...но работать оно будет неожиданно....

 

Я против VHDL програмирования - я за схемотехнику! (конечно, не при создании тесбенчей - там хоть упрограмироваться можно)

3) Нельзя сделать "латч-синхронный тригер" в одном флаконе, как и описано в коде автора.....

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

 

-----------------

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

В этом случае - никаких проблеем вообще нет (если соответственно схеме переписать код разумеется)

[SM 13]

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

Вот правда я никогда невидал синхронный D-тригер с асинхронной загрузкой одновременно....С Сетом\Ресетом асинхронными - да, а вот чтоб с асинхронной загрузкой....

 

Да, обычный синхронный триггер с асинхронной загрузкой. У альтеры, например, примитивы DFFEA или DFFEAS. Синтезатор же под латис, при формировании такого триггера, ввиду отсутствия "железной конструкции", сам генерирует хитрую схему из двух триггеров и латча (второй триггер с асинхронной предустановкой и синхронным сбросом управляет мультиплексором латч/первый_триггер).

 

но, правильное (синтезируемое) описание, выглядит так:

always @(posedge clk or posedge aload)
if (aload) ff <= adata; else if (ena) ff <= sdata;

[Lutovid 2]

В цифровой технике никокого "програмирования на VHDL" и никаких "стыковок кода" быть не может :)

Только описание схемы на языке (просто вместо рисования)

Поэтому, описанный фрагмент, должен превратится в конкретный схемотехнический элемент (как минимум в голове дизайнера :))

Иначе обсуждение того, как это реализовать - не имеет смысла.....

 

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

 

Да, обычный синхронный триггер с асинхронной загрузкой. У альтеры, например, примитивы DFFEA или DFFEAS. Синтезатор же под латис, при формировании такого триггера, ввиду отсутствия "железной конструкции", сам генерирует хитрую схему из двух триггеров и латча (второй триггер с асинхронной предустановкой и синхронным сбросом управляет мультиплексором латч/первый_триггер).

 

но, правильное (синтезируемое) описание, выглядит так:

always @(posedge clk or posedge aload)
if (aload) ff <= adata; else if (ena) ff <= sdata;

 

я что-то не пойму в чем разница между вашим и моим примером, исключая то, что он на верилоге) тот же сенсетив лист и логика же, нет?

[SM 13]

я что-то не пойму в чем разница между вашим и моим примером, исключая то, что он на верилоге) тот же сенсетив лист и логика же, нет?

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

 

Но, в принципе, если повезет, то и Вашу конструкцию синтезатор сможет синтезировать, это только от него самого и зависит.

 

UPD:

могу сказать, что конструкция, приведенная ниже, синтезируется и надежно работает во всем диапазоне всего:

always @(posedge tck or posedge cntr1_aload)
  if (cntr1_aload) counter1[2] <= load_data[7:0];
  else if (cntr1_sload) counter1[2] <= load_data[7:0];
  else if (cntr1_ena) counter1[2] <= cntr1_decrement[7:0];

[Lutovid 2]

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

 

Не сталкивался с такой проблемой никогда, буду иметь ввиду. Мой код стабильно работал(правда портил времянку), просто вопрос как раз и был про то "как правильно"), спасибо

Edited August 27, 2014 by Lutovid

[Golikov 0]

Я против VHDL програмирования - я за схемотехнику!

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

 

 

 

 

[Lutovid 2]

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

 

Я Vivado HLS осваиваю и мне нравится) так что это все тараканы ИМХО)

[Golikov 0]

вот к примеру поведенческое описание

 

reg sdata_w = 0; 
wire ff = (aload) ? adata : sdata_w;

always @(posedge clk)
   if(ena)
     sdata_w <= sdata;

 

если сигнал aload наружу выдавать adata, если нет то sdata_w, sdata_w - синхронно защелкивается по клоку если включено. Чем такое описание проиграет приведенному выше? Читабельно, понятно, и в целом пофиг найдутся ли спец триггеры для реализации или нет. Ресурсов хватает, ну и в путь?

 

 

[SM 13]

Чем такое описание проиграет приведенному выше?

reg sdata_w = 0; 
wire ff = (aload) ? adata : sdata_w;

always @(posedge clk)
   if(ena)
     sdata_w <= sdata;

Тем, что оно не описывает асинхронную загрузку, и не соответствует тому, что требуется. Тут просто мультиплексор после D-триггера. После снятия aload выход должен сохранять adata до ближайшего фронта clk, и только потом обновиться на свежую sdata. А у Вас - после снятия aload выход сразу вернется в состояние с предыдущей sdata.

 

И, вообще, есть HDL coding guidelines, которые дают авторы синтезаторов, в которых сказано для тупых, как и что правильно описать. Зачем городить что-то свое, которое не факт, что вообще заработает как задумано? Типа выпендриться?

[Golikov 0]

понятно.

 

а правильно я понимаю что в приведенной конструкции

 

always @(posedge clk or posedge aload)
if (aload) ff <= adata; else if (ena) ff <= sdata;

 

ff - это reg и он меняется по клокам или по изменению aload? И ни о какой передачи асинхронного сигнала речи не идет?

[topor_topor 0]

я что-то не пойму в чем разница между вашим и моим примером, исключая то, что он на верилоге) тот же сенсетив лист и логика же, нет?

Нивчём разница. При наличии элемента DFFEA (синхронный тригер с асинхронной загрузкой) синтезатор может это реализовать.

Похоже в плис все тригеры такие (For supported device (Arria GX, Cyclone, Cyclone II, HardCopy, Stratix, Stratix II, and Stratix GX) families, all flipflops are reported as DFFEA primitives)

 

--------------

Вопросс в том что таки надо было сделать - один DFFEA или DFF + LATCH + MUX

 

 

ff - это reg и он меняется по клокам или по изменению aload? И ни о какой передачи асинхронного сигнала речи не идет?

 

reg меняется и по aload (асинхронно) и по clk (синхронно) http://quartushelp.altera.com/12.1/mergedP..._file_dffea.htm

 

 

 

Да, обычный синхронный триггер с асинхронной загрузкой. У альтеры, например, примитивы DFFEA или DFFEAS. Синтезатор же под латис, при формировании такого триггера, ввиду отсутствия "железной конструкции", сам генерирует хитрую схему из двух триггеров и латча (второй триггер с асинхронной предустановкой и синхронным сбросом управляет мультиплексором латч/первый_триггер).

Возможно, если учесть что aload & adata синхронны clk (а автор не сказал что они асинхронны) то схема из двух триггеров и латча может быть упрощена...

 

[SM 13]

ff - это reg и он меняется по клокам или по изменению aload? И ни о какой передачи асинхронного сигнала речи не идет?

 

Такое описание схемы синтезируется в триггер с асинхронной загрузкой, который, при активном aload передает на выход adata как она есть, а при снятии aload, его защелкивает. Да, это расходится с тем, что кажется (а кажется, что в список у always еще надо добавить adata, а во втором if писать, как в VHDL, if (clk'event), то есть if (posedge clk)), но тем не менее, это вот именно так (для этого и есть документация, что и как описывать).

 

Вот, в подтверждение моих слов, документ от XILINX - http://web.stanford.edu/class/ee108/documentation/ver.pdf - стр. 6-24

 

То есть, повторю еще раз - знание того, как описывается для синтеза тот или иной элемент, из которых состоит вся схема целиком - залог успеха проектирования.

[Golikov 0]

еще раз, если клока не будет, при aload == 1, изменение на adata попадет на выход?

 

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

 

И ничего в этом нет того чего не кажется, все именно так и описано.

 

reg меняется и по aload (асинхронно) и по clk (синхронно)

союз или в моей фразе "меняется по клокам или по изменению aload" обозначает либо по клоку, либо по алоду, либо по обоим сразу. То есть как бы имел ввиду тоже самое...

[SM 13]

еще раз, если клока не будет, при aload == 1, изменение на adata попадет на выход?

 

Еще раз, в синтезированной схеме - Да! Так как такая конструкция языка по правилам синтеза создает триггер с асинхронной загрузкой.