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

[-=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 уже)