Массив векторов -> Сдвиговый регистр Опции

[-=Vitaly=-]

Здравствуйте!!!

Как собрать массив векторов reg [7:0] DATA [0:7] в один большой однобитный сдвиговый регистр??


Спасибо!!

Сообщение отредактировал -=Vitaly=- - Mar 13 2007, 12:25

[sazh]

Спасибо. К сожалению квартус выдал ошибку
Error (10170): Verilog HDL syntax error at register_file_bit_shift_gibrid.v(2) near text "["; expecting an identifier
и встал на строчке bit [15:0][7:0] register_array; //packed array
////////////////
Благодаря вашему приложенному файлу RTL разобрался. Что хочу спросить.
Используя верилог, я оперирую одним типом integer (синтез) и четырьмя ключевыми словами wire, reg, signed, unsigned. Этого достаточно, чтобы описать любую схему. Описание при этом простое и читаемо.
Вопрос. Что дает повышенный уровень абстракции. Например Вашу схему без RTL вида я бы не прочитал. Зачем отказываться от reg и wire. Ведь сила верилога в его простоте. Зачем вводить типы и уподобляться например VHDL?

[CaPpuCcino]

Спасибо. К сожалению квартус выдал ошибку
Error (10170): Verilog HDL syntax error at register_file_bit_shift_gibrid.v(2) near text "["; expecting an identifier
и встал на строчке bit [15:0][7:0] register_array; //packed array

ну стало быть Квартус не поддерживает (к стати, по совершенно непонятной причине) пакованные массивы (странно почему он может кушать такое reg [n:0] a [m:0] , но не питается таким reg [m:0][n:0] a )

Благодаря вашему приложенному файлу RTL разобрался. ... Например Вашу схему без RTL вида я бы не прочитал.

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

Используя верилог, я оперирую одним типом integer (синтез) и четырьмя ключевыми словами wire, reg, signed, unsigned. Этого достаточно, чтобы описать любую схему. Описание при этом простое и читаемо.
Вопрос. Что дает повышенный уровень абстракции. ... Зачем отказываться от reg и wire. Ведь сила верилога в его простоте. Зачем вводить типы и уподобляться например VHDL?

ну вот видете - вы сами же и отвечаете на свой вопрос -- ведь ключевые слова signed и unsigned являются совершенной абстракцией - ведь знаковое и беззнаковое число - это всего лишь интерпритация того что у вас находится в вашем reg
простота никуда не девается из Верилога -- ему добавили лишь побольше изящности
зачем это нужно попробую на конкретике: к примеру у вас есть некоторый регистр куда записывается инструкция програмно-управляемого процессора, процессор оперирует с инструкциями длинной 16 бит и предположим 2 типов: 2-х операндовые операции с операндами хранимыми в регистровом файле процессора (ну как какие-нить арифметико-логические), и команды перехода с непосредственным адресом перехода в команде.
старший бит инструкции указывает на тип этой операции. далее в зависимости от типа идёт код операции (пусть 3 бита для арифметики и 5 для джампов ) и 1) адрес источника первого,второго операнда и адрес результата (по 4 бита каждый) или 2) абсолютный адрес перехода (10 бит)

union packed {
bit [15:0] instruction_flat; // для видения регистра со стороны шины инструкций

struct packed {
bit instuction_type;
bit [2:0] op_code;
bit [3:0] op_addr_a;
bit [3:0] op_addr_b;
bit [3:0] dest_addr;
}logic_arithmetic_instruction;

struct packed {
bit instuction_type;
bit [4:0] op_code;
bit [9:0] jump_addr;
}control_flow_instruction;

} processor_instruction_uni;

теперь вы можете загружать регистр инструкций со стороны системной шины процессора вот так:
@(posedge clk) processor_instruction_uni. instruction_flat<=data_bus;
а направлят команду в декодирующий блок как-нибудь вот так:
if (processor_instruction_uni.instruction_flat[15]==1)
begin
jump_decode_instruction_function ( processor_instruction_uni.control_flow_instruction.op_code);
end
else
begin
logic_arithm_decode_instruction_function ( processor_instruction_uni.logic_arithmetic_instruction.op_code);
end
в противном случае вам на протяжении всего кода модуля пришлось бы помнить с какого по какой бит какое поле находиться, имена бы вам соверсхенно ничего не подсказывали, и дополнительно прописывать логику выбора поля инструкции
может быть я описал не так уж изящно - но всё в онлайне - поэтому возможно не без огрехов -- просто надеялся показать основную идею зачем это нужно. более жизненный пример у меня был когда приходилось писать достаточно большок код - там были регистры которые в зависимости от состояния КА интерпретировались по-разному -- код становился совершенно не самодокументируемым - помнить всё время какой диапазон бит что значит - оказалось совершенным гемороем, пришлось писать новые wire c говорящими за себя именами assign-ами-декодерами
что размер текста совершенно как понимаете не уменьшило и прибавило хлопот компилятору (по составлению таблицы сигналов) и симулятору (по контролю переприсваиваний разным сигналам)

CaPpuCcino
Пример очень интересный. Хотя, конечно, нужно твердо ЗНАТЬ, что .register_array и .bit_accessible_register - это одно и то же. При чтения кода это может вызвать трудности... как и длинные имена

ну это уже вопрос стиля кодирования
я как правило добавляю суфиксы _uni, _struct - и тогда всё становится читабельным и понимабельным
к тому же union уже подразумевает что это одно и то же

Хотел синтезировать, но тоже наткнулся на ошибку, не хотят Квартус и Синплифай кушать typedef, перемещение его внутрь модуля тоже выдает ошибку.

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

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

там вообще-то нет второго массива -- физически там регистр 16x8 - он просто виден под разными иерархическими именами и им можно оперировать как с разными типами - но физически там описан один единственный объект (!) (это важно понимать,это-union )
поэтому и на выход он (""второй"" массив) так же идёт через окошко в 8 бит именованное register_addressable под управлением селектора output_selector

[dxp]

ну стало быть Квартус не поддерживает (к стати, по совершенно непонятной причине) пакованные массивы (странно почему он может кушать такое reg [n:0] a [m:0] , но не питается таким reg [m:0][n:0] a )

В Квартусе поддерживаются пакованные массивы, но только одномерные. Так в доке написано.

Пользуясь случаем хочу спросить. Есть куча удобных и полезных операторов типа ++, += и т.д.; вопрос: можно ли ими пользоваться, скажем, при описании счетчиков? Например, в Верилог2001 тоже поддерживается оператор ++, но как выяснилось его смысл:

a++; => a = a + 1;

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

a <= a + 1;

Как дело обстоит с этим в СВ? Сам язык еще плотно не изучал, пока только "зубы точу" на него. Ваши посты имеют (на меня) хороший агитирующий за СВ эффект.

to sazh: Преимущества SystemVerilog'а вполне понятны. Разница между В и СВ примерно как между С и С++. Аналогия не полная, но хорошая, имхо.

[CaPpuCcino]

В Квартусе поддерживаются пакованные массивы, но только одномерные. Так в доке написано.

Пользуясь случаем хочу спросить. Есть куча удобных и полезных операторов типа ++, += и т.д.; вопрос: можно ли ими пользоваться, скажем, при описании счетчиков? Например, в Верилог2001 тоже поддерживается оператор ++, но как выяснилось его смысл:

a++; => a = a + 1;

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

a <= a + 1;

Как дело обстоит с этим в СВ? Сам язык еще плотно не изучал, пока только "зубы точу" на него. Ваши посты имеют (на меня) хороший агитирующий за СВ эффект.

to sazh: Преимущества SystemVerilog'а вполне понятны. Разница между В и СВ примерно как между С и С++. Аналогия не полная, но хорошая, имхо.

++,--,+=,/= и т.д. как вы парвильно заметели блокирующие операторы и пользоваться ими нужно в блоках с блокирующими присваиваниями - в СВ это по прежднему так; например ++ в тактируемых блоках я использую только в циклах for (int i ; i<n; i++)
ну а в комбинаторных always_comb пользоваться можно спокойно
вообще мне СВ вполне радует - с удовольствием пользуюсь им как при синтезе (typedef, struct, enum, union, interface, void function ...) так и в тестбенчах (+ program, class, rand, ref, class mainbox, array[], array[$]) очень хочется еще внедрить randsequence, constrain и assertion в повседневную жизнь и уже морально созрел - но на практике пока руки не доходят (надеюсь в ближайшем будущем)
периодически на форуме встречаю скептические мнения по поводу СВ, но без какой-либо конкретики - я пока ничего настораживающего в СВ не заметил (как-нить нужно будет поинтересоваться по поводу чего конкретно этот скепсис - любопытно)
на данный момент вижу некоторые препятствия в сипользовании СВ:
при синтезе: малое количество синтезаторов нормально поддерживающих СВ (по поводу Синплифая я уже неоднократно высказывал своё "фе" - ребята конкретно обленились/до смешного/) - из известных мне это ментор и синопсис (пользуюсь первым - однако качество самого синтеза /по плотности упаковки и быстродействию/ ментора и синплисити к сожалению не сравнивал - как-нибудь нужно протестировать)
при моделирование: ментор пока не слил ветки моделсима и квестасима в один продукт - поэтому assertion-ы и constrant randomization c rendsequence в моделсиме не поддерживаются (всё остальное за небольшим исключением типа const ref и generate внутри interface /то что на данный момент обнаружил/ поддерживается ок)
наблюдение: по поводу того что такое СВ - ребята из комиссии по верилогу увидели что в ВХДЛ есть составные типы и это оч удобно, забацали туда эти типы на манер Си, добавили из того же Си операторы ++, <<=, -=...., do while и т.д. потом посмотрели в сторону верификационных языков и влили в стандарт PLS + VERA (randsequence, constraint randomization, property, |->, inside,...) и классы с управлением памятю по типу JAVA (хотя на самом деле классы тоже из VERA) ... ну и получилось ... (кто бы что не стал говорить на счёт плагиатов а по-моему) нормально (!) получилось
(справедливости ради - в стандарте есть недоговоренные места /к примеру не говорится что .randomize() автоматически вызывается по иерархии класса вверх, а конструкторы членов составного класса автоматом не вызываются (типа наверное думают что это и так всем понятно - хотя совсем не очевидно)/ но думаю эти детали ещё доработаются /если денег комитету конечно башлять будут/). ok - а то всё дальше в оффтоп
P.P.S.: а вот ещё о наболевшем , пользуясь случаем хочу заметить любителям сравнения СВ с СистемЦ - основная область применения СЦ (IMHO)- моделирование(высокого уровня ), и особенно привлекательна область software/hardware моделирования. спускаться к уровню РТЛ по моим наблюдениям не очень удобно - появляется грамоздкость конструкций на подобие ВХДЛ. поэтому-то к СЦ как можно наблюдать основные синтезаторные компании интереса пылкого не проявляют (года 2 уже)

[dxp]

CaPpuCcino, спасибо за подробный ответ.

++,--,+=,/= и т.д. как вы парвильно заметели блокирующие операторы и пользоваться ими нужно в блоках с блокирующими присваиваниями - в СВ это по прежднему так; например ++ в тактируемых блоках я использую только в циклах for (int i ; i<n; i++)
ну а в комбинаторных always_comb пользоваться можно спокойно

Да, я уже разведал этот момент - к сожалению, блокирующие. Блокирующие в таком варианте тоже, конечно, нужны, но и о неблокирующих аналогах тоже можно было бы позаботиться. Не знаю, кому как, а мне анноит писать very_long_name <= very_long_name + ..., хотя редактор с комплешнами тут сильно облегчает жизнь. Да и читабельность была бы лучше у вариантов very_long_name++ и very_long_name += .... Ну, да ладно, ничо не поделаешь.

вообще мне СВ вполне радует - с удовольствием пользуюсь им как при синтезе (typedef, struct, enum, union, interface, void function ...) так и в тестбенчах (+ program, class, rand, ref, class mainbox, array[], array[$]) очень хочется еще внедрить randsequence, constrain и assertion в повседневную жизнь и уже морально созрел - но на практике пока руки не доходят (надеюсь в ближайшем будущем)
периодически на форуме встречаю скептические мнения по поводу СВ, но без какой-либо конкретики - я пока ничего настораживающего в СВ не заметил (как-нить нужно будет поинтересоваться по поводу чего конкретно этот скепсис - любопытно)

Да, согласен - ничего по сравнению с Верилогом не теряется, а расширения только на пользу. Какая тут может быть содержательная критика, когда В является подмножеством СВ - что-то если из расширений СВ не катит, всегда есть базовый вариант на В. А возможности СВ все в тему - взять те же структуры и перечислимые типы - абстракция выше, читабельность лучше. Чем больше проект, тем более значимыми становятся эти возможности.

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

Тут лед, имхо, уже тронулся.

(по поводу Синплифая я уже неоднократно высказывал своё "фе" - ребята конкретно обленились/до смешного/) - из известных мне это ментор и синопсис (пользуюсь первым - однако качество самого синтеза /по плотности упаковки и быстродействию/ ментора и синплисити к сожалению не сравнивал - как-нибудь нужно протестировать)

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

P.P.S.: а вот ещё о наболевшем , пользуясь случаем хочу заметить любителям сравнения СВ с СистемЦ - основная область применения СЦ (IMHO)- моделирование(высокого уровня ), и особенно привлекательна область software/hardware моделирования. спускаться к уровню РТЛ по моим наблюдениям не очень удобно - появляется грамоздкость конструкций на подобие ВХДЛ. поэтому-то к СЦ как можно наблюдать основные синтезаторные компании интереса пылкого не проявляют (года 2 уже)

СЦ, имхо, вполне сносно тянет на синтезируемый язык. Вообще, имхо, язык описания аппаратуры можно сделать на базе практически любого развитого языка программирования - добавить средства параллельности (процессы), события (для поведенческого описания), учесть некоторые нюансы, связанные с этим - типа блокируюих и неблокирующих присваиваний. Преимущества СВ тут перед СЦ проистекают из того, что СВ строится на базе уже готового популярного языка Верилог, для которого полно средств синтеза. Для СЦ это все надо написать, развить. Дорого, а при наличии альтернатив в виде СВ, очевидно не кажется особенно рентабельным. Кроме того, СЦ - это С++, а С++ сам по себе язык очень непростой, его выучить хорошенько - это попотеть надо и опыт плотной работы с ним иметь хотя бы года два-три. Для РС-программистов это не проблема, а вот для инженеров-"аппаратчиков" картина более тусклая. В то время как В и СВ - языки достаточно простые сами по себе - народ на них посадить проще.