[dxp 33]

struct не создает scope

struct создаёт scope - вы можете создавать объекты с одинаковыми именами в структурах, всё будет ок, struct не позволяет внутри своей scope определять тип. Когда вы объявляете объект внутри структуры, всё нормально, он живёт внутри этой области видимости, но определить тип внутри вы не можете - попробуйте написать там typedef - получите ошибку (а если нет, значит это баг тула). Когда вы определяете перечисление, вы неявно определяете его тип, и поскольку внутри структуры этот тип не может быть определён, он автоматом переносится в объемлющую область видимости со всеми вытекающими.

 

 

[flammmable 0]

struct создаёт scope - вы можете создавать объекты с одинаковыми именами в структурах, всё будет ок, struct не позволяет внутри своей scope определять тип. Когда вы объявляете объект внутри структуры, всё нормально, он живёт внутри этой области видимости, но определить тип внутри вы не можете - попробуйте написать там typedef - получите ошибку (а если нет, значит это баг тула). Когда вы определяете перечисление, вы неявно определяете его тип, и поскольку внутри структуры этот тип не может быть определён, он автоматом переносится в объемлющую область видимости со всеми вытекающими.

Звучит логично. Жаль. Не хотелось бы имена регистров копировать четыре раза вместо одного, используя module для группировки. Посмотрю что скажет Мегратек (и вообще) и покорюсь судьбе :)

[RobFPGA 27]

Приветствую!

Вот пара примеров группировки атрибутов (при помощи модуля и при помощи структуры):

...

Вам как было бы удобней производить группировку?

Простите не уловил что тут хотелось бы увидет? Какую задачу должна решать эта гуппировка? Я пытаюсь давать имена портам и сигналам чтобы хоть как то отображать их функционал. Ну и приведеные примеры функционально разные.

Мне ни кто не мешает делать так

...
logic sig_AAA, sig_BBB;
   submodul i_sub (
      .reg_A(sig_AAA),
      .reg_B(sig_BBB),
      .reg_C(some_output)
   );

 

В свою очередь хотелось бы от Вас услышать как в таком случае будете выкручиватся вместе с Qu?

struct{
  enum {IDLE=1, SOME_LITERAL_1_FIRST, SOME_LITERAL_2_FIRST} enum1_reg;
  enum {IDLE=2, SOME_LITERAL_1_SECOND, SOME_LITERAL_2_SECOND} enum2_reg;
} first_and_second_struct;
assign some_litera = first_and_second_struct.IDLE;
...

 

Удачи! Rob.

 

P.S.

Ну и для прикола - если уж так хочется в одном модуле иметь геморой одинаковые элементы в разных enum то есть способ :)

module test2 (input  int A, output int B,C);

generate begin : gg
    begin : g_fsm1
      enum {IDLE=3, SOME_STAGE_2} FSM;
    end
    begin : g_fsm2
      enum {IDLE=4, SOME_STAGE_2} FSM;
    end
    ...
end
endgenerate

assign B = gg.g_fsm1.IDLE;
assign C = gg.g_fsm2.IDLE;

endmodule

Только нафиг такая групировка нужна? этж скооко писанины лишней :wacko: Да и проверять сложно если где ошибся.

 

[flammmable 0]

Простите не уловил что тут хотелось бы увидеть?

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

 

Какую задачу должна решать эта группировка?

А какую задачу решает конструкция struct?

 

В свою очередь хотелось бы от Вас услышать как в таком случае будете выкручиватся вместе с Qu?

struct{
  enum {IDLE=1, SOME_LITERAL_1_FIRST, SOME_LITERAL_2_FIRST} enum1_reg;
  enum {IDLE=2, SOME_LITERAL_1_SECOND, SOME_LITERAL_2_SECOND} enum2_reg;
} first_and_second_struct;
assign some_litera = first_and_second_struct.IDLE;
...

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

[RobFPGA 27]

Приветствую!

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

Тю и всего то ...

package fsm1_pq;
  typedef enum {IDLE=1, SOME_STAGE_1} e_FSM_t;
  typedef struct packed {
      logic some_register;
      e_FSM_t  cur_fsm;
  } st_FSM_t;
endpackage

package fsm2_pq;
  typedef enum {IDLE=2, SOME_STAGE_1} e_FSM_t;
  typedef struct packed {
      logic some_register;
      e_FSM_t  cur_fsm;
  } st_FSM_t;
endpackage

import fsm1_pq::*;
module test (input st_FSM_t A, output int B,C);
st_FSM_t fsm1;
fsm2_pq::st_FSM_t fsm2;

  assign fsm1.cur_fsm = (A.cur_fsm==fsm1_pq::e_FSM_t'(fsm2_pq::IDLE)) ? IDLE : fsm1_pq::e_FSM_t'(int'(IDLE)+1); //;)
  assign fsm2.cur_fsm = fsm2_pq::IDLE; 

endmodule

 

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

Тогда это скорее Qu чудит - так как один и тот же синтаксис то синтезирует то нет.

Удачи! Rob.

[flammmable 0]

Тогда это скорее Qu чудит - так как один и тот же синтаксис то синтезирует то нет.

Не, Qu не синтезирует ваш пример. И ModelSim не синтезирует ваш пример. Вообще, я не очень понимаю зачем и к чему вы его написали. Пример из первого поста Qu синтезирует стабильно, так же стабильно его не синтезирует ModelSim

Изменено 12 июля, 2018 пользователем flammmable

[RobFPGA 27]

Приветствую!

Не, Qu не синтезирует ваш пример. И ModelSim не синтезирует ваш пример. Вообще, я не очень понимаю зачем и к чему вы его написали. Пример из первого поста Qu синтезирует стабильно, так же стабильно его не синтезирует ModelSim

Затем что с точки зрения синтаксиса пример #1 поста и мой одинаков! Поэтому есть неоднозначность синтеза в Qu и стабильное поведения в ModelSim. IMHO первое хуже второго.

 

Удачи! Rob.