problem with two sources

[arti]

Hello
I make a project "synchrous 4-bit up/down binary counter with dual clock
and clear" and I have a problem
I made two procesess :
---UP --
up: process (Clk_UP) is
variable temp : unsigned(3 downto 0) ;
begin
if reset ='1' then
temp := (others => '0') ;
elsif falling_edge(Clk_UP) then
temp := temp + 1;
end if ;
CoutQ <= std_ulogic_vector(temp) ; --LINE 45
end process;

-- DOWN --
down: process (Clk_DOWN) is
variable temp : unsigned(3 downto 0) ;
begin
if reset ='1' then
temp1 := (others => '0') ;
elsif falling_edge(Clk_UP) then
temp := temp - 1;
end if ;
CoutQ <= std_ulogic_vector(temp) ; -- LINE 58
end process;

first process is counting up second down but when i compile this project I
have error
# Error: ELBWRITE_0028: behavioral74f193a.vhd : (58, 0): Signal "coutQ" has
two sources, but is not resolved signal (at line 58: coutQ & at line 45:
coutQ).
How can I resolve this problem ??

regards
arti

 

[Ralf Hildebrandt]

arti wrote:

I make a project "synchrous 4-bit up/down binary counter with dual clock
and clear" and I have a problem

-> a mux for the two clocks
-> a mux for the incrementer and the decrementer
-> 4 flipflops, clocked with the muxed clock and reseted with the clear-signal

I made two procesess :

first process is counting up second down but when i compile this project I
have error
# Error: ELBWRITE_0028: behavioral74f193a.vhd : (58, 0): Signal "coutQ" has
two sources, but is not resolved signal (at line 58: coutQ & at line 45:
coutQ).
How can I resolve this problem ??

Do not write to one signal from two sources - except you are modelling a tri-state bus.
What do you expect the hardware will be, if you do such things?

=> Move everything into one process.

Ralf

 

[arti]

=> Move everything into one process.

Thanks, I did it and I have other problems

1) I don't know how can I start It at only first time with for example Cin
= 0 ? , because I have CoutQ = U but I want CoutQ = 0
2) When I set signal load =1 process doesn't see this .

P0: process (Clk_DOWN,Clk_UP) is
variable temp : unsigned(3 downto 0) ;
begin
temp := unsigned(CoutQ) ;
if reset ='1' then
temp := (others => '0') ;
elsif
falling_edge(load) then
temp := unsigned(Cin) ;
elsif
falling_edge(Clk_DOWN) then
temp := temp - 1;
elsif falling_edge(Clk_UP) then
temp := temp + 1;
end if ;
CoutQ <= std_ulogic_vector(temp) ;
end process;

ps I try to project counter SN74F193a from www.ti.com

 

[jens]

The answer to both of your questions is that reset and load aren't in
your sensitivity list.

Assuming you're trying to exactly model the part, you can AND the
clocks together, use the combined clock as the counter clock, and use
the falling edges or low levels of UP or DOWN to determine whether to
count up or down at the next combined clock.

 

[arti]

The answer to both of your questions is that reset and load aren't in
your sensitivity list.

Yes and they can't be because it is synchrous counter only when clock
change, process check load and reset signals .

Assuming you're trying to exactly model the part, you can AND the
clocks together, use the combined clock as the counter clock, and use
the falling edges or low levels of UP or DOWN to determine whether to
count up or down at the next combined clock.

Could you give me example , I don't have any idea how to do this , this is
my first VHDL program.

 

[Rob Dekker]

Hi Arti,

Looking at the schematic :
http://focus.ti.com/lit/ds/symlink/sn74f193a.pdf
it seems to me that both CLR and LOAD are a-synchronous.
So these have to be on your sensitivity list.....

The only part synchronous in the counting itself.
That is done with two clocks, reduced to a single one using an AND and an RS latch.
That is not 'synthesizable' in standard synthesis tools (yet), but you can write
the simulation model for that in HDL with the two edge conditions
that you already use. So something like this :

if (reset)
...
elsif (load)
...
elsif (rising_edge(clk1))
...
elsif (rising_edge(clk2))
...
end if

should be pretty close..

Rob

 

[kedarpapte]

Hi Arti,

I suppose you are a student.
so I will request you to please read multiple number of times.
every thing can be understandable, easy and enjoyable, try to visualise
hardware first before coding.
HDLs are to realise hardware.
don't ignore it by saying a grand paa's advice, it is practical.

any signal(sync. or async.) should be in sensitivity list to reflect
it's effect in simulation. The code may generate hardware but then
there will be a synth. simulation mismatch.

Thanks & regards,
Kedar

 

[Ralf Hildebrandt]

arti wrote:

1) I don't know how can I start It at only first time with for example Cin
= 0 ? , because I have CoutQ = U but I want CoutQ = 0
2) When I set signal load =1 process doesn't see this .

P0: process (Clk_DOWN,Clk_UP) is
variable temp : unsigned(3 downto 0) ;
begin
temp := unsigned(CoutQ) ;
if reset ='1' then
temp := (others => '0') ;

This is an asynchronous reset - so it _must_ be in the sensitivity list.

elsif
falling_edge(load) then
temp := unsigned(Cin) ;
elsif
falling_edge(Clk_DOWN) then
temp := temp - 1;

Don't use more than _one_ edge-Trigger! What you are describing is a dual-edge flipflop.
Synthesis does not support this - except for only a few tools. Almost all libraries do not
have dual-edge ffs.

Do as I told you: Model a multiplexer for the clock.

muxed_clk <= clk_1 when clk_selecter='1' else clk_2;

Not that this description is not hazard free - so be careful, if nessecary.

When I told you "Move everything into one process." I was a little bit unpreceise. Do it
for every stuff, that writes to CoutQ. Do the other stuff (muxes) in seperate processes /
cuncurrent statements.

In my 1st answer I gave you the hint, what parts you have to model. 3 things are to be
modelled - put them into 3 processes.

And last of all: Why do you write to one variable and always copy it finally to CoutQ? You
could also write to CoutQ - it would be more readable. (Eliminate temp.)


Ralf

 

[Andy]

No! Only causal signals (signals that immediately affect the output)
should be in the sensitivity list, like async resets and clocks. Since
the hardware never reacts to a change in value of a non-causal input
(i.e. 'D' input), there is no need to make the simulation model react
to it either. The current value of D is only important when some
causal input changes.

This is especially important since modern simulators merge multiple
processes that are sensitive to the same set of signals, reducing
process dispatch overhead, and approaching cycle-based performance
(ever wonder what happened to cycle-based simulators?). If every
process has a different sensitivity list, no such merging can happen.
This is a big reason to avoid separate combinatorial and register
processes (and concurrent assignments, if possible) too.

HDLs are for more than synthesizing hardware! Simulation models are
often much more efficient and more easily written/understood if the
synthesizable rule book is thrown out!

But I do agree, if you're designing hardware, think hardware.

So, if the OP's task is to write a simulation model of the 'f193a, then
non-synthesizable techniques are best. But if their task is to
synthesize an 'f193a, then by all means, write synthesizable code for
the target architecture.

Andy

 

[Andy]

If CoutQ is an output port, he cannot read it, thus the need for temp.

There are other ways to synthesize the behaviour that he has (including
an edge sensitive load command), without gating the clock, while using
d-type flops, in one process.

process (rst, load, clkup, clkdwn)
variable a,b,c,temp : unsigned (coutq'range);
begin
if rst = '1' then
a := (others => '0');
b := (others => '0');
c := (others => '0');
elsif falling_edge(load) then
c := unsigned(cin) xor a xor b;
elsif rising_edge(clkup) then
a := temp + 1 xor b xor c; -- encode temp + 1
elsif rising_edge(clkdwn) then
b := temp - 1 xor a xor c; -- encode temp - 1
end if;
temp := a xor b xor c; -- decode temp (combinatorial)
coutq <= std_logic_vector(temp); -- output coutq
end process;

Note that the 'f193 a has a level sensitive load, so this edge
sensitive implementation is not quite the same, but matches the OP's
behaviour.

Andy