Hello,
I was going through the reference MIG design in the Trenznet SVN repository and something took my attention. Rather than using the onboard 125 Mhz single ended clock, the reference design requires 2 additional differential 333 Mhz clocks.
In my design, I will be using pure RTL and MIG generated MCB cores (hence no EDK). Currently I am planning to modify the reference MIG project so that both MCB cores run at 325 Mhz and make use of the onboard 125 Mhz single ended clock. I am currently implementing the changes but I would be most happy if any of the Xilinx experts at Trenznet can comment on this approach.
Do you think that this is perfectly okey or can there be any pitfalls which I don't see now?
Dear Rifo,
You approach is absolutelly OK. It was intended that the design uses only 125MHz input clock. By default MIG core is generated to use direct memory clock as an input (the design that you are using at the moment) and cannot work on the GigaBee without external clock. To generate 325MHz clock you need to modify PLL settings (multipier, divider). Dual MCB design can use a single PLL for both MCBs, but the placement is tricky. Please take a look at Webserver EDK design system.ucf for correct PLL placement constraints.
I am getting more into MIG design lately. I saw that demo design includes synthesizable test bench and Chipscope cores. It is good starting point.
I will upload working design to SVN, but also contributions from others are more than welcome.
Best regards,
Ales
Hello Ales,
Thanks a lot for your answer. I will gladly help for the MCB core running from the 125 Mhz clock. I will try to send my first version in a couple of days.
rifo
Hello Ales,
I finished the first version of the MIG based dual DDR platform. Sorry that it took longer than expected since I had to deal with other tasks. I checked the Xilinx example but found it a little bit complicated so I prepared a small basic design. Below I give a small description of it.
A dummy module creates a 752x480 sized frame which is written/read to/from both DDRs
Each MCB has a write and a read port
Each write /read port has a Block RAM to ease data transfer to/from fabric
When "line valid" signal is asserted, corresponding line of the previous frame is read and then incoming line is written to DDR
I implemented the design in ISE 13.2 Webpack for LX45. I also prepared a simulation platform (but didn't verify the design!!!)
ps: By the way, I can't find a way to attach the designs. I would be happy if you can guide me about this.
If you think the design is okey, then we can continue together and verify DDR read/write cycles
Quote from: rifo on September 04, 2011, 11:39:59 AM
ps: By the way, I can't find a way to attach the designs. I would be happy if you can guide me about this.
- What do you mean? You do not know how/where to interface your custom logic design with the MIG platform? Did you find the way in the meanwhile?
- We downloaded your design from the SVN repository and tried to implement it but ISE 13.2b could not find the project file (.xise) or the like. Can you please tell us how we shall import your reference project into ISE?
Thanks and regards,
Horsa
Hello Horsa,
Quote from: Horsa on November 28, 2011, 11:27:12 AM
- What do you mean? You do not know how/where to interface your custom logic design with the MIG platform? Did you find the way in the meanwhile?
- We downloaded your design from the SVN repository and tried to implement it but ISE 13.2b could not find the project file (.xise) or the like. Can you please tell us how we shall import your reference project into ISE?
Thanks and regards,
Horsa
I really didn't know where to attach the finished files in a post. Ales then created a SVN repository for me and I uploaded all the design files there.
I followed the script building approach that was already there when MIG generated the MCB related files.
* For simulation run the "isim.sh" under /sim folder
* For implementation, you can run the "create_ise.sh" under /par directory and it will generate the .xise project file.
I also use ISE 13.2 so things should work just fine. I didn't test it on hardware but the simulations and the implementation on ISE were okey. I would be happy to help if there is a change that needs to be done.
ps: I use Ubuntu so if you use windows then I think replacing the sh extension with bat should suffice.
Hello Horsa,
Did you find a chance to try the code? I made a recent update to fix a minor bug. Please make sure to get it. As I said before, I would be happy to help if a change is needed.
Hello Rifo,
no, I did not come so far.
In my opinion, "replacing the sh extension with bat should suffice" in rare cases, I do not think this is it. ISE-related .tcl scripts shall be portable instead.
Does "it will generate the .xise project file" mean, .xise are available only on Windows-based systems?
Can't you export .xise project file from Linux for Windows users?
Thanks and Regards,
- Horsa
Hello Horsa,
I found a windows machine today and tried changing the "sh" extension to "bat". It worked. I was able to call "create_ise.bat" file and create an .xise project file. I also made a couple of changes on the wave diagram. When you have time, you can give it a try.
have a nice day
rifat
Quote from: rifo on August 15, 2011, 10:23:17 AM
modify the reference MIG project so that both MCB cores run at 325 Mhz and make use of the onboard 125 Mhz single ended clock
could you please give some more information on this, in which way there is an advantage using this mcb frequency?
From my knowledge, clean ratios in PLLs do result in better timing, so 3x125 = 375 should be more stable?
Hi Martin,
The frequency 325 is actually a typo. It should be 625MHz, which is actually used. This is 5x125MHz.
Best regards,
Ales
Hello,
I noticed that the MT41J128M16XX-187E component (a 2GB) is used instead of a 64M16 component (which is on the board).
Am I missing something here?
Rene
Hi Rene,
Do you need all the 256MB of memory?
If not then it is OK. The missing address bit is static.
If yes then you need to change the memory type in the memory controller and extend the RAM address bus for one bit. The extra address pin location will be handled automatically.
If you have any problems do not hesitate to write.
Best regards,
Ales
I did not make myself clear: In all MIG examples (GigaBee_ISE12.4-MIG, GigaBee_XC6SLX-MIG) the wrong component is used, i.e. a 128M16. This is not correct it should be a 64M16.
In the GigaBee_XC6LX-Axi example the correct component is used (MT41J64M16XX-187E). However, I notice here the following in the mig.ucf file:
NET "c3_sys_clk_n" LOC = "Y12" ;
NET "c3_sys_clk_p" LOC = "W12" ;
As far as I can tell Y12 is not connected (B2B_B2_L29_N); Never the less a differential clock is specified (running at 25 Mhz?).
Can you explain about the clock / pin usage?
Regards,
Rene
Hi Rene,
For the standalone MIG project the 128M16 was used to define pinout for all the compatible memories.
In the GigaBee AXI project the clocks c1_sys_clk and c3_sys_clk are not used at all. The memory clock (625MHz) for both memory controllers are generated with clock_generator core. The LOCs you mention are autogenerated by MIG.
In AXI embedeed systems only part of the MIG core is used (no _infrastructure and similar components are used).
We use only NET "c1_sys_clk" LOC = "AA12" ; which is 125MHz clock from the PHY.
Best regards,
Ales