VHDL Simulation delays

Hi everybody,
I am new to VHDL and have just started tackling the VHDL simulation. I
have read that in signal assignments of the type:

a <= b after 10 ns;

the 'after' clause is ignored in synthesis. Ok, but when should I use
such clauses in the simulation? They are very useful in the
testbenches, but when and why should I use such clauses in the VHDL
sources that will be later synthesized? Also, I am using XST from
Xilinx, here is an excerpt from the synthesis report:

Minimum period: 2.546ns (Maximum Frequency: 392.773MHz)
Minimum input arrival time before clock: No path found
Maximum output required time after clock: 7.683ns
Maximum combinational path delay: No path found

Can anyone tell me how the frequency is computed? Is this the maximum
frequency that my design is able to operate at? What influences the
maximum frequency?
Also, what is the meaning of "mininum input arrival time"(probably the
time before the clock that an input signal must be stable and valid?),
"maximum output required time after clock"(maybe the time after clock
that an output signal must remain stable and valid?) and "maximum
combinational path delay"(maybe the largest combinational path - but
path between what signals - inputs and outputs defined in the 'ports'
section of the top level entity)?
Thank you in advance!

Best regards,
Stoyan Shopov

stoyan.shopov@gmail.com

wrote:


> I am new to VHDL and have just started tackling the VHDL simulation. I
> have read that in signal assignments of the type:
>
> a <= b after 10 ns;
>
> the 'after' clause is ignored in synthesis. Ok, but when should I use
> such clauses in the simulation? They are very useful in the
> testbenches, but when and why should I use such clauses in the VHDL
> sources that will be later synthesized?

Then let me ask you one thing: What is the difference between a
testbench and a VHDL source?

I can't see one, as the testbench is also VHDL.

All parts of your project, that are going to be synthesized have to
avoid the after-clause. All others may use it.
This includes using the after clause in a subcomponent during the design
process if you are doing top-down design modelling and the subcomponent
will be modelled in a synthesizable way later.



But ... well ... I use the after-clause very seldom and avoid it even if
I do top-down modelling. Even big parts of my testbenches are
synthesizable.
I don't like to model a component in a non-synthesizable way if I have
to model it later in a synthesizable way, because the conversion often
leads to unforseen problems.

Ralf

Ralf Hildebrandt

wrote:
> Hi everybody,
> I am new to VHDL and have just started tackling the VHDL simulation. I
> have read that in signal assignments of the type:
>
> a <= b after 10 ns;
>
> the 'after' clause is ignored in synthesis. Ok, but when should I use
> such clauses in the simulation?

I use them very rarely as it makes testbench
synchronization very difficult. I prefer
a main testbench process as shown below.

-- Mike Treseler

---------------------------------------------
main : process is
---------------------------------------------
procedure tic is
begin
wait until rising_edge(clk_s);
end procedure tic;
---------------------------------------------
begin
a <= b;
tic;
-- everything else;
wait;
end process main;
---------------------------------------------

Mike Treseler

Mike Treseler wrote:
> wrote:
>
>> Hi everybody,
>> I am new to VHDL and have just started tackling the VHDL simulation. I
>> have read that in signal assignments of the type:
>>
>> a <= b after 10 ns;
>>
>> the 'after' clause is ignored in synthesis. Ok, but when should I use
>> such clauses in the simulation?
>
>
> I use them very rarely as it makes testbench
> synchronization very difficult. I prefer
> a main testbench process as shown below.
>
> -- Mike Treseler
>
> ---------------------------------------------
> main : process is
> ---------------------------------------------
> procedure tic is
> begin
> wait until rising_edge(clk_s);
> end procedure tic;
> ---------------------------------------------
> begin
> a <= b;
> tic;
> -- everything else;
> wait;
> end process main;
> ---------------------------------------------

Mike,
A rough equivalent to your code would be

main: process (clk)
begin
if (rising_edge(clk)) then
a <= b;
end if;
end process;

However, the problem is a gets assigned *exactly* at the clock, which
is not what happens in the real world (due to setup time). Here, an
"after" clause on the assignment would help simulate that. For example,
one of my designs interfaces with a QL5064 chip, whose datasheet says
that the chip's control bus signals have a 4 ns setup time. So in my
test bench, I use "data <= data_int after 4 ns;"
-Jim

Jim George

Jim George wrote:

> A rough equivalent to your code would be
> main: process (clk)
> begin
> if (rising_edge(clk)) then
> a <= b;
> end if;
> end process;

True, except for the -- everything else part. See:
http://home.comcast.net/~mike_treseler/test_uart.vhd
for a full example of this style of synchronous testbench.

> However, the problem is a gets assigned *exactly* at the clock,
> which is not what happens in the real world (due to setup time).

But it is what happens in a synchronous simulation
of the real word. Real clock to Q delays become delta delays.
The DUT provides synchronization of all inputs that
need it.

> Here,
> an "after" clause on the assignment would help simulate that. For
> example, one of my designs interfaces with a QL5064 chip, whose
> datasheet says that the chip's control bus signals have a 4 ns setup
> time. So in my test bench, I use "data <= data_int after 4 ns;"

Nothing wrong with that.

Synchronized inputs and static timing analysis
are my preference to verify the setup and holds.

This testbench style is not synthesizable like Ralf's.
It just works works like one that is -- but a
little easier for me to read.

-- Mike Treseler

Mike Treseler

> True, except for the -- everything else part. See:
> http://home.comcast.net/~mike_treseler/test_uart.vhd
> for a full example of this style of synchronous testbench.

OK, that example made it clear what kinda stuff could go into
"--everything else". Thanks!

Jim George