I've started filing TODOs as issues (#20, #21) so that they will not be forgotten, but these were only the ones that jumped at me. However, when I grepped the whole repo for question marks I got much more results, so I don't think we want them all as separate issues.
The output is not very clear here, so I recommend to grep on your own machine to see everything properly.
Some false positives are there because these are not real TODO comments, so no easy way to grep just them. For example, some comments seem to be explanatory statements about the code, not questions doubting the functionality.
ack --vhdl '\?'
RTL/Chip_Designs/EUROPRACTICE_Chip/Archived/modules_with_fault_injectors/to_be_tested/LBDR_with_checkers_with_FI.vhd:178: -- the non-faulty values of inputs go to checkers (according to the ReCoSoC, Euromicro DSD and NOCS papers ??)
RTL/Chip_Designs/EUROPRACTICE_Chip/Archived/modules_with_fault_injectors/Arbiter_one_hot_with_checkers.vhd:199:signal FI_add_sta: std_logic_vector(?? downto 0);
RTL/Chip_Designs/EUROPRACTICE_Chip/Archived/modules_with_fault_injectors/Arbiter_one_hot_with_checkers.vhd:203:FI: fault_injector generic map(DATA_WIDTH => ??)
RTL/Chip_Designs/EUROPRACTICE_Chip/Archived/modules_with_fault_injectors/Arbiter_one_hot_with_checkers.vhd:204: port map (data_in=> ?? , address=> FI_add_sta(?? downto 2), sta_0=> FI_add_sta(1), sta_1=> FI_add_sta(0), data_out=>??
RTL/Chip_Designs/EUROPRACTICE_Chip/Archived/modules_with_fault_injectors/FIFO_one_hot_with_checkers.vhd:115:signal FI_add_sta: std_logic_vector(?? downto 0);
RTL/Chip_Designs/EUROPRACTICE_Chip/Archived/modules_with_fault_injectors/FIFO_one_hot_with_checkers.vhd:119:FI: fault_injector generic map(DATA_WIDTH => ??)
RTL/Chip_Designs/EUROPRACTICE_Chip/Archived/modules_with_fault_injectors/FIFO_one_hot_with_checkers.vhd:120: port map (data_in=> ?? , address=> FI_add_sta(?? downto 2), sta_0=> FI_add_sta(1), sta_1=> FI_add_sta(0), data_out=>??
RTL/Chip_Designs/EUROPRACTICE_Chip/Archived/modules_with_fault_injectors/LBDR_with_checkers.vhd:117:signal FI_add_sta: std_logic_vector(?? downto 0);
RTL/Chip_Designs/EUROPRACTICE_Chip/Archived/modules_with_fault_injectors/LBDR_with_checkers.vhd:121:FI: fault_injector generic map(DATA_WIDTH => ??)
RTL/Chip_Designs/EUROPRACTICE_Chip/Archived/modules_with_fault_injectors/LBDR_with_checkers.vhd:122: port map (data_in=> ?? , address=> FI_add_sta(?? downto 2), sta_0=> FI_add_sta(1), sta_1=> FI_add_sta(0), data_out=>??
RTL/Chip_Designs/EUROPRACTICE_Chip/RTL/LBDR_with_checkers_with_FI.vhd:178: -- the non-faulty values of inputs go to checkers (according to the ReCoSoC, Euromicro DSD and NOCS papers ??)
RTL/Chip_Designs/IMMORTAL_Chip_2017/Testbenches/sim_uart.vhd:134: if bits_write_reg = "0000" then --nothing left to write?
RTL/Chip_Designs/IMMORTAL_Chip_2017/Testbenches/sim_uart.vhd:152: if delay_read_reg = ZERO(9 downto 0) then --done delay for read?
RTL/Chip_Designs/IMMORTAL_Chip_2017/Testbenches/sim_uart.vhd:153: if bits_read_reg = "0000" then --nothing left to read?
RTL/Chip_Designs/IMMORTAL_Chip_2017/network_files/Allocator_with_checkers_with_FI/Arbiter_in_one_hot_checkers.vhd:245:-- Shall I consider local for this case or the others case ? I guess local, according to the previous checkers
RTL/Chip_Designs/IMMORTAL_Chip_2017/network_files/Allocator_with_checkers_with_FI/Arbiter_in_one_hot_with_checkers_with_FI.vhd:7:-- Is this like the old arbiter in the router with handshaking FC ??
RTL/Chip_Designs/IMMORTAL_Chip_2017/network_files/Allocator_with_checkers_with_FI/Arbiter_in_one_hot_with_checkers_with_FI.vhd:80: -- Total: 17 bits ??!!
RTL/Chip_Designs/IMMORTAL_Chip_2017/network_files/Allocator_with_checkers_with_FI/Arbiter_in_one_hot_with_checkers_with_FI.vhd:95:-- for X_N, ... , X_L output signals, not sure whether to include them or the signals with _sig suffix in their names ??!!
RTL/Chip_Designs/IMMORTAL_Chip_2017/network_files/Allocator_with_checkers_with_FI/Arbiter_in_one_hot_with_checkers_with_FI.vhd:215: -- Here it seems N has the higest priority, is it fine ?
RTL/Chip_Designs/IMMORTAL_Chip_2017/network_files/Allocator_with_checkers_with_FI/Arbiter_out_one_hot_pseudo_checkers.vhd:264:-- Shall I consider local for this case or the others case ? I guess local, according to the previous checkers
RTL/Chip_Designs/IMMORTAL_Chip_2017/network_files/Allocator_with_checkers_with_FI/allocator_credit_counter_logic_pseudo_checkers.vhd:13: valid_N, valid_E, valid_W, valid_S, valid_L: in std_logic; -- ?? Not sure yet ! grant or valid !
RTL/Chip_Designs/IMMORTAL_Chip_2017/network_files/Allocator_with_checkers_with_FI/allocator_with_checkers_with_FI.vhd:297: -- What about Arbiter_in and Arbiter_out ?!
RTL/Chip_Designs/IMMORTAL_Chip_2017/network_files/Allocator_with_checkers_with_FI/allocator_with_checkers_with_FI.vhd:344:-- Total: ?? bits ??!!
RTL/Chip_Designs/IMMORTAL_Chip_2017/network_files/Allocator_with_checkers_with_FI/allocator_with_checkers_with_FI.vhd:374:-- for valid and grant output signals, not sure whether to include them or the signals with _sig and _signal suffix in their name ??!!
RTL/Chip_Designs/IMMORTAL_Chip_2017/network_files/Allocator_with_checkers_with_FI/allocator_with_checkers_with_FI.vhd:471:SR: shift_register_serial_in generic map(REG_WIDTH => 9) -- What about Arbiter_in and Arbiter_out ?!
RTL/Chip_Designs/IMMORTAL_Chip_2017/network_files/Allocator_with_checkers_with_FI/allocator_with_checkers_with_FI.vhd:512:-- Taking Arbiter_in checker outputs to outputs of Allocator ??!! (Behrad has written this :( )
RTL/Chip_Designs/IMMORTAL_Chip_2017/network_files/Allocator_with_checkers_with_FI/arbiter_out_one_hot_with_checkers_with_FI.vhd:68: -- Total: 17 bits ??!!
RTL/Chip_Designs/IMMORTAL_Chip_2017/network_files/Allocator_with_checkers_with_FI/arbiter_out_one_hot_with_checkers_with_FI.vhd:83:-- for grant_Y_N, ... , grant_Y_L output signals, not sure whether to include them or the signals with _sig suffix in their names ??!!
RTL/Chip_Designs/IMMORTAL_Chip_2017/network_files/FIFO_one_hot_credit_based_packet_drop_classifier_support_with_checkers_with_FI/FIFO_one_hot_credit_based_packet_drop_classifier_support_checkers.vhd:430:-- Checked! (Behrad: Is it OK to see fake credit counter like this ?? Because being negative, can also be understood as positive,
RTL/Chip_Designs/IMMORTAL_Chip_2017/network_files/FIFO_one_hot_credit_based_packet_drop_classifier_support_with_checkers_with_FI/FIFO_one_hot_credit_based_packet_drop_classifier_support_with_checkers_with_FI.vhd:185: -- Total: 44 bits ??!!
RTL/Chip_Designs/IMMORTAL_Chip_2017/network_files/FIFO_one_hot_credit_based_packet_drop_classifier_support_with_checkers_with_FI/FIFO_one_hot_credit_based_packet_drop_classifier_support_with_checkers_with_FI.vhd:195: --signal flit_type_faulty : std_logic; -- ??!! (Actually, flit_type is an alias, showing RX from bits 31 downto 29, maybe we can define it as a signal for injection) (Not sure yet !)
RTL/Chip_Designs/IMMORTAL_Chip_2017/network_files/FIFO_one_hot_credit_based_packet_drop_classifier_support_with_checkers_with_FI/FIFO_one_hot_credit_based_packet_drop_classifier_support_with_checkers_with_FI.vhd:199: signal credit_in_faulty : std_logic; -- ??!! (Actually, it is credit_in, which is the previous value of credit_out in FIFO)
RTL/Chip_Designs/IMMORTAL_Chip_2017/network_files/FIFO_one_hot_credit_based_packet_drop_classifier_support_with_checkers_with_FI/FIFO_one_hot_credit_based_packet_drop_classifier_support_with_checkers_with_FI.vhd:201: signal fault_info_sig_faulty : std_logic; -- ??!! (which goes to the fault_info output of FIFO)
RTL/Chip_Designs/IMMORTAL_Chip_2017/network_files/FIFO_one_hot_credit_based_packet_drop_classifier_support_with_checkers_with_FI/FIFO_one_hot_credit_based_packet_drop_classifier_support_with_checkers_with_FI.vhd:202: signal health_info_sig_faulty : std_logic; -- ??!! (which goes to the health_info output of FIFO)
RTL/Chip_Designs/IMMORTAL_Chip_2017/network_files/FIFO_one_hot_credit_based_packet_drop_classifier_support_with_checkers_with_FI/FIFO_one_hot_credit_based_packet_drop_classifier_support_with_checkers_with_FI.vhd:253:-- Still not sure whether to include flit_type or not ??!!
RTL/Chip_Designs/IMMORTAL_Chip_2017/network_files/FIFO_one_hot_credit_based_packet_drop_classifier_support_with_checkers_with_FI/FIFO_one_hot_credit_based_packet_drop_classifier_support_with_checkers_with_FI.vhd:255:-- for fault_info and health_info outputs, not sure whether to include them or the signals with _sig suffix in their names ??!!
RTL/Chip_Designs/IMMORTAL_Chip_2017/network_files/FIFO_one_hot_credit_based_packet_drop_classifier_support_with_checkers_with_FI/FIFO_one_hot_credit_based_packet_drop_classifier_support_with_checkers_with_FI.vhd:312: credit_out => credit_in_faulty, -- correct ?! (credit_in in FIFO is actually the previous value of credit_out, going to the input of a register)
RTL/Chip_Designs/IMMORTAL_Chip_2017/network_files/FIFO_one_hot_credit_based_packet_drop_classifier_support_with_checkers_with_FI/FIFO_one_hot_credit_based_packet_drop_classifier_support_with_checkers_with_FI.vhd:320: flit_type => RX(DATA_WIDTH-1 downto DATA_WIDTH-3), -- Behrad: Not sure about this yet ?!
RTL/Chip_Designs/IMMORTAL_Chip_2017/network_files/FIFO_one_hot_credit_based_packet_drop_classifier_support_with_checkers_with_FI/FIFO_one_hot_credit_based_packet_drop_classifier_support_with_checkers_with_FI.vhd:442: fault_info <= fault_info_sig; -- Not sure yet ?!
RTL/Chip_Designs/IMMORTAL_Chip_2017/network_files/FIFO_one_hot_credit_based_packet_drop_classifier_support_with_checkers_with_FI/FIFO_one_hot_credit_based_packet_drop_classifier_support_with_checkers_with_FI.vhd:443: health_info <= health_info_sig; -- Not sure yet ?!
RTL/Chip_Designs/IMMORTAL_Chip_2017/network_files/LBDR_packet_drop_with_checkers_with_FI/LBDR_packet_drop_with_checkers_with_FI.vhd:117: -- Total: 70 bits ??!!
RTL/Chip_Designs/IMMORTAL_Chip_2017/network_files/LBDR_packet_drop_with_checkers_with_FI/LBDR_packet_drop_with_checkers_with_FI.vhd:125: --signal cur_addr_faulty: std_logic_vector(NoC_size-1 downto 0); -- current address not included yet, in this way ??!!
RTL/Chip_Designs/IMMORTAL_Chip_2017/network_files/LBDR_packet_drop_with_checkers_with_FI/LBDR_packet_drop_with_checkers_with_FI.vhd:141:-- Still not sure whether to include cur_addr or not ??!!
RTL/Chip_Designs/IMMORTAL_Chip_2017/network_files/LBDR_packet_drop_with_checkers_with_FI/LBDR_packet_drop_with_checkers_with_FI.vhd:142:-- for packet_drop_order output, not sure whether to include that one or the signal with _sig suffix in its name ??!!
RTL/Chip_Designs/IMMORTAL_Chip_2017/network_files/customized_routers/Router_32_bit_NW_credit_based_packet_drop_classifier_SHMU_will_full_set_of_checkers_with_FI.vhd:61: --signal combined_error_signals: std_logic_vector(19 downto 0); -- Shall we only consider this for the 20 bits showing the turn faults or individual checkers ?!
RTL/Chip_Designs/IMMORTAL_Chip_2017/network_files/customized_routers/Router_32_bit_NW_credit_based_packet_drop_classifier_SHMU_will_full_set_of_checkers_with_FI.vhd:602: -- Might need to be changed ?!
RTL/Chip_Designs/IMMORTAL_Chip_2017/network_files/customized_routers/Router_32_bit_NW_credit_based_packet_drop_classifier_SHMU_will_full_set_of_checkers_with_FI.vhd:958:-- then L, N, E, W and S Arbiter_out and then Allocator's interlal logic ??!! --
RTL/Chip_Designs/IMMORTAL_Chip_2017/network_files/customized_routers/Router_32_bit_NW_credit_based_packet_drop_classifier_SHMU_will_full_set_of_checkers_with_FI.vhd:3491:-- Correct ?!
RTL/Chip_Designs/IMMORTAL_Chip_2017/network_files/customized_routers/Router_32_bit_SE_credit_based_packet_drop_classifier_SHMU_will_full_set_of_checkers_with_FI.vhd:61: --signal combined_error_signals: std_logic_vector(19 downto 0); -- Shall we only consider this for the 20 bits showing the turn faults or individual checkers ?!
RTL/Chip_Designs/IMMORTAL_Chip_2017/network_files/customized_routers/Router_32_bit_SE_credit_based_packet_drop_classifier_SHMU_will_full_set_of_checkers_with_FI.vhd:602: -- Might need to be changed ?!
RTL/Chip_Designs/IMMORTAL_Chip_2017/network_files/customized_routers/Router_32_bit_SE_credit_based_packet_drop_classifier_SHMU_will_full_set_of_checkers_with_FI.vhd:958:-- then L, N, E, W and S Arbiter_out and then Allocator's interlal logic ??!! --
RTL/Chip_Designs/IMMORTAL_Chip_2017/network_files/customized_routers/Router_32_bit_SW_credit_based_packet_drop_classifier_SHMU_will_full_set_of_checkers_with_FI.vhd:61: --signal combined_error_signals: std_logic_vector(19 downto 0); -- Shall we only consider this for the 20 bits showing the turn faults or individual checkers ?!
RTL/Chip_Designs/IMMORTAL_Chip_2017/network_files/customized_routers/Router_32_bit_SW_credit_based_packet_drop_classifier_SHMU_will_full_set_of_checkers_with_FI.vhd:602: -- Might need to be changed ?!
RTL/Chip_Designs/IMMORTAL_Chip_2017/network_files/customized_routers/Router_32_bit_SW_credit_based_packet_drop_classifier_SHMU_will_full_set_of_checkers_with_FI.vhd:958:-- then L, N, E, W and S Arbiter_out and then Allocator's interlal logic ??!! --
RTL/Chip_Designs/IMMORTAL_Chip_2017/network_files/customized_routers/Router_32_bit_NE_credit_based_packet_drop_classifier_SHMU_will_full_set_of_checkers_with_FI.vhd:61: --signal combined_error_signals: std_logic_vector(19 downto 0); -- Shall we only consider this for the 20 bits showing the turn faults or individual checkers ?!
RTL/Chip_Designs/IMMORTAL_Chip_2017/network_files/customized_routers/Router_32_bit_NE_credit_based_packet_drop_classifier_SHMU_will_full_set_of_checkers_with_FI.vhd:563: -- Might need to be changed ?!
RTL/Chip_Designs/IMMORTAL_Chip_2017/network_files/customized_routers/Router_32_bit_NE_credit_based_packet_drop_classifier_SHMU_will_full_set_of_checkers_with_FI.vhd:868:-- then L, N, E, W and S Arbiter_out and then Allocator's interlal logic ??!! --
RTL/Chip_Designs/IMMORTAL_Chip_2017/network_files/component_pack.vhd:1060: valid_N, valid_E, valid_W, valid_S, valid_L: in std_logic; -- ?? Not sure yet ! grant or valid !
RTL/Chip_Designs/IMMORTAL_Chip_2017/network_files/NI.vhd:68: signal old_address: std_logic_vector(31 downto 2); -- Behrad: What is old address ?
RTL/Chip_Designs/IMMORTAL_Chip_2017/network_files/NI.vhd:238: -- Behrad: So according to Plasma, is write_byte_enable always one-hot ?
RTL/Chip_Designs/IMMORTAL_Chip_2017/network_files/NI.vhd:295: if grant = '1' and fault_info_ready = '0' then -- Behrad: so grant here works somehow like read_en signal for FIFO ?
RTL/Chip_Designs/IMMORTAL_Chip_2017/plasma_RTL/control.vhd:108: -- does this mean that NOP acts as SLL ???
RTL/Chip_Designs/IMMORTAL_Chip_2017/plasma_RTL/mlite_cpu.vhd:228: opcode => opcode, -- is it opcode or the whole instruction ??
RTL/Chip_Designs/IMMORTAL_Chip_2017/plasma_RTL/mult.vhd:20:-- answer = (answer >> 1) + (((b&1)?a:0) << 31);
RTL/Chip_Designs/IMMORTAL_Chip_2017/plasma_RTL/reg_bank_tri_port.vhd:94: addr_write <= "00000";--"01110" --"11010"; -- Reg $26 to save PC when interrupt occurs, but is it safe ??
RTL/Chip_Designs/IMMORTAL_Chip_2017/plasma_RTL/reg_bank_xilinx.vhd:96: addr_write <= "00000";--"01110" --"11010"; -- Reg $26 to save PC when interrupt occurs, but is it safe ??
RTL/Chip_Designs/IMMORTAL_Chip_2017/plasma_RTL/uart.vhd:134: if bits_write_reg = "0000" then --nothing left to write?
RTL/Chip_Designs/IMMORTAL_Chip_2017/plasma_RTL/uart.vhd:153: if delay_read_reg = ZERO(9 downto 0) then --done delay for read?
RTL/Chip_Designs/IMMORTAL_Chip_2017/plasma_RTL/uart.vhd:154: if bits_read_reg = "0000" then --nothing left to read?
RTL/Chip_Designs/archive/IMMORTAL_Chip_2017/With_checkers/Allocator_with_checkers/Arbiter_in_one_hot_checkers.vhd:330:-- Shall I consider local for this case or the others case ? I guess local, according to the previous checkers
RTL/Chip_Designs/archive/IMMORTAL_Chip_2017/With_checkers/Allocator_with_checkers/Arbiter_in_one_hot_with_checkers.vhd:6:-- Is this like the old arbiter in the router with handshaking FC ??
RTL/Chip_Designs/archive/IMMORTAL_Chip_2017/With_checkers/Allocator_with_checkers/Arbiter_in_one_hot_with_checkers.vhd:337: -- Here it seems N has the higest priority, is it fine ?
RTL/Chip_Designs/archive/IMMORTAL_Chip_2017/With_checkers/Allocator_with_checkers/Arbiter_out_one_hot_pseudo_checkers.vhd:353:-- Shall I consider local for this case or the others case ? I guess local, according to the previous checkers
RTL/Chip_Designs/archive/IMMORTAL_Chip_2017/With_checkers/Allocator_with_checkers/allocator_credit_counter_logic_pseudo_checkers.vhd:13: valid_N, valid_E, valid_W, valid_S, valid_L: in std_logic; -- ?? Not sure yet ! grant or valid !
RTL/Chip_Designs/archive/IMMORTAL_Chip_2017/With_checkers/Allocator_with_checkers/allocator_with_checkers.vhd:1119: valid_N, valid_E, valid_W, valid_S, valid_L: in std_logic; -- ?? Not sure yet ! grant or valid !
RTL/Chip_Designs/archive/IMMORTAL_Chip_2017/With_checkers/FIFO_one_hot_credit_based_packet_drop_classifier_support_with_checkers/FIFO_one_hot_credit_based_packet_drop_classifier_support_checkers.vhd:476:-- Checked! (Behrad: Is it OK to see fake credit counter like this ?? Because being negative, can also be understood as positive,
RTL/Chip_Designs/archive/IMMORTAL_Chip_2017/With_checkers/FIFO_one_hot_credit_based_packet_drop_classifier_support_with_checkers/FIFO_one_hot_credit_based_packet_drop_classifier_support_with_checkers.vhd:404: credit_out => credit_in, -- correct ?
RTL/Chip_Designs/archive/IMMORTAL_Chip_2017/With_checkers/FIFO_one_hot_credit_based_packet_drop_classifier_support_with_checkers/FIFO_one_hot_credit_based_packet_drop_classifier_support_with_checkers.vhd:549: fault_info <= fault_info_sig; -- Not sure yet ?!
RTL/Chip_Designs/archive/IMMORTAL_Chip_2017/With_checkers/NI.vhd:68: signal old_address: std_logic_vector(31 downto 2); -- Behrad: What is old address ?
RTL/Chip_Designs/archive/IMMORTAL_Chip_2017/With_checkers/NI.vhd:238: -- Behrad: So according to Plasma, is write_byte_enable always one-hot ?
RTL/Chip_Designs/archive/IMMORTAL_Chip_2017/With_checkers/NI.vhd:295: if grant = '1' and fault_info_ready = '0' then -- Behrad: so grant here works somehow like read_en signal for FIFO ?
RTL/Chip_Designs/archive/IMMORTAL_Chip_2017/With_checkers/Router_32_bit_credit_based_packet_drop_classifier_SHMU_will_full_set_of_checkers.vhd:61: --signal combined_error_signals: std_logic_vector(19 downto 0); -- Shall we only consider this for the 20 bits showing the turn faults or individual checkers ?!
RTL/Chip_Designs/archive/IMMORTAL_Chip_2017/With_checkers/Router_32_bit_credit_based_packet_drop_classifier_SHMU_will_full_set_of_checkers.vhd:1297:-- then L, N, E, W and S Arbiter_out and then Allocator's interlal logic ??!! --
RTL/Chip_Designs/archive/IMMORTAL_Chip_2017/With_checkers/component_pack.vhd:925: valid_N, valid_E, valid_W, valid_S, valid_L: in std_logic; -- ?? Not sure yet ! grant or valid !
RTL/Chip_Designs/archive/IMMORTAL_Chip_2017/network_2x2_packet_drop_SHMU_credit_based_with_checkers.vhd:662: -- wait; --??
RTL/Processor_NI/uart.vhd:122: if bits_write_reg = "0000" then --nothing left to write?
RTL/Processor_NI/uart.vhd:150: if delay_read_reg = ZERO(9 downto 0) then --done delay for read?
RTL/Processor_NI/uart.vhd:151: if bits_read_reg = "0000" then --nothing left to read?
RTL/Processor_NI/control.vhd:94: -- does this mean that NOP acts as SLL ???
RTL/Processor_NI/mlite_cpu.vhd:228: opcode => opcode, -- is it opcode or the whole instruction ??
RTL/Processor_NI/mult.vhd:20:-- answer = (answer >> 1) + (((b&1)?a:0) << 31);
RTL/Processor_NI/reg_bank_tri_port.vhd:94: addr_write <= "00000";--"01110" --"11010"; -- Reg $26 to save PC when interrupt occurs, but is it safe ??
RTL/Processor_NI/reg_bank_xilinx.vhd:94: addr_write <= "00000";--"01110" --"11010"; -- Reg $26 to save PC when interrupt occurs, but is it safe ??
RTL/Router/credit_based/Checkers/Control_Part_Checkers/Allocator_checkers/Allocator_credit_counter_logic_checkers/allocator_credit_counter_logic_pseudo_checkers.vhd:13: valid_N, valid_E, valid_W, valid_S, valid_L: in std_logic; -- ?? Not sure yet ! grant or valid !
RTL/Router/credit_based/Checkers/Control_Part_Checkers/Allocator_checkers/Allocator_credit_counter_logic_checkers/allocator_credit_counter_logic_pseudo_with_checkers_top.vhd:74: valid_N, valid_E, valid_W, valid_S, valid_L: in std_logic; -- ?? Not sure yet ! grant or valid !
RTL/Router/credit_based/Checkers/Control_Part_Checkers/Allocator_checkers/Allocator_credit_counter_logic_checkers/allocator_credit_counter_logic_pseudo_with_checkers_top.vhd:161: valid_N => grant_N, -- ?? Valid or grant ??
RTL/Router/credit_based/Checkers/Control_Part_Checkers/Allocator_checkers/Allocator_credit_counter_logic_checkers/allocator_credit_counter_logic_pseudo_with_checkers_top.vhd:162: valid_E => grant_E, -- ?? Valid or grant ??
RTL/Router/credit_based/Checkers/Control_Part_Checkers/Allocator_checkers/Allocator_credit_counter_logic_checkers/allocator_credit_counter_logic_pseudo_with_checkers_top.vhd:163: valid_W => grant_W, -- ?? Valid or grant ??
RTL/Router/credit_based/Checkers/Control_Part_Checkers/Allocator_checkers/Allocator_credit_counter_logic_checkers/allocator_credit_counter_logic_pseudo_with_checkers_top.vhd:164: valid_S => grant_S, -- ?? Valid or grant ??
RTL/Router/credit_based/Checkers/Control_Part_Checkers/Allocator_checkers/Allocator_credit_counter_logic_checkers/allocator_credit_counter_logic_pseudo_with_checkers_top.vhd:165: valid_L => grant_L, -- ?? Valid or grant ??
RTL/Router/credit_based/Checkers/Control_Part_Checkers/Allocator_checkers/Arbiter_in_one_hot_checkers/RTL_and_Synthesis/Arbiter_in_one_hot_checkers.vhd:331:-- Shall I consider local for this case or the others case ? I guess local, according to the previous checkers
RTL/Router/credit_based/Checkers/Control_Part_Checkers/Allocator_checkers/Arbiter_in_one_hot_checkers/RTL_and_Synthesis/arbiter_in_one_hot_pseudo.vhd:6:-- Is this like the old arbiter in the router with handshaking FC ??
RTL/Router/credit_based/Checkers/Control_Part_Checkers/Allocator_checkers/Arbiter_in_one_hot_checkers/RTL_and_Synthesis/arbiter_in_one_hot_pseudo.vhd:41: -- Here it seems N has the higest priority, am I correct ?
RTL/Router/credit_based/Checkers/Control_Part_Checkers/Allocator_checkers/Arbiter_out_one_hot_checkers/RTL/Arbiter_out_one_hot_pseudo_checkers.vhd:353:-- Shall I consider local for this case or the others case ? I guess local, according to the previous checkers
RTL/Router/credit_based/Checkers/Control_Part_Checkers/FIFO_one_hot_credit_based_packet_drop_classifier_support_checkers/RTL/FIFO_one_hot_credit_based_packet_drop_classifier_support_pseudo.vhd:163:-- These are data-path related checkers, thus commented. Correct ??
RTL/Router/credit_based/Checkers/Control_Part_Checkers/FIFO_one_hot_credit_based_packet_drop_classifier_support_checkers/RTL/FIFO_one_hot_credit_based_packet_drop_classifier_support_pseudo.vhd:173:-- Shall this also be removed, because it is related to part of data-path (RX(0)) (parity checking) ??
RTL/Router/credit_based/Checkers/Control_Part_Checkers/FIFO_one_hot_credit_based_packet_drop_classifier_support_checkers/RTL/FIFO_one_hot_credit_based_packet_drop_classifier_support_pseudo.vhd:183:-- These are data-path related checkers, thus commented. Correct ??
RTL/Router/credit_based/Checkers/Control_Part_Checkers/New_SHMU_on_Node/FIFO_one_hot_credit_based_packet_drop_classifier_support_checkers/RTL/FIFO_one_hot_credit_based_packet_drop_classifier_support_pseudo.vhd:167:-- These are data-path related checkers, thus commented. Correct ??
RTL/Router/credit_based/Checkers/Control_Part_Checkers/New_SHMU_on_Node/FIFO_one_hot_credit_based_packet_drop_classifier_support_checkers/RTL/FIFO_one_hot_credit_based_packet_drop_classifier_support_pseudo.vhd:177:-- Shall this also be removed, because it is related to part of data-path (RX(0)) (parity checking) ??
RTL/Router/credit_based/Checkers/Control_Part_Checkers/New_SHMU_on_Node/FIFO_one_hot_credit_based_packet_drop_classifier_support_checkers/RTL/FIFO_one_hot_credit_based_packet_drop_classifier_support_pseudo.vhd:187:-- These are data-path related checkers, thus commented. Correct ??
RTL/Router/credit_based/Checkers/Modules_with_checkers_integrated/All_checkers/Allocator_with_checkers/Arbiter_in_one_hot_checkers.vhd:330:-- Shall I consider local for this case or the others case ? I guess local, according to the previous checkers
RTL/Router/credit_based/Checkers/Modules_with_checkers_integrated/All_checkers/Allocator_with_checkers/Arbiter_in_one_hot_with_checkers.vhd:6:-- Is this like the old arbiter in the router with handshaking FC ??
RTL/Router/credit_based/Checkers/Modules_with_checkers_integrated/All_checkers/Allocator_with_checkers/Arbiter_in_one_hot_with_checkers.vhd:337: -- Here it seems N has the higest priority, is it fine ?
RTL/Router/credit_based/Checkers/Modules_with_checkers_integrated/All_checkers/Allocator_with_checkers/Arbiter_out_one_hot_pseudo_checkers.vhd:353:-- Shall I consider local for this case or the others case ? I guess local, according to the previous checkers
RTL/Router/credit_based/Checkers/Modules_with_checkers_integrated/All_checkers/Allocator_with_checkers/allocator_credit_counter_logic_pseudo_checkers.vhd:13: valid_N, valid_E, valid_W, valid_S, valid_L: in std_logic; -- ?? Not sure yet ! grant or valid !
RTL/Router/credit_based/Checkers/Modules_with_checkers_integrated/All_checkers/Allocator_with_checkers/allocator_with_checkers.vhd:1119: valid_N, valid_E, valid_W, valid_S, valid_L: in std_logic; -- ?? Not sure yet ! grant or valid !
RTL/Router/credit_based/Checkers/Modules_with_checkers_integrated/All_checkers/Arbiter_in_one_hot_with_checkers/Arbiter_in_one_hot_checkers.vhd:329:-- Shall I consider local for this case or the others case ? I guess local, according to the previous checkers
RTL/Router/credit_based/Checkers/Modules_with_checkers_integrated/All_checkers/Arbiter_in_one_hot_with_checkers/Arbiter_in_one_hot_with_checkers.vhd:6:-- Is this like the old arbiter in the router with handshaking FC ??
RTL/Router/credit_based/Checkers/Modules_with_checkers_integrated/All_checkers/Arbiter_in_one_hot_with_checkers/Arbiter_in_one_hot_with_checkers.vhd:337: -- Here it seems N has the higest priority, is it fine ?
RTL/Router/credit_based/Checkers/Modules_with_checkers_integrated/All_checkers/Arbiter_out_one_hot_with_checkers/Arbiter_out_one_hot_pseudo_checkers.vhd:353:-- Shall I consider local for this case or the others case ? I guess local, according to the previous checkers
RTL/Router/credit_based/Checkers/Modules_with_checkers_integrated/All_checkers/FIFO_one_hot_credit_based_packet_drop_classifier_support_with_checkers/FIFO_one_hot_credit_based_packet_drop_classifier_support_with_checkers.vhd:621: -- Some default values (some sort of initialization, also used for avoiding latch(es) ??)
RTL/Router/credit_based/Checkers/Modules_with_checkers_integrated/All_checkers/LBDR_packet_drop_with_checkers/LBDR_packet_drop_with_checkers.vhd:406: Req_L_in <= Req_L_FF; -- Added to remove latch possibility. Correct ??
RTL/Router/credit_based/Checkers/Modules_with_checkers_integrated/All_checkers/New_SHMU_on_Node/FIFO_one_hot_credit_based_packet_drop_classifier_support_checkers/FIFO_one_hot_credit_based_packet_drop_classifier_support_with_checkers.vhd:400: credit_out => credit_in, -- correct ?
RTL/Router/credit_based/Checkers/Modules_with_checkers_integrated/All_checkers/New_SHMU_on_Node/FIFO_one_hot_credit_based_packet_drop_classifier_support_checkers/FIFO_one_hot_credit_based_packet_drop_classifier_support_with_checkers.vhd:543: fault_info <= fault_info_sig; -- Not sure yet ?!
RTL/Router/credit_based/Checkers/Modules_with_checkers_integrated/All_checkers/New_SHMU_on_Node/LBDR_packet_drop_checkers/LBDR_packet_drop_with_checkers.vhd:442: Req_L_in <= Req_L_FF; -- Added to remove latch possibility. Correct ??
RTL/Router/credit_based/RTL/NI_Test/NI.vhd:26: reserved_address : std_logic_vector(29 downto 0) := "000000000000000001111111111111"; -- Behrad: NI's reserved address ?
RTL/Router/credit_based/RTL/NI_Test/NI.vhd:72: signal old_address: std_logic_vector(31 downto 2); -- Behrad: What is old address ?
RTL/Router/credit_based/RTL/NI_Test/NI.vhd:228: -- Behrad: So according to Plasma, is write_byte_enable always one-hot ?
RTL/Router/credit_based/RTL/NI_Test/NI.vhd:286: if grant = '1' and fault_info_ready = '0' then -- Behrad: so grant here works somehow like read_en signal for FIFO ?
RTL/Router/credit_based/RTL/NI_Test/arbiter_in.vhd:6:-- Is this like the old arbiter in the router with handshaking FC ??
RTL/Router/credit_based/RTL/NI_Test/arbiter_in.vhd:43: -- Here it seems N has the higest priority, is it fine ?
RTL/Router/credit_based/RTL/NI_Test/deep_NI.vhd:26: reserved_address : std_logic_vector(29 downto 0) := "000000000000000001111111111111"; -- Behrad: NI's reserved address ?
RTL/Router/credit_based/RTL/NI_Test/deep_NI.vhd:72: signal old_address: std_logic_vector(31 downto 2); -- Behrad: What is old address ?
RTL/Router/credit_based/RTL/NI_Test/deep_NI.vhd:242: -- Behrad: So according to Plasma, is write_byte_enable always one-hot ?
RTL/Router/credit_based/RTL/NI_Test/deep_NI.vhd:308: if grant = '1' and fault_info_ready = '0' then -- Behrad: so grant here works somehow like read_en signal for FIFO ?
RTL/Router/credit_based/RTL/New_SHMU_on_Node/With_checkers/Arbiter_in_one_hot_checkers.vhd:330:-- Shall I consider local for this case or the others case ? I guess local, according to the previous checkers
RTL/Router/credit_based/RTL/New_SHMU_on_Node/With_checkers/Arbiter_in_one_hot_with_checkers.vhd:6:-- Is this like the old arbiter in the router with handshaking FC ??
RTL/Router/credit_based/RTL/New_SHMU_on_Node/With_checkers/Arbiter_in_one_hot_with_checkers.vhd:337: -- Here it seems N has the higest priority, is it fine ?
RTL/Router/credit_based/RTL/New_SHMU_on_Node/With_checkers/Arbiter_out_one_hot_pseudo_checkers.vhd:353:-- Shall I consider local for this case or the others case ? I guess local, according to the previous checkers
RTL/Router/credit_based/RTL/New_SHMU_on_Node/With_checkers/FIFO_one_hot_credit_based_packet_drop_classifier_support_with_checkers.vhd:406: credit_out => credit_in, -- correct ?
RTL/Router/credit_based/RTL/New_SHMU_on_Node/With_checkers/FIFO_one_hot_credit_based_packet_drop_classifier_support_with_checkers.vhd:552: fault_info <= fault_info_sig; -- Not sure yet ?!
RTL/Router/credit_based/RTL/New_SHMU_on_Node/With_checkers/LBDR_packet_drop_with_checkers.vhd:442: Req_L_in <= Req_L_FF; -- Added to remove latch possibility. Correct ??
RTL/Router/credit_based/RTL/New_SHMU_on_Node/With_checkers/allocator_credit_counter_logic_pseudo_checkers.vhd:13: valid_N, valid_E, valid_W, valid_S, valid_L: in std_logic; -- ?? Not sure yet ! grant or valid !
RTL/Router/credit_based/RTL/New_SHMU_on_Node/With_checkers/allocator_with_checkers.vhd:1119: valid_N, valid_E, valid_W, valid_S, valid_L: in std_logic; -- ?? Not sure yet ! grant or valid !
RTL/Router/credit_based/RTL/New_SHMU_on_Node/With_checkers/control.vhd:94: -- does this mean that NOP acts as SLL ???
RTL/Router/credit_based/RTL/New_SHMU_on_Node/With_checkers/mlite_cpu.vhd:228: opcode => opcode, -- is it opcode or the whole instruction ??
RTL/Router/credit_based/RTL/New_SHMU_on_Node/With_checkers/mult.vhd:20:-- answer = (answer >> 1) + (((b&1)?a:0) << 31);
RTL/Router/credit_based/RTL/New_SHMU_on_Node/With_checkers/reg_bank.vhd:85: addr_write <= "01110";--"11010"; -- Reg $26 to save PC when interrupt occurs, but is it safe ??
RTL/Router/credit_based/RTL/New_SHMU_on_Node/With_checkers/reg_bank.vhd:100: --if interrupt_in = '1' then -- ??
RTL/Router/credit_based/RTL/New_SHMU_on_Node/With_checkers/uart.vhd:75: if bits_write_reg = "0000" then --nothing left to write?
RTL/Router/credit_based/RTL/New_SHMU_on_Node/With_checkers/uart.vhd:103: if delay_read_reg = ZERO(9 downto 0) then --done delay for read?
RTL/Router/credit_based/RTL/New_SHMU_on_Node/With_checkers/uart.vhd:104: if bits_read_reg = "0000" then --nothing left to read?
RTL/Router/credit_based/RTL/New_SHMU_on_Node/LBDR_packet_drop.vhd:158: Req_L_in <= Req_L_FF; -- Added to remove latch possibility. Correct ??
RTL/Router/credit_based/RTL/New_SHMU_on_Node/arbiter_in.vhd:6:-- Is this like the old arbiter in the router with handshaking FC ??
RTL/Router/credit_based/RTL/New_SHMU_on_Node/arbiter_in.vhd:43: -- Here it seems N has the higest priority, is it fine ?
RTL/Router/credit_based/RTL/New_SHMU_on_Node/control.vhd:94: -- does this mean that NOP acts as SLL ???
RTL/Router/credit_based/RTL/New_SHMU_on_Node/mlite_cpu.vhd:228: opcode => opcode, -- is it opcode or the whole instruction ??
RTL/Router/credit_based/RTL/New_SHMU_on_Node/mult.vhd:20:-- answer = (answer >> 1) + (((b&1)?a:0) << 31);
RTL/Router/credit_based/RTL/New_SHMU_on_Node/reg_bank.vhd:85: addr_write <= "01110";--"11010"; -- Reg $26 to save PC when interrupt occurs, but is it safe ??
RTL/Router/credit_based/RTL/New_SHMU_on_Node/reg_bank.vhd:100: --if interrupt_in = '1' then -- ??
RTL/Router/credit_based/RTL/New_SHMU_on_Node/uart.vhd:75: if bits_write_reg = "0000" then --nothing left to write?
RTL/Router/credit_based/RTL/New_SHMU_on_Node/uart.vhd:103: if delay_read_reg = ZERO(9 downto 0) then --done delay for read?
RTL/Router/credit_based/RTL/New_SHMU_on_Node/uart.vhd:104: if bits_read_reg = "0000" then --nothing left to read?
RTL/Router/credit_based/RTL/FIFO_one_hot_credit_based_packet_drop_flit_saving.vhd:104: credit_in <= '0'; -- Is this actually credit_out from the router module ?
RTL/Router/credit_based/RTL/FIFO_one_hot_credit_based_packet_drop_flit_saving.vhd:111: credit_in <= '1'; -- Is this actually credit_out from the router module ?
RTL/Router/credit_based/RTL/FIFO_one_hot_credit_based_packet_drop_flit_saving.vhd:126: xor_all <= '0'; -- Is this correct ? This means parity is zero. Or does it mean we don't care about parity in this case ?
RTL/Router/credit_based/RTL/FIFO_one_hot_credit_based_packet_drop_flit_saving.vhd:175: -- Is this the place where we do the saving for packet drop ?
RTL/Router/credit_based/RTL/FIFO_one_hot_credit_based_packet_drop_flit_saving.vhd:242: state_in <= state_out; -- We can also write (state_in <= Body_flit) ?? As the state is not changed.
RTL/Router/credit_based/RTL/FIFO_one_hot_credit_based_packet_drop_flit_saving.vhd:285: -- what is this case ??
RTL/Router/credit_based/RTL/FIFO_one_hot_credit_based_packet_drop_flit_saving.vhd:286: -- we should not be here ??
RTL/Router/credit_based/RTL/FIFO_one_hot_credit_based_packet_drop_flit_saving.vhd:320: -- flit is dropped ?? Previous values of FIFO slots are re-written
RTL/Router/credit_based/RTL/FIFO_one_hot_credit_based_packet_drop_flit_saving.vhd:334: -- previous values of FIFO slots are re-written (flit is dropped ??)
RTL/Router/credit_based/RTL/LBDR_packet_drop.vhd:143: Req_L_in <= Req_L_FF; -- Added to remove latch possibility. Correct ??
RTL/Router/credit_based/RTL/arbiter_in.vhd:6:-- Is this like the old arbiter in the router with handshaking FC ??
RTL/Router/credit_based/RTL/arbiter_in.vhd:43: -- Here it seems N has the higest priority, is it fine ?
RTL/Router/handshaking/RTL/NI.vhd:49:-- RX |<---------| TX1 RX1|<---- | TX_L_R_?
RTL/Router/handshaking/RTL/NI.vhd:50:-- DRTS|<---------| RTS1 DRTS1|<---- | RTS_L_R_?
RTL/Router/handshaking/RTL/NI.vhd:51:-- CTS |--------->| DCTS1 CTS1|----> | DCTS_L_R_?
RTL/Router/handshaking/RTL/NI.vhd:53:-- TX|--------->| RX2 TX2|----> | RX_L_R_?
RTL/Router/handshaking/RTL/NI.vhd:54:-- RTS|--------->| DRTS2 RTS2|----> | DRTS_L_R_?
RTL/Router/handshaking/RTL/NI.vhd:55:-- DCTS|<---------| CTS2 DCTS2|<---- | CTS_L_R_?
RTL/Router/handshaking/RTL/NI_channel.vhd:45:-- RX |<---------| TX RX |<---- | TX_L_R_?
RTL/Router/handshaking/RTL/NI_channel.vhd:46:-- DRTS|<---------| RTS DRTS |<---- | RTS_L_R_?
RTL/Router/handshaking/RTL/NI_channel.vhd:47:-- CTS |--------->| DCTS CTS |----> | DCTS_L_R_?
I've started filing TODOs as issues (#20, #21) so that they will not be forgotten, but these were only the ones that jumped at me. However, when I grepped the whole repo for question marks I got much more results, so I don't think we want them all as separate issues.
The output is not very clear here, so I recommend to grep on your own machine to see everything properly.
Some false positives are there because these are not real TODO comments, so no easy way to grep just them. For example, some comments seem to be explanatory statements about the code, not questions doubting the functionality.