need some help with 2 xilinx error messages

[taco]

could somebody point to a solution for the following 2 xilinx problems:
I'm trying to store data directly into a ram instantiation in the following
way:
....
async_mem rom (
//outputs
.rd_data (di),
//inputs
.wr_clk (1'b0),
.wr_data (1'b0),
.wr_cs (1'b0),
.addr (A[14:0]),
.rd_cs (rom_rd_cs));

initial
begin
wait_n = 1;
int_n = 1;
nmi_n = 1;
busrq_n = 1;
//init program_code
$readmemh ("test.mem", rom.mem);
end

Xilinx doesn't report any syntax errors, but in the translate phase I get:
"Second argument to system task $readmemh must be memory type."
the mem variable is declared in the async_mem file as:
reg [7:0] mem [0:depth-1];
So it's really a memory declaration. Bug?

The seccond strange error message is for the following code snippet:
task clear_ram;
118 integer i;
119 begin
120 for (i=0; i < 32768; i = i+1)
121 ram.mem = 0;
122 end
123 endtask
124
If I call this task I get the strange message
"For loop stop condition should depend on loop variable or be static."
I cannot see what's wrong with this.
Taco

 

[Evan Lavelle]

On Wed, 10 Oct 2007 13:03:10 +0200, taco <tralalal@joepie.nl> wrote:

could somebody point to a solution for the following 2 xilinx problems:
I'm trying to store data directly into a ram instantiation in the following
way:
...
async_mem rom (
snipped
$readmemh ("test.mem", rom.mem);
end

Xilinx doesn't report any syntax errors, but in the translate phase I get:
"Second argument to system task $readmemh must be memory type."
the mem variable is declared in the async_mem file as:
reg [7:0] mem [0:depth-1];
So it's really a memory declaration. Bug?

what is 'rom.mem'? 'mem' is a Verilog "memory", which can be loaded
using $readmem. It's not related to the module you've instantiated,
which you've called 'rom'. And what's the 'translate phase'? Is it
ngdbuild? If so, you can't synthesise code that initialises memory
from a file.

= 0;

What's ram.mem?

Evan

 

[taco]

Evan Lavelle wrote:

On Wed, 10 Oct 2007 13:03:10 +0200, taco <tralalal@joepie.nl> wrote:

could somebody point to a solution for the following 2 xilinx problems:
I'm trying to store data directly into a ram instantiation in the
following way:
...
async_mem rom (
snipped
$readmemh ("test.mem", rom.mem);
end

Xilinx doesn't report any syntax errors, but in the translate phase I get:
"Second argument to system task $readmemh must be memory type."
the mem variable is declared in the async_mem file as:
reg [7:0] mem [0:depth-1];
So it's really a memory declaration. Bug?

what is 'rom.mem'? 'mem' is a Verilog "memory", which can be loaded
using $readmem. It's not related to the module you've instantiated,
which you've called 'rom'. And what's the 'translate phase'? Is it
ngdbuild? If so, you can't synthesise code that initialises memory
from a file.
I mean with the translate phase xst. I don't get the errors if I move the

readmemh line into the instantiated module:
module async_mem (rd_data, wr_clk, wr_data, wr_cs, addr, rd_cs);
parameter asz = 15, depth=32768;
input wr_clk;
input [7:0] wr_data;
input wr_cs;

input [asz-1:0] addr; //address for the 32768 bytes
inout [7:0] rd_data;
input rd_cs;

reg [7:0] mem [0:depth-1];

initial
begin
$readmemh ("test.mem", mem);
end

always @(posedge wr_clk)
begin
if (wr_cs) mem[addr] <= #1 wr_data;
end

assign rd_data = (rd_cs) ? mem[addr] : {8{1'bz}};
endmodule

but xst hangs with this.

121 ram.mem = 0;

What's ram.mem?
that's the memory from the module above. The error is not about this line

it's about the forloop:
for (i=0; i < 32768; i = i+1)
but perhaps it's just a stupid error message which originates from the line
following, because it's certainly correct verilog in my opinion.
I'm a bit beginner with verilog, so am I correct that to access a variable
in an instantiated module you refer to it with this ram.mem? It's how I
came across this in some file on the net, but perhaps it's wrong.
taco

Evan

 

[gabor]

On Oct 10, 8:23 am, taco <trala...@joepie.nl> wrote:

Evan Lavelle wrote:
On Wed, 10 Oct 2007 13:03:10 +0200, taco <trala...@joepie.nl> wrote:

could somebody point to a solution for the following 2 xilinx problems:
I'm trying to store data directly into a ram instantiation in the
following way:
...
async_mem rom (
snipped
$readmemh ("test.mem", rom.mem);
end

Xilinx doesn't report any syntax errors, but in the translate phase I get:
"Second argument to system task $readmemh must be memory type."
the mem variable is declared in the async_mem file as:
reg [7:0] mem [0:depth-1];
So it's really a memory declaration. Bug?

what is 'rom.mem'? 'mem' is a Verilog "memory", which can be loaded
using $readmem. It's not related to the module you've instantiated,
which you've called 'rom'. And what's the 'translate phase'? Is it
ngdbuild? If so, you can't synthesise code that initialises memory
from a file.

I mean with the translate phase xst. I don't get the errors if I move the
readmemh line into the instantiated module:
module async_mem (rd_data, wr_clk, wr_data, wr_cs, addr, rd_cs);
parameter asz = 15, depth=32768;
input wr_clk;
input [7:0] wr_data;
input wr_cs;

input [asz-1:0] addr; //address for the 32768 bytes
inout [7:0] rd_data;
input rd_cs;

reg [7:0] mem [0:depth-1];

initial
begin
$readmemh ("test.mem", mem);
end

always @(posedge wr_clk)
begin
if (wr_cs) mem[addr] <= #1 wr_data;
end

assign rd_data = (rd_cs) ? mem[addr] : {8{1'bz}};
endmodule

but xst hangs with this.

121 ram.mem = 0;

What's ram.mem?

that's the memory from the module above. The error is not about this line
it's about the forloop:
for (i=0; i < 32768; i = i+1)
but perhaps it's just a stupid error message which originates from the line
following, because it's certainly correct verilog in my opinion.
I'm a bit beginner with verilog, so am I correct that to access a variable
in an instantiated module you refer to it with this ram.mem? It's how I
came across this in some file on the net, but perhaps it's wrong.
taco



Evan

I don't think there's a problem with loading memory from a file for
synthesis. At least the fact that you can do it in the lower level
module seems to show that. Apparently XST does not support memory
initialization across the heirarchy. That is, it looks for a
"ROM" template in the current module, in your case the lower level
module and handles the $readmemh when the memory is created.

I can see the value in loading the memory from the upper level
module, for example if you wanted to instantiate several rom
modules and initialize each to a different pattern. You can
work around this issue by using a parameter for the initialization
file in the lower level code and defparam in the main module.

As far as your initialize loop, I think the error on line 121
is misleading. My guess is that the real problem is that you
can't clear a ram like this in a synthesizable way. What you're
asking is for the entire contents of the ram to go to zero in
one cycle. Synthesizable ram's can't do this. The loop may
work in an initialize block, but not in procedural code.

HTH,
Gabor

 

[taco]

gabor wrote:

I don't think there's a problem with loading memory from a file for
synthesis. At least the fact that you can do it in the lower level
module seems to show that. Apparently XST does not support memory
initialization across the heirarchy. That is, it looks for a
"ROM" template in the current module, in your case the lower level
module and handles the $readmemh when the memory is created.

I can see the value in loading the memory from the upper level
module, for example if you wanted to instantiate several rom
modules and initialize each to a different pattern. You can
work around this issue by using a parameter for the initialization
file in the lower level code and defparam in the main module.

As far as your initialize loop, I think the error on line 121
is misleading. My guess is that the real problem is that you
can't clear a ram like this in a synthesizable way. What you're
asking is for the entire contents of the ram to go to zero in
one cycle. Synthesizable ram's can't do this. The loop may
work in an initialize block, but not in procedural code.

HTH,
Gabor

Thanks you are right. Putting the loop inside an initial block inside the
async_mem file works but not in the procedural code and the memory
initialisation file needs indeed to be called from the module and not
across the hierarchy. Xst is still crashing, but I assume that's because of
the memory init file contents which need to be in some other format.
Thanks!
taco