Verible Format experiment #7

msfschaffner · 2020-08-11T20:20:53Z

Experimental PR to see and comment on diffs.

Signed-off-by: Michael Schaffner <[email protected]>

msfschaffner · 2020-09-08T19:18:11Z

hw/ip/aes/rtl/aes.sv

-                                                        // allows the processor to go into sleep
-                                                        // before AES starts operation.
+module aes
+import aes_pkg::*;


@fangism @hzeller @udinator @scottdj

do we expect imports to be indented or not?
looks like we tend to indent this in our codebase, e.g.:
https://github.com/lowRISC/opentitan/blob/914e1b21982805f11da55e8973e32fa6c67719ae/hw/ip/alert_handler/rtl/alert_handler.sv#L13-L19
https://github.com/lowRISC/opentitan/blob/914e1b21982805f11da55e8973e32fa6c67719ae/hw/ip/otbn/rtl/otbn.sv#L10-L18

I can confirm that they are not handled at this time and will need a new issue.

@msfschaffner we have done a similar exercise in lowRISC/ibex#1014 for Ibex, which is a much smaller code base and easier to get some of the things sorted out. It would probably be helpful to get Ibex done first, and then look at OpenTitan.

Ah great, thanks for the pointer!

Note that we are at this time not specifically working on getting this merged into upstream. This is just a dummy PR to generate some feedback on various aspects of the code base, including DV code.

I fully agree that trying to get mass-formatting to work well on Ibex is probably a better intermediate milestone.

Btwy, @fangism just told me that there are a couple of upcoming improvements related to how Verible decides whether to format pre-aligned code or not (https://github.com/google/verible#aligned-formatting). Give it another day or two such that these patches can be rolled out as part of the GH releases, but then I guess it would be worth giving this another try on Ibex.

Also, Verible should get an experimental flag for OT-specific style differences (like 2/4 space differences) in the near future.

The 2 vs. 4 space issue is tracked as chipsalliance/verible#40.

msfschaffner · 2020-09-08T19:22:10Z

hw/ip/aes/rtl/aes.sv

-    .prng_data_ack_i   ( prng_data_ack   ),
-    .prng_data_i       ( prng_data       ),
-    .prng_reseed_req_o ( prng_reseed_req ),
-    .prng_reseed_ack_i ( prng_reseed_ack ),


@fangism @hzeller @udinator @scottdj

this type of parenthesis alignment seems to be unsupported.
I think I am fine with that, as long as there is tabular alignment for the start of the parenthesis (which seems to be the case).
WDYT?

Confirming that right now we do not align close-parentheses.

msfschaffner · 2020-09-08T19:25:33Z

hw/ip/aes/rtl/aes_sbox_canright_masked.sv

-    b = q ^ aes_square_scale_gf2p4_gf2p2(a1 ^ a0)
-          ^ aes_square_scale_gf2p4_gf2p2(m1 ^ m0)
-          ^ aes_mul_gf2p4(a1, a0)
-          ^ mul_a1_m0 ^ mul_a0_m1 ^ mul_m0_m1;


@fangism if we wanted to preserve such structures, we would have to add a // comment to the end of the line, is that right?

Actually, I just enabled more re-wrap disabling today for cases like this. Give a little time for auto-releases to catch up.

Understood, will check again later.

msfschaffner · 2020-09-08T19:28:01Z

hw/ip/alert_handler/dv/env/alert_handler_virtual_sequencer.sv

-    .COV_T(alert_handler_env_cov)
-  );
+class alert_handler_virtual_sequencer extends cip_base_virtual_sequencer#(
+    .CFG_T(alert_handler_env_cfg), .COV_T(alert_handler_env_cov)


@udinator is this expected, or should this behave more like a module instantiation with one connection per line?

@fangism @hzeller

Ideally this should be one connection per line.

I would call this "named parameters in parameterized type references".
This was just enabled for module instances earlier today, I'll test whether or not it works in this context.

Doesn't work yet, so filed chipsalliance/verible#428

Thanks @fangism!

msfschaffner · 2020-09-08T19:33:27Z

hw/ip/alert_handler/dv/env/seq_lib/alert_handler_common_vseq.sv

-        [1         :1000]        :/ 5, // reset during alert
-        [1001      :16_500_000]  :/ 2,
-        [16_500_001 :17_000_000] :/ 2, // reset during ping
-        [17_000_001 :18_000_000] :/ 1


@fangism @hzeller @udinator

This is interesting, I thought an in-line comment at the end of the line prevents formatting of the block?

//coments force line breaks, but do not cause anything else around them to be preserved.

FYI, alignment of dists is chipsalliance/verible#403

Ah got it, thanks!

msfschaffner · 2020-09-08T19:45:48Z

hw/ip/alert_handler/rtl/alert_handler_accu.sv

-                                               accu_q;
+  assign accu_d = (clr_i) ? '0 :  // clear
+  (trig_gated && !(&accu_q)) ? accu_q + 1'b1 :  // saturate counter at maximum
+  accu_q;


@fangism @hzeller

example for a ternary that is not formatted correctly

Worse than that, even hang/wrap indentation doesn't look right.
Please file an issue with a reduced test case for this one.

jep, tracked here: chipsalliance/verible#431

msfschaffner · 2020-09-08T19:48:08Z

hw/ip/alert_handler/rtl/alert_handler_esc_timer.sv

-        // the counter is zero in this state. so if the
-        // timeout count is zero (==disabled), cnt_ge will be true.
+          // the counter is zero in this state. so if the
+          // timeout count is zero (==disabled), cnt_ge will be true.
        end else if (timeout_en_i && !cnt_ge && en_i) begin


@fangism @hzeller

it appears that the comments are indented here since they are technically still within the begin .. end block, but I wonder if this could be improved to detect that the comment is actually with respect to the else if condition below...

That sounds difficult, but I see your point. Comment placement is a mysterious art. How bad would it be if that comment were moved inside the following else-if-begin block?

Haha yeah I see the "mysterious art aspect". Moving the comment into the next block would be ok, just wanted to flag this since I think such comments before if/else conditions do occur once in a while...

msfschaffner · 2020-09-08T19:49:09Z

hw/ip/alert_handler/rtl/alert_handler_esc_timer.sv

-      state_q == Idle)
+  `ASSERT(CheckTimeout0,
+          state_q == Idle && timeout_en_i && en_i && timeout_cyc_i != 0 && !accum_trig_i |=>
+              state_q == Timeout)


@fangism @hzeller

this second indentation appears to be incorrect...

Can you explain a bit more here? To me it looks like a long expression, whose wrapping should beget +4 spaces.

I was more expecting something like the example below:

`ASSERT(CheckTimeout0, state_q == Idle && timeout_en_i && en_i && timeout_cyc_i != 0 && !accum_trig_i |=> state_q == Timeout)

But by wrapping it like that I basically treat the whole macro as one single expression, which may be wrong in the first place...

What's happening is that the wrapped argument is treated as one unit of formatting, whose standard rule is to hang-indent/wrap +4 spaces on continued lines. To to otherwise would require treating it as a hierarchy of units (of equal indentation). Might not get around to this any time soon.

hw/ip/alert_handler/rtl/alert_handler_ping_timer.sv

msfschaffner · 2020-09-08T19:53:20Z

hw/ip/entropy_src/dv/sva/entropy_src_bind.sv

@@ -5,22 +5,12 @@
 module entropy_src_bind;

  bind entropy_src tlul_assert #(


@fangism @hzeller @udinator

I think we probably want bind statements to behave the same way as module or interface instantiations?

As coded, they do (behave same as data declarations). What appears wrong?

Verible reformats

bind entropy_src tlul_assert #( .EndpointType("Device") ) tlul_assert_device ( .clk_i, .rst_ni, .h2d (tl_i), .d2h (tl_o) );

into

bind entropy_src tlul_assert #( .EndpointType("Device") ) tlul_assert_device (.clk_i, .rst_ni, .h2d(tl_i), .d2h(tl_o));

which is a weird choice. I.e., it prefers one parameter assignment per line, and then puts all port connections onto a single line. I would expect it to leave the port connections one per line also...

That does look surprising to me. Can you file an issue for this?

yes, I think ideally we want bind statements to look the same as a module/interface instantiation.

Tracked here: chipsalliance/verible#432

msfschaffner · 2020-09-08T19:56:37Z

hw/ip/flash_ctrl/dv/env/flash_ctrl_env.sv

+      m_eflash_tl_agent.monitor.a_chan_port.connect(scoreboard.eflash_tl_a_chan_fifo.analysis_export
+          );
+      m_eflash_tl_agent.monitor.d_chan_port.connect(scoreboard.eflash_tl_d_chan_fifo.analysis_export
+          );


@fangism @hzeller @udinator

this seems to be an unfortunate case since the statements do not fit onto one line by exactly 2 chars. @udinator, does this look ok to you, or would you prefer this to be wrapped differently?

hmm - I think I'd prefer to have it wrapped as it is in the 'before' part of the diff:

m_eflash_tl_agent.monitor.d_chan_port.connect( scoreboard.eflash...);

lines that need wrapping should now be left intact by a recently released change. let's verify that in the next round.

udinator · 2020-09-10T02:02:26Z

hw/ip/aes/dv/aes_model_dpi/aes_model_dpi_pkg.sv

+      input bit [5:0] mode_i,  // 6'b00_0001 = ECB, 6'00_b0010 = CBC, 6'b00_0100 = CFB,
+      // 6'b00_1000 = OFB, 6'b01_0000 = CTR, 6'b10_0000 = NONE


@msfschaffner @fangism this is a tricky one...both sets of comments are meant to apply to the input bit [5:0] mode_i on line 12 - with the reformatting the comment on line 13 now behaves like it applies to the following lines of code (as per the style guide).

I see. Would it then be wise to move the comments to before line 12 to follow style guidance? (whenever the trailing comment doesn't fit)

yes I think that is preferred by our style guide also (comments on a line with code describe that line of code only).

udinator · 2020-09-10T02:04:00Z

hw/ip/aes/dv/aes_model_dpi/aes_model_dpi_pkg.sv

+      // 6'b00_1000 = OFB, 6'b01_0000 = CTR, 6'b10_0000 = NONE
+      input bit [3:0][31:0] iv_i,
+      input bit [2:0] key_len_i,  // 3'b001 = 128b, 3'b010 = 192b, 3'b100 = 256b
+      input bit [7:0][31:0] key_i, input bit [7:0] data_i[], output bit [7:0] data_o[]);


@msfschaffner @fangism I think we want to keep the original formatting instead of collapsing multiple input/outputs onto one line.

Filed chipsalliance/verible#433

udinator · 2020-09-10T02:08:55Z

hw/ip/aes/dv/env/aes_env_cfg.sv

@@ -2,7 +2,9 @@
 // Licensed under the Apache License, Version 2.0, see LICENSE for details.
 // SPDX-License-Identifier: Apache-2.0

-class aes_env_cfg extends cip_base_env_cfg #(.RAL_T(aes_reg_block));
+class aes_env_cfg extends cip_base_env_cfg#(


@msfschaffner I think we want to keep the space before the # as per the Parameterized Types section, correct?
@fangism

Yes I would also expect a space before the #.

Agreed there should be a space before #. Could you file a new issue?

tracked here: chipsalliance/verible#444

udinator · 2020-09-10T02:11:22Z

hw/ip/aes/dv/env/aes_env_cfg.sv

+    str = {
+      str,
+      $sformatf("\n\t ----| Reference model:\t    %s              \t ",
+                (ref_model == 0) ? "C-MODEL" : "OPEN_SSL")
+    };


@msfschaffner @fangism What if this was reformatted as shown below?

str = {str, $sformatf("\n\t ----| Reference model... \t ", (ref_model == 0) ? ...)};

That is a possibility but it may be a while before we can make that happen. The low-level wrapping optimizer needs to be completely rewritten to evaluate rectangles and bounding boxes first.

Understood - it shouldn't be that much of an issue imo.

udinator · 2020-09-10T02:14:48Z

hw/ip/aes/dv/env/aes_message_item.sv

+    if (fixed_keylen_en) {aes_keylen == fixed_keylen};
  }

-  constraint c_key {
-    if (fixed_key_en) {
-      aes_key[0] == fixed_key[0],
-      aes_key[1] == fixed_key[1]
-    };
-  }
+  constraint c_key {if (fixed_key_en) {aes_key[0] == fixed_key[0], aes_key[1] == fixed_key[1]};}

-  constraint c_iv {
-    if (fixed_iv_en) {
-      aes_iv == fixed_iv
-    };
-  }
+  constraint c_iv {if (fixed_iv_en) {aes_iv == fixed_iv};}

-  constraint c_operation {
-     if (fixed_operation_en) {
-         aes_operation == fixed_operation
-     };
-  }
+  constraint c_operation {if (fixed_operation_en) {aes_operation == fixed_operation};}


@msfschaffner @fangism I think these constraints should be kept as the original formatting

Agreed, can you file a new issue?

chipsalliance/verible#445

udinator · 2020-09-10T02:18:00Z

hw/ip/aes/dv/env/aes_scoreboard.sv


-              if(input_item.data_in_valid() && input_item.key_clean(1) && input_item.iv_clean(1)) begin
+              if (input_item.data_in_valid() && input_item.key_clean(1) && input_item.iv_clean(1)
+                  ) begin


@msfschaffner @fangism I think this is another unfortunate scenario where the closing parens just exceeds line length

Unfortunate, indeed.

In the next iteration, this will be left alone.

udinator · 2020-09-10T02:19:52Z

hw/ip/aes/dv/env/aes_scoreboard.sv

-        `uvm_info(`gfn, $sformatf("\n\t ----| Finish test received adding message item to mg_fifo")
-         , UVM_MEDIUM)
+        wait(finish_message)
+          `uvm_info(`gfn,


@msfschaffner @fangism I don't think this uvm_info call should be indented

Actually, here the formatter is showing you the difference between writing:

wait(x); statement;

and

wait(x) statement;

These are syntactically different, though they may give you the same result semantically. (A language lawyer could speak to this.)

got it! this seems fine then.

udinator · 2020-09-15T23:14:06Z

hw/ip/alert_handler/dv/env/alert_handler_env.sv

-        alert_host_agent[i].monitor.alert_esc_port.connect(
-            scoreboard.alert_fifo[i].analysis_export);
+        alert_host_agent[i
+            ].monitor.alert_esc_port.connect(scoreboard.alert_fifo[i].analysis_export);


@msfschaffner @fangism this should be formatted as

alert_host_agent[i].monitor.alert_esc_port.connect( scoreboard.alert_fifo[i].analysis_export);

(I'm assuming this line exceeds the acceptable length)

agree, but the next iteration should leave this alone.

udinator · 2020-09-15T23:20:23Z

hw/ip/alert_handler/dv/env/alert_handler_scoreboard.sv

@@ -92,16 +90,18 @@ class alert_handler_scoreboard extends cip_base_scoreboard #(
            if (act_item.alert_esc_type == AlertEscSigTrans && !act_item.timeout &&
                act_item.alert_handshake_sta == AlertReceived) begin
              process_alert_sig(index, 0);
-            // alert integrity fail
+              // alert integrity fail


@fangism this is another interesting comment scenario - this comment applies to the line below, which is why it wasn't inline with the process_alert_sig(index, 0) line - so we want to keep the existing indentation

I see the intent. Without reading the comment like a human, I'm not sure it is possible for a tool to infer this.

udinator · 2020-09-15T23:21:30Z

hw/ip/alert_handler/dv/env/alert_handler_scoreboard.sv

-               (act_item.esc_handshake_sta == EscIntFail && !act_item.timeout)) begin
+            // escalation integrity fail
+          end else if (act_item.alert_esc_type == AlertEscIntFail || (
+                       act_item.esc_handshake_sta == EscIntFail && !act_item.timeout)) begin


@fangism another case where there is a strange linebreak right after an opening parenthesis

This will be left alone in the next iteration.

udinator · 2020-09-15T23:21:58Z

hw/ip/alert_handler/dv/env/alert_handler_scoreboard.sv

          // if class escalation is enabled, add alert to accumulation count
-          if (class_ctrl[AlertClassCtrlEn] &&
-              (class_ctrl[AlertClassCtrlEnE3:AlertClassCtrlEnE0] > 0)) begin
+          if (class_ctrl[AlertClassCtrlEn] && (class_ctrl[AlertClassCtrlEnE3:AlertClassCtrlEnE0] > 0


@fangism I think we should keep the existing formatting here

Agreed. This will be left untouched in next round.

udinator · 2020-09-15T23:23:00Z

hw/ip/alert_handler/dv/env/alert_handler_scoreboard.sv

-                  for (int sig_i = 0; sig_i < NUM_ESC_SIGNALS; sig_i++) begin
-                    if (class_ctrl[sig_i*2+7 -: 2] == phase_i && class_ctrl[sig_i+2]) begin
-                      enabled_sig_q.push_back(sig_i);
+          forever


@fangism I think we want the original formatting here as well

@udinator Interesting, so forever is considered merge-able with the construct it encloses. Can you file a new issue for this one?

udinator · 2020-09-15T23:24:20Z

hw/ip/alert_handler/dv/env/seq_lib/alert_handler_base_vseq.sv

@@ -108,8 +108,8 @@ class alert_handler_base_vseq extends cip_base_vseq #(
          if (esc_int_errs[index]) begin
            fork
              begin
-                esc_receiver_esc_rsp_seq esc_seq =
-                    esc_receiver_esc_rsp_seq::type_id::create("esc_seq");
+                esc_receiver_esc_rsp_seq


@fangism I think we should keep original formatting

Agreed, this will be left alone because it wraps (next iteration).

udinator · 2020-09-15T23:25:03Z

hw/ip/alert_handler/dv/env/seq_lib/alert_handler_esc_alert_accum_vseq.sv

-  constraint esc_accum_thresh_c {
-    foreach (accum_thresh[i]) {accum_thresh[i] inside {[0:100]};}
-  }
+  constraint esc_accum_thresh_c {foreach (accum_thresh[i]) {accum_thresh[i] inside {[0 : 100]};}}


@fangism I think we should keep the original formatting here as well

chipsalliance/verible#445

udinator · 2020-09-15T23:30:02Z

hw/ip/entropy_src/pre_dv/entropy_src_tb.sv

+      wr_reg({26'b0, ENTROPY_SRC_ES_SEED_OFFSET}, 32'h1111_1111);  // seed
+      wr_reg({26'b0, ENTROPY_SRC_ES_CONF_OFFSET}, 32'h0000_0001);  // primary enable
+      repeat (10) @(posedge clk);
+      wr_reg({


@fangism @msfschaffner I'm not sure that we want to split the stuff inside the brackets onto new lines here?

udinator · 2020-09-15T23:32:01Z

hw/ip/flash_ctrl/dv/env/flash_ctrl_env_pkg.sv

-    FlashMemInitSet,        // Initialize with all 1s.
-    FlashMemInitClear,      // Initialize with all 0s.
-    FlashMemInitRandomize,  // Initialize with random data.
+    FlashMemInitCustom


@fangism @msfschaffner this appears to be some strange formatting going on , I think we should keep the original formatting here

indeed, the original formatting would be preferred here.

udinator · 2020-09-22T18:09:15Z

hw/ip/alert_handler/fpv/tb/alert_handler_esc_timer_fpv.sv

-  output logic[EscCntDw-1:0] esc_cnt_o,
-  output logic[N_ESC_SEV-1:0] esc_sig_en_o,
-  output cstate_e esc_state_o
+module alert_handler_esc_timer_fpv


@cindychip how would you normally want this formatted?
@fangism

Thanks Udi for asking, I think "module_name"_fpv sounds good to me.

Thanks!
Also, what do you think about the way the import alert_pkg::* gets formatted to a newline? Is this something you want to keep, or would you rather keep the original way you formatted it all inline?

oh sorry, I did not notice that. I do not have a preference. I think either way works. Personally I would think having a new line for import is easier to read.

Okay, thanks for the input!

@udinator Can you file a new issue for this? And do you want the imports indented?

yes I'll file a bug.
Ideally we want the imports indented also.

hzeller · 2020-09-22T18:27:41Z

FYI, I created a formatting with the current v0.0-620-gb46d580 version of Verible here; some of the issues from last time have been fixed, and in particular pre-alignment heuristics have been improved.

hzeller@e28c2f6

udinator · 2020-09-22T18:31:31Z

hw/ip/entropy_src/pre_dv/entropy_src_tb.sv

+  initial  // clock generation
+      begin
+    clk = 0;
+    forever begin
+      #4ns clk = !clk;
    end
+  end


@fangism seems like the begin keyword got an extra indent while the contents inside got left-indented.

@udinator Can you file a new issue for this?

(Same as earlier)

udinator · 2020-09-22T18:32:06Z

hw/ip/entropy_src/pre_dv/entropy_src_tb.sv

-      rst_n = 1;
-    end
+  initial  // reset generation
+      begin


@fangism, I think this is similar to above, the begin keyword is getting indented again for some reason.

Same indeed.

udinator · 2020-09-22T18:33:35Z

hw/ip/gpio/dv/env/gpio_env_cov.sv

+      illegal_bins data_oe_1_data_out_0_data_in_1 = binsof (data_out) intersect {
+        0
+      } && binsof (data_oe) intersect {


@fangism another case of brackets getting spread out over three lines, but this time inside of covergroups.

@udinator Can you file a new issue?

msfschaffner force-pushed the format-experiment branch 2 times, most recently from bfce4ae to 6795667 Compare August 11, 2020 20:27

msfschaffner added 3 commits August 11, 2020 13:30

[verible] Update experimental formatter script

3c5c78e

Signed-off-by: Michael Schaffner <[email protected]>

Experimental formatter pass

207038c

Add formatting report

2bf9354

msfschaffner force-pushed the format-experiment branch from 6795667 to 2bf9354 Compare August 11, 2020 20:31

msfschaffner commented Sep 8, 2020

View reviewed changes

hw/ip/alert_handler/rtl/alert_handler_ping_timer.sv Show resolved Hide resolved

msfschaffner commented Sep 8, 2020

View reviewed changes

udinator reviewed Sep 10, 2020

View reviewed changes

udinator reviewed Sep 15, 2020

View reviewed changes

udinator reviewed Sep 22, 2020

View reviewed changes

hzeller mentioned this pull request Apr 6, 2021

Format OpenTitan codebase with Verible SystemVerilog code formatter chipsalliance/verible#748

Open

msfschaffner closed this Aug 19, 2021

msfschaffner deleted the format-experiment branch February 18, 2022 00:23

		@@ -5,22 +5,12 @@
		module entropy_src_bind;

		bind entropy_src tlul_assert #(

		input bit [5:0] mode_i, // 6'b00_0001 = ECB, 6'00_b0010 = CBC, 6'b00_0100 = CFB,
		// 6'b00_1000 = OFB, 6'b01_0000 = CTR, 6'b10_0000 = NONE

Verible Format experiment #7

Verible Format experiment #7

Conversation

msfschaffner commented Aug 11, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

udinator Sep 15, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

udinator Sep 15, 2020 •

edited

Loading