cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Participant
Participant
10,735 Views
Registered: ‎07-31-2010

MIG UI interface

The new version of MIG is poorly document with respect to the UI.  There is a lot of details about the internals, but little on how it would be used.  The AXI interface seems to make sense for processors, but seems less useful otherwise.

 

My setup has the 2:1 interface.  The "burst type" is BL8.  I'm assuming the "burst_type" is "sequential".  Somehow the documentation manages to mix terminology, and never describes the second "burst_type".

 

The main questions I have:

1.)  What happens if I write "ABCD" "EFGH" to the wdf, then write the af with cmd=write, and address x"00000001"?  what about x"00000002" or x"00000003"?

2.)  What happens if I write to the af with cmd=read and address = 0x00000000?  what about x"00000001", x"00000002", and x"00000003"?

3.)  How much data comes back in #2?  Eg, do I get a single valid even in BL8 mode, or do I get two valids back?  The waveforms could indicate two reads commands are required per BL8 command.

 

 

Xilinx, review the MIG documentation.  There are _several_ errors and inconsistencies.  Also, drop the odd "burst of type eight" nomenclature -- there is another setting actually called "burst type" and it is unrelated to burst length.  Basically, re-do the entire user interface section.  Nearly all of the diagrams have errors, are incomplete, redundent, or otherwise confusing.  The text basically just refers to these diagrams with little clarification of details.

8 Replies
Xilinx Employee
Xilinx Employee
10,723 Views
Registered: ‎07-11-2011

Hi,

 

The new version of MIG is poorly document with respect to the UI.  There is a lot of details about the internals, but little on how it would be used.  

-- Could you pleae be more specific which document are you referring? UG586 December 18, 2013 version?

--Internal detials are required to know core architecture, how to use the core is given in the user interface/native interface section

 

 

The AXI interface seems to make sense for processors, but seems less useful otherwise.

-- We have seen non processor applications that need AXI and hence the inteface is provided, if you do not need it you can uncheck the option in GUI and ignore the section that describes it in the doc

 

My setup has the 2:1 interface.  The "burst type" is BL8.  I'm assuming the "burst_type" is "sequential".  Somehow the documentation manages to mix terminology, and never describes the second "burst_type".

--The terminology of  Burst type and length are defined by JEDEC and Xilinx follows them.

 

The main questions I have:

1.)  What happens if I write "ABCD" "EFGH" to the wdf, then write the af with cmd=write, and address x"00000001"?  what about x"00000002" or x"00000003"?

2.)  What happens if I write to the af with cmd=read and address = 0x00000000?  what about x"00000001", x"00000002", and x"00000003"?

3.)  How much data comes back in #2?  Eg, do I get a single valid even in BL8 mode, or do I get two valids back?  The waveforms could indicate two reads commands are required per BL8 command.

--For each read command you will get one rd_valid signal, please refer below Xilinx link and its associated ARs,  if you are still unclear let us know

http://www.xilinx.com/support/answers/34779.html

  

 

Xilinx, review the MIG documentation.  There are _several_ errors and inconsistencies.  Also, drop the odd "burst of type eight" nomenclature -- there is another setting actually called "burst type" and it is unrelated to burst length.  Basically, re-do the entire user interface section.  Nearly all of the diagrams have errors, are incomplete, redundent, or otherwise confusing.  The text basically just refers to these diagrams with little clarification of details.

 

-- I think especially the UI section has no change from 6 series and almost the same content was retained in 7 series UG as well, we have not seen users complaining about it.

Can you share us where do you see the text "Burst type 8" ?

I  think re-doing is practically not possible, if you could run quick MIG simulation and analyze the UI waveforms and compare against UG timing digarms you would get better idea,  anyways  please point the exact timing diagram and the confusing text for further step.

 

 

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
Participant
Participant
10,695 Views
Registered: ‎07-31-2010

UG586, dec 18.

 

The question for the reads is because the diagram shown was for BL4/BL8.  This makes it seem that issuing a read command in BL8 mode will return a BL4-sized amount of data unless two reads are done.  It seems that you are actually incorrect, and for a single read in 2:1 BL8 mode, you actually do get two valids back.

 

They left out the sequential vs interleaved burst types.  It is in an AR last updated in 2012.  In the 1.5 years since, it has not been added to the user guide.  It isn't obvious that burst type would only work for reads and not writes.  Likewise, LPDDR2 and DDR2/3 have different definitions for burst type.

 

If users have to reverse engineer the interface in simulation, why bother writing documentation at all?

 

They also leave out other things.  For example, in 2:1 BL8 mode, can you issue the commands to the af back to back?  It would violate the requirement that the data exists in the wdf within 2 cycles if you had more than a couple commands back to back.  They show this use case in some diagrams though.  (writing to address 0 repeatedly).  Likewise, it isn't clear if you can write to the wdf a long time in advance of writing to the af.

Contributor
Contributor
10,656 Views
Registered: ‎05-17-2009

For what it's worth, I agree.  The UG586 documentation for the native UI is just awful.  They've cut and pasted bits and pieces from earlier copies of the document without updating them consistently.

 

It would help a lot if you guys provided a simple, canonical example of how to do back-to-back writes and reads, without all of the complexity of the traffic generator code.

Visitor
Visitor
8,689 Views
Registered: ‎09-18-2013

For what it's worth, I also agree.  UG586 is less than useful regarding the UI.

0 Kudos
Reply
Anonymous
Not applicable
8,339 Views

Indeed, the documentaion for the UI is lacking any useful information on how to use it at all.  Some timing daigrams are needed. It's been a year and nothing has been done.

0 Kudos
Reply
Adventurer
Adventurer
8,327 Views
Registered: ‎03-02-2015

@Anonymous:

 

Even though i found it a bit difficult to read through the doc,to be fair there are timing diagrams in the document.The timing diagrams were explained in a neat way.

 

You can find - Read,Write timing diagrams,including back to back read or write as well as how to specify commands to the UI. 

Anonymous
Not applicable
8,320 Views

Hi Dare,

 

Ineed you are quite correct - thanks.

 

The problem is that the UI is descried in two places. pg83-87 and 156-163. Starting reading from the beggining, I got to the first section I thougt that was it all.

 

The timing diagams are on pgs 156-163 of UG586 for anyone else finding this thread in the future.

0 Kudos
Reply
8,151 Views
Registered: ‎09-06-2012

For what it's worth, I also agree. The UI interface for RLDRAM3 is very poorly explained even in PG150.

I asked for support about UI interface usage in another topic, but I haven't got any answer yet.

0 Kudos
Reply