You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feature request: reverse engineer main.v Code generated by Icestudio so that I can see which vXXXXXX or wYYYYYY block or wire offends timing rules
#577
Open
SiccoDwars opened this issue
Jan 5, 2022
· 2 comments
Here's my problem: a relatively large Icestudio project is at a point where adding any more registers makes it fail with a "ERROR: Max frequency for clock 'w65': 11.84 MHz (FAIL at 12.00 MHz)". So something somewhere is my design is hitting a speed bump. But finding out which wire, which block, what signal path is actually at the root cause - that is where I struggle.
It's not that I have run out of LC's or other resources - there's still >>25% left. But the addition of anything anywhere makes it harder for the pnr tool apparently.
In my ideal world, the offending wires / blocks would show up in red. I think I'm asking too much now...
In an already better world, I would see in Icestudio what names were given to my wires or blocks when I hover my mouse over them.
Or I'd have a tool that translates wXX, vYYYYY into nickname attributes that I'd have given to my Icestudio blocks just so that I can tell which is what.
Now I need to sort of guess that 'w65' is my clk wire and that say 'vbc4b1a.vc8ac2c.w13_$glb_clk' is a verilog code block inside some deeper module etc. But which block where in my project are those?? How can I tell?
Two Icestudio projects attached, #23 works, in #24 I added almost nothing, but it fails the build. Because of something somewhere. But how can I find the part that's making it just miss the timing criteria? Which block where?? DDCS_TEST_23.zip DDCS_TEST_24.zip
The text was updated successfully, but these errors were encountered:
I quickly tested your circuit and on my machine even the number 23 fails with w65 clk error !
A good tool to help debugging will be a useful feature!,
And as you explained, the display of the vcb4f6d names when passing the mouse over the lines could be a good starting point
But maybe not easy to implement
Maybe even more difficult to implement is:
When a build fails a new windows open with the build informations (copied from the command output)
and a piece of code can detect all the nets ( 'v' followed by 6 character letter/numbers only) & 'w' followed by two numbers ) and present them on the new window as clickable (or mouseover reaction)
For the detection, If needed we can also use the information from the main.v file ( generated in the ice-build folder when we launch a build)
this file contains the same info as the verilog file generated with File/Export.../verilog.
So, these time when we pass the mouse over a 'w65' or 'vcb4f6d' text in that new "build info" windows, it highlights the corresponding net in the icestudio workspace or highlights the the block containing the net.
Hi team, yes that’s exactly what I am looking (and hoping) for.
The #23 build failure may be due to me not consistently saving the .ice project file prior to a build. (i’d have favored an auto-save function each time i press verify/build/upload - most C or java compilers that i use do this, Icestudio not doing that is a nuisance for me).
On Jan 6, 2022, at 9:45 AM, jojo535275 ***@***.***> wrote:
Hi SiccoDwars,
I quickly tested your circuit and on my machine even the number 23 fails with w65 clk error !
A good tool to help debugging will be a useful feature!,
And as you explained, the display of the vcb4f6d names when passing the mouse over the lines could be a good starting point
But maybe not easy to implement
Maybe even more difficult to implement is:
When a build fails a new windows open with the build informations (copied from the command output)
and a piece of code can detect all the nets ( 'v' followed by 6 character letter/numbers only) & 'w' followed by two numbers ) and present them on the new window as clickable (or mouseover reaction)
For the detection, If needed we can also use the information from the main.v file ( generated in the ice-build folder when we launch a build)
this file contains the same info as the verilog file generated with File/Export.../verilog.
So, these time when we pass the mouse over a 'w65' or 'vcb4f6d' text in that new "build info" windows, it highlights the corresponding net in the icestudio workspace or highlights the the block containing the net.
Ideas to be precised ...!
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you authored the thread.
Here's my problem: a relatively large Icestudio project is at a point where adding any more registers makes it fail with a "ERROR: Max frequency for clock 'w65': 11.84 MHz (FAIL at 12.00 MHz)". So something somewhere is my design is hitting a speed bump. But finding out which wire, which block, what signal path is actually at the root cause - that is where I struggle.
It's not that I have run out of LC's or other resources - there's still >>25% left. But the addition of anything anywhere makes it harder for the pnr tool apparently.
In my ideal world, the offending wires / blocks would show up in red. I think I'm asking too much now...
In an already better world, I would see in Icestudio what names were given to my wires or blocks when I hover my mouse over them.
Or I'd have a tool that translates wXX, vYYYYY into nickname attributes that I'd have given to my Icestudio blocks just so that I can tell which is what.
Now I need to sort of guess that 'w65' is my clk wire and that say 'vbc4b1a.vc8ac2c.w13_$glb_clk' is a verilog code block inside some deeper module etc. But which block where in my project are those?? How can I tell?
Two Icestudio projects attached, #23 works, in #24 I added almost nothing, but it fails the build. Because of something somewhere. But how can I find the part that's making it just miss the timing criteria? Which block where??
DDCS_TEST_23.zip
DDCS_TEST_24.zip
The text was updated successfully, but these errors were encountered: