register synthesized but not utilized?

Two simple questions

- Why do you start a new thread on the topic you have previously posted

- Why don't you use straightforward constructs that can do the same test without referring to "noprune", e.g. a register chain?

@FvM:

• I started a new thread because the problem I'm facing now is different than the original problem I had posted in the other thread - perhaps that was in bad taste - but I thought it would be clearer this way.

• When you say register-chain - do you mean an instantiation of several DFF modules structurally linked together? The reason I'm doing this is quite frankly because I don't have the experience to know any better. I've just been dealing with the issues as they've been coming up. If there is an altogether easier way to do this - I'll be happy to hear it.

Thanks

I agree that the problem is different in so far that you are now using real registers and noprune is basically working.

IMHO it's closely related to the previous thread and forum members will take advantage when viewing both threads as one. But that's surely a matter of taste.

I don't know if something changes when you increase the number of registers. The gate level netlist suggests that all registers are implemented. Did you possibly forget to edit one of the related statements?

Nevertheless I would prefer a test method that enforces implementation of all involved resources. The said register chain does, it can be written as a simple iteration statement. You can connect an output pin and don't evem need a noprone statement. Inference of a RAM based SR must be disabled explicitely.

module trigger_test2(trigger, reset, clk, test) ;
input clk;
input reset;
output reg trigger;
output test;
reg  data = 6000'b0 /* synthesis altera_attribute = "-name AUTO_SHIFT_REGISTER_RECOGNITION OFF" */;
reg  counter = 16'h32; //Trigger will be set every 1000ns (1us).
wire test = data; 
integer n;
always @(posedge clk) begin
if(~reset) begin
    trigger <= 1'b0;
    //data <= 6000'b0;
    data <= 1'b0;
    counter <= 16'h32;
end 
else begin
    if(!counter) begin
        trigger <= 1'b1;    //Trigger and data will stay at these values for 20ns because they're synced with the clk.
        data <= 1'b1;
        counter <= 16'h32;
    end
    else begin
        trigger <= 1'b0;
        data <= 1'b0;
        counter <= counter - 1;
    end
   // Altera complains about iteration loops larger than 5000
    for(n = 1; n < 5000; n = n + 1)
      data <= data;
    for(n = 5000; n < 6000; n = n + 1)
      data <= data;
end
end
endmodule

P.S.: I see you have asked about SR inference in a different thread. You can apply the setting to the register, as shown in the code.

I guess I should have been more clear - the absence of the 'data' register in the RTL viewer isn't a consequence of expanding the size of the register - it is absent in either case.

In other words - whether the 'data' register is 3000 flops or 6000 flops - it doesn't show up in the RTL viewer.

When I first synthesized both versions, I saw in the Synthesis report that the appropriate % of registers had been implemented - and the resource usage also looked reasonable in the chip planner - so I went ahead and synthesized both designs - and monitored the power consumption through a dedicated jumper.

Note: I'm using the CycloneIII Dev. Kit - which has a sense-resistor attached to the J6 jumper and to the VCCINT of the FPGA core on.

I measured the voltage on this jumper with a scope (should be proportional to power) and the measurements were roughly the same (I would have expected a doubling going from 3000 to 6000).

So, I opened up the RTL viewer and noticed that the 'data' register wasn't in the schematic. That left me wondering if the resources were allocated - but not used? If that were the case, it would explain the lack of difference in power consumption - since there wouldn't be any switching activity.

Or perhaps monitoring the J6 jumper for power readings is not as straight-forward as I expected?

@FvM - Ahh, I see where you're going with that example. That is perhaps a better alternative. Although, I'm still curious as to what was happening in the last version - and also if the method in which I'm measuring power is valid.

Any insights are greatly appreciated.

--- Quote Start ---

I guess I should have been more clear - the absence of the 'data' register in the RTL viewer isn't a consequence of expanding the size of the register - it is absent in either case.

In other words - whether the 'data' register is 3000 flops or 6000 flops - it doesn't show up in the RTL viewer.

--- Quote End ---

I see. That's curious, but doesn't mean much.

For the actual gate level implementation, you need to look to the technology map netlist anyway.

P.S.: Although I tend to believe the gate level list, I can't guarantee that it's true if you force the synthesis tool to do needless things, like the noprune attribute does at least in the present case. May be if the fitter runs in a problem to route 6000 unused register input signals, it decides that 3000 are enough? I don't know for sure.

The above suggested method has the advantage that it can't be ignored without affecting the design output.