Mismatch in post-PnR sim and chip operation

[tarik-ibrahimovic]

uart_tx changes with a change in declared IO ports of the module

In this design, when declaring logic tick_02us in the 1.hw/top.sv as an IO port everything functions correctly (tick_02us is not intended to be real IO, but in cases was used as means to debug).

However, if removed as an IO port, and left just as an internal signal, the uart_tx starts misbehaving. Also, the output duplicate of uart_tx,sent, becomes incorrect. This isn't present in post-PnR sim which seems fine. Important note: When tick_02us is mapped to a location like "IO_NB_A0" it still misbehaves, but if mapped to "IO_NB_A2" like in the repo the design works just fine.

Steps to recreate the issue

These instructions are for the Olimex board:

1. First, run the design as is, following the steps presented in the repo folder
2. At this point everything should seem fine, written data should be the same as read data
3. Comment or delete the tick_02us from 1.hw/top.sv and uncomment the declaration left below logic tick_02us
4. Comment or delete the tick_02us port from 1.hw/constraints/constraints.ccf
5. Remove the tick_02us port from 2.sim/tb.sv to run the simulations correctly
6. Verify that RTL sim matches post-PnR sim by running make then make all_impl
7. See that the board isn't running the design correctly by invoking the python 4.testing/pyauto.py script which communicates via Serial
8. Get an oscilloscope and tie it to the IO_NB_A1 pin and notice that sent which is a duplicate of uart_tx is also incorrect and doesn't match post-PnR sim.

[chili-chips-ba]

@pu-cc , is there anything you still need from Tarik to address this problem?

[chili-chips-ba]

@pu-cc is the plan to get us this fix in the upcoming tool update?

[tarik-hamedovic]

I was having problems running the PSRAM example on my Olimex board even though @tarik-ibrahimovic had no problems with the exact same code. When running the pyauto.py script in 4.testing folder I get an ERROR that says that what is written doesn't match what is read or sometimes nothing is happening after establishing a succesfull connection to /dev/ttyACM0.

After flipping the send and tick_02us pins in the constraint file from:

Pin_out      "sent"            Loc = "IO_NB_A1";
Pin_out      "tick_02us"       Loc = "IO_NB_A2";

To:

Pin_out      "sent"            Loc = "IO_NB_A2";
Pin_out      "tick_02us"       Loc = "IO_NB_A1";

While, thanks to this random change that I cannot see an engineering explanation for, the PSRAM example now works as designed, the main issue is still there. Moreover, it now begs a question in even louder voice:

• Why does GateMate exhibit these undue dependencies on unrelated pins?

What is going under the hood, at both silicon and tool level, that is causing these bizarre behaviors?

[pu-cc]

Changing a pin can very well lead to a differently placed and routed design. If this has to an error, we have to investigate exactly what the cause is - it is not possible to make a general statement as we are looking at a different design.

Does the error still exist if the pins are used again with the original mapping? That is not clear to me at the moment. There have been some updates in P&R since September.

[chili-chips-ba]

@tarik-ibrahimovic when you find time, please try with the latest tool. If the problem is fixed, close this issue.