XST synthesis

S

Simon

Guest
Was wondering if anyone would be kind enough to help me out here - I've been
struggling with a synthesis problem in Webpack, and would appreciate being
pointed in the right direction :)

XST is telling me:

WARNING:Xst:528 - Multi-source in Unit <cpu> on signal <data<31>> not
replaced by logic
Sources are: data<31>5:data<31>, data<31>4:data<31>, data<31>3:data<31>,
data<31>2:data<31>, data<31>1:data<31>, data<31>:data<31>
WARNING:Xst:528 - Multi-source in Unit <ramController> on signal
<dataOut<31>> not replaced by logic
Sources are: I181_0:O, I180_0:O
WARNING:Xst:528 - Multi-source in Unit <soc> on signal <_n0017> not replaced
by logic
Sources are: c:data<31>, rc:dataOut<31>, mul:data<31>, timer1:data<31>

.... I'm not sure what the syntax data<31>5:data<31> means, but there are 6
of them, and the only direct manipulation of 'data' (it's a module port) is:

assign data = `ADDSUB ? addsub : `MSB'bz;
assign data = `MULTIPLY ? multiply : `MSB'bz;
assign data = `DIVIDE ? divide : `MSB'bz;
assign data = `LOGIC ? logic : `MSB'bz;
assign data = `SHIFT ? shift : `MSB'bz;
assign data = `JAL ? pc : `MSB'bz;

.... which (coincidentally?) has 6 assign statements... The definitions of
the `PARAMETERS are as follows:

`define ADDSUB (opMajor == 4'b0001)
`define MULTIPLY (opMajor == 4'b0100 & opMinor[1] == 1'b1)
`define DIVIDE (opMajor == 4'b0100 & opMinor[1] == 1'b0)
`define LOGIC (opMajor == 4'b0011)
`define SHIFT (opMajor == 4'b0111)
`define JAL ((opMajor == 4'b0000) & (opMinor == 4'b0000))

.... which seem orthogonal. Is the synthesis tool complaining because there
are conflicts between the modules, then ? Icarus verilog seemed to handle it
all in its' stride while simulating (though I know that's no guarantee :) I
was under the impression that a port declared inout could be assigned
multiple times, if it only has one driver at a time, and if all others drive
it to Z. Presumably I'm not managing to keep it to one driver across all the
modules, then ?

Cheers,
Simon
 
On Sat, 21 Aug 2004 18:08:26 +0000, Simon wrote:

Was wondering if anyone would be kind enough to help me out here - I've been
struggling with a synthesis problem in Webpack, and would appreciate being
pointed in the right direction :)

XST is telling me:

WARNING:Xst:528 - Multi-source in Unit <cpu> on signal <data<31>> not
replaced by logic
Sources are: data<31>5:data<31>, data<31>4:data<31>, data<31>3:data<31>,
data<31>2:data<31>, data<31>1:data<31>, data<31>:data<31
WARNING:Xst:528 - Multi-source in Unit <ramController> on signal
dataOut<31>> not replaced by logic
Sources are: I181_0:O, I180_0:O
Multi source errors occur because you are setting a signal in two
different always blocks, the most common cause of this is doing the reset
in one block and doing an assignment in a different block. This is legal
behavioral code (although a bad idea) but it's not synthesizable which is
why simulators don't object but synthesis tools to.
 
On Sat, 21 Aug 2004 18:08:26 +0000, Simon wrote:

Was wondering if anyone would be kind enough to help me out here - I've
been
struggling with a synthesis problem in Webpack, and would appreciate
being
pointed in the right direction :)

XST is telling me:

WARNING:Xst:528 - Multi-source in Unit <cpu> on signal <data<31>> not
replaced by logic
Sources are: data<31>5:data<31>, data<31>4:data<31>, data<31>3:data<31>,
data<31>2:data<31>, data<31>1:data<31>, data<31>:data<31
WARNING:Xst:528 - Multi-source in Unit <ramController> on signal
dataOut<31>> not replaced by logic
Sources are: I181_0:O, I180_0:O

Multi source errors occur because you are setting a signal in two
different always blocks, the most common cause of this is doing the reset
in one block and doing an assignment in a different block. This is legal
behavioral code (although a bad idea) but it's not synthesizable which is
why simulators don't object but synthesis tools to.
Thanks for the help:)

I was going to write this ...

----8<----8<----- cut here ----8<----8<-----
There were no actual 'always' blocks, it was always assigned using 'assign'
with the same sort of construct as below, but I guess that could easily have
the same problems if the conditions were not mutually exclusive throughout
all the modules (though I thought they were...). To test, I commented out
all references to 'data' in the other modules or in fact the reference to
the modules themselves, and I now get only the single error related to this:

WARNING:Xst:528 - Multi-source in Unit <cpu> on signal <data<31>> not
replaced by logic
Sources are: data<31>5:data<31>, data<31>4:data<31>, data<31>3:data<31>,
data<31>2:data<31>, data<31>1:data<31>, data<31>:data<31>
ERROR:Xst:415 - Synthesis failed

The mentions of 'ramController' and 'soc' have disappeared as expected, but
the *only* reference to 'data' being written to within the 'cpu' module is:

assign data = `ADDSUB ? addsub : `MSB'bz;
assign data = `MULTIPLY ? multiply : `MSB'bz;
assign data = `DIVIDE ? divide : `MSB'bz;
assign data = `LOGIC ? logic : `MSB'bz;
assign data = `SHIFT ? shift : `MSB'bz;
assign data = `JAL ? pc : `MSB'bz;

.... as in the first post, with the conditions being assigned orthogonal
values... still confused :-(

'data' appears as an input to another module within 'cpu', but that's just a
RAM and is defined as an 'input' not an 'inout' to the RAM module, so surely
couldn't have any impact on the sources to the 'data' bus...
----8<----- cut here ----8<----8<-----

.... but I've just figured out that in a 32-bit-wide processor, `MSB is
defined to be 31 and the assign statements all need to be of the form:

assign data = `CONDITION ? value : 32'bz;

AAaaaarrrrgggghhhh. Talk about staring you in the face :-(( I'm guessing
then that the message data<31>.. only refers to the 32nd bit of the data
bus, and not [31:0] as I had assumed...

Cheers,
Simon
 
On Sat, 21 Aug 2004 20:03:11 +0000, Simon wrote:

On Sat, 21 Aug 2004 18:08:26 +0000, Simon wrote:

Was wondering if anyone would be kind enough to help me out here - I've
been
struggling with a synthesis problem in Webpack, and would appreciate
being
pointed in the right direction :)

XST is telling me:

WARNING:Xst:528 - Multi-source in Unit <cpu> on signal <data<31>> not
replaced by logic
Sources are: data<31>5:data<31>, data<31>4:data<31>, data<31>3:data<31>,
data<31>2:data<31>, data<31>1:data<31>, data<31>:data<31
WARNING:Xst:528 - Multi-source in Unit <ramController> on signal
dataOut<31>> not replaced by logic
Sources are: I181_0:O, I180_0:O

Multi source errors occur because you are setting a signal in two
different always blocks, the most common cause of this is doing the reset
in one block and doing an assignment in a different block. This is legal
behavioral code (although a bad idea) but it's not synthesizable which is
why simulators don't object but synthesis tools to.


Thanks for the help:)

I was going to write this ...

----8<----8<----- cut here ----8<----8<-----
There were no actual 'always' blocks, it was always assigned using 'assign'
with the same sort of construct as below, but I guess that could easily have
the same problems if the conditions were not mutually exclusive throughout
all the modules (though I thought they were...). To test, I commented out
all references to 'data' in the other modules or in fact the reference to
the modules themselves, and I now get only the single error related to this:

WARNING:Xst:528 - Multi-source in Unit <cpu> on signal <data<31>> not
replaced by logic
Sources are: data<31>5:data<31>, data<31>4:data<31>, data<31>3:data<31>,
data<31>2:data<31>, data<31>1:data<31>, data<31>:data<31
ERROR:Xst:415 - Synthesis failed

The mentions of 'ramController' and 'soc' have disappeared as expected, but
the *only* reference to 'data' being written to within the 'cpu' module is:

assign data = `ADDSUB ? addsub : `MSB'bz;
assign data = `MULTIPLY ? multiply : `MSB'bz;
assign data = `DIVIDE ? divide : `MSB'bz;
assign data = `LOGIC ? logic : `MSB'bz;
assign data = `SHIFT ? shift : `MSB'bz;
assign data = `JAL ? pc : `MSB'bz;

... as in the first post, with the conditions being assigned orthogonal
values... still confused :-(

'data' appears as an input to another module within 'cpu', but that's just a
RAM and is defined as an 'input' not an 'inout' to the RAM module, so surely
couldn't have any impact on the sources to the 'data' bus...
----8<----- cut here ----8<----8<-----

... but I've just figured out that in a 32-bit-wide processor, `MSB is
defined to be 31 and the assign statements all need to be of the form:

assign data = `CONDITION ? value : 32'bz;

AAaaaarrrrgggghhhh. Talk about staring you in the face :-(( I'm guessing
then that the message data<31>.. only refers to the 32nd bit of the data
bus, and not [31:0] as I had assumed...

Cheers,
Simon
Use a case statement inside of an always block or a function.
 
assign data = `ADDSUB ? addsub : `MSB'bz;
assign data = `MULTIPLY ? multiply : `MSB'bz;
assign data = `DIVIDE ? divide : `MSB'bz;
assign data = `LOGIC ? logic : `MSB'bz;
assign data = `SHIFT ? shift : `MSB'bz;
assign data = `JAL ? pc : `MSB'bz;

Replace this portion with

assign data = `ADDSUB ? addsub :
`MULTIPLY ? multiply :
`DIVIDE ? divide :
`LOGIC ? logic :
`SHIFT ? shift :
`JAL ? pc : `MSB'bz;

and it will work.

You can't use multiple assigns on same wire variable.

Kelvin
 
"Kelvin" <thefatcat28@hotmail.com> wrote in message
news:cg99ef$289$1@reader01.singnet.com.sg...
You can't use multiple assigns on same wire variable.
When each of the ?: values was all Z, this idiom used to correctly infer a
set of TBUFs. Now that there are 0.25 TBUF/LUT and plenty of F5, etc.
MUXes, this implementation style is inferior to implementing a MUX tree in
LUTs.

Jan Gray, Gray Research LLC
 
i thought multiple assign to same wire is a syntaz violation.
put it in an always block, and replace assign, it's correct also.

Kelvin



"Jan Gray" <jsgray@acm.org> wrote in message
news:Tl1Wc.115$Y%3.50@newsread2.news.atl.earthlink.net...
"Kelvin" <thefatcat28@hotmail.com> wrote in message
news:cg99ef$289$1@reader01.singnet.com.sg...
You can't use multiple assigns on same wire variable.

When each of the ?: values was all Z, this idiom used to correctly infer a
set of TBUFs. Now that there are 0.25 TBUF/LUT and plenty of F5, etc.
MUXes, this implementation style is inferior to implementing a MUX tree in
LUTs.

Jan Gray, Gray Research LLC
 

Welcome to EDABoard.com

Sponsor

Back
Top