Re: Advice for active FPGA forums

Mike Perkins <spam@spam.invalid> wrote:

On 11/10/2024 23:07, Theo wrote:

Mike Perkins <spam@spam.invalid> wrote:

I am currently using an Intel Cyclone V, a 5CEBA2F23C8N and a LPDDR2 memory.
>
The reason for this initial choice is due to a Terasic development board
that used a Altera/Intel high end Cyclone V device with a functioning
LPDDR2 IP. Some code was breadboarded here.
>
Unfortunately I can't get the LPDDR2 IP to work on my PCB. I get errors
and I have given up.

 
Argh, I hate doing stuff with DDR on FPGAs.  It seems the failure modes (on
Intel anyway) are just 'it doesn't work' with no feedback as to why.  I end
up randomly tweaking things and rebuilding in the hope that something will
work one day.

 
That has become my conclusion too. The LPDDR2 IP is also a little dated
and no longer shipped with later versions of Quartus. That does concern
me too as to why this might be the case?

That's not unusual: FPGA tools aren't ever improving in the context of a
specific target.  Sometimes version N+1 removes devices/IPs/etc that were in
N, or the algorithms are optimised better for modern devices than older
devices.

Often there's a sweet spot in terms of version for a particular device, and
you need to run that version.  It's never been a good plan to upgrade just
for the sake of having the highest version number, and you often need to
keep multiple versions installed.

If you have a working project with the IP in a particular version of
Quartus, stick with that version for this project.  Version upgrades can be
a reason why things stop working.

Upgrading versions is effectively a port to a new platform - it needs care
to ensure that everything works correclty.  The main thing is to start with
something working and then do the upgrades carefully, ensuring it stays
working at each step.  If it stops working, back off and look more carefully
at what you did.

Usually there's a bunch of board-level timing parameters (in picoseconds) in
the IP config, which they expect you to work out from simulating your board
in HyperLynx or similar.  How did you generate those parameters, or did you
just copy the ones from the dev board?

 
That's a good point, I used those from the dev board.

They're important because DDR uses a delay locked loop: the idea is that the
clock arrives at the RAM chip right in the middle of the data valid period.
The DLL adjusts timing to make that happen, which is why it needs a good
idea of the board timing to start the DLL in the right ballpark.

(I've not used LPDDR but I assume it's similar)

When you instantiate the LPDDR controller there may be a calibration or
debug component (typically exposed via an Avalon slave interface) - it's
worth enabling that and seeing if you get anything out of it.

I might start by porting the Terasic demo project to your board.  To begin
with, swap out the LPDDR controller for a BRAM to check the rest of the
design works (keep the LPDDR controller in the design, just rewire in a
BRAM).  Then re-enable the LPDDR and then query the debug component to
see if there's anything to learn from it.

If it's down to the DLL, you may need to scope the DRAM to compare the
arrival of the data and the clock signals to confirm their phase
relationship.  Eye diagrams may be needed...

I'm struggling with setting clock speed and appropriate timing where the
timing simply fails, despite setting the options to max speed. The
delays are simply too many ns.

 
It may be the part is just not fast enough to do that in soft logic - the
last FPGA I used with a soft DDR controller was the Stratix 4, and I think
that still had some hard parts.  It's a quite low end part.

 
The part is quoted with a clock speed of 400 MHz and I get a narrow
sweet spot at 150 MHz. The soft logic is letting the interface down.

If that's an LPDDR speed quoted, that's the speed of the hard PHY.
(and hard controller, if it has one)

In general terms the FPGA soft logic will only reach high speeds if you have
a very pipelined design with relatively little happening in each stage, and
avoiding long paths.  The Cyclone V is not known for being a particularly
quick part, and lacks some of the features for raising clock speeds like the
pipelined interconnect in more modern parts like the Stratix 10. 

150MHz seems pretty good timing wise, although I couldn't comment on your
specific design.

I think it would be better to work on getting the Intel/Altera IP to work,
as that is designed to use whatever hardened controller is in the silicon
and that's qualified to work, whereas your soft IP may never meet its timing
goals on this silicon.

Theo