Hi! This is the first time I’m branching out and trying to use the DDR3 memory on the Au V2 in a larger project. The core concept is to do distance measurements by measuring phase differences between two signals (think: laser rangefinder). The data flow will have 2 8-bit ADC modules feed into 2 FFT cores, then feed the results through 2 CORDIC cores to get the phases for each signal. A micro controller would then connect to the FPGA through I2C (FPGA is the peripheral) and query the phase data.
I had thought to use the DDR3 ram on the Au because why not? but the issue I’m now encountering is that I’ve set up the rest of the cores to reference the 100MHz system clock, and the MIG core uses a slower clock. The MIG core customization was a bit over my head and the .tcl script indicated that the memory part is a “custom part” in Vivado, so I was not super confident I could adjust the parameters to get the mig.ui_clk up to 100MHz.
Main question now is this: do I stick with trying to use the DDR3 ram, or do I instead go with a simpler ram component? Will the “simple dual port ram” component be able to keep up with the 100MHz sample speeds? Is crossing the clock domains between the data pipeline and the DDR3 worth the hassle?
Thanks in advance for any insight. I’ll admit I’m a bit of a noob with FPGA stuff so I’m sorry if I’m not being super clear in my descriptions.
The Au v2 is capable of running the ddr3 at 100MHz, unlike the original Au which had a lower speed rating. So this clock domain issue ought to be resolved on the v2. It was definitely an issue exactly as you describe on the v1, where you had the choice of clocking the whole design slower to match the memory, or else having to do domain crossing.
I would start by figuring out how you might have misconfigured the memory? I think that’s what happened to you but I’m not sure how, in Alch Labs I thought it all got configured for you.
I followed along with the tutorial here, which should be for the Lucid V2 and the newer boards. Unless I’m mistaken on that front!
I guess I hadn’t actually verified that the mig.ui_clk was slower than 100MHz, let me see if I can hop into Vivado and confirm its config.
Hopping into Vivado I checked and it seems that the MIG core is running 400MHz with a 4:1 ratio, meaning the UI clock should indeed be 100MHz! I guess the tutorial might need to be updated to reflect the updated MIG core speeds.
edited to add: the mig.prj file called by the mig.tcl script corroborates the 100MHz default clock.
1 Like
Aha, that tutorial (which I have likewise followed before, but last year with the Au v1) predates the v2. While the tutorial does have you generate 100MHz and 200MHz clocks to drive the memory, the lower speed grade on the Au v1 did not support running the entire interface design at the full 100MHz speed. But when you configure the MIG on the v2, you get the 100MHz design because the higher speed grade supports it.