Simulation vs Synthesis

They're both declared in the same module - you can see them at

formatting link
(specifically
formatting link
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

Reply to
Simon
Loading thread data ...

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[i] = 0; zp[i] = 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
Reply to
rickman

Rick is correct. This code: for (i=0; i

Reply to
Alan Reynolds

= 0;

to be a ROM which means that this code snippet (without the stack[i]) shou ld be in an "initial" statement, not an "always" statement for correct infe rencing 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.

Reply to
Simon

? 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

Reply to
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.

Reply to
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

Reply to
BobH

Ah - sorry :)

Cheers Simon.

Reply to
Simon

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.