configuration of generic - again?

I have a testbench which simulates my rtl design.

Then I synthesize (synplify) the rtl code and get a netlist, but also a
".vhm" file which
is a netlist description in vhdl of the synhtesis result.
Great, I use my old testbench with a new configuration (net_cfg) that
puts the netlist
entity in place of the rtl entity and can test the synt result.

Now I'd like to do the same for the "gate" level (xilinx fpga) netlist
which can be obtained
using ISE toolsuite (netgen).
I create a new configuration (gate_cfg), and start the simulator.
Now I discover that my test bench was not aware of the clock-to-out
delay that
the "real" system now shows.

So i put a generic (clock_to_out) in the testbench entity declaration.
But I would
still like to simulate on my configurations, and have them to set the
generic value!

This seem impossible?!? I read a thread here "Specifying generics in
configuration" which
touched upon similar issues, but did't come to a conclusion, except
wrapping
the testbench up in another entity where the generic can be reached.

I'm awear of the possibillity: "vsim -gclock_to_out=12ns ..." but I
would like (if possible)
to keep all such specifications into the dedicated configuration.

Any ideas or clues are appreciated!

Regards, Pontus

 

[Mike Treseler]

pontus.stenstrom@gmail.com wrote:

This seem impossible?!?

Questions about timing simulation and configurations are
asked frequently here. If you google the questions separately
you will find long discussions.

The consensus is that synchronous design techniques and static timing
analysis are adequate to verify timing. A timing simulation
based on a routed netlist is a check-off item that may be deferred until
the design is complete. A timing simulation based on an unrouted netlist
has much less value.

Using a vhdl configuration to swap netlist for code
is possible but much more complicated than
just using a separate script or "project"
to handle this non-recurring verification.

-- Mike Treseler

 

Hi,

pontus.stenstrom@gmail.com wrote:

This seem impossible?!?

Questions about timing simulation and configurations are
asked frequently here. If you google the questions separately
you will find long discussions.

I do my best.

The consensus is that synchronous design techniques and static timing
analysis are adequate to verify timing. A timing simulation
based on a routed netlist is a check-off item that may be deferred until
the design is complete. A timing simulation based on an unrouted netlist
has much less value.

Our design nevers seems to get complete
It's a mixture of many codestyles and many coders over many years.
New features added, old features revised.
So when the [rare] parity error occurs on an interface, someone will
ask about timing
constraints, simulation with worstcase and bestcase timing etc.

Using a vhdl configuration to swap netlist for code
is possible but much more complicated than
just using a separate script or "project"
to handle this non-recurring verification.

-- Mike Treseler

After a while there becomes alot of scripts, and alot of projects!
I've been trying to reduce and reuse the scripts/makefiles and
would prefer having the design's timing specific issues apart
from the machinery that sims/synts/P&Rs the design.

To my original question,
Is there a specific reason for not allowing to set generics of the
entity
being configured?

My way around this will probably be to have a "tester" entity in the
testbench
which exercises the DUT, and expects certain behaviour, rather than
having
the tester as a process in the testbench. Then the generic can be
reached.

/Pontus

 

[Mike Treseler]

pontus.stenstrom@gmail.com wrote:

To my original question,
Is there a specific reason for not allowing to set generics of the
entity
being configured?

I'm not sure I understand.
I can pass generics to the testbench
but for a timing simulation, the DUT
is a generated netlist with timing
backanno (if any) already in an .sdf file.


-- Mike Treseler

 

I was after something similar to:

1: configuration cfg of tb is
2: for test -- arch of tb
3: for dut : my_comp
4: use entity my_lib.my_ent;
-- alternatively: use entity my_synt_result_lib.my_ent;
-- or use entity my_par_result_lib.my_ent;
5: end for;

6: for tester : my_tester
7: use entity my_tb_lib.my_tester
8: generic map (tester_dut_clock_to_out => 8 ns);
9: end for;

10: end for;
11:end configuration cfg;

But instead of setting the generic (line 8) of a sub component, I tried
to have a statement
between line 1 and 2 with the following (to set a generic of the tb
itself):
generic map (tb_dut_clock_to_out => 8 ns).

Anyway, it didn't work that way and I was wondering if there was some
obvious (or not)
reason for this language "limitation".

 

[KJ]

pontus.stenstrom@gmail.com wrote:

To my original question,
Is there a specific reason for not allowing to set generics of the
entity
being configured?

And below I think is your original question:

So i put a generic (clock_to_out) in the testbench entity declaration.
But I would still like to simulate on my configurations, and have them
to set the generic value!
-----

And I think I have the same confusion that Mike has....just what
generic do you think you can vary in the entity of the design under
test?

In order to get a timing accurate netlist that you can simulate, ALL of
the generics that go into that the top level entity must be defined and
all will have a specific value. The build process goes on USING THOSE
generics...in other words they are no longer parameters that you can
tweak from the outside. The output of that build process is whatever
bitstream you need to actually program the device and a simulation
netlist, reports, etc. But this simulation netlist is only valid for
the particular set of parameters that were chosen (or defaulted) at the
start of synthesis.

So the short answer is that you can't vary any of the parameters that
are inputs to the build process without first rebuilding using the new
set of parameter values to produce a new simulation netlist (and all
other build process artifacts).

That's probably not the answer you were hoping for, but it answers what
I *think* you were asking....if not, then at least it's the answer to
some other different question :O

KJ

 

[KJ]

OK...think I answered the wrong question on the last post...try, try
again..

You say...

So i put a generic (clock_to_out) in the testbench entity declaration. But I would still > like to simulate on my configurations, and have them to set the generic value!
and...
But instead of setting the generic (line 8) of a sub component, I tried
to have a statement
between line 1 and 2 with the following (to set a generic of the tb
itself):
generic map (tb_dut_clock_to_out => 8 ns).

Is what you're trying to do then set up something to sweep through
several values of the different generics of your testbench?

If it is, then you don't want to have configurations of the testbench,
but basically multiple copies of the testbench being run inside a sort
of 'super' testbench. I guess I'm missing why you would use a
configuration block at all, I *think* you want to use a 'generate'.

architecture XYZ of Super_Testbench is
** Define an array type of the appropriate type to contain a list of
the times you want to use
constant List_Of_tester_dut_clock_to_out: My_List_Of_Times_Type :=
(8 ns, 2 ns, ...);
begin
G_X : for i in 1 to N generate
U1 : tb generic map (List_Of_tester_dut_clock_to_out(i));
end generate;
end XYZ;

I'll bet this is the answer to some other question also though...but I
tried....good luck!

KJ

 

Thanks for your answer(s), perhaps more intresting than the original
question!

It all started off as simulating my original source code, and I was a
bit confused
by a "coregen" (a ROM) component, and thought I needed a configuration
to switch in
a ".mif" file (to prefill the ROM with values).

So I had a configuration of the testbench and managed to write another
similar
configuration to insert the synt result (vhdl netlist), and to have
that to use the same .mif file.

After PAR (and generating the netlist, compiling it and a "gate_cfg"
for it) however,
I got real timing (clock-to-out of say 10 ns), and so needed the
testbench to be aware of this. So I changed the the tb to expect
results at a later
time. I though it would be nice to have this time as a generic, and so
it went on...

I'm starting to like configurations ?)

/Pontus

 

[Andy]

There are a couple of ways out of this pickle jar you've gotten us into


One is to create a wrapper around your testbench, and a configuration
for it that can set the generic on your "original top level" testbench
Since your original testbench should have no IO, such a wrapper would
be trivially short! I ran into this when I found out that you cannot
compile a configuration for an entity into a library different from
that which contains the entity! I had to create my own wrapper entity
in my own library, then I could configure it (and everything under it)
with my configuration compiled into my own library.

The second is to set the value of the generic on the top level test
bench with a command line switch when you compile it for simulation.

Hope this helps,

Andy


KJ wrote:

pontus.stenstrom@gmail.com wrote:
To my original question,
Is there a specific reason for not allowing to set generics of the
entity
being configured?

And below I think is your original question:

So i put a generic (clock_to_out) in the testbench entity declaration.
But I would still like to simulate on my configurations, and have them
to set the generic value!
-----

And I think I have the same confusion that Mike has....just what
generic do you think you can vary in the entity of the design under
test?

In order to get a timing accurate netlist that you can simulate, ALL of
the generics that go into that the top level entity must be defined and
all will have a specific value. The build process goes on USING THOSE
generics...in other words they are no longer parameters that you can
tweak from the outside. The output of that build process is whatever
bitstream you need to actually program the device and a simulation
netlist, reports, etc. But this simulation netlist is only valid for
the particular set of parameters that were chosen (or defaulted) at the
start of synthesis.

So the short answer is that you can't vary any of the parameters that
are inputs to the build process without first rebuilding using the new
set of parameter values to produce a new simulation netlist (and all
other build process artifacts).

That's probably not the answer you were hoping for, but it answers what
I *think* you were asking....if not, then at least it's the answer to
some other different question :O

KJ

 

[jtw]

Comment embedded below:

"Andy" <jonesandy@comcast.net> wrote in message
news:1156966841.569912.42500@p79g2000cwp.googlegroups.com...

There are a couple of ways out of this pickle jar you've gotten us into


One is to create a wrapper around your testbench, and a configuration
for it that can set the generic on your "original top level" testbench
Since your original testbench should have no IO, such a wrapper would
be trivially short! I ran into this when I found out that you cannot
compile a configuration for an entity into a library different from
that which contains the entity! I had to create my own wrapper entity
in my own library, then I could configure it (and everything under it)
with my configuration compiled into my own library.

The second is to set the value of the generic on the top level test
bench with a command line switch when you compile it for simulation.

I believe you mean set the value of the generic with a command line switch
when elaborating it for simulation. I call vsim in this manner quite often
(but typically not for delays.) For selecting various configurations, all
of which are compiled into available libraries, you invoke the simulator
with the configuration name, not the architecture name. I believe this
could (at least partially) resolve the poster's issue. Definitely, between
the use of generics (for setting some specific delay(s) and/or other
parameters at run-time) and configurations (for selecting which entity to
simulate.)

JTW

Hope this helps,

Andy


KJ wrote:
pontus.stenstrom@gmail.com wrote:
To my original question,
Is there a specific reason for not allowing to set generics of the
entity
being configured?

And below I think is your original question:

So i put a generic (clock_to_out) in the testbench entity declaration.
But I would still like to simulate on my configurations, and have them
to set the generic value!
-----

And I think I have the same confusion that Mike has....just what
generic do you think you can vary in the entity of the design under
test?

In order to get a timing accurate netlist that you can simulate, ALL of
the generics that go into that the top level entity must be defined and
all will have a specific value. The build process goes on USING THOSE
generics...in other words they are no longer parameters that you can
tweak from the outside. The output of that build process is whatever
bitstream you need to actually program the device and a simulation
netlist, reports, etc. But this simulation netlist is only valid for
the particular set of parameters that were chosen (or defaulted) at the
start of synthesis.

So the short answer is that you can't vary any of the parameters that
are inputs to the build process without first rebuilding using the new
set of parameter values to produce a new simulation netlist (and all
other build process artifacts).

That's probably not the answer you were hoping for, but it answers what
I *think* you were asking....if not, then at least it's the answer to
some other different question :O

KJ