an error on multi-source, but I can't understand...

[Neil]

Hi, All,
I encounter an error when synthesis with ISE 7.1i webpack.

-- ************************************************ --
-- part of the code as follow: --

-- process a --
a: process(clk,reset)
begin
if reset='1' then
LoadA<='0';
wr<='0';
elsif clk'event and clk='1' then
if wr='1' and TxBusy='0' then
... ...
-- more code here --
... ...
end if;
end if;
end process;

-- process b --
b: process(clk,reset)
begin
if reset='1' then
ReadA<='0';
rdReq<='0';
elsif clk'event and clk='1' then
if RxData=x"01" then
wr<='1';
... ...
... ...
elsif RxData=x"02" then
wr<='0';
... ...
... ...
end if;
end if;
end process;

-- ************************************************ --

the error is:"Xst:528 - Multi-source in Unit <...> on signal <wr>".
but I don't find any multi-source for it, and these two processes are
only triggered by clk or reset.

And if I move the assignment "wr <= '0';" from process a to process b,
and also place it under "if reset = '1'" clause, the error disappears.
What's the difference between them? I can't understand... Can anyone
help me explain it? Thank you!

Regards!
-- Neil

 

[Ralf Hildebrandt]

-- process a --
a: process(clk,reset)
begin
if reset='1' then
LoadA<='0';
wr<='0'; ....
end process;

-- process b --
b: process(clk,reset)
begin ....
elsif clk'event and clk='1' then
if RxData=x"01" then
wr<='1'; ....
end process;

-- ************************************************ --

the error is:"Xst:528 - Multi-source in Unit <...> on signal <wr>".
but I don't find any multi-source for it

For me it was very easy to find it: You write to wr from both processes.

Every process generates a signal driver.

Furtunately you use an unresolved data type for wr and therefore you got
this error.

What do you think this can be in hardware? Two flipflops driving the
same wire? There is only one exception where this makes sense: Tri-state
drivers.


Hint: It does not matter, that wr gets a value assigned in the
reset-clause in the 1st process and in the edge-sensitive clause in the
2nd process. For a HDL you have written two drivers and in real world it
would be a fixed '0' at the 1st wire and a flipflop (without
asynchronous set/reset) for the 2nd wire. Both wires are connected,
which is impossible.

Ralf

 

[Neil]

Hi, Ralf
I'm a beginner in VHDL, and I can't understand your explanation well...

Even each process will generate a signal driver for the signal
separately, there is also assert function / assert signal to determin
the value of the signal at that time. So why does it mean is there two
wire in real world? It always has only one proper value at a time...

And if "wr <= '0';" is placed in the reset-clause in the process b, how
many wires are there? one or two?
And how to know how many wires will be gotten for a signal in the real
world? Thank you!

Regards!
-- Neil

 

[ajahn]

Hi Neil,
try to see every process and every concurrent assignment in your block
as a black box. Signals are the wires between them. If you assign
values to signals in such a box, you produce a driver to a wire
(signal). It does not matter, that you only assign a value during
reset, once you write to the signal, the driver is there. If you assign
a value only during reset, you actually produce a flipflop that is
reset to some value and then drives this value all the time. This is
then optimized in a synthesis tool so that the flipflop becomes a
constant driver.
The thing with hdl's is you have to try to think hardware not just
"program" something...

I hope that helps you a bit..
Andreas

 

[Neo]

in short remove the statement "wr<='0'; " from the process-a and put it
in process-b

 

[Ralf Hildebrandt]

I'm a beginner in VHDL, and I can't understand your explanation well...

Even each process will generate a signal driver for the signal
separately, there is also assert function / assert signal to determin
the value of the signal at that time. So why does it mean is there two
wire in real world? It always has only one proper value at a time...

And if "wr <= '0';" is placed in the reset-clause in the process b, how
many wires are there? one or two?
And how to know how many wires will be gotten for a signal in the real
world? Thank you!

Let me explain with a flipflop as an example.
In VHDL a FF is coded like:
---
process(reset, clock)
begin
if (reset = '0') then
ff<='0';
elsif rising_edge(clock) then
ff<=data_in;
end if;
end process;
---
In real world this can be represented as a D-flipflop with asynchornous
low-active reset:
_____
data_in __| |__ ff
clock __|D-FF |__ NOT(ff)
|_____|
o
|
reset




If you write
---
A : process(reset, clock)
begin
if (reset = '0') then
ff<='0';
elsif rising_edge(clock) then
-- ff<=data_in;
end if;
end process A;
---
this will be a wire

'0' __________ ff





If you write
---
B : process(reset, clock)
begin
if (reset = '0') then
-- ff<='0';
elsif rising_edge(clock) then
ff<=data_in;
end if;
end process B;
---
this will be a D-flipflop without reset:
_____
data_in __| |__ ff
clock __|D-FF |__ NOT(ff)
|_____|





If you write both processes A and B this will result in

'0' ___________
|
_____ |
data_in __| |__|__ ff
clock __|D-FF |__ NOT(ff)
|_____|

And now guess, what will happen if you do this.



This is the reason, why you are not allowed to write to one signal from
more than process in VHDL.
(O.k. if you are going to model a tri-state bus you have to do exactly
this, but then you usually know what you are doing and a resolved data
type will let you do this.)


Ralf

 

[ajahn]

Ralf, I don't think, process a will be a wire. It will rather be a FF
with output looped back to its input and an async reset. If you
simulate it, the behavior would be to have 'U' assigned to it upon
simulator initialization and '0' during and all the time after reset. A
wire would be '0' all the time... like a concurrent wr <= '0'; .
Of course synthesis tools will optimize this to be a wire....

Cheers,
Andreas.

 

[Ralf Hildebrandt]

Ralf, I don't think, process a will be a wire. It will rather be a FF
with output looped back to its input and an async reset. If you
simulate it, the behavior would be to have 'U' assigned to it upon
simulator initialization and '0' during and all the time after reset.

Good point - I think you are right.

The conclusion (multiple drivers) stays valid.

Ralf

 

[Andy Peters]

Hi, All,
I encounter an error when synthesis with ISE 7.1i webpack.

-- ************************************************ --
-- part of the code as follow: --

-- process a --
a: process(clk,reset)
begin
if reset='1' then
LoadA<='0';
wr<='0';

wr is assigned here ...

elsif clk'event and clk='1' then
if wr='1' and TxBusy='0' then
... ...
-- more code here --
... ...
end if;
end if;
end process;

-- process b --
b: process(clk,reset)
begin
if reset='1' then
ReadA<='0';
rdReq<='0';
elsif clk'event and clk='1' then
if RxData=x"01" then
wr<='1';

... and here ...

... ...
... ...
elsif RxData=x"02" then
wr<='0';
... ...
... ...
end if;
end if;
end process;

Simple reason for the synthesis complaint: Your problem is that you're
assigning the same signal in two processes. If you want to generate
real hardware, you can't do that.

-a

 

[Neil]

Now, I almost get it.
Thank you, All

 

[flaving]

i have a device with two components wich use same registers and flags, so i need registers have more sources...how to resolve the problem of multi source???

 

[vipinlal]

hope this helps..
vhdlguru.blogspot.com/2010/03/synthesis-error-signal-is-connected-to.html