Electronics > FPGA
Hyperram to MAX10 (with no DQS shift)
LootMaster:
Hello all, I am trying to design a PCB for MAX10 with hyperram, a 3.3 volt PCB with 3.3volt hyperram, wich can go up to 166 Mhz but if I can get 75 Mhz I would be happy. This person suggest something but I cant quite understand yet to finish and order the PCB. I got an optimization here that I can do, if I wire the FPGA, The crystal CMOS chip, and the hyperram. Correctly first, and then optimally with PCB guidelines secondly, from the wonderful advice of this reddit poster, that I need help understanding (see image). Theres alot that the MAX10 can do with PLL.
PLZ help.
So for Hyperram theres
CS
RWDS
8x I/0
CK single ended
On my FPGA I got, CLKp(preferred clock pins), High_speed pins, and a PLL_CLKOUT, wich could play a beneficial role if I wire this right, with the CMOS clock wich is connected to a Clkp0 input, a preferred clock.
BrianHG:
Ohhh boy...
Ok, step 1, when connecting a clock oscilator, you need to to use a dedicate clock input. Preferably one wired to an internal PLL which can drive the same bank where your hyperbus port will be at.
Now, for clocking the hyperbus ram.
Your ram should be differentially clocked.
(single ended might work, but I would prioritize the 2 traces and IO pins just to not mess around...)
The 8 data bits should be on ad DDR DQ8 port with RWDS and #CS preferably on the same IO bank.
The Max10 had a dedicated CK/#CK differential output for when using normal DDR memories, however, these pins are not the same dedicated PLL output pins. If you want compatibility with some third party memory controllers, I recommend using these output to clock your hyperbus ram.
When locating which 8 bit DQ group and bank you can use, use quartus' pin planner and select 8-bit DDR memories and highlight the bank you want which has the CK/#CK output pins.
RWDS should be tied to the DQS pin for that IO bank.
See my quartus Max10 pin planner to show you what to click on to see if it is available on your 144pin tqfp version of the chip:
https://github.com/BrianHGinc/BrianHG-DDR3-Controller/tree/main/Screenshots_Pin_Planner
Even though you are using hyperbus, if you use these IOs, you should easily meet 200MHz/400mtps as this connection when wired to DDR3 can easily achieve 300mhz/600mtps and I have successfully achieved 400mhz/800mtps with my controller.
If the CK/#CK outputs arent available, then the dedicated PLL clock output pins will also work, but you still need to use the differential for best design consistency. Make sure the PLL clock outputs are in the same IO bank as your 8bit DQ port.
Also, when clocking the Hyperbus ram, you might use my DDR output buffer technique where I set the falling clock edge to a 0 and the rising clock edge to a 1. Instead running the dedicated PLL clock output buffer in direct PLL buffer mode, this forces the use of a DDR output buffer at the output pins matching the delay characteristics of the 8-bit DDR-DQ port. You get a few additional picoseconds of jitter compared to using the output in PLL buffer mode, however, timing closure becomes much easier for quartus as you will not need additional internal PLL clock phases to align the timing difference as well as clock recalibration, especially at clock rates below 300MHz.
(This is why my DDR3 controller achieves an error free overclocked 500Mhz/1000mtps operation roasting altera's DDR3 300mhz software controller limit, no periodic recalibration, just a read-calibration once at powerup, not to mention a true 400mhz/800mtps 100% cleared timing closure operation mode.)
Don't forget to completely simulate your design...
Make sure you find a Verilog or VHDL model of hyperbus ram so you can run simulations with simulated attached memory to your IO pins. The Verilog model will show errors and what's happening with the connected memory.
(Only if you need some real speed, like 32 bit display graphics processing, if you were to go to a small BGA package max10, IE:256 pin, you would be better off using a DDR3 memory chip with a second 1.5v regulator for it's IOs. Speed, cores and price would be a plus and my controller can run DDR3 at 300MHz/600mtps on the slowest -8G fabric.)
(Not that my DDR3 controller does not use DQS shift. It uses it DQS once during real calibration at power-up as a latched read-enable, or data valid. There should not be any problems controlling Hyperbus ram.)
SiliconWizard:
Yeah, single-ended at 166 MHz with a bit of careful routing should be fine though - I've certainly done that with SDRAM without a problem.
BrianHG:
At 166MHz, even 200MHz hyperbus ram, all he needs is 1 IO bank with 10 DDR capable DQ pins in the same bank.
Clocking the ram should be done with my DDR output as a clock output pin trick and read clock phase VS data bus output will be guaranteed with a minimal timing constraints .sdc entry, no temperature drift to worry about.
So long as his 25mhz oscillator is wired to a dedicated clock input wired to a PLL driving that IO bank, he will meet all timing requirements with ease. It will then come down to coding skill and if he wants to do a read-data phase check at power-up, or assume a fixed PLL read clock offset.
(Note that the only headache with simulation is that the read-phase input will be off unless he does a full timing simulation, or does a read-phase calibration test at power-up which will discover the instant perfect timing of a logic sim.)
BrianHG:
DDR output pin as a clock trick: (System Verilog)
(The pseudo differential needs to be changed to single ended for a single clock pin + remove the '.pad_io_b (DDR3_CK_n)' )
DDR3_CK_p/n are the output pins.
DDR_CLK is the internal FPGA system clock, this would be the 150MHz or 75MHz system clock which will be sent as a copy to the DDR3_CK_p/n output pins. So long at the DDR DQ8 bus is also clocked with a relative phase to DDR_CLK from the same PLL, the DDR DQ8 outputs will have a perfect timing relationship to the DDR3_CK_p/n output pins without temperature drift. It is just the read phase clock for the DQ8 pins which LootMaster needs to learn how to setup. Any temp drift when reading will be due to the hyperbus ram's internal capabilities.
--- Code: ---// ****************************************
// DDR3 Memory IO port -> DDR3_CK_p/n pins for a MAX10
// ****************************************
altera_gpio_lite #(
.PIN_TYPE ("output"), .SIZE ( 1 ), .REGISTER_MODE ("ddr"),
.BUFFER_TYPE ("pseudo_differential"), .ASYNC_MODE ("none"), .SYNC_MODE ("none"),
.BUS_HOLD ("false"), .OPEN_DRAIN_OUTPUT ("false"), .ENABLE_OE_PORT ("true"),
.ENABLE_NSLEEP_PORT ("false"), .ENABLE_CLOCK_ENA_PORT ("false"), .SET_REGISTER_OUTPUTS_HIGH ("false"),
.INVERT_OUTPUT ("false"), .INVERT_INPUT_CLOCK ("false"), .ENABLE_OE_HALF_CYCLE_DELAY ("false"),
.INVERT_CLKDIV_INPUT_CLOCK ("false"), .ENABLE_PHASE_INVERT_CTRL_PORT ("false"), .ENABLE_HR_CLOCK ("false"),
.INVERT_OUTPUT_CLOCK ("false"), .INVERT_OE_INCLOCK ("false"), .ENABLE_PHASE_DETECTOR_FOR_CK ("false"),
.USE_ONE_REG_TO_DRIVE_OE ("true"), .USE_DDIO_REG_TO_DRIVE_OE ("true"), .USE_ADVANCED_DDR_FEATURES ("false"),
.USE_ADVANCED_DDR_FEATURES_FOR_INPUT_ONLY ("true")
) DDR3_IO_CK (
.inclock (DDR_CLK), .outclock (DDR_CLK),
.dout (), .din (1'b1,1'b0),
.pad_io (DDR3_CK_p), .pad_io_b (DDR3_CK_n), .oe (1'b1),
.inclocken (1'b1), .outclocken (1'b1), .fr_clock (), .hr_clock (),
.invert_hr_clock (1'b0), .phy_mem_clock (1'b0), .mimic_clock (), .pad_in (1'b0),
.pad_in_b (1'b0), .pad_out (), .pad_out_b (), .aset (1'b0),
.aclr (1'b0), .sclr (1'b0), .nsleep (1'b0) );
--- End code ---
Navigation
[0] Message Index
[#] Next page
Go to full version