Hello All!
I'm having an issue implementing some VERY simple IP for an asynchronous SRAM chip (on digikey: http://www.digikey.com/product-detai...104-ND/1831380). It's really making me doubt myself.
It's just a dumb bit of code, that's I've used years ago on an old project (Quartus II 9.1 I think)
module sram(
// global clk/reset
clk,
reset_n,
// avalon slave
s_chipselect_n,
s_byteenable_n,
s_write_n,
s_read_n,
s_address,
s_writedata,
s_readdata,
// SRAM interface
SRAM_DQ,
SRAM_ADDR,
SRAM_UB_n,
SRAM_LB_n,
SRAM_WE_n,
SRAM_CE_n,
SRAM_OE_n
);
parameter DATA_BITS = 16;
parameter ADDR_BITS = 18;
input clk;
input reset_n;
input s_chipselect_n;
input [(DATA_BITS/8-1):0] s_byteenable_n;
input s_write_n;
input s_read_n;
input [(ADDR_BITS-1):0] s_address;
input [(DATA_BITS-1):0] s_writedata;
output [(DATA_BITS-1):0] s_readdata;
output SRAM_CE_n;
output SRAM_OE_n;
output SRAM_LB_n;
output SRAM_UB_n;
output SRAM_WE_n;
output [(ADDR_BITS-1):0] SRAM_ADDR;
inout [(DATA_BITS-1):0] SRAM_DQ;
assign SRAM_DQ = SRAM_WE_n ? 'hz : s_writedata;
assign s_readdata = SRAM_DQ;
assign SRAM_ADDR = s_address;
assign SRAM_WE_n = s_write_n;
assign SRAM_OE_n = s_read_n;
assign SRAM_CE_n = s_chipselect_n;
assign {SRAM_UB_n,SRAM_LB_n} = s_byteenable_n;
endmodule
That's it, just 54 lines with white space.
The issue I'm having is that:
If Quartus uses the same fitter seed each time where's the random'ness come from? It should compile exactly the same sof each time... but I'm getting different results.
The SRAM doesn't have any electrical faults - it's highly reliable when Quartus builds it right. It's fast enough to read single cycle (10ns cycle) on a Nios2/e running at 50MHz. I have two working tested boards that I'm testing on, both give me identical results. I've sprayed them with cold spray to test for bad soldering, damage to the devices from reflow, etc. All Quartus settings are default, and I have rebuilt my project from scratch many times - I use Quartus shell and a TCL script to load assigmnents for pins and IO voltage - nothing else is changed.
Is this my fault or is Quartus screwing me over here... ? I'm downloading 13.0 to see if it does the same. I'm not great with TimeQuest, but I can't see any warnings, all my slack is +ve as it's a simple design. There are NO critical warnings in the whole compilation.
Please critique my code and tell me if it's my fault - am I having asynchronous issues? Should I register the signals in and out? It's an asychronous RAM with 10ns performance, it shouldn't be necessary right? The avalon bus will make all synchronous when it samples?
Please help... (whimpering noise)...
I'm having an issue implementing some VERY simple IP for an asynchronous SRAM chip (on digikey: http://www.digikey.com/product-detai...104-ND/1831380). It's really making me doubt myself.
It's just a dumb bit of code, that's I've used years ago on an old project (Quartus II 9.1 I think)
module sram(
// global clk/reset
clk,
reset_n,
// avalon slave
s_chipselect_n,
s_byteenable_n,
s_write_n,
s_read_n,
s_address,
s_writedata,
s_readdata,
// SRAM interface
SRAM_DQ,
SRAM_ADDR,
SRAM_UB_n,
SRAM_LB_n,
SRAM_WE_n,
SRAM_CE_n,
SRAM_OE_n
);
parameter DATA_BITS = 16;
parameter ADDR_BITS = 18;
input clk;
input reset_n;
input s_chipselect_n;
input [(DATA_BITS/8-1):0] s_byteenable_n;
input s_write_n;
input s_read_n;
input [(ADDR_BITS-1):0] s_address;
input [(DATA_BITS-1):0] s_writedata;
output [(DATA_BITS-1):0] s_readdata;
output SRAM_CE_n;
output SRAM_OE_n;
output SRAM_LB_n;
output SRAM_UB_n;
output SRAM_WE_n;
output [(ADDR_BITS-1):0] SRAM_ADDR;
inout [(DATA_BITS-1):0] SRAM_DQ;
assign SRAM_DQ = SRAM_WE_n ? 'hz : s_writedata;
assign s_readdata = SRAM_DQ;
assign SRAM_ADDR = s_address;
assign SRAM_WE_n = s_write_n;
assign SRAM_OE_n = s_read_n;
assign SRAM_CE_n = s_chipselect_n;
assign {SRAM_UB_n,SRAM_LB_n} = s_byteenable_n;
endmodule
That's it, just 54 lines with white space.
The issue I'm having is that:
- Using Quartus II 12.1 Build 177, I will build the project, and it works 100%.
- Then, I'll change something very very simple in the Verilog, recompile and find that my Nios2 will not run - and gives me a verify failed error:
- The change can be as simple as moving a single output to a different pin on the device, and then nios2 just won't execute for SRAM verify failure. I'm losing my cool by this point.
- Now, if I go back to Quartus and just hit *compile* again, without making any changes at all, the new SOF works fine, Nios2 verifies and runs from SRAM... really lost my cool now.
If Quartus uses the same fitter seed each time where's the random'ness come from? It should compile exactly the same sof each time... but I'm getting different results.
The SRAM doesn't have any electrical faults - it's highly reliable when Quartus builds it right. It's fast enough to read single cycle (10ns cycle) on a Nios2/e running at 50MHz. I have two working tested boards that I'm testing on, both give me identical results. I've sprayed them with cold spray to test for bad soldering, damage to the devices from reflow, etc. All Quartus settings are default, and I have rebuilt my project from scratch many times - I use Quartus shell and a TCL script to load assigmnents for pins and IO voltage - nothing else is changed.
Is this my fault or is Quartus screwing me over here... ? I'm downloading 13.0 to see if it does the same. I'm not great with TimeQuest, but I can't see any warnings, all my slack is +ve as it's a simple design. There are NO critical warnings in the whole compilation.
Please critique my code and tell me if it's my fault - am I having asynchronous issues? Should I register the signals in and out? It's an asychronous RAM with 10ns performance, it shouldn't be necessary right? The avalon bus will make all synchronous when it samples?
Please help... (whimpering noise)...