Allocating Clock Blocks

[Treczoks]

Hi!

Todays Topic (for me, at least) is "clock blocks".
If I define an IO port it is ok to write things like "on stdcore[0]: port FOO = XS1_PORT_4E;", because I have to layout this anyway, and need it to be at a fixed location.
But why do I have to pre-allocate clock blocks in the same, static way: "on stdcore[0]: clock = XS1_CLKBLK_2;"?
Or did I just totally miss the functions to allocate this kind of resource dynamically?

Most of my IO structures need a bunch of ports and at least a clock block. When I moved a slice to another port on the other tile, I could keep the IO ports (I just had to change the "on stdcore" stuff), but I stepped on another software modules toe by using its clock block. A dynamic allocation scheme which is already available for channels and timers would be nice for clock blocks, too, so I could fill ot the clock block parameter of my port structure and then link everything.

And additional interesting function would be a way to "ask" a port about associated clock blocks ("this port drives", "this port is driven by"), which would ease ways to cleaner and more structured programming.

Yours, Christian Treczoks

[segher]

If I define an IO port it is ok to write things like "on stdcore[0]: port FOO = XS1_PORT_4E;", because I have to layout this anyway, and need it to be at a fixed location.
But why do I have to pre-allocate clock blocks in the same, static way: "on stdcore[0]: clock = XS1_CLKBLK_2;"?
Or did I just totally miss the functions to allocate this kind of resource dynamically?

The ports use the clocks directly, in hardware. If you could allocate
and deallocate clocks dynamically the chip really should check if
anything is still using the clock. That isn't very feasible.

Most of my IO structures need a bunch of ports and at least a clock block. When I moved a slice to another port on the other tile, I could keep the IO ports (I just had to change the "on stdcore" stuff), but I stepped on another software modules toe by using its clock block. A dynamic allocation scheme which is already available for channels and timers would be nice for clock blocks, too, so I could fill ot the clock block parameter of my port structure and then link everything.

You can do a #define for it, so you only have to change it in one place.
It would be nice if you could do that in the XN file.

And additional interesting function would be a way to "ask" a port about associated clock blocks ("this port drives", "this port is driven by"), which would ease ways to cleaner and more structured programming.

Read PS reg id + 0x60; for a port, it gives you the id of the clock block
it uses; for a clock block, it gives you the id of the port it is driven by
(or 1, for the system clock).

[Treczoks]

Thanks fro replying, Segher!

The ports use the clocks directly, in hardware. If you could allocate and deallocate clocks dynamically the chip really should check if anything is still using the clock. That isn't very feasible.

No need for de-allocation. Just a nice way to get an unused clock block without the need to keep an extra paper trace. Once it is put to use with a port, nobody is going to return it.

You can do a #define for it, so you only have to change it in one place. It would be nice if you could do that in the XN file.

Yep. Thats one of the things that should be done, maybe even with an easy tool that actually knows about ports (i.e. warns on double allocation or from selecting a port from the wrong tile when setting up a group of ports)

Read PS reg id + 0x60; for a port, it gives you the id of the clock block it uses; for a clock block, it gives you the id of the port it is driven by (or 1, for the system clock).

I am well aware that the answer to my question is computable, but that is exactly what a debugger should be able to do.

At the moment, I do most of my debugging with an oscilloscope as the debug environment of the xTimeStudio is a nightmare - for real (and especially realtime) embedded debugging, eclipse and gdb is a pain in the ***. Sorry to be that harsh, but thats it.