«

Hello,

what if you clock one trigger by std_logic CLK and another by
to_bit(CLK)? What if another clock is to_stdulogic(to_bit(std)). We have
std-to-bit-to-std converter on the clock line in this case. Any VHDL HW
engeneer has a feeling that the conversion is redundant and will be
"optimized out" by synthesizer. In my case, the intermediate value is of
tri-valued type instead of bit, but idea is the same.

Below is the code that intermediately converts an std_logic CLK into a
multibit type and then makes an inverse conversion. The clock never
takes the 3rd value; it is just a convenient way to pass a signal from a
two-valued circuit to a multivalued one that has its clock also
multivalued for convenience. During logic optimization, synthesizer
should replace the 'doniting' converters with a plain wire; so, the
behavour must be like there is a single clock net.

To demonstrate equivalence of the original CLK and the final bitCLK, I
put two regs in pipeline and expect that the following register Q
reproduces the leading D with a single clock cycle delay. Unfortunately,
all RTL simulators I tried (Symphony, Modelthech and my favorite
Active-HDL) agree on something different: Q is fetched the same value as
D simultaneously, without the cycle shift. That is because D is updated
earlier than the clock event reaches Q (I suspect that converter delays
evaluation of clk at Q by 2 delta-cycles). Nevertheless, synthesizer
does not disappoint me: XST removes the unnecessary conversion functions
and gives the implementation the desired pipeline behaviour.

The experiment reveals that simulators 1) refuse to model the FF
behaviour (that requires to fetch the value active at reg input in the
moments preceding the CLK rising edge) 2) nor aim to predict the
synthesised HW behaviour. Nevertheless, the simulators have no
difficulty handling the widely used std-bit conversion:

bitCLK <= std_logic_1164.to_bit(stdlogicCLK);
process begin wait until bitCLK='1'; ...

It is this deceptive success of this given sample that mislead me to my
design. Can you explain why the simulators démarche in case of my
conversion?

I always have problems finding the LRM. Does it require that the sync
clocks are the same wire (not just logically identical)? I have resolved
the issue by balancing the delays (the clock of the first reg is also
null-converted) but it looks fragile and I do not understand why no
balancing is needed in case of std-bit conversion? Or I mistake and the
latter is also unreliable?


use IEEE.STD_LOGIC_1164.ALL;
entity BIST is
port (
CLK: std_logic;
Q: out std_logic
);
end entity;

architecture RTL of BIST is

type TRIVAL is ('U', '0', '1');

FUNCTION BIT_TO_TRIVAL(b: bit) return TRIVAL is -- returns TRIVAL
equivalent of bit
begin
if b = '0' then return '0';
else return '1';
end if;
end function;

signal triCLK: TRIVAL;
signal D: std_logic := '0';

begin


SQUARE_GEN: process
begin
wait until clk = '1';
D <= not D;
end process;

triCLK <= BIT_TO_TRIVAL(to_bit(CLK));

TRIVAL_CLOCKED: block
signal bitCLK: bit;
FUNCTION To_bit ( a : TRIVAL; umap : BIT := '0') RETURN BIT IS
BEGIN
CASE a IS
WHEN '0' => RETURN ('0');
WHEN '1' => RETURN ('1');
WHEN OTHERS => RETURN umap;
END CASE;
END;


begin
bitCLK <= To_bit(triCLK); -- TRIVAL clock to bit

process begin
--wait until CLK='1'; -- this is ok
wait until bitCLK='1'; -- this causes problems
Q <= D;
end process;
end block;

end RTL;



library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
entity BIST_TB is
end entity;

architecture BEH of BIST_TB is
signal CLK: std_logic := '0';
begin
process begin
loop
CLK <= not CLK; wait for 50 ns;
end loop;
end process;

BIST_U: entity work.BIST
port map(CLK);

end architecture;


Thank you for participation.

Thank you for response.


> The conversions don't matter - either in synthesis or simulation.
> The signal assignments do. You can rewrite this with the same type
> throughout for your intermediate clock signals - no conversions -
> and it will do the same. Try it.

Your are right. I've checked that and confirm that these are the
assignmnents rather than conversion or non-std logic that create the
skew problem. It is unbelivable since the assignment looks as a plain
conductor, which is a way simpler than the multilevel conversion, which
is so complex that you may not even recognize the trivial identity
operation in it.


> The simulators are effectively modelling what you wrote as a race condition and
> alerting you that this code gives a likelihood of clock skew. In other words,
> they are correct.
>

Unfortunately, they do not alert. XST sometimes does but not in this case.


> You are lucky that XST implemented it as you expect; it could have decided to
> insert a clock buffer between "clk" and "bitCLK" and then what would happen?
> (XST probably won't ... though different XST versions have put clock buffers in
> different places in the past ... but what about other tools?)

I think all synthesizers are the same: they all do logical optimization.
And, if they put a buffer, they know that logic is identical.
Actually, I believe that they always put buffers on the clock -- it is
so large and what will happen if they do not put the buffers The
proper buffer placement is FPGA supplier concern.



>> I always have problems finding the LRM. Does it require that the sync
>> clocks are the same wire (not just logically identical)?
>
> The LRM doesn't, but good design practice does.
> Generate the clock; then use the same clock for both
> the producer and consumer (of D in this example).

Thank you. Unfortunately, there are the cases where the clock passes
through a block of non-standard logic, like it does in mine case. And,
shouldn't it be the LRM that tells us what the good design practice is?

I was surprised to know that it is the assignment rather than conversion
that causes the simulation clock skew. It is furthermore surprising when
I think of instantiation. The port mapping looks very much like
assigning signals to I/O. Yet, the unbalanced depth hierarchies are not
known to cause the clock skew.

On Thu, 21 Jan 2010 18:42:56 +0200, valentin tihhomirov
<> wrote:

>I was surprised to know that it is the assignment rather than conversion
>that causes the simulation clock skew. It is furthermore surprising when
>I think of instantiation. The port mapping looks very much like
>assigning signals to I/O. Yet, the unbalanced depth hierarchies are not
>known to cause the clock skew.

AAAAAARGH!!!!!!!!!!!!

Yes, your "discovery" is correct, and in fact is a very
fundamental idea in VHDL: when you connect a signal to
a port, the signal OUTSIDE the port and the signal
INSIDE the port are completely merged, and become
one and the same signal.

This is true even if there is a type conversion in the
port map.

This identity of signals on either side of a port
makes it possible, for example, to detect and use
the 'TRANSACTION attribute of a signal in a different
module than that containing the driver.

It is an important difference between VHDL and
Verilog; in Verilog, a unidirectional port generally
looks like a continuous assignment (a buffer) across
the module boundary. Bidirectional ports in Verilog
are merged, just as in VHDL. Unfortunately it's
not that simple, because simulators are entitled
to merge unidirectional ports as an optimization.
Luckily this does not lead to impossible skew
problems, because the buffer delay in Verilog is
actioned earlier than the nonblocking assignment
delay that is normally used for flipflops.

HOWEVER.................

under pressure from <insert names of your enemies here>
VHDL 2008 has permitted expressions in port maps, and
such expressions DO create a delta-cycle delay across
the port. Personally I regard this as a very misguided
move, breaking an important and elegant feature of the
language for the sake of a trivial improvement in
convenience for some kinds of RTL design. But that
is a completely different rant, for another day...
--
Jonathan Bromley
--
Jonathan Bromley, Verification Engineer

Verilab www.THAT_COMPANY.com

On Jan 21, 11:00*am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
> under pressure from <insert names of your enemies here>
> VHDL 2008 has permitted expressions in port maps, and
> such expressions DO create a delta-cycle delay across
> the port. *Personally I regard this as a very misguided
> move, breaking an important and elegant feature of the
> language for the sake of a trivial improvement in
> convenience for some kinds of RTL design. *But that
> is a completely different rant, for another day...
> --
> Jonathan Bromley

Jonathan,

How does a pre-2008 port type conversion function execute without a
delta delay? How are events passed from the one type to the other
without a delta between them?

What if one or both types are resolved types?

I was pretty sure that the Pre-2008 port conversions incurred a delta
delay, but I could very easily be wrong about that... I could see how
an implicit conversion between similar types (e.g. unsigned <-> SLV, a
"cast") could work without a delta, but not an arbitrary, explicit
conversion function (e.g. SL to boolean).

Andy

Jonathan Bromley wrote:
> On Thu, 21 Jan 2010 18:42:56 +0200, valentin tihhomirov
> <> wrote:
>
>> I was surprised to know that it is the assignment rather than conversion
>> that causes the simulation clock skew. It is furthermore surprising when
>> I think of instantiation. The port mapping looks very much like
>> assigning signals to I/O. Yet, the unbalanced depth hierarchies are not
>> known to cause the clock skew.
>
> AAAAAARGH!!!!!!!!!!!!
>
> Yes, your "discovery" is correct, and in fact is a very
> fundamental idea in VHDL: when you connect a signal to
> a port, the signal OUTSIDE the port and the signal
> INSIDE the port are completely merged, and become
> one and the same signal.
>
> This is true even if there is a type conversion in the
> port map.
>
> This identity of signals on either side of a port
> makes it possible, for example, to detect and use
> the 'TRANSACTION attribute of a signal in a different
> module than that containing the driver.
>
> It is an important difference between VHDL and
> Verilog; in Verilog, a unidirectional port generally
> looks like a continuous assignment (a buffer) across
> the module boundary. Bidirectional ports in Verilog
> are merged, just as in VHDL. Unfortunately it's
> not that simple, because simulators are entitled
> to merge unidirectional ports as an optimization.
> Luckily this does not lead to impossible skew
> problems, because the buffer delay in Verilog is
> actioned earlier than the nonblocking assignment
> delay that is normally used for flipflops.
>
> HOWEVER.................
>
> under pressure from <insert names of your enemies here>
> VHDL 2008 has permitted expressions in port maps, and
> such expressions DO create a delta-cycle delay across
> the port. Personally I regard this as a very misguided
> move, breaking an important and elegant feature of the
> language for the sake of a trivial improvement in
> convenience for some kinds of RTL design. But that
> is a completely different rant, for another day...


One of the "enemies" desired the expressions was me:
http://groups.google.ee/group/comp.l...964f76d0b64cc2
and
http://groups.google.ee/group/comp.l...4b103de6179efa

Yet, my confusion goes deeper as VHDL experts tell the strange things
like expressions must incur a delay (why?) if Brain just pointed out
that the conversions do not impose any. May be it is appropriate place
to inform the reader that I have resolved my problem by using

wait until multivaluedCLK = '1';

construction. It is considerably more concise and less fragile than
keeping the balancing the assignments.

On Thu, 21 Jan 2010 10:09:52 -0800 (PST), Andy wrote:

>How does a pre-2008 port type conversion function execute without a
>delta delay? How are events passed from the one type to the other
>without a delta between them?

Well... if asked to hazard a guess, I'd say that...
- on input, the signal inside the module is rewritten to be
of the "outside" type, and all readers inside the module
get the incoming conversion automatically applied;
- on output, the signal inside is likewise rewritten to be
of the "outside" type, and the value presented by each
driver inside the module automatically suffers the outgoing
conversion before being applied to the signal.
In this way, events pass through unharmed but values are mapped.

>What if one or both types are resolved types?
See above; the conversion can be per-reader and per-writer.
I don't actually know, but I guess on output the inside type's
resolution function could be applied to all the inside drivers,
and then the result converted before being sent to the outside
type's resolution function.

>I was pretty sure that the Pre-2008 port conversions incurred a delta
>delay,

You panicked me with your post, so I tried it just to be sure.
Try this... the signal assignment incurs a delta delay (of course)
and so you see differences between s_bo and p_bo, but the
converted port p_bi and unconverted p_bo always match.
And it's a custom conversion function :-0

package p is
function to_bit(b: boolean) return bit;
end;

package body p is
function to_bit(b: boolean) return bit is
begin
if b then return '1'; else return '0'; end if;
end;
end;

use work.p.all;
entity e is
port (p_bi: in bit; p_bo: in boolean);
end;
architecture a of e is
signal s_bo: boolean;
begin
s_bo <= p_bo;
process(p_bi, p_bo)
begin
if p_bi = to_bit(p_bo) then
report "OK: " & bit'image(p_bi) & ", " & boolean'image(p_bo);
else
report "??: " & bit'image(p_bi) & ", " & boolean'image(p_bo);
end if;
end process;
process(s_bo, p_bo)
begin
if s_bo = p_bo then
report "OK: " & boolean'image(s_bo) & ", " &
boolean'image(p_bo);
else
report "??: " & boolean'image(s_bo) & ", " &
boolean'image(p_bo);
end if;
end process;
end;

use work.p.all;
entity tb is end;
architecture a of tb is
signal b: boolean;
begin
b <= TRUE after 1 ns, FALSE after 2 ns, TRUE after 3 ns;
test: entity work.e port map (p_bi => to_bit(b), p_bo => b);
end;

--
Jonathan Bromley
--
Jonathan Bromley, Verification Engineer

Verilab www.THAT_COMPANY.com

On Jan 21, 12:55*pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
> On Thu, 21 Jan 2010 10:09:52 -0800 (PST), Andy wrote:
> >How does a pre-2008 port type conversion function execute without a
> >delta delay? How are events passed from the one type to the other
> >without a delta between them?
>
> Well... if asked to hazard a guess, I'd say that...
> * - on input, the signal inside the module is rewritten to be
> * * of the "outside" type, and all readers inside the module
> * * get the incoming conversion automatically applied;
> * - on output, the signal inside is likewise rewritten to be
> * * of the "outside" type, and the value presented by each
> * * driver inside the module automatically suffers the outgoing
> * * conversion before being applied to the signal.
> In this way, events pass through unharmed but values are mapped.
>
> >What if one or both types are resolved types?
>
> See above; the conversion can be per-reader and per-writer.
> I don't actually know, but I guess on output the inside type's
> resolution function could be applied to all the inside drivers,
> and then the result converted before being sent to the outside
> type's resolution function.
>
> >I was pretty sure that the Pre-2008 port conversions incurred a delta
> >delay,
>
> You panicked me with your post, so I tried it just to be sure.
> Try this... *the signal assignment incurs a delta delay (of course)
> and so you see differences between s_bo and p_bo, but the
> converted port p_bi and unconverted p_bo always match.
> And it's a custom conversion function :-0
>
> package p is
> * function to_bit(b: boolean) return bit;
> end;
>
> package body p is
> * function to_bit(b: boolean) return bit is
> * begin
> * * if b then return '1'; else return '0'; end if;
> * end;
> end;
>
> use work.p.all;
> entity e is
> * port (p_bi: in bit; p_bo: in boolean);
> end;
> architecture a of e is
> * signal s_bo: boolean;
> begin
> * s_bo <= p_bo;
> * process(p_bi, p_bo)
> * begin
> * * if p_bi = to_bit(p_bo) then
> * * * report "OK: " & bit'image(p_bi) & ", " & boolean'image(p_bo);
> * * else
> * * * report "??: " & bit'image(p_bi) & ", " & boolean'image(p_bo);
> * * end if;
> * end process;
> * process(s_bo, p_bo)
> * begin
> * * if s_bo = p_bo then
> * * * report "OK: " & boolean'image(s_bo) & ", " &
> boolean'image(p_bo);
> * * else
> * * * report "??: " & boolean'image(s_bo) & ", " &
> boolean'image(p_bo);
> * * end if;
> * end process;
> end;
>
> use work.p.all;
> entity tb is end;
> architecture a of tb is
> * signal b: boolean;
> begin
> * b <= TRUE after 1 ns, FALSE after 2 ns, TRUE after 3 ns;
> * test: entity work.e port map (p_bi => to_bit(b), p_bo => b);
> end;
>
> --
> Jonathan Bromley
> --
> Jonathan Bromley, Verification Engineer
>
> Verilab *www.THAT_COMPANY.com

Fair enough; thanks for the explanation!

"Learn something new every day."

Andy

On Thu, 21 Jan 2010 11:37:53 -0800 (PST), Andy wrote:

>"Learn something new every day."

I try; honestly, I try. But as I get older, the
learning process becomes less comfortable.
Increasingly I depend on the youngsters to keep
me honest and to show me the places I still need
to learn more...
--
Jonathan Bromley
--
Jonathan Bromley, Verification Engineer

Verilab www.THAT_COMPANY.com

On Thu, 21 Jan 2010 20:32:07 +0200, valentin tihhomirov wrote:

>Yet, my confusion goes deeper as VHDL experts tell the
> strange things like expressions must incur a delay (why?)

Expressions *in a port map* incur a delta delay, because
the port map

instance: some_component port map (e_port => expression, ...);

is equivalent to

temp_signal <= expression; -- here is the delta delay
instance: some_component port map (e_port => temp_signal, ...);

Note that the delay is caused by the signal assignment -
it is NOT caused by the expression itself. An expression
is merely a calculation and it takes place in zero time,
without a delta delay.

> I have resolved my problem by using
>
> wait until multivaluedCLK = '1';

How is this different from any other way of
sensing an event on multivalueCLK ???
--
Jonathan Bromley
--
Jonathan Bromley, Verification Engineer

Verilab www.THAT_COMPANY.com