P
Petter Gustad
Guest
I think NIOS and SOPC builder are great products. However, there are a
couple things I find annoying regarding the generated Verilog code
when it comes to compatibility with third party synthesis tools and
simulators. They are:
* Support of specific synthesis tool only. The generated code have
statements like:
//exemplar translate_off
Rather than:
//synthesis translate_off
* Mix of design and testbench code in the same file
The generated top level NIOS file contains the following structure:
module nios32 ...etc...
endmodule
//exemplar translate_off
`include "/eda/sim_lib/220model.v"
`include "cpu.v"
...
module test_bench ;
...
endmodule
//exemplar translate_on
I would prefer if the testbench was generated in a separate file
(testbench.v or similar). This would ease simulation of the NIOS in
my own environment. In this case I would simply not include
testbench.v.
Sanity checks and assertions included in //synthesis
translate_off/on pairs are of course ok.
* Use of `ifdef MODEL_TECH
Not a big issue I as I can do a +define+MODEL_TECH (even though it
took me a while to figure this out) in my favorite simulator.
However, I think more descriptive preprocessor variable names would
be better, e.g.
//synthesis translate_off
`ifdef NIOS_SIM_GEN_OPCODE
assign opcode = ((((~instruction[15] && ~instruction[14] ...
//synthesis translate_on
In some cases the simulation wont work if you don't define
MODEL_TECH, e.g. like in:
`ifdef MODEL_TECH
//////////////// SIMULATION-ONLY CONTENTS
altsyncram the_altsyncram
(
...
I don't know the reason behind this structure since the synthesis
tool wont touch this code. The `ifdef MODEL_TECH could have been
left out.
* Use of include. The generated code will look like:
`include "/eda/sim_lib/altera_mf.v"
`include "/eda/sim_lib/220model.v"
`include "cpu.v"
The first two will cause problems for third party tools since they
have no clue where to look. Further the path is absolute so I can't
fix this in DC-FPGA by setting the search_path variable.
There is no need for include statements in this case. The filenames
can be included on the command line or file input list in a
synthesis tool or simulator.
It appears that my synthesis tool is processing the include
statements even inside // synthesis translate_off (I guess the could
be a synthesis translate_on in the include file), which results in
an error when it hits the absolute path.
Are these issues present in NIOS-II?
Petter
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
couple things I find annoying regarding the generated Verilog code
when it comes to compatibility with third party synthesis tools and
simulators. They are:
* Support of specific synthesis tool only. The generated code have
statements like:
//exemplar translate_off
Rather than:
//synthesis translate_off
* Mix of design and testbench code in the same file
The generated top level NIOS file contains the following structure:
module nios32 ...etc...
endmodule
//exemplar translate_off
`include "/eda/sim_lib/220model.v"
`include "cpu.v"
...
module test_bench ;
...
endmodule
//exemplar translate_on
I would prefer if the testbench was generated in a separate file
(testbench.v or similar). This would ease simulation of the NIOS in
my own environment. In this case I would simply not include
testbench.v.
Sanity checks and assertions included in //synthesis
translate_off/on pairs are of course ok.
* Use of `ifdef MODEL_TECH
Not a big issue I as I can do a +define+MODEL_TECH (even though it
took me a while to figure this out) in my favorite simulator.
However, I think more descriptive preprocessor variable names would
be better, e.g.
//synthesis translate_off
`ifdef NIOS_SIM_GEN_OPCODE
assign opcode = ((((~instruction[15] && ~instruction[14] ...
//synthesis translate_on
In some cases the simulation wont work if you don't define
MODEL_TECH, e.g. like in:
`ifdef MODEL_TECH
//////////////// SIMULATION-ONLY CONTENTS
altsyncram the_altsyncram
(
...
I don't know the reason behind this structure since the synthesis
tool wont touch this code. The `ifdef MODEL_TECH could have been
left out.
* Use of include. The generated code will look like:
`include "/eda/sim_lib/altera_mf.v"
`include "/eda/sim_lib/220model.v"
`include "cpu.v"
The first two will cause problems for third party tools since they
have no clue where to look. Further the path is absolute so I can't
fix this in DC-FPGA by setting the search_path variable.
There is no need for include statements in this case. The filenames
can be included on the command line or file input list in a
synthesis tool or simulator.
It appears that my synthesis tool is processing the include
statements even inside // synthesis translate_off (I guess the could
be a synthesis translate_on in the include file), which results in
an error when it hits the absolute path.
Are these issues present in NIOS-II?
Petter
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?