-
-
Notifications
You must be signed in to change notification settings - Fork 304
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFE: Reduce unnecessary intermediate signals assignments #132
Comments
Note: I now see that I already filed issue #125 about this. :-) However, I think this issue is about more than just the VexRiscv. For me personally, it's one of the biggest reasons that is hold me back to fully commit to SpinalHDL for my personal projects. In isuse #125, I was also primarily talking about registers ( For example:
Straight up assignments like If you really go the distance, then even _zz_101, could be optimized away like this: Old:
New:
You could use a heuristic that takes into account the fanout of _zz_101 to decide whether or not to optimize it away. (Or does it already do that?) Tom |
sure _zz_105 could be simplified automaticaly I will add this to my todo list.
it is because of Delay(haltRequest, 5, init=False) which currently anomusly create stages. So it isn't a SpinalHDL compiler issue, but just a library improvment. There is already the feature to manualy make this possible in a clash safe way. xx.setCompositeName(nameable: Nameable, postfix: String)
So to resume, in general i choosed safe approach to generate the VHDL/Verilog, as the generated file are only netlist which normaly doesn't need to be human checked. Then when you are learning the language and want to check things, i understand it make sense to check it out. Also it could reduce the post synthesis naming transformation :) So wooooooooork on the stack. Thanks for your previous feedback ^^ |
I just commited in fix in the dev branch for 3) and 1) new Component {
val input = in Bool()
val output = out Bool()
val readableOutput = out Bool()
output := RegNext(Delay(RegNext(input),4))
val yolo = RegNext(input)
readableOutput := True
val miaou = Bool
miaou := readableOutput
} will give
|
It's extremely common in Verilog to read back an output signal. A tool that doesn't support it would essentially be useless.
Thanks a lot for considering all this! I'm convinced that it will lower the barrier of entry for people who are considering SpinalHDL. I wish I could be more helpful with the implementation, but I'm still too green about Scala to figure this out. :-) (I couldn't even find the place in the code where to added the trailing "_" ...) Tom |
In a traditional Verilog flow, you need to look at the source code to figure out which signals to display on the waveform viewer. You comment above makes me wonder if you do things differently when debugging SpinalHDL? At the end of the day, you're going to be looking at waves just the same, right? Am I overlooking some debugging technique? Tom |
So my debuging technique is, running the sim, looking the wave, then checking the SpinalHDL code acordingly. I'm never watching the generated VHDL/Verilog, unless i'm realy doing some "meta hardware description" which had gone wrong. So debuging SpinalHDL is like debuging Verilog, you just look the wave and the source code, which is SpinalHDL then ^^ |
Fixed the literal stuff in 9902346 |
It's inevitable that the generated code will still have anonymous signals, and some of this is more a matter of heuristics, but it's much better than what it used to be. A bunch intermediate signals are because you split combinatorial and sequential processes. This is consequence of issue #94 (which I strongly disagree with, but that's a different issue.) Tom |
This is probably a very fundamental request, but I'm going to propose it any way.
Right now, SpinalHDL creates tons of intermediate zz* signals that are not strictly required and that make debugging a whole lot more difficult than necessary.
Here's a typical example:
Except for their declaration, these are the only places where _zz_178 and _zz_179 are used.
The problem, of course, is that one has to page through the code to understand the last 'if' statement is really nothing more than:
and that the whole code can be rewritten like this:
Not all signasl can obviously be reduced that easily (see _zz_110), but I'll take whatever I can get as long as it reduced the zz soup.
However, speaking about _zz_110, there's this:
The trivial renaming step would result in _zz_105 being eliminated completely:
And a slightly smarter renaming post-processing step could do the following (assuming there won't be a name clash) :
I don't understand the SpinalHDL framework well enough to know if this kind of deriving of names is at all possible (e.g. as a post-processing step), but it would make it so much easier to debug.
Right now, making a single change will make all the zz signals in a .gtkw file useless.
Tom
The text was updated successfully, but these errors were encountered: