«

Hi,

for synthesis we often face the situation that we have to write a
wrapper with input and output registers to see what the performance
etc. of the module looks like.

For example:


entity test_module is
port( Clk : in std_logic;
i_Data : in std_logic_vector(7 downto 0);
o_Data : out std_logic_vector(7 downto 0)
);
end test_module;

architecture rtl of test_module is
....
end rtl;

------------------------------------------------------------------------

The wrapper:

entity wrap_test_module is
port( Clk : in std_logic;
i_Data : in std_logic_vector(7 downto 0);
o_Data: out std_logic_vector(7 downto 0)
);
end wrap_test_module;

architecture wrapper of wrap_test_module is

component test_module ...


signal l_data_in, l_i_test_Data : std_logic_vector(7 downto 0);

begin

process(Clk)
begin
wait until rising_edge(Clk);
l_data_in <= i_Data;
o_Data <= l_i_test_Data;
end process;


i_test : test_module
port map ( Clk => Clk,
i_Data => l_data_in,
o_Data => l_i_test_Data
);

end wrapper;


Is there some possibility to introduce some automatism to create those
kind of wrappers ?
Has someone done that kind of job, for example with TCL ?

Cheers,
hssig

Not really automated, but simpler:

Why not just create another architecture of test_module that wraps the
rtl architecture?

architecture wrapped of test_module is

signal l_data_in, l_i_test_Data : std_logic_vector(i_data'range);

begin

-- register ins and outs
l_data_in <= i_data when rising_edge(clk);
o_data <= l_i_test_data when rising_edge(clk);

-- instantiate entity/arch for uut
entity work.test_module(rtl)
port map (
clk => clk,
i_data => l_data_in,
o_data => l_i_test_data
);

end wrapped;


Then synthesize the wrapped architecture of test_module.

Andy

On 20 Okt., 12:03, hssig <hs...@gmx.net> wrote:
> Hi,
>
> for synthesis we often face the situation that we have to write a
> wrapper with input and output registers to see what the performance
> etc. of the module looks like.
>
> For example:
>
> entity test_module is
> port( Clk : in std_logic;
> * * * * i_Data : in *std_logic_vector(7 downto 0);
> * * * *o_Data : out std_logic_vector(7 downto 0)
> * * * );
> end test_module;
>
> architecture rtl of test_module is
> ...
> end rtl;
>
> ------------------------------------------------------------------------
>
> The wrapper:
>
> entity wrap_test_module is
> port( Clk : in *std_logic;
> * * * * i_Data : in *std_logic_vector(7 downto 0);
> * * * *o_Data: out std_logic_vector(7 downto 0)
> * * *);
> end wrap_test_module;
>
> architecture wrapper of wrap_test_module is
>
> component test_module ...
>
> signal l_data_in, l_i_test_Data : std_logic_vector(7 downto 0);
>
> begin
>
> process(Clk)
> begin
> * * *wait until rising_edge(Clk);
> * * *l_data_in <= i_Data;
> * * o_Data * * <= l_i_test_Data;
> end process;
>
> i_test : test_module
> port map ( Clk => Clk,
> * * * * * * * * *i_Data => l_data_in,
> * * * * * * * * *o_Data => l_i_test_Data
> * * * * * * * *);
>
> end wrapper;
>
> Is there some possibility to introduce some automatism to create those
> kind of wrappers ?
> Has someone done that kind of job, for example with TCL ?
>
> Cheers,
> hssig

Hi,
why do you add output registers anyway, when your design is clocked.
In that case it should have registers on all outputs anyway.

And for the Inputs, it should also be obsolete, since your test design
should have registers at the outputs that connect to the DUTs inputs.

So this extra one clock latency at input and output of your DUT makes
no real sense.

Also, what kind of performance analysis are you doing?
Don't you trust the static timing analysis?
Or do you want to sqeeze out a little more than calculated?

Have a nice synthesis
Eilert

Hi backhus,

> And for the Inputs, it should also be obsolete, since your test design
> should have registers at the outputs that connect to the DUTs inputs.

yes, you are right. But when synthesizing modules stand-alone there
are not always given
input registers in the description of the module, so at least one
input register stage should
be inserted for test synthesis.

>Don't you trust the static timing analysis?
Yes, I trust it. BUT without input registers the module is not
synthesized like it would be synthesized when being placed in the
"middle" of a design.

@ Andy: Good idea, thank you.

Cheers,
hssig

Hi Andy,

one question regarding your suggestion:

How do you handle both architectures that is does the architecture
"wrapped" have some entity (even the same entity?) ?


Cheers,
hssig

hssig wrote:

> How do you handle both architectures that is does the architecture
> "wrapped" have some entity (even the same entity?) ?

I would probably make entity_plain and entity_wrapped
to keep things simple.

-- Mike Treseler

"hssig" <> wrote in message
news:e0ab7791-7e92-47f4-ac2e-...
>
<snip>
>
> Is there some possibility to introduce some automatism to create those
> kind of wrappers ?
> Has someone done that kind of job, for example with TCL ?
>

The closest you're going to get is to use ISE or other software to make a
test-bench from the desired file. All the components and signals will be
there, and all you'll need to do is modify a few lines.

Hope that idea helps.

On Oct 21, 2:37*am, hssig <hs...@gmx.net> wrote:
> Hi Andy,
>
> one question regarding your suggestion:
>
> How do you handle both architectures that is does the architecture
> "wrapped" have some entity (even the same entity?) ?
>
> Cheers,
> hssig

Both architectures are for the same entity.

The entity and both architectures can be defined in the same or
different files. If the same file, most tools will require the wrapped
architecture to appear after the rtl architecture, which would appear
after the entity. In practice, it would be rather simple to just add
the wrapped architecture to the bottom of the same file with the
entity and rtl architecture. Or you could create a second file with
just the wrapped arch, and only include it in your test synthesis
runs.

When instantiating them, use configurations (and component
declarations) to specify which architecture you want, or skip all that
and just use direct entity instantiation. If this is a synthesis
wrapper, it is doubtful that any vhdl code would ever instantiate the
wrapped version; I wouldn't bother simulating the wrapped version. I
use components and configurations extremely rarely; direct entity (and
architecture) instantiation is just much easier. Just beware that
direct entity/architecture instantiation requires both the entity and
the architecture to have been previously compiled. If your tool has
that cool automatic compilation-reordering option, then you can just
throw the units and files in any order at it and the tool will figure
it out.

To instantiate the rtl version:
uut: entity work.test_module(rtl)
port map ...

To instantiate the wrapped version:
uut: entity work.test_module(wrapped)
port map ...

What is simpler about "entity work.entity_plain" compared to "entity
work.entity(rtl)"?

Andy

Andy wrote:
> On Oct 21, 2:37 am, hssig <hs...@gmx.net> wrote:

> What is simpler about "entity work.entity_plain" compared to "entity
> work.entity(rtl)"?

Nothing.
Thanks for the idea.

-- Mike Treseler

Hi,

it is not clear to me yet.

Concerning the configuration, is the following approach correct ?:

1. file "test_module.vhd" with entity "test_module" and architectures
"rtl", "wrapped"
2. file "test_module_TOP.vhd" for configuration:

The second file:

library ieee;
use ieee.std_logic_1164.all;

entity test_module_TOP is
port( Clk : in std_logic;
i_Data : in std_logic_vector(7 downto 0);
o_Data : out std_logic_vector(7 downto 0)
);
end test_module_TOP;

architecture TOP of test_module_TOP is
begin

uut: entity work.test_module(wrapped)
port map ( Clk => Clk,
i_Data => i_Data,
o_Data => o_Data
);
end TOP;



When importing both files in Lattice-ispLEVER 7.2 I get the warning
"Circular hierarchy reference found" but nevertheless I am able to
synthesize it with different architectures.

Is that the way you suggested or did I get something wrong?


When regarding the motivation of my post to have a quick way of
building a synthesis wrapper for a given module, I have to assert that
now I have to write two additional modules (architecture "wrapped",
module "test_module_TOP"). Is that easier than my first
proposal "wrap_test_module"? I think not.


Cheers,
hssig