Mixed Simulation of Design (VHDL and Verilog)

[Mirza]

Dear all,

I need to simulate my design with a design whihc was done already in
verilog. Design in Verilog will communicate with the Design in VHDL.

I did simulation of my Design in VHDL using a test bench, but for
practical reasons I need to used the other design in same test.

[b:0157fe5128]HOW TO USE A DESIGN(VERILOG) IN A VHDL DESIGN SIMULATION??

PLEASE ADVISE, ANY TIPS, ANY KIND OF LITRATURE??[/b:0157fe5128]

thanks in advance,

mirza

 

[HT-Lab]

"Mirza" <mirza.attiq@gmail.com> wrote in message
news:1184227904.451010.71810@w3g2000hsg.googlegroups.com...

Dear all,

I need to simulate my design with a design whihc was done already in
verilog. Design in Verilog will communicate with the Design in VHDL.

I did simulation of my Design in VHDL using a test bench, but for
practical reasons I need to used the other design in same test.

[b:28284807ad]HOW TO USE A DESIGN(VERILOG) IN A VHDL DESIGN SIMULATION??

PLEASE ADVISE, ANY TIPS, ANY KIND OF LITRATURE??[/b:28284807ad]

Please don't shout

Most if not all commercial simulators allow you to mix and match any HDL
language (Verilog, VHDL, SystemC, SystemVerilog) at any level of the
hierarchy. It is just a question of paying the dosh for that extra language
feature and reading the section on mix-language simulation.

Hans
www.ht-lab.com

thanks in advance,

mirza

 

[KJ]

"Mirza" <mirza.attiq@gmail.com> wrote in message
news:1184227904.451010.71810@w3g2000hsg.googlegroups.com...

Dear all,

I need to simulate my design with a design whihc was done already in
verilog. Design in Verilog will communicate with the Design in VHDL.

I did simulation of my Design in VHDL using a test bench, but for
practical reasons I need to used the other design in same test.

[b:933fed7255]HOW TO USE A DESIGN(VERILOG) IN A VHDL DESIGN SIMULATION??

PLEASE ADVISE, ANY TIPS, ANY KIND OF LITRATURE??[/b:933fed7255]

1. If not already obtained, pay the money necessary to get mixed language
support from your simulator tool of choice.
2. Read the user's guide from that simulator tool on how to instantiate the
Verilog component into a VHDL design (or vice versa).
3. Do what it says.

For what it's worth, instantiating a Verilog module into VHDL source using
Modelsim is completely transparent. You add the Verilog source file to your
project and compile it (as you would with any VHDL file) and then simply
instantiate the module in the same way you would an entity. The following
shows the VHDL source you would use to instantiate a VHDL and a Verilog
widget.

DUT1 : entity work.MyVhdlEntity generic map(...) port map(...);
DUT 2: entity work.MyVerilogModule generic map(...) port map(...);

Usually the only issues that come up in mixed language sims is not how to
plop down the module in the code but if there are 'non-standard' signal
types on the interfaces. If everything is std_ulogic/std_ulogic_vector (and
their Verilog counterparts) as is typically the case, then there should be
no issues.

KJ

 

[C. G.]

But then, why bother to pay the extra dollars/euros or whatever when
Aldec's simulators offer mixed language as standard and that for very
realistic pricing.

 

[Paul Uiterlinden]

C. G. wrote:

But then, why bother to pay the extra dollars/euros or whatever when
Aldec's simulators offer mixed language as standard and that for very
realistic pricing.

But not with a realistic level of quality. At least not for me.

I've tried the Riviera simulator and found that it could not compile my
existing verification libraries (VHDL only). Numerous segmentation
violations and hang situations occurred. From the eight testcases that I
sent to Aldec, four where segmentation violations, one hang situation and
three "normal" error messages (due to unsupported language constructs).

The feedback from Aldec was quite fast. Within a week or so I got a new
version with my reported issues fixed. However, now I found other issues
(still in the compilation stage) and I did not want to spend more time.

I guess sending the complete verification environment (all libraries) is the
only way to get Riviera working for me. In fact, that is what the AE
suggested. I didn't want to go down that road, not knowing where it would
lead to, how long it would be and how much time it would cost me.

So that is why we keep on paying the extra bucks.

--
Paul Uiterlinden
www.aimvalley.nl
e-mail addres: remove the not.

 

[Duane Clark]

Paul Uiterlinden wrote:

I've tried the Riviera simulator and found that it could not compile my
existing verification libraries (VHDL only). Numerous segmentation
violations and hang situations occurred. From the eight testcases that I
sent to Aldec, four where segmentation violations, one hang situation and
three "normal" error messages (due to unsupported language constructs).

I'll just say that I just started using Riviera (version 2007.06) about
a month ago, after having used Modelsim for years. I am running some
fairly large and complex (mixed, though mostly VHDL) designs through it.
I had no problems with compiling anything. I did have one problem with
one particular piece of code with a crash when trying to initialize the
simulator, but I quickly found a workaround. And once reported to Aldec,
they quickly fixed it, and I have had no such issues since.

Like all engineering software, it has its "features". But have gotten to
like it, and it does simulate fast. And for independent consultants,
Aldec has some nice discounts. I have now switched to it as my main
simulator.

 

[Xilinx User]

"C. G." <site_blackhole@trellisys.ie> wrote in message
news:f7ggpn$me8$02$1@news.t-online.com...

But then, why bother to pay the extra dollars/euros or whatever when
Aldec's simulators offer mixed language as standard and that for very
realistic pricing.

When I contacted Aldec for an evaluation-license and pricing (Active-HDL),
their price-list showed single-language (VHDL or Verilog) at roughly $5000,
and mixed-HDL at roughly $9500.

What pricing did you get, and what makes it more 'realistic' than say,
Modelsim PE Designer Edition? (Which is in roughly the same range.)

 

[Duane Clark]

Xilinx User wrote:

"C. G." <site_blackhole@trellisys.ie> wrote in message
news:f7ggpn$me8$02$1@news.t-online.com...
But then, why bother to pay the extra dollars/euros or whatever when
Aldec's simulators offer mixed language as standard and that for very
realistic pricing.

When I contacted Aldec for an evaluation-license and pricing (Active-HDL),
their price-list showed single-language (VHDL or Verilog) at roughly $5000,
and mixed-HDL at roughly $9500.

What pricing did you get, and what makes it more 'realistic' than say,
Modelsim PE Designer Edition? (Which is in roughly the same range.)

Well, for one thing, no Linux version of Modelsim PE. That means I
cannot use Modelsim PE. And another factor would be the relative
performance of Riviera versus Modelsim PE. Since I have never used
Modelsim PE, I don't know how fast it is. I do know that Riviera is
quite fast. Don't compare on price alone.

But yes, when I purchased Riviera recently, I paid extra for mixed
language support.

 

[Paul Uiterlinden]

Duane Clark wrote:

I'll just say that I just started using Riviera (version 2007.06) about
a month ago, after having used Modelsim for years. I am running some
fairly large and complex (mixed, though mostly VHDL) designs through it.
I had no problems with compiling anything.

The problems I saw where all in the verification environment. This is quite
a complex environment, using the VHDL language to its limits. Mostly
behavioral constructs. I guess that side is not that well covered in
Riviera.

Like all engineering software, it has its "features". But have gotten to
like it, and it does simulate fast.

That's interesting. Thanks for the information.

May be, just may be I should take Riviera in (re)consideration again.

--
Paul Uiterlinden
www.aimvalley.nl
e-mail addres: remove the not.

 

[C. G.]

Xilinx User schrieb:

When I contacted Aldec for an evaluation-license and pricing
(Active-HDL), their price-list showed single-language (VHDL or
Verilog) at roughly $5000, and mixed-HDL at roughly $9500.

What pricing did you get, and what makes it more 'realistic' than
say, Modelsim PE Designer Edition? (Which is in roughly the same
range.)

Well, I went for Riviera instead of ActiveHDL since I do most of my work
under Linux. The figures you mentioned for ActiveHDL are somewhere along
the lines of the equivalent European list prices (EUR8500 for full mixed
language version) I have heard of for this tool. But the EUR8500 is
mixed language (Verilog/VHDL/SystemC/PSL and a basic implementation of
SystemVerilog. Also, some graphic tools which afaik place you somewhere
around Mentor HDL-Author). Will modelsim PE really do that for the same
price? That wasn't my impression.

I don't really think it would be fair to disclose exact prices since the
sales reps need some degree of freedom in trying to find a good
compromise between what the client is willing to pay and what Aldec
considers as an absolute minimum price. I personally was very satisfied
with my final Riviera offer (List price according to my info for the
all-bells and-whistles version, EUR25000). It was considerably less than
the standard list price and considerably less than what Mentor were
prepared to give me as a consultant for their equivalent. And, the
Mentor solution didn't have SystemVerilog as part of the package. My rep
allowed me pay in two installments six months apart which eased the
burden even more.

As regards the quality of Riviera, currently I do mostly VHDL with some
Verilog and SystemC and I don't have any problems. I can't say I share
Paul Uiterlinden's bad experience. Without wanting to start a
competition with Paul about "who can write the most complex (or obscure)
code" I'll just say that my test-benches are generally TLM based with
plenty of abstract data types, access types and unconstrained arrays
i.e. things that you wouldn't normally find in the synthesisable VHDL
subset. I had a single problem with unconstrained arrays while I was
still evaluating but Aldec sent me a patch within two days. I agree
fully with some of the other posters here. I too find Riviera very fast.
I think I am in a position to compare since one of my major customers
expects me to use his (Mentor based) tool base when I am working on his
projects.

So, for what it's worth, that's my detailed summary.

 

[Paul Uiterlinden]

C. G. wrote:

As regards the quality of Riviera, currently I do mostly VHDL with some
Verilog and SystemC and I don't have any problems. I can't say I share
Paul Uiterlinden's bad experience. Without wanting to start a
competition with Paul about "who can write the most complex (or obscure)
code"

I never said that I strive to write the most complex or even obscure
code. Sorry if I gave you that impression.

I'll just say that my test-benches are generally TLM based with
plenty of abstract data types, access types and unconstrained arrays
i.e. things that you wouldn't normally find in the synthesisable VHDL
subset.

Same here. And to show you that the things that tripped Riviera are
not exactly the rocket science equivalence of VHDL, here are some
samples (code not complete). Note that these are in no way obscene
contrived examples. They are stand-alone testcases extracted from
existing code.

1) Attribute 'HIGH not allowed in certain circumstances:

PROCEDURE p
(
state : INOUT state_type
) IS
ALIAS reg: bit_vector(state.reg.data'LENGTH-1 DOWNTO 0)
IS state.reg.data;
BEGIN
reg := reg(reg'HIGH-1 DOWNTO 0) & '0';
END PROCEDURE p;


2) Dependency exists between package a and package BODY b

A very very basic bug where a use clause of package b caused a
dependency to the BODY of package b, in stead of the PACKAGE.
Because of this I could not use my makefiles without modification.


3) Segmentation violation caused by an index in the formal parameters
in a procedure call.

PROCEDURE p1
(
d : INOUT bit;
e : IN bit;
m : IN m_type
) IS
BEGIN
p2(d_vec(0) => d, e_vec(0) => e, m => m);
END PROCEDURE p1;


4) Segmentation violation caused by a LOOP/NEXT combination

PROCEDURE p
(
a : IN bit_vector
) IS
SUBTYPE c_range IS natural RANGE a'RANGE;
VARIABLE a_prev : bit_vector(a'RANGE);
BEGIN
c_loop: FOR c IN c_range LOOP
NEXT c_loop WHEN a(c) = a_prev(c);
END LOOP c_loop;
END PROCEDURE p;


5) Segmentation violation if a subtype is used as an index
range of a vector.

PROCEDURE p
(
a : OUT bit_vector
) IS
SUBTYPE a_range IS natural RANGE a'RANGE;
BEGIN
a := (a_range => '0');
-- Workaround: use a'RANGE in stead of a_range
END PROCEDURE p;


6) Segmentation violation if a subtype is used as an index of a
for loop, which surrounds a while loop.

PROCEDURE p
(
a : INOUT bit_vector
) IS
SUBTYPE a_range IS natural RANGE a'RANGE;
BEGIN
FOR b IN a_range LOOP
-- Workaround: use a'RANGE in stead of a_range
WHILE a(b) = '0' LOOP
a(b) := NOT a(b);
END LOOP;
END LOOP;
END PROCEDURE p;


7) Hang situation of vcom (100% CPU usage)

TYPE enum_type IS
(
a1, a2, a3, a4, a5,
b1, b2, b3, b4, b5,
c1, c2, c3, c4, c5
);
SUBTYPE enum_subtype IS enum_type RANGE b1 TO b5;

PROCEDURE p
(
a : IN enum_subtype
) IS
BEGIN
CASE a IS
WHEN b2 TO b4 => -- Trouble maker
WHEN b1 | b5 =>
END CASE;
END PROCEDURE p;


Now where is the obscure code? I hope you agree the complexity
of the code shown is quite low. Most of it (if not all) should even
be synthesizable. And it is all in the analyze stage, I never reached
the simulation stage!

As said before, the reaction time of Aldec was amazingly fast.
However, after these issues where fixed, I stumbled on other issues,
preventing me to start the simulation I wanted to use for my
evaluation. That was the point where I did not invest any more time.

I had a single problem with unconstrained arrays while I was
still evaluating but Aldec sent me a patch within two days. I agree
fully with some of the other posters here. I too find Riviera very fast.
I think I am in a position to compare since one of my major customers
expects me to use his (Mentor based) tool base when I am working on his
projects.

So, for what it's worth, that's my detailed summary.

I'm glad it works for you and I thank you for your information.

And let it be absolutely clear: in no way am I trying to put Riviera
in a bad light. All I want to say: YMMV (your mileage may vary). And
in this particular case: MMV (my mileage varies).

--
Paul Uiterlinden
www.aimvalley.nl
e-mail addres: remove the not.