Simulation and Verification

[pmumby]

Hello, I'm fairly new to xilinx tools, and am just beginning with Verilog design.

I have designed a simple SHA256 Hashing core, and now want to simulate it to ensure it works as expected.

It synthesizes fine, (without this error) but when I try to simulate, it throws an error.

Here is my verilog:

	generate
		for(i=0; i<STAGES; i = i + 1) begin : STAGE
			
			wire [31:0] k_local = Kval[`INDEX(i)];
			wire [255:0] hashwire_local;
			reg [511:0] wbuf;
			
			if(i==0) begin
				//First (input) Stage in the Pipeline
				SHA256_Stage SHAPIPE_START (
					.en(en),
					.clk(clk),
					.w(wbuf[`INDEX(15)]),
					.k(k_local),
					.in(Hval),
					.out(hashwire_local)
				);
			end else if(i==(STAGES-1))begin
				//Last (output) Stage in the Pipeline
				SHA256_Stage SHAPIPE_END (
					.en(en),
					.clk(clk),
					.w(wbuf[`INDEX(15)]),
					.k(k_local),
					.in(STAGE[i-1].hashwire_local),
					.out(hashwire)
				);
			end else begin
				//Middle Stages of the Pipeline
				SHA256_Stage SHAPIPE_MID (
					.en(en),
					.clk(clk),
					.w(wbuf[`INDEX(15)]),
					.k(k_local),
					.in(STAGE[i-1].hashwire_local),
					.out(hashwire_local)
				);
			end					
			
			always @ (posedge clk) begin
				if(en) begin
					if(i<16) begin
						if(i<1) begin
							wbuf <= {data[511:32],data[`INDEX(0)]};
						end else begin
							wbuf <= {STAGE[i-1].wbuf[511:32],STAGE[i-1].wbuf[`INDEX(0)]};
						end
					end else begin
						wbuf <= {wbuf[511:32],STAGE[i-1].wbuf[`INDEX(0)] + `S0(STAGE[i-1].wbuf[`INDEX(1)]) + STAGE[i-1].wbuf[`INDEX(9)] + `S1(STAGE[i-1].wbuf[`INDEX(14)])};
					end
					if(i==(STAGES-1)) begin
						hashbuf <= hashwire;
					end
				end
			end 

The error is on the line:

wbuf <= {STAGE[i-1].wbuf[511:32],STAGE[i-1].wbuf[`INDEX(0)]};

The error is:

Line 118: <STAGE[-1].wbuf[511:32]> is not declared.

It appears it's trying to access the -1, even though that if condition should only allow that line to be generated if i > 0 (which is a problem because then the resulting element would be negative).

My terminology might be broken, but I hope I'm getting my idea across successfully.

Any help/assitance/tips would be greatly appreciated.

Thanks!

[markcurry]

Your error looks to be because you're trying to reference a local variable of

another iteration of your generate loop using a Cross Module Reference (XMR)

(The '.' syntax).

I've never tried that.  I'm surprised it worked at all - XST took it without errors?  That's

really surprising.  As far as I understood XST doesn't support XMR in any fashion.

My advice - don't do that.  If you need access data between iterations, then don't create

local regs (within the generate loop) , use global regs (within the module), and index

into the global regs appropriately.  i.e. the decleration for wbuf should be (before the

generate):

 // reg [ STAGES - 1 : 0 ] [ 511 : 0 ] wbuf;

reg [ STAGES *512 - 1 : 0 ] wbuf;

Why that commented version? Well that's really how you want to declare it - and

it's legal SystemVerilog.  Which is NOT supported in XST.  So you need the second

form of the decleration.  I like to have at least the comment there to remind myself

what I'm really intending with that really long wire. 

Then within the generate loop, you'll need to index into wbuf appropriately.

--Mark

[pmumby]

Hmm... The concern is I'm passing a 512bit data block along a pipeline. (64 stage pipeline) and I was concerned about there being long runs on place and route if I had all 64 stages referencing a single 32kbit global register.

SHA256 requires passing the data block along, each pipeline stage relies on the modifications made by previous stages.

I adopted this technique because I had seen it used in other open source verilog that compiles (and works) fine. (but amusingly it also won't simulate). The challenge is I need to validate if my SHA core works.

I can switch it to use a global reg like you suggest, but will that impact routing latency? (I'm already struggling with timing constraints on this design). (currently at 12ns estimated by synthesis, and I'm targeting 5ns - 8ns)

Thanks!

[markcurry]

My suggested fix didn't change the underyling algorithm at all.  I don't know your algorithm, but if it has 64 stages, with 512 bit outputs from each stage, then yes, that's 32k wires that you have to deal with - no matter how you express it.  I just basically changed the scope of the variable definiition (from a local to a global "module" scope).

Now, that's not saying you couldn't rearchitect things differently.

--Mark

[rcingham]

"currently at 12ns estimated by synthesis"

DO NOT give any credence to the synthesis timing estimates. They can be very optimistic or very pessimistic for no obvious reason (apart from a necessarily simplistic algorithm).

Only the post-P&R timing analysis is worth paying attention to. However, if you implement a partial design in the full chip, the routing delay is likely to be overly large unless you constrain the area. You may also need to add extra registers in a wrapper to prevent exceesive unrealistic delays in the block's IO signals.