Verilog module in VHDL for Altera devices

R

Raj

Guest
I found a verilog core which performs the task I want and I wish to use it within my VHDL module.

Is such a functionality possible? If yes, what all additional steps would be required?

I found this source http://quartushelp.altera.com/14.1/mergedProjects/hdl/vlog/vlog_file_mixed_lang.htm

which tells me that I have to declare components within Verilog in the VHDL module, which creates a portmap.

My question here is, do I do this within my top level file itself? or create a new file for this mapping?

Thanks,
Raj
 
On Tuesday, April 5, 2016 at 2:36:02 AM UTC-4, Raj wrote:
I found a verilog core which performs the task I want and I wish to use it within my VHDL module.

Is such a functionality possible? If yes, what all additional steps would be required?

I found this source http://quartushelp.altera.com/14.1/mergedProjects/hdl/vlog/vlog_file_mixed_lang.htm

which tells me that I have to declare components within Verilog in the VHDL module, which creates a portmap.

My question here is, do I do this within my top level file itself? or create a new file for this mapping?

Thanks,
Raj

And also while portmapping if a signal is input in the Verilog core, then I should make it output where I will be doing the port maps. Right?
 
On Tuesday, April 5, 2016 at 2:36:02 AM UTC-4, Raj wrote:
> My question here is, do I do this within my top level file itself? or create a new file for this mapping?

You simply instantiate the Verilog module as if it was a VHDL entity. Nothing special.

Kevin
 
On Tuesday, April 5, 2016 at 11:28:15 AM UTC-4, rickman wrote:
On 4/5/2016 7:43 AM, Allan Herriman wrote:
On Tue, 05 Apr 2016 03:45:47 -0700, KJ wrote:

On Tuesday, April 5, 2016 at 2:36:02 AM UTC-4, Raj wrote:
My question here is, do I do this within my top level file itself? or
create a new file for this mapping?

You simply instantiate the Verilog module as if it was a VHDL entity.
Nothing special.

I wish that were true.

The last time I tried Quartus, entity instantiation of Verilog in VHDL
didn't work; component instantiation was required.

What is "entity instantiation"???


--

Rick

library IEEE;
USE IEEE.STD_LOGIC_1164.ALL;
USE IEEE.NUMERIC_STD.ALL;

entity FFT_TOP is
port (
CK : in std_logic;
RT : in std_logic;
ED : in std_logic;
START : in std_logic;
SHIFT : in std_logic_vector(3 downto 0);
DR : in std_logic_vector(15 downto 0);
DI : in std_logic_vector(15 downto 0);
RDY : out std_logic;
OVF1 : out std_logic;
OVF2 : out std_logic;
ADDR : out std_logic_vector(7 downto 0);
DOR : out std_logic_vector(15 downto 0);
DOI : out std_logic_vector(15 downto 0)
);
end FFT_TOP;

architecture arch of FFT_TOP is
component FFT256
port (
CLK : in std_logic;
RST : in std_logic;
ED : in std_logic;
START : in std_logic;
SHIFT : in std_logic_vector(3 downto 0);
DR : in std_logic_vector(15 downto 0);
DI : in std_logic_vector(15 downto 0);
RDY : out std_logic;
OVF1 : out std_logic;
OVF2 : out std_logic;
ADDR : out std_logic_vector(7 downto 0);
DOR : out std_logic_vector(15 downto 0);
DOI : out std_logic_vector(15 downto 0)
);
end component;

signal my_CLK, my_RST, my_ED, my_START, my_RDY, my_OVF1, my_OVF2 : std_logic;
signal my_DR, my_DI, my_DOR, my_DOI : std_logic_vector(15 downto 0);
signal my_SHIFT : std_logic_vector(3 downto 0);
signal my_ADDR : std_logic_vector(7 downto 0);

begin
i : FFT256 port map
(
CLK => CK,
RST => RT,
ED => ED,
START => START,
SHIFT => SHIFT,
DR => DR,
DI => DI,
RDY => RDY,
OVF1 => OVF1,
OVF2 => OVF2,
ADDR => ADDR,
DOR => DOR,
DOI => DOI
);
end arch;



This works! We just need to use the same name for the signals used in verilog.
 
On Tue, 05 Apr 2016 03:45:47 -0700, KJ wrote:

On Tuesday, April 5, 2016 at 2:36:02 AM UTC-4, Raj wrote:
My question here is, do I do this within my top level file itself? or
create a new file for this mapping?

You simply instantiate the Verilog module as if it was a VHDL entity.
Nothing special.

I wish that were true.

The last time I tried Quartus, entity instantiation of Verilog in VHDL
didn't work; component instantiation was required.

I think Vivado is similarly broken, which is quite sad because entity
instantiation of Verilog in VHDL worked worked quite well in ISE ten
years ago.

Regards,
Allan
 
rickman wrote:

On 4/5/2016 7:43 AM, Allan Herriman wrote:
On Tue, 05 Apr 2016 03:45:47 -0700, KJ wrote:

On Tuesday, April 5, 2016 at 2:36:02 AM UTC-4, Raj wrote:
My question here is, do I do this within my top level file itself? or
create a new file for this mapping?

You simply instantiate the Verilog module as if it was a VHDL entity.
Nothing special.

I wish that were true.

The last time I tried Quartus, entity instantiation of Verilog in VHDL
didn't work; component instantiation was required.

What is "entity instantiation"???

INST_BOB: entity work.bob(Bobhavioral)
port map (...);

With no component declaration.

--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.
 
rickman wrote:

On 4/5/2016 2:26 PM, Rob Gaddi wrote:
rickman wrote:

On 4/5/2016 7:43 AM, Allan Herriman wrote:
On Tue, 05 Apr 2016 03:45:47 -0700, KJ wrote:

On Tuesday, April 5, 2016 at 2:36:02 AM UTC-4, Raj wrote:
My question here is, do I do this within my top level file itself? or
create a new file for this mapping?

You simply instantiate the Verilog module as if it was a VHDL entity.
Nothing special.

I wish that were true.

The last time I tried Quartus, entity instantiation of Verilog in VHDL
didn't work; component instantiation was required.

What is "entity instantiation"???



INST_BOB: entity work.bob(Bobhavioral)
port map (...);

With no component declaration.

Ok, I did a little reading on this and I think I understand. I'm amazed
I never came across this before. So as long as the entity/architecture
is compiled and visible the component declaration is not required.

Other than a packages, I don't typically put more than one entity in a
file. But I see now this is not really a limitation if I understand
correctly, entity instantiation can still be used. I will try this with
my next project. The duplication of the component declaration is a bit
absurd really.

The one limitation is that direct entity instantiation plays very
Verilogily with simulation. With a component declaration, if you
recompile the thing you're instantiating you can just restart the
simulation and go. With direct entities you have to recompile your way
everything back up the way.

--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.
 
On 4/5/2016 7:43 AM, Allan Herriman wrote:
On Tue, 05 Apr 2016 03:45:47 -0700, KJ wrote:

On Tuesday, April 5, 2016 at 2:36:02 AM UTC-4, Raj wrote:
My question here is, do I do this within my top level file itself? or
create a new file for this mapping?

You simply instantiate the Verilog module as if it was a VHDL entity.
Nothing special.

I wish that were true.

The last time I tried Quartus, entity instantiation of Verilog in VHDL
didn't work; component instantiation was required.

What is "entity instantiation"???


--

Rick
 
On 4/5/2016 11:40 AM, rajesh.krissh@gmail.com wrote:
On Tuesday, April 5, 2016 at 11:28:15 AM UTC-4, rickman wrote:
On 4/5/2016 7:43 AM, Allan Herriman wrote:
On Tue, 05 Apr 2016 03:45:47 -0700, KJ wrote:

On Tuesday, April 5, 2016 at 2:36:02 AM UTC-4, Raj wrote:
My question here is, do I do this within my top level file itself? or
create a new file for this mapping?

You simply instantiate the Verilog module as if it was a VHDL entity.
Nothing special.

I wish that were true.

The last time I tried Quartus, entity instantiation of Verilog in VHDL
didn't work; component instantiation was required.

What is "entity instantiation"???


--

Rick

library IEEE;
USE IEEE.STD_LOGIC_1164.ALL;
USE IEEE.NUMERIC_STD.ALL;

entity FFT_TOP is
port (
CK : in std_logic;
RT : in std_logic;
ED : in std_logic;
START : in std_logic;
SHIFT : in std_logic_vector(3 downto 0);
DR : in std_logic_vector(15 downto 0);
DI : in std_logic_vector(15 downto 0);
RDY : out std_logic;
OVF1 : out std_logic;
OVF2 : out std_logic;
ADDR : out std_logic_vector(7 downto 0);
DOR : out std_logic_vector(15 downto 0);
DOI : out std_logic_vector(15 downto 0)
);
end FFT_TOP;

architecture arch of FFT_TOP is
component FFT256
port (
CLK : in std_logic;
RST : in std_logic;
ED : in std_logic;
START : in std_logic;
SHIFT : in std_logic_vector(3 downto 0);
DR : in std_logic_vector(15 downto 0);
DI : in std_logic_vector(15 downto 0);
RDY : out std_logic;
OVF1 : out std_logic;
OVF2 : out std_logic;
ADDR : out std_logic_vector(7 downto 0);
DOR : out std_logic_vector(15 downto 0);
DOI : out std_logic_vector(15 downto 0)
);
end component;

signal my_CLK, my_RST, my_ED, my_START, my_RDY, my_OVF1, my_OVF2 : std_logic;
signal my_DR, my_DI, my_DOR, my_DOI : std_logic_vector(15 downto 0);
signal my_SHIFT : std_logic_vector(3 downto 0);
signal my_ADDR : std_logic_vector(7 downto 0);

begin
i : FFT256 port map
(
CLK => CK,
RST => RT,
ED => ED,
START => START,
SHIFT => SHIFT,
DR => DR,
DI => DI,
RDY => RDY,
OVF1 => OVF1,
OVF2 => OVF2,
ADDR => ADDR,
DOR => DOR,
DOI => DOI
);
end arch;



This works! We just need to use the same name for the signals used in verilog.

This looks like a component instantiation. I don't see how it is
different.

--

Rick
 
On 4/5/2016 2:26 PM, Rob Gaddi wrote:
rickman wrote:

On 4/5/2016 7:43 AM, Allan Herriman wrote:
On Tue, 05 Apr 2016 03:45:47 -0700, KJ wrote:

On Tuesday, April 5, 2016 at 2:36:02 AM UTC-4, Raj wrote:
My question here is, do I do this within my top level file itself? or
create a new file for this mapping?

You simply instantiate the Verilog module as if it was a VHDL entity.
Nothing special.

I wish that were true.

The last time I tried Quartus, entity instantiation of Verilog in VHDL
didn't work; component instantiation was required.

What is "entity instantiation"???



INST_BOB: entity work.bob(Bobhavioral)
port map (...);

With no component declaration.

Ok, I did a little reading on this and I think I understand. I'm amazed
I never came across this before. So as long as the entity/architecture
is compiled and visible the component declaration is not required.

Other than a packages, I don't typically put more than one entity in a
file. But I see now this is not really a limitation if I understand
correctly, entity instantiation can still be used. I will try this with
my next project. The duplication of the component declaration is a bit
absurd really.

--

Rick
 
rickman wrote:
On 4/5/2016 2:26 PM, Rob Gaddi wrote:
rickman wrote:

On 4/5/2016 7:43 AM, Allan Herriman wrote:
On Tue, 05 Apr 2016 03:45:47 -0700, KJ wrote:

On Tuesday, April 5, 2016 at 2:36:02 AM UTC-4, Raj wrote:
My question here is, do I do this within my top level file itself? or
create a new file for this mapping?

You simply instantiate the Verilog module as if it was a VHDL entity.
Nothing special.

I wish that were true.

The last time I tried Quartus, entity instantiation of Verilog in VHDL
didn't work; component instantiation was required.

What is "entity instantiation"???



INST_BOB: entity work.bob(Bobhavioral)
port map (...);

With no component declaration.

Ok, I did a little reading on this and I think I understand. I'm amazed
I never came across this before. So as long as the entity/architecture
is compiled and visible the component declaration is not required.

Other than a packages, I don't typically put more than one entity in a
file. But I see now this is not really a limitation if I understand
correctly, entity instantiation can still be used. I will try this with
my next project. The duplication of the component declaration is a bit
absurd really.

The entity doesn't need to be in a particular file. It just needs to
compile into a known library ("work" in Rob's example). In Xilinx ISE,
all Verilog modules compile into library "work" and there is no way
to change it. On the other hand, Verilog has no concept of libraries,
so it makes sense that you'd place them all together to allow
connectivity within the Verilog part of a design. The last time I
had a project where VHDL needed to instantiate Verilog modules in ISE,
I seem to remember I still needed component instantiation. That was
probably around ISE version 10.1, though. I haven't had the pleasure
(pain?) of working with Vivado yet.

--
Gabor
 
On Tuesday, April 5, 2016 at 3:31:25 PM UTC-4, Rob Gaddi wrote:
The one limitation is that direct entity instantiation plays very
Verilogily with simulation. With a component declaration, if you
recompile the thing you're instantiating you can just restart the
simulation and go. With direct entities you have to recompile your way
everything back up the way.

That has not been my experience with direct entity instantiation. If I change something, I just recompile the file that changed and go. If I change something on the entity, like add/remove a signal, then I also have to recompile the file(s) that instantiate that entity. But that behavior I don't think is any different than if a component is declared.

Kevin Jennings
 
On Tue, 05 Apr 2016 14:50:27 -0400, rickman wrote:

On 4/5/2016 2:26 PM, Rob Gaddi wrote:
rickman wrote:

On 4/5/2016 7:43 AM, Allan Herriman wrote:
On Tue, 05 Apr 2016 03:45:47 -0700, KJ wrote:

On Tuesday, April 5, 2016 at 2:36:02 AM UTC-4, Raj wrote:
My question here is, do I do this within my top level file itself?
or create a new file for this mapping?

You simply instantiate the Verilog module as if it was a VHDL
entity.
Nothing special.

I wish that were true.

The last time I tried Quartus, entity instantiation of Verilog in
VHDL didn't work; component instantiation was required.

What is "entity instantiation"???



INST_BOB: entity work.bob(Bobhavioral)
port map (...);

With no component declaration.

Ok, I did a little reading on this and I think I understand. I'm amazed
I never came across this before. So as long as the entity/architecture
is compiled and visible the component declaration is not required.

Other than a packages, I don't typically put more than one entity in a
file. But I see now this is not really a limitation if I understand
correctly, entity instantiation can still be used. I will try this with
my next project. The duplication of the component declaration is a bit
absurd really.

Direct entity instantiation is one of those things that most designers
switch over to using the moment they discover it, and never go back.
The compile order dependencies are a small price to pay for the
elimination of component declarations.

It was introduced to the language in the 1993 revision. Tool support
wasn't reliable for quite a few years though. I started using it in 2001
or 2002. (Google says my first c.l.v post about it dates from 2002.)


One of the best pieces of advice one can give regarding VHDL (or Verilog
for that matter) is to ignore any training material that was written last
century.

Regards,
Allan
 
On Wednesday, April 6, 2016 at 9:44:20 AM UTC-4, Martin Thompson wrote:
KJ writes:

On Tuesday, April 5, 2016 at 3:31:25 PM UTC-4, Rob Gaddi wrote:

The one limitation is that direct entity instantiation plays very
Verilogily with simulation. With a component declaration, if you
recompile the thing you're instantiating you can just restart the
simulation and go. With direct entities you have to recompile your way
everything back up the way.


That has not been my experience with direct entity instantiation. If I change something, I just recompile the file that changed and
go. If I change something on the entity, like add/remove a signal, then I also have to recompile the file(s) that instantiate that
entity. But that behavior I don't think is any different than if a component is declared.


If you have your entity and architecture in the same file (as many
people do), unless you can instruct the compiler to only compile the
architecture, you end up with the effect that is described (having to
recompile all the way up).

vcom -just b something.vhd

does the trick with Modelsim.
Cheers,
Martin

Interesting, but like I said, that has not been my experience. Except for unusual cases, I have entity/architecture in the same file, I use direct entity instantiation and I use Modelsim. When I only change the architecture the steps are:
- Edit/Save
- Click in the GUI to compile out of date files (which results in that one file getting compiled)
- Restart sim with either 'do run.do' (which reinvokes vsim, logs signals, etc.) or 'restart -f; run -a'
- Debug
- Repeat until design is working

I wonder what we're doing differently that I'm not having to compile back up to the top and others are.

Kevin Jennings
 
KJ wrote:

On Wednesday, April 6, 2016 at 9:44:20 AM UTC-4, Martin Thompson wrote:
KJ writes:

On Tuesday, April 5, 2016 at 3:31:25 PM UTC-4, Rob Gaddi wrote:

The one limitation is that direct entity instantiation plays very
Verilogily with simulation. With a component declaration, if you
recompile the thing you're instantiating you can just restart the
simulation and go. With direct entities you have to recompile your way
everything back up the way.


That has not been my experience with direct entity instantiation. If I change something, I just recompile the file that changed and
go. If I change something on the entity, like add/remove a signal, then I also have to recompile the file(s) that instantiate that
entity. But that behavior I don't think is any different than if a component is declared.


If you have your entity and architecture in the same file (as many
people do), unless you can instruct the compiler to only compile the
architecture, you end up with the effect that is described (having to
recompile all the way up).

vcom -just b something.vhd

does the trick with Modelsim.
Cheers,
Martin


Interesting, but like I said, that has not been my experience. Except for unusual cases, I have entity/architecture in the same file, I use direct entity instantiation and I use Modelsim. When I only change the architecture the steps are:
- Edit/Save
- Click in the GUI to compile out of date files (which results in that one file getting compiled)
- Restart sim with either 'do run.do' (which reinvokes vsim, logs signals, etc.) or 'restart -f; run -a'
- Debug
- Repeat until design is working

I wonder what we're doing differently that I'm not having to compile back up to the top and others are.

Kevin Jennings

Now that's just very strange. Most of my experience has been on
Active-HDL, but I recently switched over to Modelsim. I'll have to
confirm at some point that what I remember being the case is the case.
Since component declarations are terrible.

--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.
 
KJ <kkjennings@sbcglobal.net> writes:

On Tuesday, April 5, 2016 at 3:31:25 PM UTC-4, Rob Gaddi wrote:

The one limitation is that direct entity instantiation plays very
Verilogily with simulation. With a component declaration, if you
recompile the thing you're instantiating you can just restart the
simulation and go. With direct entities you have to recompile your way
everything back up the way.


That has not been my experience with direct entity instantiation. If I change something, I just recompile the file that changed and
go. If I change something on the entity, like add/remove a signal, then I also have to recompile the file(s) that instantiate that
entity. But that behavior I don't think is any different than if a component is declared.

If you have your entity and architecture in the same file (as many
people do), unless you can instruct the compiler to only compile the
architecture, you end up with the effect that is described (having to
recompile all the way up).

vcom -just b something.vhd

does the trick with Modelsim.
Cheers,
Martin

--
martin.j.thompson@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.co.uk/capabilities/39-electronic-hardware
 
KJ <kkjennings@sbcglobal.net> writes:

Interesting, but like I said, that has not been my experience. Except for unusual cases, I have entity/architecture in the same
file, I use direct entity instantiation and I use Modelsim. When I only change the architecture the steps are:
- Edit/Save
- Click in the GUI to compile out of date files (which results in that
one file getting compiled)

That may be the difference, the GUI :) I tend to stick at the command
line and just recompile the bits I know I'm working on (if it's only a
couple of files) or run the Makefile which tends to compile everything.
I'll have to check out the GUI option (although it runs counter to my
ingrained habits of command-lining allt he time I can!)

Thanks,
Martin

--
martin.j.thompson@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.co.uk/capabilities/39-electronic-hardware
 
On Thursday, April 14, 2016 at 11:21:09 AM UTC-4, Martin Thompson wrote:
KJ writes:


Interesting, but like I said, that has not been my experience. Except for unusual cases, I have entity/architecture in the same
file, I use direct entity instantiation and I use Modelsim. When I only change the architecture the steps are:
- Edit/Save
- Click in the GUI to compile out of date files (which results in that
one file getting compiled)

That may be the difference, the GUI :) I tend to stick at the command
line and just recompile the bits I know I'm working on (if it's only a
couple of files) or run the Makefile which tends to compile everything.
I'll have to check out the GUI option (although it runs counter to my
ingrained habits of command-lining allt he time I can!)

In that case, I would wager that the reason you're compiling files all the way to the top is due to the make file. I'm guessing that file is setup with dependency rules that if file X changes then you must also compile the parents/grandparents/etc of file X. The GUI is simply compiling the file(s) that have changed since the last compile, there is no notion of dependencies for this operation.

Kevin
 
KJ <kkjennings@sbcglobal.net> writes:



I'm guessing
that file is setup with dependency rules that if file X changes then
you must also compile the parents/grandparents/etc of file X.

Agreed. Make has no concept of design units within files or the ability
to only compile parts of the file. Make is not ideally suited to VHDL
work :)

The GUI is simply compiling the file(s) that have changed since the last compile, there is no notion of dependencies for this
operation.

I'd go further - I think the GUI is only compiling *parts* of the file
(like I do from the command-line) as if it compiled the whole file, it
would recompile the entity which would then trigger an "upward flow" of
recompiles (which you are not observing).

Does the GUI compile show what commands it is executing anywhere?

Martin


--
martin.j.thompson@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.co.uk/capabilities/39-electronic-hardware
 
On 21/04/2016 11:52, Martin Thompson wrote:
KJ <kkjennings@sbcglobal.net> writes:



I'm guessing
that file is setup with dependency rules that if file X changes then
you must also compile the parents/grandparents/etc of file X.

Agreed. Make has no concept of design units within files or the ability
to only compile parts of the file. Make is not ideally suited to VHDL
work :)

The GUI is simply compiling the file(s) that have changed since the last compile, there is no notion of dependencies for this
operation.

I'd go further - I think the GUI is only compiling *parts* of the file
(like I do from the command-line) as if it compiled the whole file, it
would recompile the entity which would then trigger an "upward flow" of
recompiles (which you are not observing).

Does the GUI compile show what commands it is executing anywhere?

Transcript window?

Seriously, I assume you are using Modelsim project files? If so then I
would strongly recommend you switch to .do/.tcl files as it will make
your life a lot easier. If compilation takes a long time then you can
use vmake although I believe you need to switch back to the old library
format to use them (I might be wrong). Just add the win32pe directory to
your search path and you can use simple batch/bash/.. scripts to compile
and run your code. If you want to use some Tcl in your script then you
can use vsim -c -do "-do mycompile.tcl;quit -f" type of commands.

Hans
www.ht-lab.com

 

Welcome to EDABoard.com

Sponsor

Back
Top