verilog vs vhdl difference

[zlotawy]

HEllo,
I have the same component written in verilog and vhdl.

--------------------------------
entity COMP is
port(
CLK: in std_logic;
WE :in std_logic;
W_ADDR :in std_logic_vector(5 downto 0);
R_ADDR :in std_logic_vector(5 downto 0);
DIN :in std_logic_vector(7 downto 0);
DOUT ut std_logic_vector(7 downto 0)
);
end COMP ;

architecture Behavioral of COMP is
type cube_array is array(2**6-1 downto 0) of std_logic_vector(7 downto 0);
--type cube_array is array(natural range <>) of std_logic_vector(7 downto
0);
signal sig_dout : std_logic_vector(7 downto 0);
signal s_mem : cube_array;

begin

process(CLK)
begin
if rising_edge(CLK) then
if WE='1' THEN
s_mem(conv_integer(R_ADDR)) <= din;
else
sig_dout <= s_mem(conv_integer(W_ADDR));
end if;
end if;
end process;
dout <=sig_dout;
end Behavioral;


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

module sram (
clk, we, w_adr, r_adr, din, dout
);

parameter
a_w = 6, // parametry formalne
d_w = 8;

input clk, we;
input [a_w-1:0] w_adr, r_adr;
input [d_w-1:0] din;
output [d_w-1:0] dout;

reg [ d_w-1:0] dout;
reg [2**a_w-1:0] s_mem[7:0];

always @(posedge clk)
if (we) s_mem[r_adr] <= din;
else dout <= s_mem[w_adr];

endmodule----------------------------and afer synthesize for vhdl I got
Maximum Frequency: 339.732MHzand for verilog I got Maximum Frequency:
438.308MHz.Device is 2vp30-5ff1152.Why are there differences?Thanks,zlotawy

 

[Jonathan Bromley]

I have the same component written in verilog and vhdl.

[...]

Looks right to me.

and afer synthesize for vhdl I got
Maximum Frequency: 339.732MHz
and for verilog I got Maximum Frequency:
438.308MHz.
Device is 2vp30-5ff1152.
Why are there differences?

Good question. At a guess I would suggest that
the synthesis tool has inferred RAM from one of
your descriptions, but not from the other - or
maybe different kinds of RAM from the two
descriptions. Did you check the synthesis reports
or the schematic to see what was created? In some
tools, RAM inference is very sensitive to coding style.

I can't think of any other sane reason, unless there's a
conspiracy by your tool vendor to force everyone to use
Verilog "because it's faster"
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
(e-mail address removed)
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[zlotawy]

Uzytkownik "Jonathan Bromley" <[email protected]> napisal w
wiadomosci
thera are rams in both causes. but I see difference in report:

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

VERILOG:

INFO:Xst:2664 - HDL ADVISOR - Unit <sram> : The RAM <Mram_s_mem> will be
implemented on LUTs either because you have described an asynchronous read
or because of currently unsupported block RAM features. If you have
described an asynchronous read, making it synchronous would allow you to
take advantage of available block RAM resources, for optimized device usage
and improved timings. Please refer to your documentation for coding
guidelines.


WARNING:Xst:2677 - Node <inst_Mram_mem8> of sequential type is unconnected
in block <sram>.
..
..
..
WARNING:Xst:2677 - Node <inst_Mram_mem63> of sequential type is unconnected
in block <sram>.


HDL Synthesis Report

Macro Statistics
# RAMs : 1
8x64-bit dual-port RAM : 1
# Registers : 1
8-bit register : 1


--------------------------------------------------------------------------
VHDL:

INFO:Xst:2452 - Unit <komorka> : The small RAM <Mram_s_mem> will be
implemented on LUTs in order to maximize performance and save block RAM
resources. If you want to force its implementation on block, use
option/constraint ram_style.

There ano warnings.

HDL Synthesis Report

Macro Statistics
# RAMs : 1
64x8-bit dual-port RAM : 1
# Registers : 1
8-bit register : 1

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


Hmmm.... I have no idea

zlotawy

 

[ghelbig]

Uzytkownik "Jonathan Bromley" <[email protected]> napisal w
wiadomosci
thera are rams in both causes. but I see difference in report:

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

VERILOG:

INFO:Xst:2664 - HDL ADVISOR - Unit <sram> : The RAM <Mram_s_mem> will be
implemented on LUTs either because you have described an asynchronous read
or because of currently unsupported block RAM features. If you have
described an asynchronous read, making it synchronous would allow you to
take advantage of available block RAM resources, for optimized device usage
and improved timings. Please refer to your documentation for coding
guidelines.

WARNING:Xst:2677 - Node <inst_Mram_mem8> of sequential type is unconnected
in block <sram>.
.
.
.
WARNING:Xst:2677 - Node <inst_Mram_mem63> of sequential type is unconnected
in block <sram>.

HDL Synthesis Report

Macro Statistics
# RAMs : 1
8x64-bit dual-port RAM : 1
# Registers : 1
8-bit register : 1

--------------------------------------------------------------------------
VHDL:

INFO:Xst:2452 - Unit <komorka> : The small RAM <Mram_s_mem> will be
implemented on LUTs in order to maximize performance and save block RAM
resources. If you want to force its implementation on block, use
option/constraint ram_style.

There ano warnings.

HDL Synthesis Report

Macro Statistics
# RAMs : 1
64x8-bit dual-port RAM : 1
# Registers : 1
8-bit register : 1

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

Hmmm.... I have no idea

zlotawy

They answer may be in the Macro Statistics. In one case, a 64*8 RAM
is inferred. In the other, the ram is 8*64. The 64*8(VHDL) will be
slower, as the address decode takes longer.

Are you 100% sure the two pieces of code are equivalent?

G.

 

[KJ]

HEllo,
I have the same component written in verilog and vhdl.

438.308MHz.Device is 2vp30-5ff1152.Why are there
differences?Thanks,zlotawy

Using your posted code and Quartus 6.1 targetting a Stratix III I got

VHDL: Fmax = 535.33 MHz
Verilog: Fmax = 539.37 MHz

The technology map viewer using both designs looks like it came out the
same. I suspect that the fact that I didn't lock down pins or anything is
the reason for the minor performance difference.

Perhaps XST is trying to convert people from Verilog to VHDL by giving them
inferior results....or maybe there is something else going on that you're
missing since XST inferred a different memory width and depth.

KJ

 

[Mark McDougall]

and afer synthesize for vhdl I got
Maximum Frequency: 339.732MHzand for verilog I got Maximum Frequency:
438.308MHz.Device is 2vp30-5ff1152.Why are there differences?

I think it's because the VHDL component has more lines of code, it's
slower... ?



Regards,

 

[KJ]

I think it's because the VHDL component has more lines of code, it's
slower... ?

So it just got tired of synthesizing?

Since Quartus was able to infer the exact same circuit with both code sets,
whatever is going on is either:
- User error (i.e. the posted code is really not quite what he posted
results from)
- Synthesis tool having trouble with VHDL where the competitor's tools do
not.

KJ

 

[Andy]

Then try this:

ENTITY COMP IS
GENERIC(
a_w : integer := 6;
d_w : integer := 8);
PORT(
clk, we : IN std_logic;
w_addr, r_addr : IN integer RANGE 0 TO 2**a_w-1;
din : IN integer RANGE 0 TO 2**d_w-1;
dout : OUT integer RANGE 0 TO 2**d_w-1);
END COMP;

ARCHITECTURE Behavioral OF COMP IS
TYPE cube_array IS ARRAY(2**a_w-1 DOWNTO 0)
OF integer RANGE 0 TO 2**d_w-1;
SIGNAL s_mem : cube_array;
BEGIN
s_mem(w_addr) <= din WHEN rising_edge(clk) AND we = '1';
dout <= s_mem(r_addr) WHEN rising_edge(clk) AND we = '0';
END Behavioral;

Fewer lines than verilog, even w/ added parameters,
so it's got to synthesize to a faster circuit, right? ;^)

BTW, r_addr and w_addr appear to be swapped in the original post.

Andy

 

[David Spencer]

afer synthesize for vhdl I got Maximum Frequency: 339.732MHzand for
verilog I got Maximum Frequency: 438.308MHz.Device is 2vp30-5ff1152.Why
are there differences?Thanks,zlotawy

I'm guessing that these figures are actually post place-and-route, rather
than post synthesis. If so, do you have an fmax constraint set? If you do,
the tool will do what it can to reach the required number but once it's
there it won't waste a CPU cycle more on trying to better it. Therefore, for
example, if your fmax was set to 300MHz then the tools would claim job well
done in both cases. If you don't have an fmax constraint then you should set
one since without one the tool has no way of knowing how hard it should try.

 

[Marcus Harnisch]

Fewer lines than verilog,

Of course not ;-)

module sram #(parameter a_w =6, d_w = 8)
(input clk,
we,
[a_w-1:0] w_adr, r_adr,
[d_w-1:0] din,
output reg [d_w-1:0] dout);

reg [2**a_w-1:0] s_mem[7:0];

always @(posedge clk)
if (we) s_mem[r_adr] <= din;
else dout <= s_mem[w_adr];

endmodule

 

[Andy]

Of course not ;-)

Of course, there is always the absurd limit of a single line for the
entire design... ;^)

Andy

 

[Andy]

I'm guessing that these figures are actually post place-and-route, rather
than post synthesis. If so, do you have an fmax constraint set? If you do,
the tool will do what it can to reach the required number but once it's
there it won't waste a CPU cycle more on trying to better it. Therefore, for
example, if your fmax was set to 300MHz then the tools would claim job well
done in both cases. If you don't have an fmax constraint then you should set
one since without one the tool has no way of knowing how hard it should try.

In synplify, if you don't set one, it is the same as "make it as fast
as possible"

 

[Marcus Harnisch]

Of course, there is always the absurd limit of a single line for the
entire design... ;^)

Besides trying to be funny, I wanted to make the point that old style
port declarations in Verilog are sooo nineties ('95 to be exact) and
not really the best way to declare module ports.

Regards
Marcus

 

[Andy]

Besides trying to be funny, I wanted to make the point that old style
port declarations in Verilog are sooo nineties ('95 to be exact) and
not really the best way to declare module ports.

Thanks for the clarification, the difference slipped by me.

Both languages suffer from a lot of "historical" (read: archaic, IMHO)
coding styles and practices (NOT that I'm advocating the concurrent
assignment statement style for registers in general, but it does come
in handy at times). For VHDL, I'm thinking more along the lines of
components/configurations vs entity/architecture instantiation,
variables vs signals, separate processes for combinatorial logic and
registers, non-standard arithmetic packages, and on, and on...

Andy