-
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.
-
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.) -
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.
-
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.)
-
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: [Select]// ****************************************
// 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) ); -
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.
Gotcha. -
Wow, this is good. What's not good is all the PCB moving job I gotta do now. I was using both IO banks in a half ass kinda way, should have came here sooner.
What is the CK# is not available? O well, I'll try and make it available.
I got Quartus Lite version obviously, can I try DDR 8 pin pin planning?
Not too knowledeable about Quartus honestly, my choice is BANK3. Anybody can make me an image? or just tell me where they see RWDS ? I will choose ck6 pin 55/56 ad differential clocks.
-
So long as all the IOs, including your clock output are all in your chosen bank3, and all of them happen to support a DDR buffer (I think all IO pins do this except for the 'dedicated global clock inputs' reserved for direct connect to the PLL inputs, you can make a 200MHz Hyperbus interface even with the slowest -8 variant of the Max10 FPGA.
Though, it is preferable to make the 8bit data bus located within a DQ8 group while the RWDS goes to one of the 2 DQS pins for that 8-bit DQ8 group (if not a normal DDR DQ pin withing the same IO bank). This will solidify your signal integrity at high speed and it will guarantee better compatibility with third party memory controllers.
If you are writing your own and only need <150MHz, anything you do could be made to work, but, if there ever was some weird unknown glitch related to timing, you will need to work around it.
Make a new Quartus Project with your selected FPGA, then go into 'Pin Planner'. Highlight the pulldown selection I have listed in DDR3 pin planner photo and see if a single DQ8 bank exists...
https://github.com/BrianHGinc/BrianHG-DDR3-Controller/blob/main/Screenshots_Pin_Planner/Max10_pinplanner.png -
LootMaster, now look carefully as there is at least 1 IO pin in bank 3 which you cannot use.
When going into Quartus Prime's Pin planner, adjust the layout as seen in this first picture.
I selected for you a valid global clock input pin for your 25 MHz oscillator.
Now, look at the 'Pin Properties' window when I click on pin 38, it tells you what the pin can do.
It says it is a high-speed DFFIO_TX_RX_xx, these are the type of IOs capabilities you need for your Hyperbus ram controller.
Now look at when I selected pin 54. It says it's special function is just 'IO'.
Do not use this pin on your Hyperbus ram. (IE: also do not use pin 48...)
Careful as some other pins may be a VCCIO for IO-Bank 3 and have no IO functions.
None of these pin are a direct PLL output pins, so to clock your Hyperbus, you will want to use a matched N and P pins together for the best timing results combined with my using a DDR output pins as a clock output for your Hyperram trick. (EG: Pins 57 & 58 are DFFIO_TX_RX_B20n/p, it's that both pins are B20) Don't worry about the N & P polarity, just route that 'Pseudo Differential' pair together in a straight line. If you need to invert polarity of the clock, just swap the order of the DDR drive 1/0 inputs on my code line:
.din (1'b1,1'b0),
Remember, FPGAs compile best when withing your system, everything possible spans from 1 clock domain, always 1 clock polarity. Try not to use negative clock internally except under special circumstances.
-
Just an additional note about my above pin-planner post. Yes, for the 144pin tqfp, quartus will not show any DQ8 memory bus pin groups. I guess the total available IO pins within 1 bank just aren't available. You need at least a 256 pin BGA fpga to show at least 1 DDR-DQ8 pin group with DQS strobe & DDR_CK io pins.
-
BrianHG, you are one awesome dude, I am gon share with you my work of art PCB triple camera AI megaboard with you. That way you can become master of the universe, like me. Just need to finish it up.
-
@LootMaster. I've shown you some of the pitfalls one may encounter when they are beginners, or haven't completely read through the data sheets. You have enough here to properly wire a Hyperbus ram to a smaller 144pin Max 10 fpga.
Now, to make it work error free, you will need to understand programming in your preferred HDL, what simulator to use when writing your HDL, (I prefer ModelSim, Intel/Altera still provides their free version for download and ModelSim is also used with Lattice FPGAs, Gowin FPGAs as well as some Xilinx users still use it.)
You should learn how to use ModelSim (or other simulator) outside of Quartus when writing HDL and how to write a proper simulation testbench. It's a pain for first time users, but, you will be able to see and proof all your mistakes before waiting for Quartus to compile.
Also, don't forget that pure logic sims read data coming in instantly from your stimuli if you decide to engineer your controller on a FPGA central clock timing core.
Good Luck.
-
BrianHG, I am ready for our chat, I got a product that can be unleashed by a guy like you, we split 50/50. or more like, you get what I get.
Because I like you.
please answer this
-
I know 144pin has few IOs and options to choose from...
Going forward, I would say look at the 3.3v VS 1.8v hyperbus ram component availability, then choose which version to use. Not being able to source components is worse than having to deal with 2 IOs operating at 1.8v in a 3.3v system.
As for powering your IO bank at 1.8v, your input should not excede the VCCIO voltage +~0.3v. I believe the only exception are the dedicated global clock inputs which are 3.3v tolerant. For me, if the data on the input you need to use is slow (IE: below 10mhz), then I would use a series resistor like 10k and rely on the FPGA's internal clamping diode to protect the input, but remember a logic high begins at only ~0.5v. (Make sure the input you use has the clamping diodes, in the data sheet.) Using a pull-down resistor, as in a normal resistor divider at the IO will properly narrow your 3.3v to 1.8v, however, this complicates things if you want to use the IO as an output as well.
Note that if you are driving a normal 74HCxxx logic, switching to 74LVxxx which is 3.3v tolerant while powering that logic with 1.8v. (Double check your 74LV datasheet to be sure...) -
Ok please confirm that this VCCIO +0.3v is legit info because I'm gonna make the pcb like this.
If I understand corectly, in quartus the VCCIO that is included in the colored square of the IO baank is that IO bank's respective VCCIO ( well duh). So heres is my circuit, please confirm.
As for availability, this is the situation. I believe going forward 3.3v will get phased out.
Brian, ca you answer your pm, I have a circuit I would liek you to review, a pcb, its beautiful, its powerful, the future of canada's economy revolves around something like this. Please help, my hero. Help me make a cool robot before the return of Jesus and the destruction of Canada.
-
Why not use pin 96 to drive the Hyperram reset signal and use the other 3.3v IO to directly drive the othe 3.3v io signal.
As for the 3.3v clock, just use a series 1k resistor with a 1.2k pulldown to GND. This will change the 3.3v to 1.8v, safe withing the 1.8v allowable range and should be good to 100mhz if the 1.2k pulldown to GND is close to your FPGA input pin.
-
pin 96 is a dpclock(whatever that means), I will use this as a control pin for various arrangements. its a multiway bus on IO bank 5, theres dual bank mode qspi (meant for flash)from the H7 stm32 to access this RAM (wich is video buffer from a camera), so clock+8 pins+NCS, wich is 2 inches away and can go up to 120MHz. the resistor solution sounds sucky if global clock inputs are 3.3v tolerant. I can live with 3.3 V hyperram if global clock inputs arent really 3.3 V tolerant. 128Mbit holds a 8k image @ 16 bit color per pixel
-
I was under the impreszion that pin 88 was a global clock input 3.3 v tolerant? even if its respective vccio is @ 1.8 v
-
Switch to 470 ohm series, and 510ohm or 560ohm pulldown. That should be good to 200mhz.
Note that you can also clock the FPGA from global clock inputs on pins 26,27,28,29 or 55,56,547,58. You cannot use pin 88 to properly reference clock the PLL in the FPGA. You can still use pin 88 to drive the hyperram reset as it is still an output.
As for the hyperbus ram reset, this one doesn't need to be very fast at all. You can use a resistor divider here with 1k & 1.2k if you like.Quotepin 96 is a dpclock(whatever that means)?
I don't know, however you can still use it as a regular IO for the Hyperam as you have already used another dpclock2 for the ram anyways.
As for the 3.3v tolerant dedicated clock input, try setting the IO bank to 1.8v and the clock input to 3.3v in quartus and compile. Quartus will yell at you if the combination isn't allowed, IE: The global clock input isn't 3.3v tolerant if the rest of the IO bank is configured for 1.8v.
-
what version of the chip? 25 version shows me global input region on pin 88 and this is an input. stm32 qspi clock drives this pin from 2 inches away. I mean... the drawing says it likes a rising edge signal... the drawing man... the drawing... thats my analysis... clock input must want a clock input I thought I understood fpga and synchronous parallel comms with the outside world?? yeah ur right tho, reset doest need to be fast so I will use a garbage vref output with resistor divider not a chip lol. thats noob to always be a chip addict.
-
Ok I did it like you said, you probably know the and if and buts of all my thoughts and assumptions who am I to argue with you? now pin 87 is used for qspi clock input, my treasured "dpclock whatever that means" pin 96 as input from qspi ncs with voltage divider resistor network, and garbage vref from other banks are used as input for control. no more chips needed just 2 resistors. and now hopefully, pin 87 can be more easily "pll referenced". according to the wisdom of Brian.
-
To feed the PLL properly, only use one of these dedicated inputs: pins 26,27,28,29 or 55,56,57,58.
The other dedicated inputs, like pin 87, can be used to more effectively clock logic at 1:1 speed and they wont be sufficient if you will be clocking you hyperram from them. I am not sure if they can feed the PLL directly. The hyperram must have it's logic clocked from the FPGA's PLL since you will need a few different 'phase' outputs from the PLL for shifting the data bus VS the clock out signal. (usually a 90deg/270deg signal.)
If you are using pin 87 as an output to clock your stm32, or the stm32 driving pin 87 is the databus clock, then you will not have any problems.