30 percent and up to 70 percent reduction in compile times
Every release seems to include similar claims ?
I see they also claim small changes are handled faster again
With Quartus II software v13.1, you will experience an average of 30% reduction in compile time and an additional average of 50 percent reduction for small design changes, enabling quicker design turns and faster time to market.
That is a standard claim for the major release, which just gets used, until the next major release. Nobody wants to talk about the .000x percent improvements, or regressions in a point release, so mostly they don't.
I see they also claim small changes are handled faster again
With Quartus II software v13.1, you will experience an average of 30% reduction in compile time and an additional average of 50 percent reduction for small design changes, enabling quicker design turns and faster time to market.
It's taken hours to download everything, but now it's installed and I just ran it. It compiled 7% faster. Same bug, though.
Chip,
Just a thought - SEL or SELX isn't a reserved or predefined name in Quartus?? Occasionally I have been caught by naming something that conflicts, giving incorrect results.
Chip,
Just a thought - SEL or SELX isn't a reserved or predefined name in Quartus?? Occasionally I have been caught by naming something that conflicts, giving incorrect results.
Good idea. Well, Quartus doesn't seem to color-code code the word, so it seems like a valid variable name. I might get more desperate and try a different name, but I think that's not it.
Well, I made 16 flops that I could index in the GENERATE and, still, the same bug. This makes no sense, at all. Some combinatorial logic function is mixing adjacent bits.
Now I'm trying a discrete approach: {sel[(7+i)%8], sel[(6+i)%8], sel[(5+i)%8], sel[(4+i)%8], sel[(3+i)%8], sel[(2+i)%8], sel[(1+i)%8], sel[(0+i)%8]}
In Verilog, % is a modulus operator. This should handle the wrapping okay. We'll see if it works. 15 more minutes to go...
That last compile exhibits the same bug. It's like it took the separate GENERATE blocks and OR'd the "sel" signals together, which were offset between them. I should try compiling three cogs and see if I get 3x pulses. I would really like to get to the bottom of this and have some confidence that things make sense. The thing is, this WAS working before.
That last compile exhibits the same bug. It's like it took the separate GENERATE blocks and OR'd the "sel" signals together, which were offset between them. I should try compiling three cogs and see if I get 3x pulses. I would really like to get to the bottom of this and have some confidence that things make sense. The thing is, this WAS working before.
I have tested some simple concatenations and I am not sure that the output is what it should be:
module signed_number;
reg [31:0] a;
reg [31:0] b;
reg [31:0] c;
reg [31:0] d;
reg [2:0] i;
initial begin
a = 8'b10101010;
$display ("Value of a = %b", a);
b = {2{a}};
$display ("Value of b = %b", b);
i = 3'b100;
c = {2{a+i}};
$display ("Value of c = %b", c);
i = 3'b1;
d = {2{a+i}};
$display ("Value of d = %b", d);
end
endmodule
Output:
Value of a = 00000000000000000000000010101010
Value of b = 00000000000000000000000010101010
Value of c = 00000000000000000000000010101110
Value of d = 00000000000000000000000010101011
(Changing some "reg" to "wire" give some weird warnings and errors. So maybe what Sapieha said could be in the right direction)
It is, indeed, OR'ing the "hub_sel" signals together, across different cogs. I have no idea why it is doing this. It must be something to do with GENERATE. I compiled three cogs and, sure enough, the "sel" pulses are now 3 clocks wide, instead of 2, for 2 cogs. I see what it's doing, but I don't understand why yet. This has wasted a whole day, so far.
Thanks for trying to think of what is wrong, Guys. It may be kind of futile from your end, but I appreciate your efforts.
Here is what is going on, in a nutshell:
wire [15:0] selx = {2{sel}};
genvar i;
generate
for (i = 0; i < cogs; i++)
begin : coggen
cog cog_ (hub_sel(selx[i+7:i]), etc.)
end
endgenerate
All of the different sets of hub_sel(selx[i+7:i]) signals going to the cogs are OR'd together, word-wise. Why in the world should this be happening?
It is, indeed, OR'ing the "hub_sel" signals together, across different cogs. I have no idea why it is doing this. It must be something to do with GENERATE. I compiled three cogs and, sure enough, the "sel" pulses are now 3 clocks wide, instead of 2, for 2 cogs. I see what it's doing, but I don't understand why yet. This has wasted a whole day, so far.
Thanks for trying to think of what is wrong, Guys. It may be kind of futile from your end, but I appreciate your efforts.
Here is what is going on, in a nutshell:
wire [15:0] selx = {2{sel}};
genvar i;
generate
for (i = 0; i < cogs; i++)
begin : coggen
cog cog_ (hub_sel(selx[i+7:i]), etc.)
end
endgenerate
All of the different sets of hub_sel(selx[i+7:i]) signals going to the cogs are OR'd together, word-wise. Why in the world should this be happening?
I've never used Verilog, so I may just be talking out the wrong end...
On the surface it looks like the sequence for selx values would be:
selx[7:0]
selx[8:1]
selx[9:2]
...
Just guessing that 7:0 indicates bits 7 through 0 and 8:1 indicates bits 8 through 1, that would seem to imply overlapping values.
It is, indeed, OR'ing the "hub_sel" signals together, across different cogs. I have no idea why it is doing this. It must be something to do with GENERATE. I compiled three cogs and, sure enough, the "sel" pulses are now 3 clocks wide, instead of 2, for 2 cogs. I see what it's doing, but I don't understand why yet. This has wasted a whole day, so far.
Thanks for trying to think of what is wrong, Guys. It may be kind of futile from your end, but I appreciate your efforts.
Here is what is going on, in a nutshell:
wire [15:0] selx = {2{sel}};
genvar i;
generate
[COLOR=#b22222][B]for (i = 0; i < cogs; i++)[/B][/COLOR]
begin : coggen
cog cog_ (hub_sel(selx[i+7:i]), etc.)
end
endgenerate
All of the different sets of hub_sel(selx[i+7:i]) signals going to the cogs are OR'd together, word-wise. Why in the world should this be happening?
Also, mostly because I'm curious, why do you pass the entire vector in instead of just a single control signal?
Good question, this feels like a SW/HW boundary blur issue, where Generate has a longer 'memory' than expected and so does more in SW than expected, before the HW result is output.
Things to try would be to de-complicate the params, and unroll the generate loop.
You can use
`ifdef
'endif
for different generate cases, and sidestep the minefield this way.
Each cog's hub_sel[7:0] needs to have a different wrapped offset of this pattern, with hub_sel[0] being that cog's actual hub cycle indicator. Other taps are needed, though, to do other things. It is proper that cog0 gets selx[7:0], while cog1 gets selx[8:1], etc.
Good question, this feels like a SW/HW boundary blur issue, where Generate has a longer 'memory' than expected and so does more in SW than expected, before the HW result is output.
Things to try would be to de-complicate the params, and unroll the generate loop.
You can use
`ifdef
'endif
for different generate cases, and sidestep the minefield this way.
Yes, it may come to this, but I'm loathe to do that since there are maybe 50 assignments per cog and lots of room for errors. The thing is, this WAS working up to a few days ago! It just went crazy, all of the sudden.
Yes, it may come to this, but I'm loathe to do that since there are maybe 50 assignments per cog and lots of room for errors. The thing is, this WAS working up to a few days ago! It just went crazy, all of the sudden.
Then something must have triggered it - did you change nesting levels, add more Generates, or other increase in complexity that has crossed over some 'ability to cope' threshold ?
Do you mean you have 50 places with this type of Generate ? Unroll of just this one should be relatively simple.
Then something must have triggered it - did you change nesting levels, add more Generates, or other increase in complexity that has crossed over some 'ability to cope' threshold ?
Do you mean you have 50 places with this type of Generate ? Unroll of just this one should be relatively simple.
I added another GENERATE within the cog file, I think. I will investigate. This has been such a detour that I can't even remember what I was working on, exactly.
I mean this GENERATE has only 4 iterations (or a maximum of 8 if we had a big-enough FPGA), but each cog instantiation has ~50 assignments.
Other ideas
- Change the loop variable to something that is not used anywhere else.
- Load an older project that you know is ok, and confirm it is the newest code, not the Tool Flow, or settings, or anything else, that triggers the effect.
I added another GENERATE within the cog file, I think. I will investigate. This has been such a detour that I can't even remember what I was working on, exactly.
I mean this GENERATE has only 4 iterations (or a maximum of 8 if we had a big-enough FPGA), but each cog instantiation has ~50 assignments.
By chance is the compiler memory or storage bound? Does it process intermediate files? Can you move everything and do a complete rebuild?
That sort of ceiling failure tends to be more blunt - this sounds like it is 'failing with finesse' where it is doing something intelligent, just not the intelligence in the details that Chip is wanting. More along the lines of a confusion or contamination within the tools.
I agree generally. However, it may be worth eliminating the possibility. I've seen very subtle things happen within those rough failure cases, particularly intermediate files.
Comments
Every release seems to include similar claims ?
I see they also claim small changes are handled faster again
With Quartus II software v13.1, you will experience an average of 30% reduction in compile time and an additional average of 50 percent reduction for small design changes, enabling quicker design turns and faster time to market.
Is it possible You put on forum entire snippet of code that are compilable.
So I can test it on my Quartus versions both 12.1 and 13.0
It's taken hours to download everything, but now it's installed and I just ran it. It compiled 7% faster. Same bug, though.
If I narrowed down the code, I know it wouldn't have this bug.
Just a thought - SEL or SELX isn't a reserved or predefined name in Quartus?? Occasionally I have been caught by naming something that conflicts, giving incorrect results.
Good idea. Well, Quartus doesn't seem to color-code code the word, so it seems like a valid variable name. I might get more desperate and try a different name, but I think that's not it.
In attachment are my version of RounRobin. (4 way)
Maybe that helps
Now I'm trying a discrete approach: {sel[(7+i)%8], sel[(6+i)%8], sel[(5+i)%8], sel[(4+i)%8], sel[(3+i)%8], sel[(2+i)%8], sel[(1+i)%8], sel[(0+i)%8]}
In Verilog, % is a modulus operator. This should handle the wrapping okay. We'll see if it works. 15 more minutes to go...
It is maybe PORT's conflict in code.
Sometimes I need break code in Components before faults is gone
I don't know if this helps, but there are some online verilog compilers:
http://iverilog.com/index.php
http://www.compileonline.com/compile_verilog_online.php
I have tested some simple concatenations and I am not sure that the output is what it should be:
module signed_number; reg [31:0] a; reg [31:0] b; reg [31:0] c; reg [31:0] d; reg [2:0] i; initial begin a = 8'b10101010; $display ("Value of a = %b", a); b = {2{a}}; $display ("Value of b = %b", b); i = 3'b100; c = {2{a+i}}; $display ("Value of c = %b", c); i = 3'b1; d = {2{a+i}}; $display ("Value of d = %b", d); end endmoduleOutput:
Value of a = 00000000000000000000000010101010
Value of b = 00000000000000000000000010101010
Value of c = 00000000000000000000000010101110
Value of d = 00000000000000000000000010101011
(Changing some "reg" to "wire" give some weird warnings and errors. So maybe what Sapieha said could be in the right direction)
Thanks for trying to think of what is wrong, Guys. It may be kind of futile from your end, but I appreciate your efforts.
Here is what is going on, in a nutshell:
wire [15:0] selx = {2{sel}}; genvar i; generate for (i = 0; i < cogs; i++) begin : coggen cog cog_ (hub_sel(selx[i+7:i]), etc.) end endgenerateAll of the different sets of hub_sel(selx[i+7:i]) signals going to the cogs are OR'd together, word-wise. Why in the world should this be happening?
I've never used Verilog, so I may just be talking out the wrong end...
On the surface it looks like the sequence for selx values would be:
selx[7:0]
selx[8:1]
selx[9:2]
...
Just guessing that 7:0 indicates bits 7 through 0 and 8:1 indicates bits 8 through 1, that would seem to imply overlapping values.
Is that correct?
C.W.
Line colored in code give me error.
But rewriten to
for (i = 0; i <= cogs; i = + 1) ---> give no compile error.
But it is still to little info to made module of yours code
What does the hub_sel function do?
You've got that right.
This would move the "window" to the right, thereby causing the bit to "shift" to the left.
Good question, this feels like a SW/HW boundary blur issue, where Generate has a longer 'memory' than expected and so does more in SW than expected, before the HW result is output.
Things to try would be to de-complicate the params, and unroll the generate loop.
You can use
`ifdef
'endif
for different generate cases, and sidestep the minefield this way.
In the source variable "sel", which is 8 flipflops, the pattern it cycles through is this:
00000001
00000010
00000100
00001000
00010000
00100000
01000000
10000000
<repeat>
Each cog's hub_sel[7:0] needs to have a different wrapped offset of this pattern, with hub_sel[0] being that cog's actual hub cycle indicator. Other taps are needed, though, to do other things. It is proper that cog0 gets selx[7:0], while cog1 gets selx[8:1], etc.
The hub_sel signal needs
I tried using 'i=i+1', but it didn't change anything. Thanks for doing that check, though.
Yes, it may come to this, but I'm loathe to do that since there are maybe 50 assignments per cog and lots of room for errors. The thing is, this WAS working up to a few days ago! It just went crazy, all of the sudden.
Then something must have triggered it - did you change nesting levels, add more Generates, or other increase in complexity that has crossed over some 'ability to cope' threshold ?
Do you mean you have 50 places with this type of Generate ? Unroll of just this one should be relatively simple.
I added another GENERATE within the cog file, I think. I will investigate. This has been such a detour that I can't even remember what I was working on, exactly.
I mean this GENERATE has only 4 iterations (or a maximum of 8 if we had a big-enough FPGA), but each cog instantiation has ~50 assignments.
- Change the loop variable to something that is not used anywhere else.
- Load an older project that you know is ok, and confirm it is the newest code, not the Tool Flow, or settings, or anything else, that triggers the effect.
As I said from start -- that can be PORT conflict (some Names in 2 parts become same)
That sort of ceiling failure tends to be more blunt - this sounds like it is 'failing with finesse' where it is doing something intelligent, just not the intelligence in the details that Chip is wanting. More along the lines of a confusion or contamination within the tools.