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

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


Спасибо!!

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

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

wire [255:0] out_data; ///////?


assign out_data = {DATA[0], DATA[1], ........., DATA[7]};

Спасибо, вы правильно поняли, а можно ли адресовать 1 бит например DATA[0][0] ??

Да все конечно можно
reg [7:0] DATA [0:7];

wire [63:0] out_data;


assign out_data = {DATA[0][7], DATA[0][6:0], DATA[1], ........., DATA[7]};

union packed {
bit [m-1:0][n-1:0] register_array;
bit [m*n-1:0] bit_accessible_register;
} register_array_shift_register;

bit [n-1:0]example_register;
wire example_shift_in_bit;

register_array_shift_register.register_array[k]<=example_register;
register_array_shift_register.bit_accessible_register[m*n-1:0]<={register_array_shift_register.bit_accessible_register[m*n-2:0],example_shift_in_bit};//shift with a shift in bit

To CaPpuCcino
Если можно, приведите пожалуйста полный модуль. Чтобы можно было оценить достоинства system verilog в том числе и пользователю, который с ним незнаком.

ну, я просто хотел показать как одну и ту же структуру можно представлять в разных обличиях: с одной стороны ее можно видеть как регистровый файл а с другой стороны как единый сдвиговый регистр
ну коли хотите какой-нить модулёчек то пожалте (глуповатый модулёк получился, но для примера подойдёт):
в зависимости от выбранного режима:
a )регистровый файл можно загружать пословно с указанием адреса загрузки
b )в него можно вдвигать битик (тогда весь файл будет как цепочка двигающихся бит)

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

Спасибо. К сожалению квартус выдал ошибку
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?

да вроде как писанины меньше

sazh Как мне кажется, VHDL от наличия определяемых пользователем типов нисколько не страдает... как раз наоборот.

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

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

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

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

ну вот видете - вы сами же и отвечаете на свой вопрос -- ведь ключевые слова 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-ами-декодерами
что размер текста совершенно как понимаете не уменьшило и прибавило хлопот компилятору (по составлению таблицы сигналов) и симулятору (по контролю переприсваиваний разным сигналам)


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


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



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

Спасибо!

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

Пользуясь случаем хочу спросить. Есть куча удобных и полезных операторов типа ++, += и т.д.; вопрос: можно ли ими пользоваться, скажем, при описании счетчиков? Например, в Верилог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 уже)