[CaPpuCcino 0]

Всё здорово, вот только не соответствует условиям задачи :( Зачем использовать bit, class? Ведь это уже не Verilog (ни 1995, ни 2001), а System Verilog.

 

В результате у преподавателя может появиться подозрение и в результате такое решение выйдет боком автору темы.

текущий стандарт верилог 1364-2005. bit легко заменяется на reg. ну, и потом, пока чуваки договорятся, что такое стэк, семестр подойдёт к концу

[Consigliere 0]

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 12]

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 - Шина чтения

[CaPpuCcino 0]

господа, не пора ли переместиться в соответствующий раздел форума?

Форум разработчиков электроники - Electronics developers forum > Программируемая логика (ПЛИС) - Programmable Logic (FPGA,CPLD, PLD) > Языки проектирования на ПЛИС - FPGA programming languages

[Consigliere 0]

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

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

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

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

С этим как раз все просто - гораздо проще сделать 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 12]

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

Т.е. предполагается 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 0]

Т.е. предполагается 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 12]

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

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

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

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

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

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

 

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

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

[Consigliere 0]

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

хорошо, попробовать можно.

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

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

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

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

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

с шиной без контроллера, хм.. ну просто задаешь в тест-бенче воздействия и все, так не прокатит?

 

 

дело в том что из за малых знаний и опыта, у меня нет возможности полноценно дискутировать, а жаль:(

[xvr 12]

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

Код предполагается синтезируемый или это чисто поведенческая модель? Если первое, то надо считать, что это может быть реальной плисиной :)

с шиной без контроллера, хм.. ну просто задаешь в тест-бенче воздействия и все, так не прокатит?

Я имел в виду контролер между физическими выводами I2C (SDC,SDA) и контролером стека. Или шину I2C тоже предполагается сделать на поведенческом уровне (т.е. без выводов вообще :) )?

дело в том что из за малых знаний и опыта, у меня нет возможности полноценно дискутировать, а жаль :(

Опыт - дело наживное

[Consigliere 0]

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

[xvr 12]

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

Как предполагается задавать шину I2C - как ноги SDC/SDA или как абстрактый модуль с каким угодно интерфейсом не подключенный вообще ни к чему?

[Consigliere 0]

на счет этого не знаю, но предполагаю что абстрактный модуль, ну максимум на бумаге:)

[xvr 12]

на счет этого не знаю, но предполагаю что абстрактный модуль, ну максимум на бумаге :)

Ну тогда вообще проблем никаких - подключить модуль стека прямо к проводам и формировать на них необходимые сигналы.

[Consigliere 0]

я пока что заболел, лежу с температурой, как только поправлюсь сразу сообщу:-(