Перейти к содержанию
    

Как реализовать на Verilog'e

А красиво это как в VHDL типа open написать.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Плохая привычка и "bad coding style", это:

...

По причинам 2) и 3) - VHDL весь целиком это "bad coding style" :)

Полностью поддерживаю! Любители "error proof" пишут сразу на VHDL, им не жалко пальцы )

 

 

У каждого свое понятие о красоте.
Назовите как хотите. Я сказал лишь, как бы я хотел это видеть. Есть в верилоге такое решение? Похоже уже дали ответ, что нельзя навроде open написать...

 

В VHDL так сделать нельзя.
А так? (стрелочки в другую сторону)

port1_out(2) => port1_out(0),
port1_out(1) => open,
port1_out(0) => port1_out(1)

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Плохая привычка и "bad coding style", это:

1) не использовать все возможности языка.

2) объявлять то, что объявлять бессмысленно.

3) вообще, тратить байты и силы на написание ненужных букв.

 

По причинам 2) и 3) - VHDL весь целиком это "bad coding style" :)

 

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

Про протекание тока - забавное определение. Сигнал в данном случае - некая философская сущность используемая для логического соединения портов модулей. Правильнее сказать наверное не "сигнал" а "соединение".

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

Вообще мне вся эта дискуссия о прописных истинах напоминает какой-то глупый троллинг... Предлагаю прекратить.

З Ы Про стандарт соврал - пункт 6.10 описывает implicit declaration.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Оговаривает:

3.5 Implicit declarations

The syntax shown in 3.2 shall be used to declare nets and variables explicitly. In the absence of an explicit declaration, an implicit net of default net type shall be assumed in the following circumstances: If an identifier is used in a port expression declaration, then an implicit net of type wire shall be assumed, with the vector width of the port expression declaration. See 12.3.3 for a discussion of port expression declarations.

If an identifier is used in the terminal list of a primitive instance or a module instance, and that identifier has not been explicitly declared previously in one of the declaration statements of the instantiating module, then an implicit scalar net of default net type shall be assumed. See Section 19 for a discussion of control of the type for implicitly declared nets with the ‘default_nettype compiler directive.

 

Я сказал лишь, как бы я хотел это видеть. Есть в верилоге такое решение?

 

Так и напишите:

a a_inst (.out({a_out[1], open, a_out[0]}));

t t_inst (.out({t_out[1], open2, open3, t_out[0]}));

 

Будет аккурат по-вашему, и полностью соответствовать спецификации языка. Отчасти и для этого придуманы implicit объявления, чтобы висящие провода объявлять так, как себе красивым кажется. Хоть "dummy", хоть "open",

 

Правильнее сказать наверное не "сигнал" а "соединение".

Вот и я про это же. Соединение должно что-то с чем-то соединять. А это, не сигнал и не соединение. Про протекание тока, это было не определение, а аналогия со схемотехническим решением, которое описывается на HDL.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А так? (стрелочки в другую сторону)
И так тоже. Нельзя часть выходной шины сделать open.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

И так тоже. Нельзя часть выходной шины сделать open.
Ну значит и здесь VHDL ничем не лучше Verilog'а

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ну значит и здесь VHDL ничем не лучше Verilog'а

Ага. Зато здесь Verilog лучше VHDL :) :), благо позволяет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Вот-вот, тем более, что верилог позволяет конкатенацию для выходного порта прямо в портмэпе, а вхдл только для входного.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Вот-вот, тем более, что верилог позволяет конкатенацию для выходного порта прямо в портмэпе, а вхдл только для входного.

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

за такие "удобные" костыли.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Читабельность кода от подобных фенечек только теряет.

Это чисто субъективно. IMHO - приобретает. Потому, что сразу все в одной строке видно, не надо по коду разбегаться.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Это чисто субъективно. IMHO - приобретает. Потому, что сразу все в одной строке видно, не надо по коду разбегаться.
Поддерживаю. Чем компактнее - тем нагляднее. Точнее чем больше информации влезет в поле зрения без перелистывания, тем нагляднее видно, как это работает. Краткость - сестра таланта, да и принцип бритвы Оккама никто не отменял ))

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

принцип бритвы Оккама никто не отменял ))

Согласен со всем сказанным. При чтении VHDL глаза разбегаются во все стороны и мозг плавится, потому, что, прежде чем понять суть кода, надо сначала откинуть кучу мусора, затеняющую эту суть, и только потом начинаешь что-то понимать. А тут все сразу видно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

лямда функции С стандарта 2011 видели? Я тут недавно получил в наследство такой код, убил бы за такую компактность.

 

Важно не число строк, а структура кода,

 

утверждаю что такой кусок кода

 

wire SignalToModul1
wire SignalToModul2
wire SignalToModul3   
wire Module4OutputBus;
assign {SignalToModul1, SignalToModul2, SignalToModul3} = Module4OutputBus;
Module4 Mod_inst (.out(Module4OutputBus));

 

в сто раз нагляднее чем

Module4 Mod_inst (.out({sig1, new_sig, new_newSig_3}));

 

с соответствующим продолжением по остальным модулям. А есть таланты что все переменные не длиннее 3 букв называют, вот там компактность просто бешеная у кода, жалко что для его изменения надо его неделю читать....

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А есть таланты что все переменные не длиннее 3 букв называют

Всему должна быть мера. Я ни разу не спорил, что имена цепей (и модулей, разумеется) должны быть осмысленными и максимально понятными без комментариев (но, одновременно, и максимально короткими, на сколько это возможно без потери понятности). Это единственная основа читаемости.

Но вот то, что каждое лишнее пересоединение / переприсваивание затрудняет понимание, это (для меня) аксиома. Это делают те, кто хочет запутать код. Если это можно сделать сразу при присоединении к портам, то так и надо делать.

 

лямда функции С стандарта 2011 видели?

От прогресса не уйти... Полезные штуковины. К читаемости отношения никакого не имеют, они нечитаемы, если "читатель" не понимает их функциональности.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

(про имена сигналов и переменных речь не идет - должны в максимально короткм названии передавать в названии сущность)

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

 

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

за такие "удобные" костыли.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...