How to Connect External Memory to Altera FPGA

Status
Not open for further replies.
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.

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?
 

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

Attachments

  • screenshot.rar
    268.6 KB · Views: 78

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.
 

talkyztalky said:
please find attached zip file, those are the screenshots of all the steps, with the endit block removed and work directory removed.
Click to expand...

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.
 

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.
Click to expand...
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.
 

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?
 

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

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

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
 

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.
 

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)
 

talkyztalky said:
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)
Click to expand...

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?
 

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
 

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 !
 

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:
 

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
Code: 
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
Code: 
vsim -voptargs=+acc work.dd
# vsim -voptargs=+acc work.dd 
# Loading work.dd
 

Status
Not open for further replies.

Similar threads

Menu
Log in
Register
Cookies are required to use this site. You must accept them to continue using the site. Learn more…