Automatic naming of signals in HAL
- Finngineering
- Offline
- Senior Member
-
Less
More
- Posts: 46
- Thank you received: 31
23 Feb 2025 10:30 #322354
by Finngineering
Automatic naming of signals in HAL was created by Finngineering
This is for discussion about a potential feature which would automatically name/identify signals in HAL. Right now, a signal name always have to be given with the net command. But I see no technical reason why that is the case. New signal names could be generated automatically if none is given. And if trying to connect to a pin which already have a signal connected, that could simply be detected and linked to the already existing signal.
Right now I am using some code like:
I see very little additional value in the signal names geartrain_reverse_OR_stage1-3. It only clutters the "logic". And this clutter gets only worse the more complicated the logic is. Even the gearbox_search_slow provides little value. Instead, it could be like this:At least to my brain, the logic function is in this case easier to read. The net command could the automatically generate signal names where they are not provieded. For instance net_0001, net_0002, net_0003, net_0004 or similar. And if I want to use for instance geartrain.stage2.search_reverse for something else, the "net geartrain.stage2.search_reverse => hm2_7i95.0.7i84.0.0.output-03" command could automatically identify that the signal connected to the pin is named "net_0002" and just add to that same signal.
Similarly, if I want to for instance turn on a light when the spindle should be running, I could simply do "net spindle.0.on => hm2_7i95.0.7i84.0.0.output-01" instead of having to figure out where a signal was first connected to "spindle.0.on" and then use that signal name.
What are other peoples thoughts on this? I do think that giving meaningful names to signals is general good practice. But why force it in cases where "anonymous" signals would make more sense?
Right now I am using some code like:
loadrt logic names=geartrain_slow_OR personality=0x203
addf geartrain_slow_OR servo-thread
net geartrain_reverse_OR_stage1 <= geartrain.stage1.search_reverse => geartrain_reverse_OR.in-00
net geartrain_reverse_OR_stage2 <= geartrain.stage2.search_reverse => geartrain_reverse_OR.in-01
net geartrain_reverse_OR_stage3 <= geartrain.stage3.search_reverse => geartrain_reverse_OR.in-02
net gearbox_search_slow => hm2_7i95.0.7i84.0.0.output-10 <= geartrain_slow_OR.orI see very little additional value in the signal names geartrain_reverse_OR_stage1-3. It only clutters the "logic". And this clutter gets only worse the more complicated the logic is. Even the gearbox_search_slow provides little value. Instead, it could be like this:
loadrt logic names=geartrain_slow_OR personality=0x203
addf geartrain_slow_OR servo-thread
net geartrain.stage1.search_reverse => geartrain_reverse_OR.in-00
net geartrain.stage2.search_reverse => geartrain_reverse_OR.in-01
net geartrain.stage3.search_reverse => geartrain_reverse_OR.in-02
net geartrain_slow_OR.or => hm2_7i95.0.7i84.0.0.output-10Similarly, if I want to for instance turn on a light when the spindle should be running, I could simply do "net spindle.0.on => hm2_7i95.0.7i84.0.0.output-01" instead of having to figure out where a signal was first connected to "spindle.0.on" and then use that signal name.
What are other peoples thoughts on this? I do think that giving meaningful names to signals is general good practice. But why force it in cases where "anonymous" signals would make more sense?
The following user(s) said Thank You: TangentAudio
Please Log in or Create an account to join the conversation.
- PCW
-
- Offline
- Moderator
-
Less
More
- Posts: 18388
- Thank you received: 5020
23 Feb 2025 15:17 - 23 Feb 2025 15:18 #322368
by PCW
Replied by PCW on topic Automatic naming of signals in HAL
Yes, I think its a good idea and something I have suggested a while ago.
Especially for multi-stage logic, simply connecting pin to pin makes more
sense.
Especially for multi-stage logic, simply connecting pin to pin makes more
sense.
Last edit: 23 Feb 2025 15:18 by PCW.
The following user(s) said Thank You: TangentAudio
Please Log in or Create an account to join the conversation.
- Finngineering
- Offline
- Senior Member
-
Less
More
- Posts: 46
- Thank you received: 31
25 Feb 2025 08:27 #322565
by Finngineering
Replied by Finngineering on topic Automatic naming of signals in HAL
Okay, good that somebody else feels the same.
I realize the first post was rather long. The TL;DR is: why not have the HAL net command give signal names automatically in case no net name is specified. And if multiple connections is done to the same pin, simply link the following ones to the signal that is already there, without having to explicitly specify its name.
I realize the first post was rather long. The TL;DR is: why not have the HAL net command give signal names automatically in case no net name is specified. And if multiple connections is done to the same pin, simply link the following ones to the signal that is already there, without having to explicitly specify its name.
Please Log in or Create an account to join the conversation.
- dm17ry
-
- Offline
- Elite Member
-
Less
More
- Posts: 184
- Thank you received: 69
25 Feb 2025 10:28 - 26 Feb 2025 06:55 #322572
by dm17ry
Replied by dm17ry on topic Automatic naming of signals in HAL
i was suggesting that you can easily do it in TCL youself, but apparently there's no command which would return a net name a pin connected to. only "show pin" which prints to stdout. and it's a bit complicated to capture it into a variable...
anyways, the following show work:
anyways, the following show work:
proc redirect_variable {varname cmd} {
rename puts ::tcl::orig::puts
global __puts_redirect
set __puts_redirect {}
proc puts args {
global __puts_redirect
set __puts_redirect [concat $__puts_redirect [lindex $args end]]
}
uplevel $cmd
upvar $varname destination
set destination $__puts_redirect
unset __puts_redirect
rename puts {}
rename ::tcl::orig::puts puts
}
set netno 1
proc anet {args} {
redirect_variable res {show pin {*}$args}
if [regexp {[<=]=[=>]\s+(\w+)} $res match net] {
net $net {*}$args
} else {
net net_$::netno {*}$args
incr ::netno
}
}
loadrt logic names=geartrain_slow_OR personality=0x203
addf geartrain_slow_OR servo-thread
anet geartrain.stage1.search_reverse => geartrain_reverse_OR.in-00
anet geartrain.stage2.search_reverse => geartrain_reverse_OR.in-01
net named_net geartrain.stage3.search_reverse
anet geartrain.stage3.search_reverse => geartrain_reverse_OR.in-02
anet geartrain.stage3.search_reverse => geartrain_reverse_OR.in-02
anet geartrain_slow_OR.or => hm2_7i95.0.7i84.0.0.output-10
but debugging HAL files won't be easy...
Last edit: 26 Feb 2025 06:55 by dm17ry.
Please Log in or Create an account to join the conversation.
- Finngineering
- Offline
- Senior Member
-
Less
More
- Posts: 46
- Thank you received: 31
25 Feb 2025 21:11 #322632
by Finngineering
Replied by Finngineering on topic Automatic naming of signals in HAL
That's really interesting. I had no idea hal "scripts" are actually Tcl. Thank you for the neta function. I did just quickly test it out and indeed it appears to work.
Why do you say that debugging hal files would be difficult? From where I'm standing, debugging usually starts by checking why one input (or output) is not what its expected to be. The following step is to check what is connected to that input. To do that we can use the "show sig" command, which will then display all pins connected together. So I already see which (other) pin is driving that signal, and the name of the signal has little significance.
Is there some normal use case I'm not thinking about? I'm not saying that named nets are bad, I'm just questioning why there is no inbuilt automatic naming of nets. Is it just that nobody has done it, or is there some more fundamental argument against (supporting) automatic naming of nets?
Why do you say that debugging hal files would be difficult? From where I'm standing, debugging usually starts by checking why one input (or output) is not what its expected to be. The following step is to check what is connected to that input. To do that we can use the "show sig" command, which will then display all pins connected together. So I already see which (other) pin is driving that signal, and the name of the signal has little significance.
Is there some normal use case I'm not thinking about? I'm not saying that named nets are bad, I'm just questioning why there is no inbuilt automatic naming of nets. Is it just that nobody has done it, or is there some more fundamental argument against (supporting) automatic naming of nets?
Please Log in or Create an account to join the conversation.
Time to create page: 0.095 seconds