cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Visitor
Visitor
10,487 Views
Registered: ‎08-01-2014

MIG DDR3 SDRAM Controller - Problems in Example Design Simulations

Jump to solution

Hi,

 

i am running simulations "sim_tb_top" of example design of MIG DDR3 SDRAM Memory Controller. But i am not getting the expected results. I have implemented the test bench according to the instructions given in "ug406". I have used BURST_MODE 8. Data is written properly to write FiFo but read FiFo is not giving me the expected written values back and also not in correct order. The problems i am facing are explained in the following,

 

1. After the "phy_init_done" signal becomes High, the FIRST data in the read FiFo "app_rd_data[255:0]" is always "xxxxxxxx..." whenever the "app_rd_data_valid" turns high. Is this the default value i am expected to get everytime or i am doing any mistake somewhere?

 

2. When "app_rd_data_valid" signal turns High for the rest of the times, i am getting the written data back in read FiFo but in reverse order. For example, if i write the data[1aaa..., 2aaa...] in "app_wdf_data[255:0]" in two clock cycles, i get it back in read FiFo "app_rd_data[255:0]" in reverse order like [2aaa..., 1aaa...]. Is this the default way of getting the written data back in read FiFo or i am making any mistake somewhere?

 

3. The last written data is not returned back in the read FiFo though i sent the read command after every written command. Why?

 

4. Whenever the "app_rd_data_valid" signal turns High, read FiFo "app_rd_data[255:0]" gets the same value TWICE. Which is not the normal behaviour. Why is this so?

 

The Simulation Results Snapshopts for the above mentioned problems are also being attacehd. Please help me in solving all the above mentioned problems. I will be very grateful to you.

 

Regards,

Ali

0 Kudos
Reply
1 Solution

Accepted Solutions
Xilinx Employee
Xilinx Employee
17,397 Views
Registered: ‎07-11-2011

Hi,

 

1. After the "phy_init_done" signal becomes High, the FIRST data in the read FiFo "app_rd_data[255:0]" is always "xxxxxxxx..." whenever the "app_rd_data_valid" turns high. Is this the default value i am expected to get everytime or i am doing any mistake somewhere?

[Vanitha] This is not expected, I suspect if your first address is not written is properly,  read from an unwritten address can be "XXXX.."

 

2. When "app_rd_data_valid" signal turns High for the rest of the times, i am getting the written data back in read FiFo but in reverse order. For example, if i write the data[1aaa..., 2aaa...] in "app_wdf_data[255:0]" in two clock cycles, i get it back in read FiFo "app_rd_data[255:0]" in reverse order like [2aaa..., 1aaa...]. Is this the default way of getting the written data back in read FiFo or i am making any mistake somewhere?

[Vanitha] Data will be obtained in the written order, from your waves I see if you are issuing 2 write commands (app_en asserted for 2 clocks) with two different datas, so there is a change address gets assigned with seond beat of data, please go through UG406 Interfacing with the core, write, read and command path timing diagrams.

 

3. The last written data is not returned back in the read FiFo though i sent the read command after every written command. Why?

[Vanitha] similar to 1, write might not be proper for the last address.

 

4. Whenever the "app_rd_data_valid" signal turns High, read FiFo "app_rd_data[255:0]" gets the same value TWICE. Which is not the normal behaviour. Why is this so?

[Vanitha] Same as 2, fom your waves I see you are issuing 2 commands

 

I would sugget you to run the simulation with xilinx provided tarffic gen and analyze the waveforms so that you will get  better idea.

 

Regards,

Vanitha

---------------------------------------------------------------------------------------------
Please do google search before posting, you may find relavant information.
Mark the post - "Accept as solution" and give kudos if information provided is helpful and reply oriented

View solution in original post

0 Kudos
Reply
7 Replies
Xilinx Employee
Xilinx Employee
17,398 Views
Registered: ‎07-11-2011

Hi,

 

1. After the "phy_init_done" signal becomes High, the FIRST data in the read FiFo "app_rd_data[255:0]" is always "xxxxxxxx..." whenever the "app_rd_data_valid" turns high. Is this the default value i am expected to get everytime or i am doing any mistake somewhere?

[Vanitha] This is not expected, I suspect if your first address is not written is properly,  read from an unwritten address can be "XXXX.."

 

2. When "app_rd_data_valid" signal turns High for the rest of the times, i am getting the written data back in read FiFo but in reverse order. For example, if i write the data[1aaa..., 2aaa...] in "app_wdf_data[255:0]" in two clock cycles, i get it back in read FiFo "app_rd_data[255:0]" in reverse order like [2aaa..., 1aaa...]. Is this the default way of getting the written data back in read FiFo or i am making any mistake somewhere?

[Vanitha] Data will be obtained in the written order, from your waves I see if you are issuing 2 write commands (app_en asserted for 2 clocks) with two different datas, so there is a change address gets assigned with seond beat of data, please go through UG406 Interfacing with the core, write, read and command path timing diagrams.

 

3. The last written data is not returned back in the read FiFo though i sent the read command after every written command. Why?

[Vanitha] similar to 1, write might not be proper for the last address.

 

4. Whenever the "app_rd_data_valid" signal turns High, read FiFo "app_rd_data[255:0]" gets the same value TWICE. Which is not the normal behaviour. Why is this so?

[Vanitha] Same as 2, fom your waves I see you are issuing 2 commands

 

I would sugget you to run the simulation with xilinx provided tarffic gen and analyze the waveforms so that you will get  better idea.

 

Regards,

Vanitha

---------------------------------------------------------------------------------------------
Please do google search before posting, you may find relavant information.
Mark the post - "Accept as solution" and give kudos if information provided is helpful and reply oriented

View solution in original post

0 Kudos
Reply
Visitor
Visitor
10,464 Views
Registered: ‎08-01-2014

Hi Vanitha,

thank you very much for your reply. yes you are right. I was writing the "write" command for two cycles, Problem 4 has been solved by limiting the "write" command to one cycle only.

But Problem 1, Problem 2 and Problem 3 still exists. Simulations results file is attached again. Also I have attached "sim_tb_top.vhd" in which you can also have a look on my implemented test bench code.

As you suggested for Problem 1 and Problem 3, address is not written properly; but i am only using one address from start of my simulations till end (for each write and read command).

And as you suggested, i should run the simulations with xilinx provided tarffic gen. I already did it before, but the simulations didn't stop. I terminated myself the simulations with traffic gen after almost 10hours and got no results(waveform). "phy_init_done" signal did not turned to logic value 'True', and every other signal was giving its initialized value only. May be i didn't set the parameters values correctly, but i don't know which parameters should i set before running the simulations with xilinx provided tarffic gen. Could you please also tell me what should i look for before running the simulations with xilinx provided tarffic gen?

Regards
Ali

0 Kudos
Reply
Xilinx Employee
Xilinx Employee
10,458 Views
Registered: ‎07-11-2011

Hi,

 

To run example design simulation no need to set any parameters, generate MIG, open ISE command prompt(from start Menu->ISE Design Suite-> Accessories), navigare to exampl_design/sim folder in MIG generated directory and run isim.bat

If you are able to run that and analyze the waves I wish you could solve other problems as well.

Your test bench seems to be fully combinational which I don't think will help in Synthesis, so better go for process and counters oriented approach.

Also UI interface signal assertions depend on your MIG configuration so please upload your mig.prj and ucf as well.

 

 

 

---------------------------------------------------------------------------------------------
Please do google search before posting, you may find relavant information.
Mark the post - "Accept as solution" and give kudos if information provided is helpful and reply oriented
0 Kudos
Reply
Visitor
Visitor
10,454 Views
Registered: ‎08-01-2014

Hi,

 

please find the mig.prj and ucf in the attached files. And thanks for your suggestions as well.

 

Regards

Ali

0 Kudos
Reply
Xilinx Employee
Xilinx Employee
10,415 Views
Registered: ‎07-11-2011

Hi,

 

I did send you an example UI traffic logic,  please generate MIG example design, comment out traffic gen and stich the entity that I sent and see how it goes.

You may need to change app_wdf_data width etc as per your core settings

 

Regards,

Vanitha

---------------------------------------------------------------------------------------------
Please do google search before posting, you may find relavant information.
Mark the post - "Accept as solution" and give kudos if information provided is helpful and reply oriented
0 Kudos
Reply
Visitor
Visitor
10,405 Views
Registered: ‎08-01-2014

Hi Vanitha,

 

thank you for your email too. I will try that example UI traffic logic and will let you know about my findings.

 

Regards,

Ali

0 Kudos
Reply
Visitor
Visitor
10,139 Views
Registered: ‎08-01-2014

Hi Vanitha,

 

i have tried the UI traffic logic provided by you but it didn't work. I checked my code again and found out that i was making a big blunder, was considering '000' as a read command and '001' as a write command which was incorrect. Also i was issung 'app_en' command at the same time along with writing data to FIFO, but now from tutorial i found out that 'app_en' command should be issued AFTER writing data to FIFO. So when i made these changes BL8 mode is working perfectly now.

 

Thanks alot for your help.

 

Regards,

Ali

0 Kudos
Reply