Simulation vs Synthesis

[rickman]

On 12/4/2015 1:58 AM, Simon wrote:

On Thursday, December 3, 2015 at 10:35:10 PM UTC-8, rickman wrote:
On 12/4/2015 1:07 AM, Simon wrote:
On Thursday, December 3, 2015 at 9:41:18 AM UTC-8, Mike Field wrote:
INFO: [Synth 8-5545] ROM "zp_reg[255]" won't be mapped to RAM because
address size (32) is larger than maximum supported(25)"


The problem might be How are you indexing that small block of registers - is the address being used to index zp_reg also 8 bits?

Yep. The only part that references anything larger than 8 bits is where I select out 8 bits from a 32-bit register, using constant bit-ranges.

`define W 8
`define NW (`W-1)

reg [`NW:0] stack[0:255]; // Stack-page
reg [`NW:0] SP; // Stack pointer

...

if ((action & `UPDATE_SP) == `UPDATE_SP)
begin
if (numSPBytes == 1)
begin
stack[SP] <= newSPData[`NW:0];
SP <= SP - 1;
end
else if (numSPBytes == 2)
begin
stack[SP] <= newSPData[`NW:0];
stack[SP-1] <= newSPData[`W*2-1:`W];
SP <= SP - 2;
end
else if (numSPBytes == 3)
begin
stack[SP] <= newSPData[`NW:0];
stack[SP-1] <= newSPData[`W*2-1:`W];
stack[SP-2] <= newSPData[`W*3-1:`W*2];
SP <= SP - 3;
end
end


Also, why 255 elements and not 256?

Well, it goes from 0 to 255 inclusive, so there are 256 entries.

Where is zp_reg[255] declared? That is the ROM being complained about.
I assume it is considering it a ROM because it is not written to
anywhere.

They're both declared in the same module - you can see them at http://0x0000ff.com/6502/ (specifically http://0x0000ff.com/6502/6502.v towards the top) and they're both triggering the message...

INFO: [Synth 8-5545] ROM "stack_reg[0]" won't be mapped to RAM because address size (32) is larger than maximum supported(25)

Both 'zp' and 'stack' are in fact written to - you can see the logic in `EXECUTE in 6502.v above under `STORE_MEM. I'm not sure why it thinks it's a ROM. Unless that logic is being optimised away for the time being, of course. I haven't checked that yet.

I am not familiar with Verilog, but I know it does various things that
are not obvious by looking at the code. That is the main difference
with VHDL. The statements...

stack = 0;
zp = i+8'h40;

both index the memories by 'i' which is an integer. Does Verilog do
something like assume the memory has to be of a range 0:2^32-1 because
the index is 32 bits?

It has been awhile since I did much with VHDL, but I'm pretty sure the
declarations define the size of the memory and using an integer index
will only get you in trouble in simulation if the index value is out of
range. This would not be a problem in synthesis as long as it doesn't
use block RAM. This code initializes the memory and you can't
initialize block RAM on reset, only on configuration.

--

Rick

 

[Simon]

On Thursday, December 3, 2015 at 10:35:10 PM UTC-8, rickman wrote:

On 12/4/2015 1:07 AM, Simon wrote:
On Thursday, December 3, 2015 at 9:41:18 AM UTC-8, Mike Field wrote:
INFO: [Synth 8-5545] ROM "zp_reg[255]" won't be mapped to RAM because
address size (32) is larger than maximum supported(25)"


The problem might be How are you indexing that small block of registers - is the address being used to index zp_reg also 8 bits?

Yep. The only part that references anything larger than 8 bits is where I select out 8 bits from a 32-bit register, using constant bit-ranges.

`define W 8
`define NW (`W-1)

reg [`NW:0] stack[0:255]; // Stack-page
reg [`NW:0] SP; // Stack pointer

...

if ((action & `UPDATE_SP) == `UPDATE_SP)
begin
if (numSPBytes == 1)
begin
stack[SP] <= newSPData[`NW:0];
SP <= SP - 1;
end
else if (numSPBytes == 2)
begin
stack[SP] <= newSPData[`NW:0];
stack[SP-1] <= newSPData[`W*2-1:`W];
SP <= SP - 2;
end
else if (numSPBytes == 3)
begin
stack[SP] <= newSPData[`NW:0];
stack[SP-1] <= newSPData[`W*2-1:`W];
stack[SP-2] <= newSPData[`W*3-1:`W*2];
SP <= SP - 3;
end
end


Also, why 255 elements and not 256?

Well, it goes from 0 to 255 inclusive, so there are 256 entries.

Where is zp_reg[255] declared? That is the ROM being complained about.
I assume it is considering it a ROM because it is not written to
anywhere.

They're both declared in the same module - you can see them at http://0x0000ff.com/6502/ (specifically http://0x0000ff.com/6502/6502.v towards the top) and they're both triggering the message...

INFO: [Synth 8-5545] ROM "stack_reg[0]" won't be mapped to RAM because address size (32) is larger than maximum supported(25)

Both 'zp' and 'stack' are in fact written to - you can see the logic in `EXECUTE in 6502.v above under `STORE_MEM. I'm not sure why it thinks it's a ROM. Unless that logic is being optimised away for the time being, of course. I haven't checked that yet.

Cheers
Simon

 

[Simon]

On Friday, December 4, 2015 at 6:44:14 AM UTC-8, Alan Reynolds wrote:

Rick is correct. This code:

for (i=0; i<256; i=i+1)

begin

  zp       = i+8'h40;

                           stack    = 0;

                        end

accesses zp with an integer address which is 32 bits. It is also supposed to be a ROM which means that this code snippet (without the stack) should be in an "initial" statement, not an "always" statement for correct inferencing by humans and synthesis tools.

Thanks to both of you for this - I was completely missing that. I should be used to how many times you can stare at something and your eyes just flick to the next statement without registering the problem, but it still amazes me...

It's not *actually* supposed to be a ROM, it's supposed to be R/W, but your point about always/initial is well taken, that's another error...

Cheers
Simon.

 

[Alan Reynolds]

On 2015-12-04 07:18:49 +0000, rickman said:

On 12/4/2015 1:58 AM, Simon wrote:
On Thursday, December 3, 2015 at 10:35:10 PM UTC-8, rickman wrote:
On 12/4/2015 1:07 AM, Simon wrote:
On Thursday, December 3, 2015 at 9:41:18 AM UTC-8, Mike Field wrote:
INFO: [Synth 8-5545] ROM "zp_reg[255]" won't be mapped to RAM because
address size (32) is larger than maximum supported(25)"


The problem might be How are you indexing that small block of registers
- is the address being used to index zp_reg also 8 bits?

Yep. The only part that references anything larger than 8 bits is where
I select out 8 bits from a 32-bit register, using constant bit-ranges.

`define W 8
`define NW (`W-1)

reg [`NW:0] stack[0:255]; // Stack-page
reg [`NW:0] SP; // Stack pointer

...

if ((action & `UPDATE_SP) == `UPDATE_SP)
begin
if (numSPBytes == 1)
begin
stack[SP] <= newSPData[`NW:0];
SP <= SP - 1;
end
else if (numSPBytes == 2)
begin
stack[SP] <= newSPData[`NW:0];
stack[SP-1] <= newSPData[`W*2-1:`W];
SP <= SP - 2;
end
else if (numSPBytes == 3)
begin
stack[SP] <= newSPData[`NW:0];
stack[SP-1] <= newSPData[`W*2-1:`W];
stack[SP-2] <= newSPData[`W*3-1:`W*2];
SP <= SP - 3;
end
end


Also, why 255 elements and not 256?

Well, it goes from 0 to 255 inclusive, so there are 256 entries.

Where is zp_reg[255] declared? That is the ROM being complained about.
I assume it is considering it a ROM because it is not written to
anywhere.

They're both declared in the same module - you can see them at
http://0x0000ff.com/6502/ (specifically http://0x0000ff.com/6502/6502.v
towards the top) and they're both triggering the message...

INFO: [Synth 8-5545] ROM "stack_reg[0]" won't be mapped to RAM because
address size (32) is larger than maximum supported(25)

Both 'zp' and 'stack' are in fact written to - you can see the logic in
`EXECUTE in 6502.v above under `STORE_MEM. I'm not sure why it thinks
it's a ROM. Unless that logic is being optimised away for the time
being, of course. I haven't checked that yet.

I am not familiar with Verilog, but I know it does various things that
are not obvious by looking at the code. That is the main difference
with VHDL. The statements...

stack = 0;
zp = i+8'h40;

both index the memories by 'i' which is an integer. Does Verilog do
something like assume the memory has to be of a range 0:2^32-1 because
the index is 32 bits?

It has been awhile since I did much with VHDL, but I'm pretty sure the
declarations define the size of the memory and using an integer index
will only get you in trouble in simulation if the index value is out of
range. This would not be a problem in synthesis as long as it doesn't
use block RAM. This code initializes the memory and you can't
initialize block RAM on reset, only on configuration.

Rick is correct. This code:
for (i=0; i<256; i=i+1)
begin
zp = i+8'h40;
stack = 0;
end
accesses zp with an integer address which is 32 bits. It is also
supposed to be a ROM which means that this code snippet (without the
stack) should be in an "initial" statement, not an "always"
statement for correct inferencing by humans and synthesis tools.

 

[BobH]

On 12/3/2015 11:58 PM, Simon wrote:

Well, it goes from 0 to 255 inclusive, so there are 256 entries.

Where is zp_reg[255] declared? That is the ROM being complained about.
I assume it is considering it a ROM because it is not written to
anywhere.

They're both declared in the same module - you can see them at http://0x0000ff.com/6502/
(specifically http://0x0000ff.com/6502/6502.v towards the top) and they're both triggering
the message...

INFO: [Synth 8-5545] ROM "stack_reg[0]" won't be mapped to RAM because address
size (32) is larger than maximum supported(25)

Both 'zp' and 'stack' are in fact written to - you can see the logic in `EXECUTE
in 6502.v above under `STORE_MEM. I'm not sure why it thinks it's a ROM. Unless

? that logic is being optimised away for the time being, of course. I
haven't checked that yet.

This may be because I am used to older syntaxes, but don't you need a
start and a terminal number for array specification?
reg [7:0] zp_reg [0:255];

BobH

 

[Simon]

On Friday, December 4, 2015 at 3:10:25 PM UTC-8, BobH wrote:

On 12/3/2015 11:58 PM, Simon wrote:

Well, it goes from 0 to 255 inclusive, so there are 256 entries.

Where is zp_reg[255] declared? That is the ROM being complained about.
I assume it is considering it a ROM because it is not written to
anywhere.

They're both declared in the same module - you can see them at http://0x0000ff.com/6502/
(specifically http://0x0000ff.com/6502/6502.v towards the top) and they're both triggering
the message...

INFO: [Synth 8-5545] ROM "stack_reg[0]" won't be mapped to RAM because address
size (32) is larger than maximum supported(25)

Both 'zp' and 'stack' are in fact written to - you can see the logic in `EXECUTE
in 6502.v above under `STORE_MEM. I'm not sure why it thinks it's a ROM. Unless
? that logic is being optimised away for the time being, of course. I
haven't checked that yet.

This may be because I am used to older syntaxes, but don't you need a
start and a terminal number for array specification?
reg [7:0] zp_reg [0:255];

BobH

Hmm, yes - the range is 256-long though, just like [0:1] gives you two values (0 and 1), [0:255] gives you 256 values (0,1,...,254,255). The declaration in 6502.v looks like:

reg [`NW:0] zp[0:255];

Or at least, that's my understanding. Are you saying that [0:255] only gives you 0,1,...,253,254 or something similar ?

Cheers
Simon.

 

[Simon]

On Saturday, December 5, 2015 at 12:13:56 PM UTC-8, BobH wrote:

On 12/5/2015 11:24 AM, Simon wrote:
On Friday, December 4, 2015 at 3:10:25 PM UTC-8, BobH wrote:
On 12/3/2015 11:58 PM, Simon wrote:

Well, it goes from 0 to 255 inclusive, so there are 256 entries.

Where is zp_reg[255] declared? That is the ROM being complained about.
I assume it is considering it a ROM because it is not written to
anywhere.

They're both declared in the same module - you can see them at http://0x0000ff.com/6502/
(specifically http://0x0000ff.com/6502/6502.v towards the top) and they're both triggering
the message...

INFO: [Synth 8-5545] ROM "stack_reg[0]" won't be mapped to RAM because address
size (32) is larger than maximum supported(25)

Both 'zp' and 'stack' are in fact written to - you can see the logic in `EXECUTE
in 6502.v above under `STORE_MEM. I'm not sure why it thinks it's a ROM. Unless
? that logic is being optimised away for the time being, of course. I
haven't checked that yet.

This may be because I am used to older syntaxes, but don't you need a
start and a terminal number for array specification?
reg [7:0] zp_reg [0:255];

BobH

Hmm, yes - the range is 256-long though, just like [0:1] gives you two values (0 and 1),
[0:255] gives you 256 values (0,1,...,254,255). The declaration in 6502.v looks like:

reg [`NW:0] zp[0:255];

Or at least, that's my understanding. Are you saying that [0:255] only gives
you 0,1,...,253,254 or something similar ?

Cheers
Simon.

Hi Simon,
In several places in this discussion, I saw references to:
reg [`NW:0] zp [255];
I had not gone out to look at your web site with the code, as I usually
don't follow links from people that I don't know on usenet. I went to
your site and saw that it was actually:
reg [`NW:0] zp [0:255];
which seems correct. What I thought previously, was that the declaration
was not correct, which might have been causing synthesis issues.

Regards,
BobH

Ah - sorry

Cheers
Simon.

 

[BobH]

On 12/5/2015 11:24 AM, Simon wrote:

On Friday, December 4, 2015 at 3:10:25 PM UTC-8, BobH wrote:
On 12/3/2015 11:58 PM, Simon wrote:

Well, it goes from 0 to 255 inclusive, so there are 256 entries.

Where is zp_reg[255] declared? That is the ROM being complained about.
I assume it is considering it a ROM because it is not written to
anywhere.

They're both declared in the same module - you can see them at http://0x0000ff.com/6502/
(specifically http://0x0000ff.com/6502/6502.v towards the top) and they're both triggering
the message...

INFO: [Synth 8-5545] ROM "stack_reg[0]" won't be mapped to RAM because address
size (32) is larger than maximum supported(25)

Both 'zp' and 'stack' are in fact written to - you can see the logic in `EXECUTE
in 6502.v above under `STORE_MEM. I'm not sure why it thinks it's a ROM. Unless
? that logic is being optimised away for the time being, of course. I
haven't checked that yet.

This may be because I am used to older syntaxes, but don't you need a
start and a terminal number for array specification?
reg [7:0] zp_reg [0:255];

BobH

Hmm, yes - the range is 256-long though, just like [0:1] gives you two values (0 and 1),
[0:255] gives you 256 values (0,1,...,254,255). The declaration in 6502.v looks like:

reg [`NW:0] zp[0:255];

Or at least, that's my understanding. Are you saying that [0:255] only gives
you 0,1,...,253,254 or something similar ?

Cheers
Simon.

Hi Simon,
In several places in this discussion, I saw references to:
reg [`NW:0] zp [255];
I had not gone out to look at your web site with the code, as I usually
don't follow links from people that I don't know on usenet. I went to
your site and saw that it was actually:
reg [`NW:0] zp [0:255];
which seems correct. What I thought previously, was that the declaration
was not correct, which might have been causing synthesis issues.

Regards,
BobH