How to Connect External Memory to Altera FPGA

[mrflibble]

Well there is nothing wrong with the vlog compilation. Did you post this snippet of the transcript because of the warnings? The warning is not a problem it only signifies that you probably didn't stop the previous simulation so that it released the wlf file. Exiting Modelsim completely and delete all the wlf files will allow Modelsim to open the default vsim.wlf.

What is the vsim command line look like, it appears that it was left out of your post?

Amusing how these things & thought processes work, because while I was reading the above I was thinking "mmmh, he (talkyztalky) had better be damn sure that his simulation actually reflects the latest sources". Because recently I had a fun little puzzle that was 100% my own fault, but annoying nonetheless. And the root cause was that I didn't delete all the old intermediate results.

I don't know if you are running the VHDL & Verilog simulations in the same directory, but I would probably try deleting the work library and recreate it, so you start fresh with only the verilog modules complied into the work library. This at a minimum will ensure you aren't using some old module or picking up something compiled for VHDL.

Yup, exactly that! Throw away the "work" directory & then re-run simulation. Otherwise you may be seeing old results.

As for posting logs with warnings, by all means keep up that habit. Posting too little information generally is infuriatingly annoying far more often than by posting too much information. If only because logs can sometimes contain little clues.

And indeed the Z's are might suspicious. In fact, I really thought that the endit in the initial block was holding up the rest of the simulation from running. Which is why I suggested removing it.

talkyztalky:
Could you post a screenshot of the simulation AFTER you removed the endit block?

 

[talkyztalky]

please find attached zip file, those are the screenshots of all the steps, with the endit block removed and work directory removed.

 

[mrflibble]

Confounded! Unfortunately that indeed looks like you described.

In which case I can only echo what ads-ee already said, with bold for added emphasis.

If there are no warnings from vsim after the clean reparse/compile, then it looks like you will have to debug it by tracing the signals back. It's very suspicious that the Verilog simulation is filled with Zs. I would trace the clock back through the hierarchy and try to find out what is stopping it from being generated.

 

[ads-ee]

please find attached zip file, those are the screenshots of all the steps, with the endit block removed and work directory removed.

Tsk, tsk, tsk,...You're running as Administrator on the machine!? Hasn't anyone told you about system security...You should be running normally as a user not an administrator.

dd_example_top_tb.v seems to have a instantiated module that is missing a reset.

 

[mrflibble]

Nah. He just doctered the paths and then took a screenshot. That's what I'd do to mess with people. XD

dd_example_top_tb.v seems to have a instantiated module that is missing a reset.

Good call. I did notice the ZZZ signal in the testbench, but that was hardly unique given all the Z's. But that warning message is a pretty good hint.

 

[talkyztalky]

what about posting the project and if someone have time to check it?

 

[talkyztalky]

one more thing, the simulation works only if i compile the testbench alone without other modules,

while if i compile all files the simulation doesn't start

does this means something?

 

[ads-ee]

while if i compile all files the simulation doesn't start

Are you saying the simulation hangs at 0 ns? or do you mean something else?

 

[talkyztalky]

sorry i mean like the previous screenshots, it started but all signals zzz and xxx

 

[ads-ee]

Did you check what I posted in #24 about the missing reset?

 

[talkyztalky]

yes,

in vhdl it gives the same error but the simulation works fine for that i thought it's not the problem

and while cheking the error, it's nothing with the reset signal

 

[ads-ee]

Without the design files I don't think I can help further. As I don't have Altera tools installed on any machines I use...well I can't help even if you posted the design archive. :-(

This seems like one of those subtle problems that an experienced person would find after some effort, but looks more or less overwhelming to a relative novice. I guess you'll just have to develop some experience and methodically go through the simulation and trace the X/U's back through the design till you find, what is not getting initialized properly.

 

[talkyztalky]

these 2 images from modelsim, one using vhdl and the other using verilog, does the difference in colors mean anything? (signals compilation or anything else)

 

[ads-ee]

these 2 images from modelsim, one using vhdl and the other using verilog, does the difference in colors mean anything? (signals compilation or anything else)

The color only signifies the use of Verilog or VHDL. I originally noticed the difference in mixed mode simulations.

Have you tried tracing back through the design for when the first Z or X appears?

 

[talkyztalky]

yes i did and ther is no difference in the hierarchy between the two designs, z and x signals in the verilog one exist from the begining and not affected from any other signal (clocks and resets).

one more thing, i noticed a green arrow on the signals in the vhdl design and missing in the verilog design

 

[talkyztalky]

one last question, i noticed difference between files after compilation in the library, anyone knows what it means?

one for the vhdl and the other for the verilog, the testbench type is different !

 

[ads-ee]

A hierarchy of VHDL code is an entity (you do know VHDL?) and the hierarchy of Verilog code is a module (you do know Verilog?).

You are floundering around grasping at straws. Take a step back and look at the overall testbench, make sure the testbench is stimulated the design in exactly the same way for both versions.

One way to test the testbenches for the Verilog/VHDL is to swap the IP generated from each. As the I/O for the core should be the same try putting the IP core generated from the non-working version in the testbench for the working version. If the IP starts working then the testbench is likely the problem. If it stops working test the non-working testbench with the working IP core and if that test now works, then the IP has a problem.

After reading some of the older posts in this thread...
Post a screen capture of the first say 400 ns of the simulation for both the VHDL and Verilog designs with only the testbench signals in the waveform view. If there are any X's or U's in the testbench that is a bad thing. Testbenches should never ever send X's or U's into a DUT. I'm starting to suspect you may be thinking something is okay because you don't know any better and think that the code generated by the tools is automatically good code. I've found that most if not all of the IP produced by FPGA vendors is only slightly better than something found on OpenCores. It's no wonder they encrypt their cores! :wink:

 

[talkyztalky]

i generated the ip and put it as top level entity and compiled the design

the simulation in vhdl was successful and the components of the ip were visible

vsim -voptargs=+acc work.dd
# vsim -voptargs=+acc work.dd 
# Loading std.standard
# Loading std.textio(body)
# Loading ieee.std_logic_1164(body)
# Loading work.dd(syn)
# Loading ieee.numeric_std(body)
# Loading ieee.std_logic_arith(body)
# Loading ieee.std_logic_unsigned(body)
# Loading altera.altera_europa_support_lib(body)
# Loading altera_mf.altera_mf_components
# Loading work.dd_controller_phy(europa)
# Loading sgate.sgate_pack(body)
# Loading work.dd_alt_mem_ddrx_controller_top(rtl)
# Loading altera_mf.altera_common_conversion(body)
# Loading altera_mf.altera_device_families(body)
# Loading altera_mf.altsyncram(translated)
# Loading ieee.std_logic_signed(body)
# Loading sgate.oper_add(sim_arch)
# Loading sgate.oper_decoder(sim_arch)
# Loading sgate.oper_left_shift(sim_arch)
# Loading sgate.oper_less_than(sim_arch)
# Loading sgate.oper_mux(sim_arch)
# Loading sgate.oper_selector(sim_arch)
# Loading altera_mf.scfifo(behavior)
# Loading ieee.vital_timing(body)
# Loading ieee.vital_primitives(body)
# Loading altera.dffeas_pack
# Loading altera.altera_primitives_components
# Loading cycloneiv.cycloneiv_atom_pack(body)
# Loading cycloneiv.cycloneiv_components
# Loading work.dd_phy(rtl)
# Loading altera_mf.altddio_bidir(struct)
# Loading altera_mf.altddio_in(behave)
# Loading altera_mf.altddio_out(behave)
# Loading cycloneiv.cycloneiv_ddio_oe(arch)
# Loading altera.dffeas(vital_dffeas)
# Loading cycloneiv.cycloneiv_mux21(altvital)
# Loading cycloneiv.cycloneiv_ddio_out(arch)
# Loading cycloneiv.cycloneiv_latch(vital_latch)
# Loading cycloneiv.cycloneiv_routing_wire(behave)
# Loading cycloneiv.cycloneiv_io_ibuf(arch)
# Loading cycloneiv.cycloneiv_io_obuf(arch)
# Loading work.dd_phy_alt_mem_phy_pll(syn)
# Loading altera_mf.mf_pllpack(body)
# Loading altera_mf.altpll(behavior)
# Loading altera_mf.mf_cycloneiiigl_pll(vital_pll)
# Loading altera_mf.mf_stingray_mn_cntr(behave)
# Loading altera_mf.mf_stingray_post_divider(behave)
# Loading altera_mf.mf_stingray_scale_cntr(behave)
# Loading work.dd_phy_alt_mem_phy_seq_wrapper(rtl)
# Loading work.dd_phy_alt_mem_phy_record_pkg(body)
# Loading work.dd_phy_alt_mem_phy_constants_pkg
# Loading work.dd_phy_alt_mem_phy_regs_pkg(body)
# Loading work.dd_phy_alt_mem_phy_iram_addr_pkg(body)
# Loading work.dd_phy_alt_mem_phy_addr_cmd_pkg(body)
# Loading work.dd_phy_alt_mem_phy_seq(struct)
# Loading work.dd_phy_alt_mem_phy_admin(struct)
# Loading work.dd_phy_alt_mem_phy_dgrb(struct)
# Loading work.dd_phy_alt_mem_phy_dgwb(rtl)
# Loading work.dd_phy_alt_mem_phy_ctrl(struct)
# Loading sgate.tri_bus(sim_arch)

the simulation in verilog gives z signals and the components of the ip weren't visible

vsim -voptargs=+acc work.dd
# vsim -voptargs=+acc work.dd 
# Loading work.dd