Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

strategy for consecutive WR/RD command

Status
Not open for further replies.

syedshan

Advanced Member level 1
Advanced Member level 1
Joined
Feb 27, 2012
Messages
463
Helped
27
Reputation
54
Reaction score
26
Trophy points
1,308
Location
Jeonju, South Korea
Visit site
Activity points
5,134
Dear all,

I have to write VHDL code for DDR3 communication where I have to write code for consecutive WRITE or READ commands...
Now I could not understand of strategy for that...I mean that these commands are feed in to the DDR3 and unless DDR3 is not ready i.e. does not accept the previous command next command should stay in pipeline. Now if lets say 3 or 4 or more commands come in pipeline while the first command is not even accepted at the target side, then how to save these commands, one option I can think of is using buffer, but I could not visualize how to do that in vhdl...

frankly speaking I am not even sure if it is called pipeling or not...
Or is there any better strategy

Please see the figure.

Any idea, or suggestion...please share
 

Attachments

  • Capture.JPG
    Capture.JPG
    63.4 KB · Views: 120
Last edited:

Unfortunately I don't have a solution for you, but I do have a suggestion... It might help if you keep post together in the same thread. I am assuming this is a continuation of the problem with the "8 size burst" thing right? If you keep it in one thread, people can see the history of your problem which may help in finding you a solution. Or at the very least post links to other related threads... Just an idea.
 

Yes,


You get it not exactly right, but it is directly related to it and it is actually that thing...
So I have figure out myself, would like you to comment...
Why don't use a FIFO memory and then attach its rd_en pin to the logic that is dealing with the data and address.

Bests,
Shan
 

Not 100% sure what you mean here. A fifo might help if your data is generated at irregular data rates. But since I don't know your data patterns...
If your data and address patterns are such that a fifo will help, then use a fifo. :p

So you say "not exactly right", but why do I have the feeling it's exactly right and part of exactly the same problem? :p At any rate, you have some DDR module and it has a burst size of 8, and you having problems creating the bit that generates the addresses. And as I said in the previous thread, I don't really understand the problem. Generate addresses and gogogo. Maybe I am missing something, but can you take the time to explain what the issue is? Other than the issue "don't know what to do". Because my response to that is "don't know how to help", because I don't understand the problem.
 

Thank you for your deep interest as always...^^
and sorry for late reply since I actually (I think) found the solution and was implementing it, took time ! again as always :-( although I want to
excel fast in this field, but...ah!

any how...
As yo might know that MIG interface for DDR3 has 2 paths,
a. command path
b. data path

Hence in command path command*(please read command and address) and addresses are fetched which becomes precursor for data-path.
Please see the figure below
b2b_data.JPG

Hence when a command is issued then the MIG gives off RDY signal indicating that command has been issued, ok go-on and send data...
It itself has an internal FIFO for back-to-back transfer-case multiple commands which gives me idea of implementing my own FIFO as well since I wish to give back to back
data and for that has to increase the address consecutively. Hence I also implemented a FIFO buffer...



Hope this helps explaining, may be it might help others later on, also if you have better answer or solution please do share, although I think I wont be going back because of time limit...

One more question: not related this time...If I may ask?
How much time did it take you to master the FPGA designing...
I mean I think I know the syntax of VHDL and verilog quite well. I understand the digital logic as well.
Can very well read and understand the data sheets, but I think when it comes to implement hard and big logics to VHDL I find it difficult(in the starting I guess...It looks like I would not make some good,lets say ADC-interfacing-sort-of code).
And it is the first phase when goto implementation...Damn! it gives more hard time.

So many things, so little time, simulation, timing simulation, understand different protocols, dont-know-ISE-implementation-phase-in-much-detail; just rely on software itself,
Please share your experience.

of course implementing medium level is ok for me...
I am all stressed up with this...but still trying. And by the way I like this thing as well.
Whenever I saw digital things, or articles I am attracted towards it by sixth sense or what ^^
 
Last edited:

Thanks for taking the time to try and explain things. Stupid question: are you using the core generator (MIG) thing, or something else? I was assuming core generator, but you never really mentioned. Single port? Multi port? Is it on an existing fpga dev board, or on a custom board?

Also, I must admit I haven't played with DDR3 yet. Only DDR and DDR2. DDR3 is on my todo list, and I am hoping it will be roughly the same as DDR2 on the fpga side. :)

As for this ...

So many things, so little time, simulation, timing simulation, understand different protocols, dont-know-ISE-implementation-phase-in-much-detail; just rely on software itself,

Heh, I am in pretty much the same boat as you. There indeed is so much stuff and so little time... You don't happen to have any PCIe x1 reference designs floating around have you?
 

Thanks for reply again

Yes I am using MIG by core generator , it is not on any development board. It is a 4rd party DSP board. which is PCIe based, but I dont have to deal with it since they have that done already.
Never mind, you can share your experiences for burst in DDR2 since it has BL4 as far as I remember.

About PCIe x1. I wish I had done something so that I could share with you...:)
Never mind good luck

Bests,
Shan
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top