Описание стека на Verilog, подскажите что не так Опции

[Consigliere]

Идея в том, чтоб описать 8-битный стек, запись и чтение производится с помощью управляющего сигнала "wr"

Код

module stack(out_stack, in_stack);
    output [7:0] out_stack;
    input [7:0] in_stack;
    wire st0 [7:0],
    st1 [7:0],
    st2 [7:0],
    st3 [7:0],
    st4 [7:0],
    st5 [7:0],
    st6 [7:0],
    st7 [7:0];
    wire wr;
    
        
    always in_stack
        
    if (wr)
        st7 = st6;
        st6 = st5;
        st5 = st4;
        st4 = st3;
        st3 = st2;
        st2 = st1;
        st1 = st0;
        st0 = in_stack;
        
endmodule

при компиляции выдает данное сообщение

# Pass 1. Scanning modules hierarchy.
# Error: VCP2000 stack.v : (20, 8): Syntax error. Unexpected token: =. Expected tokens: '#' , '(' , ':' , 'delay' , ',' ... .
# Error: VCP2000 stack.v : (21, 8): Syntax error. Unexpected token: =. Expected tokens: '#' , '(' , ':' , 'delay' , ',' ... .
# Error: VCP2000 stack.v : (22, 8): Syntax error. Unexpected token: =. Expected tokens: '#' , '(' , ':' , 'delay' , ',' ... .
# Error: VCP2000 stack.v : (23, 8): Syntax error. Unexpected token: =. Expected tokens: '#' , '(' , ':' , 'delay' , ',' ... .
# Error: VCP2000 stack.v : (24, 8): Syntax error. Unexpected token: =. Expected tokens: '#' , '(' , ':' , 'delay' , ',' ... .
# Error: VCP2000 stack.v : (25, 8): Syntax error. Unexpected token: =. Expected tokens: '#' , '(' , ':' , 'delay' , ',' ... .
# Error: VCP2000 stack.v : (26, 8): Syntax error. Unexpected token: =. Expected tokens: '#' , '(' , ':' , 'delay' , ',' ... .
# Warning: VCP2515 stack.v : (21, 1): Undefined module: st4 was used. Port connection rules will not be checked at such instantiations.
# Warning: VCP2515 stack.v : (20, 1): Undefined module: st5 was used. Port connection rules will not be checked at such instantiations.
# Warning: VCP2515 stack.v : (23, 1): Undefined module: st2 was used. Port connection rules will not be checked at such instantiations.
# Warning: VCP2515 stack.v : (22, 1): Undefined module: st3 was used. Port connection rules will not be checked at such instantiations.
# Warning: VCP2515 stack.v : (26, 1): Undefined module: in_stack was used. Port connection rules will not be checked at such instantiations.
# Warning: VCP2515 stack.v : (25, 1): Undefined module: st0 was used. Port connection rules will not be checked at such instantiations.
# Warning: VCP2515 stack.v : (24, 1): Undefined module: st1 was used. Port connection rules will not be checked at such instantiations.
# Compile failure 7 Errors 7 Warnings Analysis time : 0[s].
# done

не могу понять что я делаю не так...
Заранее спасибо за помощь.)

если не туда разместил тему перенесите пожалуйста в нужный раздел форума

[Consigliere]

XVR, вобщем как выяснилось, смысл был не совсем тот.
Поправки:
1. Сама шина I2C со стеком не работает. Работает через устройство управления стеком.
2. Необходимо спроектировать это устройство. Взаимодействие с шиной и со стеком. Порядок такой: проверка адреса(берем из шины), совпадает -> проверка команды read/write -> соответственно действие если read то отправляем на стек сигнал rd, для получения информации и сдвига стека, если write, то берем информацию из шины, сдвигаем стек и записываем. Запись и чтение между устройством управления и стеком производятся через 2 буфера(в качестве них выбраны регистры), т.е. один на чтение, второй на запись (не совсем понятна конечно эта идея, зачем оно надо).
Описание стека было удовлетворительно, т.е. зачет. На данный момент поставлена задача разработать устройство управления. Я пока что не думал, идей нет. Планирую завтра заняться этим, соответственно сообщу.
По Вашему предложению: 1. Адрес в обменах по I2C игнорируется, направление обмена определяется битом R/W в первом байте - получается, что нет
2. Размер стека - 8 байт - да.
3. Обмен со стеком поддерживается только побайтовый (1 байт за один цикл шины I2C) - не совсем понятна идея, если смысл в том что за 1 такт только заполняется 1 ячейка стека, то да.
4. Запись в стек производится только при наличие в нем свободного места, данные для записи берутся из байта данных (2й байт цикла записи шины I2C) - изначально он пуст. Думаю просто переполнение не будет допускаться.
5. Запрос записи подтверждается ACK в адресном цикле шины I2C только при наличии свободного места в стеке - не до конца понимаю этот процесс
6. Чтение из стека производится только в случае непустого стека в первом байте ответа цикла чтения по I2C - естественно что пустую информацию брать не целесообразно.
7. Запрос чтения подтверждается ACK в адресном цикле шины I2C только при наличии данных в стеке - аналогично не понимаю, как при записи

[XVR]

XVR, вобщем как выяснилось, смысл был не совсем тот.
Поправки:
1. Сама шина I2C со стеком не работает. Работает через устройство управления стеком.

Это устройство включает непосредственно стек, или сам стек это еще одно устройство?

2. Необходимо спроектировать это устройство. Взаимодействие с шиной и со стеком. Порядок такой: проверка адреса(берем из шины), совпадает -> проверка команды read/write -> соответственно действие если read то отправляем на стек сигнал rd, для получения информации и сдвига стека, если write, то берем информацию из шины, сдвигаем стек и записываем.

Устройство (равно как и все остальные) рекомендуется делать синхронным, т.к. почти все современные схемы синхронные.

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

С этим как раз все просто - гораздо проще сделать 2 раздельные однонаправленные шины, чем одну двунаправленную, к которой понадобятся дополнительные сигналы для управления направлением передачи данных. Кроме того, во многих FPGA просто нет внутренних шин с 3мя состояниями.

По Вашему предложению: 1. Адрес в обменах по I2C игнорируется, направление обмена определяется битом R/W в первом байте - получается, что нет

Это не существенно, добавится один компаратор на адрес.

3. Обмен со стеком поддерживается только побайтовый (1 байт за один цикл шины I2C) - не совсем понятна идея, если смысл в том что за 1 такт только заполняется 1 ячейка стека, то да.

В смысле не поддерживается обмен пакетами данных по I2C - только побайтово (1 байт за один полный цикл обмена)

4. Запись в стек производится только при наличие в нем свободного места, данные для записи берутся из байта данных (2й байт цикла записи шины I2C) - изначально он пуст. Думаю просто переполнение не будет допускаться.

Кем не будет допускаться? И что делать контроллеру стека, если оно все же произошло?

5. Запрос записи подтверждается ACK в адресном цикле шины I2C только при наличии свободного места в стеке - не до конца понимаю этот процесс

Обмен по шине I2C подтверждается адресуемым устройством в цикле передачи адреса. Имеется в виду, что данное устройство не будет подтверждать обмен (т.е. мастер I2C просто не увидит устройства на шине), если оно (устройство) не может обслужить запрос на чтение или запись.

6. Чтение из стека производится только в случае непустого стека в первом байте ответа цикла чтения по I2C - естественно что пустую информацию брать не целесообразно.

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



В общем вырисовываются такие сигналы в интерфейсе:

1. input clk - Системный клок
2. input enable - Обращение к контролеру стека
3. input write - Цикл записи (1-запись, 0-чтение)
4. output full - Признак заполненности стека
5. output empty - Признак пустоты стека
6. input [7:0] in_data - Шина записи
7. output [7:0] out_data - Шина чтения

[Consigliere]

Это устройство включает непосредственно стек, или сам стек это еще одно устройство?

полагаю что это еще одно устройство

Устройство (равно как и все остальные) рекомендуется делать синхронным, т.к. почти все современные схемы синхронные.

полностью согласен

С этим как раз все просто - гораздо проще сделать 2 раздельные однонаправленные шины, чем одну двунаправленную, к которой понадобятся дополнительные сигналы для управления направлением передачи данных. Кроме того, во многих FPGA просто нет внутренних шин с 3мя состояниями.

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

В смысле не поддерживается обмен пакетами данных по I2C - только побайтово (1 байт за один полный цикл обмена)

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

Кем не будет допускаться? И что делать контроллеру стека, если оно все же произошло?

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

Обмен по шине I2C подтверждается адресуемым устройством в цикле передачи адреса. Имеется в виду, что данное устройство не будет подтверждать обмен (т.е. мастер I2C просто не увидит устройства на шине), если оно (устройство) не может обслужить запрос на чтение или запись.

И тогда у нас данный цикл не завершится никогда что ли? Непосредственно в шине I2C

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

предпочтительнее лучше чтение нуля

В общем вырисовываются такие сигналы в интерфейсе:

1. input clk - Системный клок
2. input enable - Обращение к контролеру стека
3. input write - Цикл записи (1-запись, 0-чтение)
4. output full - Признак заполненности стека
5. output empty - Признак пустоты стека
6. input [7:0] in_data - Шина записи
7. output [7:0] out_data - Шина чтения

Если на участке шина - контроллер, то согласен.


по поводу контроллера есть такая идея:
output [7:0] to_bus - данные передающиеся шине из стека
output [7:0] to_stack - данные из шины на запись в стек
output rd - сигнал управления стеком(на считывание)
output wr - сигнал управления (на запись)
input [7:0] from_bus - данные из шины
input [7:0] from_stack - данные из стека

впервую очередь проверяем from_bus, сверяем адрес, если подходит то начинаем считывать команду wr/rd и отправляем сигнал wr/rd, для подготовки стека к записи/чтению, затем непосредственно передача данных.
Так нормально, или не очень?

[XVR]

полагаю что это еще одно устройство

Т.е. предполагается 3 устройства (I2C контролер, контролер стека, стек)? В таком случае одно из этих устройств лишнее - просто набор проводов

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

Не совсем понимаю, что такое 'шина передачи данных', но если под этим понимается 3х стабильная двунаправленная шина, то вне зависимости от того, как передаются сигналы rd & wr в данном дезайне такая шина будет лишним усложнением.

т.е. если у нас стек может хранить слова размером 8 байт, то необходимо будет 8 циклов?

Да

Расскажите почему Вы предпочли такой вариант, а не все сразу?

Это сложнее реализовать

И тогда у нас данный цикл не завершится никогда что ли? Непосредственно в шине I2C

Завершится, но master, начавший цикл, получит ошибку обмена.

предпочтительнее лучше чтение нуля

Ок, это даже проще

по поводу контроллера есть такая идея:
output [7:0] to_bus - данные передающиеся шине из стека
output [7:0] to_stack - данные из шины на запись в стек
output rd - сигнал управления стеком(на считывание)
output wr - сигнал управления (на запись)
input [7:0] from_bus - данные из шины
input [7:0] from_stack - данные из стека

Похоже на набор проводов Или это имеется в виду контролер I2C?

впервую очередь проверяем from_bus, сверяем адрес, если подходит то начинаем считывать команду wr/rd и отправляем сигнал wr/rd, для подготовки стека к записи/чтению, затем непосредственно передача данных.

Слишком усложнено. Все сравнения адресов и машинерия с I2C шиной должна остаться внутри I2C контролера. Наружу нужно выдать уже голые команды чтения и записи в стек. Интерфейс будет один в один совпадать с интерфейсом стека (за исключением направления сигналов - оно будет противоположным)

Если сделать отдельно интерфейс к I2C и потом его пристыковывать к стеку, через еще один модуль, то придется реализовавать более-менее полноценную имплементацию протокола I2C со всеми ACK/NAK, подсчетом принятых и переданных байтов, т.к. цепи генерации ACK будут находится в другом модуле и придется всю эту логику протаскивать через интерфейсы 2х модулей. При этом реально это все будет не нужно, т.к. пользователь у шины I2C в вашем случае один, и набор требований у него фиксированный, т.ч. можно сделать под него урезанную имплементацию I2C



PS. Реализация стека здесь тривиальная, по сравнению с реализацией I2C контролера.

[Consigliere]

Т.е. предполагается 3 устройства (I2C контролер, контролер стека, стек)? В таком случае одно из этих устройств лишнее - просто набор проводов

3 устройства:шина I2C, контроллер стека, стек

Не совсем понимаю, что такое 'шина передачи данных', но если под этим понимается 3х стабильная двунаправленная шина, то вне зависимости от того, как передаются сигналы rd & wr в данном дезайне такая шина будет лишним усложнением.

я тоже не понимаю что такое 3х стабильныя двунаправленная шина хорошо попробую выразиться иначе. Эти сигналы wr/rd идут по 2м отдельным каналам(не каналы передачи данных которые по 8байт передают с шины в стек, а отдельные)

Завершится, но master, начавший цикл, получит ошибку обмена.

ок

Похоже на набор проводов Или это имеется в виду контролер I2C?

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

Слишком усложнено. Все сравнения адресов и машинерия с I2C шиной должна остаться внутри I2C контролера. Наружу нужно выдать уже голые команды чтения и записи в стек. Интерфейс будет один в один совпадать с интерфейсом стека (за исключением направления сигналов - оно будет противоположным)

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

Если сделать отдельно интерфейс к I2C и потом его пристыковывать к стеку, через еще один модуль, то придется реализовавать более-менее полноценную имплементацию протокола I2C со всеми ACK/NAK, подсчетом принятых и переданных байтов, т.к. цепи генерации ACK будут находится в другом модуле и придется всю эту логику протаскивать через интерфейсы 2х модулей. При этом реально это все будет не нужно, т.к. пользователь у шины I2C в вашем случае один, и набор требований у него фиксированный, т.ч. можно сделать под него урезанную имплементацию I2C

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

PS. Реализация стека здесь тривиальная, по сравнению с реализацией I2C контролера.

а он нам нужен?

[XVR]

3 устройства:шина I2C, контроллер стека, стек

Предлагаю объединить контролер стека с самим стеком, ибо я не предсталяю их отдельной реализации. Они и вместе вряд ли займут более 10 строк кода

я тоже не понимаю что такое 3х стабильныя двунаправленная шина хорошо попробую выразиться иначе. Эти сигналы wr/rd идут по 2м отдельным каналам(не каналы передачи данных которые по 8байт передают с шины в стек, а отдельные)

Хм. До сих пор я считал, что это очевидно. Кроме того, я слабо представляю, как их можно сделать иначе

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

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

а он (контролер I2C) нам нужен?

А как вы собираетесь общаться с I2C шиной без контролера?