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
Allocating Clock Blocks
-
- Active Member
- Posts: 38
- Joined: Thu Mar 21, 2013 11:18 am
-
- XCore Expert
- Posts: 844
- Joined: Sun Jul 11, 2010 1:31 am
The ports use the clocks directly, in hardware. If you could allocateTreczoks wrote: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?
and deallocate clocks dynamically the chip really should check if
anything is still using the clock. That isn't very feasible.
You can do a #define for it, so you only have to change it in one place.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.
It would be nice if you could do that in the XN file.
Read PS reg id + 0x60; for a port, it gives you the id of the clock blockAnd 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.
it uses; for a clock block, it gives you the id of the port it is driven by
(or 1, for the system clock).
-
- Active Member
- Posts: 38
- Joined: Thu Mar 21, 2013 11:18 am
Thanks fro replying, Segher!
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.
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.segher wrote: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.
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)segher wrote: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.
I am well aware that the answer to my question is computable, but that is exactly what a debugger should be able to do.segher wrote: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).
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.