02:57 <mithro> litghost: Just FYI, GitHub actions has significantly longer timeouts than Travis

02:57 <mithro> The default is 360 minutes, but it can be extended to be much longer by using https://docs.github.com/en/free-pro-team@latest/actions/reference/workflow-syntax-for-github-actions#jobsjob_idtimeout-minutes

02:57 <mithro> * Job execution time - Each job in a workflow can run for up to 6 hours of execution time. If a job reaches this limit, the job is terminated and fails to complete.

02:57 <mithro> * Workflow run time - Each workflow run is limited to 72 hours. If a workflow run reaches this limit, the workflow run is cancelled.

02:57 <tpb> Title: Workflow syntax for GitHub Actions - GitHub Docs (at docs.github.com)

02:58 <mithro> kgugala: BTW What is the status of setting up self-hosted runnings for GitHub actions?

08:32 <sf-slack> <kgugala> mithro: we have the initial stuff running there are some issues with artifacts permissions - working on that

11:04 <powie> Hey, I have a question about project xray, at its current state is it able to read the contents of blockrams from a bitstream ?

14:37 <sf-slack> <mholenko> @timo.callahan Do you mean https://github.com/renode/renode-infrastructure/blob/master/src/Emulator/Main/Peripherals/CPU/RegisterValue.cs#L13? `RegisterValue` is a generic class that we use for both 32- and 64-bit CPUs so `RawValue` is expressed as an unsigned 64-bit integer, but there is an additional `Bits` property that allows you to check how many of them are actually important; if the particular register stores a

14:37 <sf-slack> signed value you should cast it manually

15:03 <promach3> Why broken pipe when using boolector ?

16:29 <litghost> powie: Yes and no. There is a specific bug that means that BRAM's in the right most column of the FPGA have their upper bits stripped off, see https://github.com/SymbiFlow/prjxray/issues/1285 and a potential fix in https://github.com/SymbiFlow/prjxray/pull/1335

16:30 <litghost> powie: Otherwise, we expect BRAM init read/write to work as expected

19:12 <sf-slack> <syed.ahmed.emails> Hi all, does anyone know a bit about the `router_lookahead_extended_map.cpp` code? I am running into the following error and would love some guidance on where to look at for debugging: ```/media/lilbirb/research/code/pld/third_party/vtr-verilog-to-routing/vpr/src/route/router_lookahead_extended_map.cpp:143 get_src_opin_cost: Assertion 'std::isfinite(expected_delay_cost) && std::isfinite(expected_cong_cost)'

19:12 <sf-slack> failed. make: [Makefile:141: output_fun/out.route] Error 134 (ignored)``` This assertion is failing for me. I printed out the intermediate values and looks like the assertion fails because of infinite values returned from `router_lookahead_cost_map.cpp` (line 112): ```Warning 11139: delta_x: 0.000000 Warning 11140: delta_y: 0.000000 Warning 11141: params.criticality: 1.000000 Warning 11142: reachable_wire_inf.delay: 0.000000

19:12 <sf-slack> Warning 11143: cost_entry.delay: inf Warning 11144: reachable_wire_inf.congestion: 0.000000 Warning 11145: cost_entry.congestion: inf Warning 11146: this_delay_cost: -nan Warning 11147: this_cong_cost: inf Warning 11148: expected_delay_cost: inf Warning 11149: expected_cong_cost: inf Warning 11150: expected_delay_cost: inf Warning 11151: expected_cong_cost: inf```

19:15 <litghost> Context?

19:18 <sf-slack> <syed.ahmed.emails> Sorry! This is on a200t, where we are trying to implement some logic on a partial reconfiguration region (@butta’s work).

19:18 <sf-slack> <syed.ahmed.emails> placement passes

19:19 <litghost> I'd expect one of the segments no longer makes sense?

19:19 <litghost> How small of a region did you slice?

19:19 <litghost> Also did you regenerate the lookahead on your subgraph?

19:21 <sf-slack> <syed.ahmed.emails> The region is almost a square shaped and has 6400 luts.

19:23 <sf-slack> <syed.ahmed.emails> What do you mean by regenerating the lookahead? We have been using the lookahead.bin generated when we call the make command on a device definition: e.g. ```make file_xc_xc7_archs_artix7_200t_devices_rr_graph_xc7a200t-${DEVICE_NAME}_test.rr_graph.real.bin```

19:24 <sf-slack> <syed.ahmed.emails> also thanks for your response!

19:26 <litghost> So the "this_delay_cost: -nan" is definitely a problem

19:32 <sf-slack> <syed.ahmed.emails> `float this_delay_cost = (1. - params.criticality) * (reachable_wire_inf.delay + cost_entry.delay);` yeah not sure how the -nan is coming. Based on the values 0 * inf == -nan?

22:17 <sf-slack> <naachhilfe> Hello, I have been following the project for a few days now and would like to do my bit. I am interested in reverse engineering the bitstream formats for the machxo2 fpgas. That way the project can support projects like TinyFPGA. How and where do I start? I have scripting experience in Python and have done low level C coding. I speak hex and binary fluently. Please let me know if I can be of any help.

22:29 <tnt> I think cr1901_modern is/was working on that