How to force all code to be compiled?

[sci4me]

Hi guys. So, I am working on a processor and at the moment, since I haven't implemented a proper way to program it, i am just putting to code into the ram before i compile and program the processor. The issue is that, I think the compiler is actually looking at my program and only compiling the parts of the processor that are needed to run the program. Is there some way I can disable this?

[mrflibble]

I'm guessing an fpga implementation of a cpu... But you'll have to be a wee bit more specific. Without more specifics you can read up on using the KEEP and SAVE constraints if you use Xilinx or the equivalent constraints on Altera.

[mrflibble]

Doh! Just noticed your n00b fpga thread ... Try to keep it to one thread please.

[sci4me]

Sorry, its just that its a slightly different topic which is why I decided on a new one. As far as using the KEEP/SAVE, I assume that means it will compile the code even if its not needed? I am writing this for an Altera Cyclone IV E on the DE0 Nano board. You said that those are for xilinx though? Ill look into the altera ones.

[mrflibble]

KEEP/SAVE are for xilinx yes. You'll have to check the altera docs for the equivalent. Basically these constraints are to make sure the synthesizer doesn't try to optimize away certain logic you would like to keep.

[sci4me]

Will I need to put the keyword on EVERY line? or can I just encapsulate what I want to keep?

[mrflibble]

You will need to put it wherever you need to put it, which shall all become clear after you read the fine manual.

But you can start by making sure that the flip-flops for your RAM are not optimized away. Because currently they are probably interpreted as constants, which is nice for the optimizer.

Quick way: INIT value for ram is whatever your program is. Then make sure you attach a clock to those registers and simply feed back the flip-flop outputs back to the inputs. That should be good enough to keep those constant valued RAMs around.

And pre-empting your next question: did you RTFM yet?

[sci4me]

Okay, bearing in mind that im still a beginner who is trying to learn, this is what my RAM looks like:

Code: [Select]

module ram
(
input [31:0] data,
input [11:0] addr,
input we, clk,
output [31:0] q
);

reg [31:0] ram[2**11:0];

reg [11:0] addr_reg;

initial
begin : INIT
integer i;
for(i = 0; i < 2**11; i = i + 1)
ram[i] = {32{1'b0}};

ram[0] = 47;
ram[1] = 512;

ram[513] = 3;
ram[514] = 512;
ram[515] = 18; //stack pointer 512

ram[516] = 74; //BIO
   ram[517] = 0; //PIN0
ram[518] = 523; //addr
ram[519] = 72; //SIO
ram[520] = 0; //PIN0
ram[521] = 47; //JMP
ram[522] = 516; //addr
ram[523] = 70; //CIO
ram[524] = 0; //PIN0
ram[525] = 47; //JMP
ram[526] = 516; //addr
end

always @ (posedge clk)
begin
if (we)
ram[addr] <= data;

addr_reg <= addr;
end

assign q = ram[addr_reg];
endmodule

As far as did i RTFM, I read the manual for the development board I got, and ive looked at some verilog information, but thats basically it. Ive learned quite a bit just by looking at simple examples online.

[mrflibble]

Well, the fine manual I refer to is the constraints guide from Altera. That will tell you what constraints will make the synthesizer (quartus in this case) leave your RAM unmolested.

Just google on "altera constraints guide", the first several hits are relevant.

[sci4me]

Well the ram isnt being changed.. like, the program I put in is working, but if I dont use all parts of the processor in the program, the unused parts of the processor arent compiled...

[mrflibble]

...  the unused parts of the processor arent compiled...

See previous statements about stuff being optimized away.

[sci4me]

Okay, but my question is why would I need to worry about the ram if the processor is whats being optimized away?

[mrflibble]

If a module (any module) doesn't have a load connected to it's drivers then the synthesizer concludes that apparently this module is not needed.

Also, if a module only has constant outputs and the synthesizer is able to detect this then it will use those constant values, NOT the logic or whatever that generated those constant outputs. Because a line pulled high/low is a lot cheaper than a collection of convoluted logic that apparently resulted in a constant result.

All that to say that sometimes module B is optimized away because module A is optimized away because it's outputs are static.

So while you may focus on module B (because OMG module B optimized away), the root cause can be module A.

[sci4me]

Right, so since the ram values are constant... its optimizing things away, but ... the ram values can change... or should be able to...

[jahonen]

You are likely after preserve synthesis attribute:

http://quartushelp.altera.com/13.0/mergedProjects/hdl/vlog/vlog_file_dir_preserve.htm

So try

Code: [Select]

reg [31:0] ram[2**11:0] /* synthesis preserve */;

there. But this might not work if there are no-fanout registers, in which case you'd need to add noprune attribute too.

Regards,
Janne

[mrflibble]

but ... the ram values can change... or should be able to...

Well, which is it? Do the ram values change in reality (where the synthesizer lives) or just in your intentions? If you have verified that ram values really do change then this is unlikely to be the culprit...

[sci4me]

Well they can change if I program the device to change them...

[mrflibble]

That doesn't really tell me all that much. But no matter, in the meantime you no doubt worked out how to apply constraints where needed so problem solved.