model sim problem

[The Weiss Family]

All,

I can simulate my design just fine if I simulate the behavioral model.
When I try to simulate anything else (mapped, placed and routed, etc...),
I get an error saying that a generic is not part of the entity.
It obviously is, though, because it compiles and synthesizes just fine.
Any ideas?

Thanks,

Adam

 

[The Weiss Family]

Is this a "feature" of the compiler?
When it does the behavioral model simulation, does it do it simply based on
the syntax,
but then in the placed and routed version, the generic is no longer generic
due to synthesis?
Seems wierd to me.

At any rate, I can definitely try hard-coding the generic for simulation.

Thanks for the advice.

Adam

"Tom Verbeure" <hombre@gmail.com> wrote in message
news:ccoqm5$red@odak26.prod.google.com...

You may have generics in your original entity, but probably not in the
synthesized version. (At least, that's how it is for Synopsys DC. Other
tools may have a difference behavior.) Your synthesized version
declares a new entity that does not have generics. In general, it's ok
to use generics for interal modules, but this is not so for the
toplevel module that will be synthesized, unless you're willing to
maintain 2 testbenches, one with the generics and one without.
One solution to this is to create a wrappe around your toplevel entity
with exactly the same ports, but without generics. In this module, you
instanciate the original module and strap the generic value.
Tom Verbeure

The Weiss Family wrote:
All,

I can simulate my design just fine if I simulate the behavioral
model.
When I try to simulate anything else (mapped, placed and routed,
etc...),
I get an error saying that a generic is not part of the entity.
It obviously is, though, because it compiles and synthesizes just
fine.
Any ideas?

Thanks,

Adam

 

[Mike Treseler]

The Weiss Family wrote:

Is this a "feature" of the compiler?

It's a "feature" of the vendor-supplied sim model
not matching the core netlist exactly.

You can get a perfect match by inferring
the core function from code rather than
instancing the vendor "free" cores.

You can eliminate the need for a post-route
sim by using a 100% synchronous design
and static timing analysis.

-- Mike Treseler

 

[The Weiss Family]

You can eliminate the need for a post-route
sim by using a 100% synchronous design
and static timing analysis.

How do I do a static timing analysis?
Sorry for the questions, I'm still somewhat new to this.

Oh yeah. When you say 100% synchronous, what do you mean?
For example, if I have two signals that are synchronous to a common clock,
can I use an asynchronous comparator to compare them, or should I also
compare them with reference to the same clock?

Thanks again,

Adam

 

[The Weiss Family]

"Tom Verbeure" <hombre@gmail.com> wrote in message
news:ccrrkq$e2q@odbk17.prod.google.com...

Look at it this way:
the generic specification in RTL code is used to make it easy to change
certain simple parameters or to disable certain parts of logic. Anyway,
you want to make a particular piece of code configurable.

E.g.

entity MyAddr is
generic(
gc_WordSize : integer;
);
port(
A,B : in std_ulogic_vector(gc_WordSize-1 downto 0);
C : buffer std_ulogic_vector(gc_WordSize downto 0);
);
end entity;

architecture RTL of MyAddr is
begin
C <= std_ulogic_vector(unsigned('0' & A) + unsigned('0' & B));
end RTL;

When you synthesize this piece of code, what you expect is a blob of
gates that implements the given function for one particular values of
gc_WordSize. Obviously, different values of gc_WordSize will result in
a different set of gates. Thus keeping the generic parameter in the
entity would be a bad idea.

Synopsys does it this way: it will create an entity with a name that
looks something like this: "MyAdder_gc_WordSize_15". (This can result
in really long entity names if you have modules with a lot of generic
parameters...)
I don't see any other way in which it could reasonably behave.

Tom

I get it! That was a great explanation.
Thanks again,

Adam