The report in
http://www.gaisler.com/doc/Evaluation_of_synthesizable_CPU_cores.pdf
might come handy to you at this point.
Regards,
Partha.
That report might give the OP some ideas about synthesizable cores in
general, but it has a lot of flaws ("portability" is judged by "how did I
get it running on my single Xilinx demo card"), and doesn't even mention
the NiosII.
I don't know about the Microblaze, but the Nios II comes with a
substantial software development environment based around Eclipse, with
gcc as the compiler and gdb for debugging (with Eclipse as the gui). You
get full software breakpointing, a few hardware breakpoints, reading and
writing of memory and variables, and everything else you would expect from
a modern debugger. You can buy extra tracing functionality (some using
internal fpga resources, others using external equipment) if you need it.
Both toolchains are based on GNU (GCC, binutils), so not many
differences.
NIOS II comes with eclipse (an IDE), but you can download that
separatly for MicroBlaze anyway,
> Does it include breakpoints and examination of register and
> memory variables? I do appriciate to tell me your experience with
> Microblaze and NiosII.
Both toolchains use GDB, so you get the same set of features.
Cheers,
Jon
From press release:
--------------------------------------------------------------------------
The Platform Studio tool suite automates a host of architecture-level design
steps and offers a powerful new software environment based on the
industry-standard Eclipse integrated design environment (IDE). The Platform
Studio 6.3i release supports the Xilinx processor solutions, including the
MicroBlaze and immersed PowerPC cores.
--------------------------------------------------------------------------
What does the download of eclipse buy you?
-Newman
This not a NIOS-II Microblaze issue, but a related Altera SOPC-Builder
vs. Xilinx XPS issue.
In SOPC-Builder you can select if you want to generate Verilog or
VHDL. Since I'm using Synopsys VCS for my simualtions I've used
Verilog as target. All the generated files are Verilog source files.
However, with Xilinx XPS it appears that only the top level module is
Verilog and it consists of several wrapper modules. The actual code
for the IP are written mostly in VHDL. Hence I can't use VCS for my
simulations (unless I spend several tens of thousands of dollars per
license to get the MX version). Alternatively, I'll have to do gate
level simulations only.
Is my understanding correct, or is there some kind of conversion I can
do in XPS?
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?
NO. There is not
the difference is in the way the IP cores are delivered.
SOPC ip cores are written in Perl and use special package "Europa"
to generate either VHDL or Verilog, so thats why it is possible to
choose either verilog or VHDL in SOPC
in EDK the IP cores are delivered in either VHDL or Verilog or BOTH
but mostly the IP cores are VHDL only.
Only in the case ALL the IP cores you are using are delivered BOTH
(that is both VHDL and Verilog versions are delivered) you can not
create a full verilog simulation model, as there is never a conversion
done from verilog to/from VHDL
if the IP core used as HDL that matches the desired simulaton language
it will be choosen, if it does not exist then resulting model will be mixed
language. As the primary language for EDK cores is VHDL so you
have no way to create full simulation model with pure verilog
gate level sim could do, but thats not always fun I guess
Antti
I didn't realise they had included it with the EDK now. So nothing.
Cheers,
Jon
I'd like to add that SOPC IP cores can be written in *at least* vhdl,
verilog, or bdf. You do not have to write your cores in Perl!
There is a wizard that imports your hdl/bdf and even generates a parameter
wizard for your core if needed!
You can also just create a custom interface to a core by setting up the
signals in a simple wizard then connecting them to the core in Quartus.
That core then appears as a memory mapped peripheral. Very simple.
We have cores integrated into our NiosII system using a mix of these
methods.
Ken
>
>
>
>
>
>
>