Delta delay problem between multiple ports

[Trygve Odegaard]

I have Module1 with an output port ClkA.
Module1 is instantiated in Module2 that has the two output ports ClkA
and ClkB.


mapping Module1.ClkA to either module2.ClkA or Module2.ClkB without
delta delay is easy.

But, is there any VHDL constructs, such that: Module1.ClkA can be
mapped to both Module2.ClkA and Module2.ClkB without any

delta delay difference between these 3 ?

Thanks in advance
Trygve

 

[Thomas Stanka]

On 28 Mai, 16:21, Trygve Odegaard <tro...@start.no> wrote:

I have Module1 with an output port ClkA.
Module1 is instantiated in Module2 that has the two output ports ClkA
and ClkB.
But, is there any VHDL constructs, such that: Module1.ClkA can be
mapped to both Module2.ClkA and Module2.ClkB without any

delta delay difference between these 3 ?

Question: Why do you bother about delta delays?
Use "Y <= X after 1 ns" for clocked signals and you have no problem
with delta delays.

There is no construct for signal assignment, that is free of delta
delay, only variables are updated in the same tick, but I would'nt use
variables for clocks, as i find it no good idea to have a rising edge
of clock within one delta delay (would'nt suprise me, if the tools
wouldn't support this propperly).

bye Thomas

 

[Trygve Odegaard]

On 30 Mai, 06:53, Thomas Stanka <usenet_nospam_va...@stanka-web.de>
wrote:

On 28 Mai, 16:21, Trygve Odegaard <tro...@start.no> wrote:

I have Module1 with an output port ClkA.
Module1 is instantiated in Module2 that has the two output ports ClkA
and ClkB.
But, is there any VHDL constructs, such that:  Module1.ClkA can be
mapped to both Module2.ClkA and Module2.ClkB without any

delta delay difference  between these 3 ?

Question: Why do you bother about delta delays?
Use "Y <= X after 1 ns" for clocked signals and you have no problem
with delta delays.

There is no construct for signal assignment, that is free of delta
delay, only variables are updated in the same tick, but I would'nt use
variables for clocks, as i find it no good idea to have a rising edge
of clock within one delta delay (would'nt suprise me, if the tools
wouldn't support this propperly).

bye Thomas

My Module1 output data ( delta synchronously with clkA) in addition to
clkA. At he output of module2,
I still want both to be delta-synchronous, which is no problem. I
have already experienced how hard it is to debug HW-failures when the
simulation-OK is due to a architechually deeply buried delta offset.
The simple case with clock & data only, gives me no problem. The
problem arise when I want to take a clock, and split into two copies
at the next-higher level, still with all three copies at the same
delta.
Regards Trygve

 

[Tricky]

On 28 May, 15:21, Trygve Odegaard <tro...@start.no> wrote:

I have Module1 with an output port ClkA.
Module1 is instantiated in Module2 that has the two output ports ClkA
and ClkB.

mapping Module1.ClkA to either module2.ClkA or Module2.ClkB without
delta delay is easy.

But, is there any VHDL constructs, such that: Module1.ClkA can be
mapped to both Module2.ClkA and Module2.ClkB without any

delta delay difference between these 3 ?

Thanks in advance
Trygve

There is no way to avoid adding delta delays with signal assignments.
SingalB <= SignalA will always add a 1 delta delay. Its unavoidable.

I still dont understand why you are so worried. Delta delays are
infinitely small, so have no meaning in reality. If you are having
problems with variables updating, then I suggest that you are
triggering a process in the wrong way.

To align deltas in processes, you can add 1 delta wait states:
wait for 0 ns; will hold a process for 1 delta.

 

[Mike Treseler]

Trygve Odegaard wrote:

The simple case with clock & data only, gives me no problem. The
problem arise when I want to take a clock, and split into two copies
at the next-higher level, still with all three copies at the same
delta.

The system clock should never appear
on the right side of an assignment,
or on a port output.

-- Mike Treseler

 

[Dal]

You can put a delta on the data to match those suffered by splitting
the clocks. Use local signals in the module2 architecture;

module2_ClkA <= module1_ClkA;
module2_ClkB <= module1_ClkA;
module2_data <= module1_data;

where module1_* are signals connected to the module1 instantiation
port map and module2_* are the module2 port names.

Obviously this only works if module2_data is an 'out' and not 'inout'.

Darrin

 

[Brian Drummond]

On Fri, 30 May 2008 10:08:28 -0700, Mike Treseler
<mike_treseler@comcast.net> wrote:

Trygve Odegaard wrote:

The simple case with clock & data only, gives me no problem. The
problem arise when I want to take a clock, and split into two copies
at the next-higher level, still with all three copies at the same
delta.

The system clock should never appear
on the right side of an assignment,
or on a port output.

Agreed.

But tell that to certain IP providers, or memory vendors with free VHDL
simulation models, which do strange things to the unwary.

I have occasionally had to resort to the "... after 1 ns" kludge on
external ports, to make simulations do something sensible, safe in the
knowledge the synthesis tool will ignore it.

To the OP : the delta cycle matching approach will cause trouble. It is
cleaner to take a local clock to the top level, assign it to system
clock, and distribute that ONE copy everywhere including back down to
the block that generated it. For blocks within an FPGA or ASIC, it won't
cost you extra pins or hardware resources.

Interfacing to external devices, or badly written internal IP, may
require devious behaviour (If I can't clean it up, I like to wrap such
IP in a simple wrapper entity which disguises it as clean IP).

- Brian

 

[Thomas Stanka]

On 30 Mai, 19:08, Mike Treseler <mike_trese...@comcast.net> wrote:

The system clock should never appear
on the right side of an assignment,
or on a port output.

Unless you intend to do so with reason (and knowing what to do).
I had several designs where it is necessary to have the clock on right
hand side of assignments or provide internal clocksignals at an
output.

bye Thomas