Why do port output operations block?

[dfe]

I am trying to get my Wi-Fi slice to work on my sliceKIT. The sample code eventually executes

spi_tiwisl_ctrl.p_cs_pwr <: 0x03;

to fire up the power to the module. This blocks; the corresponding instruction

out (r2r) res[r3], r11 *
 
seems to never return. (Yes, r3 seems reasonable and r11 contains 3.)
 
Whilst obviously it's possible that my Wi-Fi slice is broken, what can cause this sort of blocking? A previous "out" to the port, of 0x01, works as expected.
 
Thanks!

[richard]

Every port is associated with a clock block resource that provides a clock to that port. The first time you output on a port it queues the output value to be driven on the next falling edge of the clock. If you output to the port a second time and there hasn't been a falling clock edge, the second output instruction blocks utill the previous output value has been driven. If the clock associated with the port is not running, there will never be a falling clock edge and the second output will hang forever.

When you declare a port it is associated with a running clock block that runs at 100MHz. In this initial state, outputs never hang. However if the code configures the port to run off a different clock block (e.g. with the configure_*_port functions defined in xs1.h), then it is possible for outputs to hang. If you have a hanging output I would check:

• What clock block is the port configured to use?
• Has the clock block been started using the start_clock() function?
• Is the clock block configured to use a 1 bit port as a source? If so is a suitable external clock signal being provided on that pin?
• Is the port configured to use ready in signals? If so is the ready in signal high?

[srinie]

Tried to run your sample program  both on sim and on L16 sliceKIT - both were able to execute corretly.

 

Setting to 0x01
Setting to 0x01
Setting to 0x03
Done

...

Looks strange on why it did not run as expected at your end!

Can you check on simulator once?

[infiniteimprobability]

I haven't looked at the detail of the wifi module interface code, but I wonder if this is related to the fact that clocked ports use the actual port clock pin output level rather than an internal version. For example, if port a is clocked from port b, if port b is stuck-at a level, then port a will not see it's clock and cause blocking on port a output instructions..

[dfe]

After months I am back at this. Consider the following:

Code: Select all

#include <platform.h>
#include <xs1.h>
#include <print.h>

on tile[0]: out port p = XS1_PORT_4E;
on tile[0]: clock clk = XS1_CLKBLK_1;

int main(void) {
	configure_clock_rate(clk, 100, 8);
	configure_out_port(p, clk, 3);
	start_clock(clk);

	printstr("Setting to 0x03\n");
	p <: 0x03;
	printstr("Done\n");

	return 0;
}

The XA-SK-WIFI-TIWISL is in the triangle slot of a sliceKIT L16, so power and CS should be on port 4E.

The call to configure_out_port() never returns if the final argument is 3 (i.e., turning on the WiFi module). Values of 0 or 1 let the programme progress to sending output to port p, which does not return.

I'm very unclear what is going on!

[mon2]

We recall testing this WIFI slice board with our SliceKit and it worked just fine.

Are you following this posted code and related documentation ?

https://www.xmos.com/published/tiwi-sl- ... 1.1.1rc0.a