Your basic problem is probably the p=p+a
in top_module
. This doesn't make sense; try to draw the schematic. This is a combinatorial path with the output of an adder fed back to its input. Get rid of it, and just add together the , depending on the relevant bit of y
. This may be enough to get you going.
EDIT
Your code is unlikely to be (correctly) synthesisable (by any sane synthesiser, anyway). Consider this:
always @(x , y)
begin
a=x;
p=0;
for(i=0;i<8;i=i+1)
begin
if(y[i])
p=p+a;
a=a<<1;
end
end
This is combinatorial code. You are asking the synthesiser to unroll your i
loop. Every time x
or y
changes, you want the synthesiser to evaluate all 8 loop iterations, shifting a
, and accumulating to p
. Synthesisers are normally pretty good at loop unrolling, but this one is pushing it. Get rid of the loop, whether or not you think XST understands it; it's just bad practice, and is probably confusing XST. Draw a schematic on paper. All you're doing is shifting a
: you've got one unmodified a
, and 7 instances where a
is shifted by 1 to 7 bits. You need an adder which adds together all 8 busses, but you only add in bus i if the corresponding bit of y
is set. In other words, each input to the adder has a multiplexer on it; one input is held to zero, the other is your shifted a
. You'll need to write the code yourself. This is how you do hardware design: break everything down into basic units - multiplexers, shifters, adders, whatever, and wire them togehter. Don't write behavioural code that your synthesiser has to try to work out for you; that's software, not hardware.
Greg may be right in that your actual circuit can be simplified according to your actual input conditions, and that this circuit is eventually unused anyway; it's not a 5-minute job to confirm that, and it's pointless anyway. You're trying to write a multiplier, and your input conditions will change, and you need to get the code right. XST may, or may not, be able to work out that in any particular situation it can simplify the logic, but you have to fix your input code first.
You have other issues. Don't assign X's to your variables as Don't Cares. This is very bad practice, and will go wrong. Read Mike Turpin's paper, among others. In short, never use X's unless you know exactly what you're doing. Use non-blocking assignments in the x
/y
always block. There may be other issues, which aren't obvious on a very quick read-through.