Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Register Log in

Map : 116 - The design is empty. No processing will be done

Status
Not open for further replies.
H

hassanzia

Junior Member level 3
Junior Member level 3
Joined
Nov 24, 2011
Messages
30
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,286
Activity points
1,506
Hi,
i'm unable to figure out why i'm getting the following error.

ERROR:Map:116 - The design is empty. No processing will be done.
ERROR:Map:52 - Problem encountered processing RPMs.

Code: 
module AESEncryptor(InputPlainText, InputPassword, OutputCipherText, clk, rst_n
    );
	 
	 input clk,rst_n;
	 input [127:0] InputPlainText;
	 input  [127:0] InputPassword;
	 output reg [127:0] OutputCipherText;
	 
	 	 
	 // Storing Values in RCON LUT
	 reg [7:0] RCON [0:9];
	 
	 // PlainText stores the plain text as an 8x176 RAM
	 reg [7:0] PlainText [0:175];
	 
	 // RoundKeys is the 8x176 RAM for storing the RoundKeys
	 reg [7:0] RoundKeys [0:175];
	 
	 // tempRoundKey for storing a 4 byte number (in RoundKey process)
	 reg [7:0] tempRoundKey [0:3];
	 
	 reg [7:0] CipherText [0:15];
	 
	 integer i,j=0;
	 	 
	 initial
	 begin
		
		// initializing RCON register
		RCON [0] = 8'h01;	RCON [1] = 8'h02;	RCON [2] = 8'h04;	RCON [3] = 8'h08;
		RCON [4] = 8'h10;	RCON [5] = 8'h20;	RCON [6] = 8'h40;	RCON [7] = 8'h80;
		RCON [8] = 8'h1b;	RCON [9] = 8'h36;
				
	 end
	 
	 always @ (posedge clk or negedge rst_n)
	 begin
	 if (!rst_n)
	 begin
		for (i=0;i<16;i=i+1)
			CipherText [i] = 0;
	 end
		// storing password into 16x8 RAM
		// storing the initial 16 bytes RoundKeys in a RAM
		
	else
	begin
	
		// Storing the password as the first 16 bytes of Roundkey
		// Converting the Input Plain Text into 8x16 bytes of RAM
	 	for (i=0;i<16;i=i+1)
		begin
			RoundKeys [i] = InputPassword [(8*(i+1)-1)-:8];
			PlainText [i] = InputPlainText [(8*(i+1)-1)-:8];
		end
		
		//*****************Initial Round****************
		
	end
		
	 end
	 	 
endmodule
 

Im guessing the clock is stuck at '0' or '1' or the reset is stuck at '0'.
 

Thanks for the quick reply

How can a clock or reset stuck in an implementation module? Aren't these modules independent of initialization issues?
 

Among the many issues in your code, the main one is that you do not output anything from the module (i.e. OutputCipherText is never assigned). Therefore the synthesizer will consider every other signal to be superfluous and remove the logic. Thus, no design.

r.b.
 

rberek said:
Among the many issues in your code, the main one is that you do not output anything from the module (i.e. OutputCipherText is never assigned). Therefore the synthesizer will consider every other signal to be superfluous and remove the logic. Thus, no design.

r.b.
Click to expand...

Thats probably the bigger problem!
 
rberek said:
Among the many issues in your code
r.b.
Click to expand...

Can you please mention some, for future reference, so I may avoid these errors in future.

Also I normally directly map my code after every few lines (like compiling a C++ code after every writing every few lines) just to check that I'm on the right track. Is this a good practice?

This is my first major project so if you notice any basic errors please do mention them as well.
 

Hi
Here is what I think you need to look at.

1) Initial statements are not often used in synthesizeable code, I know for a fact that what you have written will not work at all if synthesized in Synplify Pro. In hardware, there is no magic way to have memory arrays start up in a specific state. This must be directed by you, the hardware designer. If it is an array of flip flops, you should reset them to your desired state using the reset signal, as you have done for some of the other arrays. If the LUT is going to be a compiled memory, then the vendor will have some method for you to specify a non-zero power up state (i.e. memory initialization file or similar). I believe it may be possible to specify a $readmemh command in an initial block and have it synthesize correctly, but I have never tried it. I prefer to write code to explicitly describe the way I would like things set up.

2) In sequential always blocks, you use non-blocking assignments (<=) rather than blocking assignments (=).

3) You have an incompletely specified if else clause which will lead to the generation of latches. I'm sure you don't want these. FPGAs don't have them, and in ASICs they are used only in very special cases or in certain high-speed design techniques. You don't say what value CipherText will take if rst is 1, or what RoundKeys and PlainText are when rst is 0;

4) I have never used for loops in the manner in which you use them (i.e. multiple copies of logic). The more common way to do this is with generate and endgenerate blocks. I work for a large company and we have to follow coding guidelines where only generate blocks can be used, so I have never tried what you are trying. Perhaps other people can comment. It may very well work correctly.

As for compiling frequently, that is your choice. It is good practice if it helps you write better code. When you have larger designs where compiles take hours, then it is not practical to do that. Also, once you get experience, you are more worried about whether or not your logic is correct rather than whether or not it will synthesize correctly. Let's face it, when you are doing product development, your RTL doesn't often get fancy - you stick to your own "known good" coding style and synthesis issues mostly come from finger errors rather than architecture errors. But what you are doing is fine.

Hope this helps.

r.b.
 
Thanks for the pointers r.b., I'll keep them in mind
 

rberek said:
Hi

1) Initial statements are not often used in synthesizeable code, I know for a fact that what you have written will not work at all if synthesized in Synplify Pro. In hardware, there is no magic way to have memory arrays start up in a specific state. This must be directed by you, the hardware designer. If it is an array of flip flops, you should reset them to your desired state using the reset signal, as you have done for some of the other arrays. If the LUT is going to be a compiled memory, then the vendor will have some method for you to specify a non-zero power up state (i.e. memory initialization file or similar). I believe it may be possible to specify a $readmemh command in an initial block and have it synthesize correctly, but I have never tried it. I prefer to write code to explicitly describe the way I would like things set up.
Click to expand...

I disagree with initial statement with flip flops. Xilinx (and i think in 99% altera) fully support initialization to '1' or '0'. Xilinx even recommend it in one white paper that, if engineer add reset signal just to put dff into known state after booting the device to use signal initialization instead and remove reset from your design to relax routing and implementation constraints.
 

axcdd said:
I disagree with initial statement with flip flops. Xilinx (and i think in 99% altera) fully support initialization to '1' or '0'. Xilinx even recommend it in one white paper that, if engineer add reset signal just to put dff into known state after booting the device to use signal initialization instead and remove reset from your design to relax routing and implementation constraints.
Click to expand...

Ditto. There's I believe several papers where this is mentioned. The idea is to use the global reset to take care of the initial conditions of your flip flop. That way you reduce the number of control signals, and as axcdd points out this will help during routing.

I always have to chuckle a little when I see the pedantic MUST HAVE RESET on something that is 100% targeted for fpga, and then the reset that they MUST HAVE is only ever asserted at startup. Oh whatever shall we use this here global reset for... I understand if you have a module that needs reset during operation for some reason (calibration phase, taking care of metastables, whatever), then you use the explicit reset. But regular boring initial condition after powerup & configuration, lets just use the global reset as recommended by the fpga vendor.

Code Verilog - [expand]
1
2
3
4
5
6

reg some_flipflop = 1'b0; // properly initialized after configuration using the global reset
 
// note the total lack of reset in here
always @(posedge clk) begin
    some_flipflop <== something;
end


This topic comes up every once in a while, and I suspect not everyone will agree on the above. But I have yet to hear a compelling argument on why one would use an explicit reset for all flip-flops in a design targeting fpga.
 

mrflibble said:
This topic comes up every once in a while, and I suspect not everyone will agree on the above. But I have yet to hear a compelling argument on why one would use an explicit reset for all flip-flops in a design targeting fpga.
Click to expand...

Actually for Altera there is a small paragraph in their documentation that explicitly states (for Cyclone II, III, Stratix III, IV, don't know about the others), the power up state of a flip-flop isn't guaranteed unless there is a reset on the flip-flop. I'm not able to go search for it right now, but when I have time I'll go look for that paragraph and post details.

Xilinx explicitly states that the chip wide GSR will be asserted after configuration setting every flip-flop to the reset/preset state defined by the reset logic or to 0 if there is no reset/preset on the flip-flop.
 
I confess to not being up to speed with Altera. I was more or less expecting Altera parts also to have a global reset that takes care of the flip flops, but apparently not. That is a bit strange though, because you'd expect a GSR to take care of initialization. Precisely because if it doesn't, then you will have to expend extra routing resources for your control signals. And having a predictable flip flop state after configuration is a fairly common requirement. Man, it's been ages since I last used an Altera part... Maybe it's time to try out some new parts. Especially since Xilinx synthesis tools for anything before 7 series are rather stale, and Altera seems to be keeping up a bit more in that regard. What I read so far about Altera Max 10 serie sure looks interesting.

ads-ee said:
I'm not able to go search for it right now, but when I have time I'll go look for that paragraph and post details.
Click to expand...

That would indeed be very helpful. :)
 

I actually didn't want take part in this reawakening of an old thread which was triggered by a useless post.

But now I can't refrain from commenting the "guaranteed power-up state" point. I'm restricting myself to what I know about Altera devices, although I'm quite sure that it's almost the same with other vendors.

1. The FPGAs have an internal power-on-reset network that is setting a defined initial state for all registers. Verilog initial blocks or VHDL initializing signal statements are supported using the POR feature.

2. The POR is released asynchronously, possibly with already toggling design clocks. Due to this fact, the initial state of counters or state machines may be unexpected or even an illegal trap state, caused by timing violations.

3. So an explicite, sychronously released global reset is often wanted. It's additional resource consumption is rather small.

- - - Updated - - -

Here's a quote from the recent Quartus software handbook:
Inferred Power-Up Levels

Quartus II Integrated Synthesis reads default values for registered signals defined in Verilog HDL and VHDL code, and converts the default values into Power-Up Level settings. The software also synthesizes variables with assigned values in Verilog HDL initial blocks into power-up conditions. Synthesis of these default and initial constructs allows synthesized behavior of your design to match, as closely as possible, the power-up state of the HDL code during a functional simulation.

The following register declarations all set a power-up level of VCC or a logic value “1”, as shown in this example:

signal q : std_logic = '1'; -- power-up to VCC
reg q = 1'b1; // power-up to VCC
reg q;
initial begin q = 1'b1; end // power-up to VCC
Click to expand...

A special reservation should be mentioned. Applying both asynchronous set and reset (or asynchronous load) to a register that hasn't the respective hardware feature uses a synthesis workaround with latches and xor circuits. In this case, the power-up level is undefined. The synthesis tool issues a warning about the problem.
 
This was one of the knowledge base articles I read about this subject. I couldn't find the other article and I haven't looked in the documentation for the corresponding information.
Click to expand...
Both links are essentially focussing on the same point, it's the undefined timing relation between reset release and clock that causes the problems.
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top