Some preliminary help for an FPGA selection

It will be the first FPGA for me. What I want to do is not complex,
I have done similar controllers (more complex really)numerous times
using logic parts, PLD, CPLD-s etc.
I need to put together a display controller, to just do framebuffer
memory -> display interface. Framebuffer memory will be some sort of
DDRAM (DDR-which depending on the FPGA type), I'll be happy with
a 1920x1080 framebuffer, 32 bits per pixel (likely just 24 will
be used initially). The framebuffer will be updated via PCIe by the
processor so the FPGA has to be large enough to allow me to do
say 2k words fifos for access (2 of them).
How the output will go is unclear yet; probably HDMI (which adds
some complexity of course but looks doable).
The LVDS cable drivers are another unknown - is it a good idea
(if possible at all) to have them on-chip (chip being the fpga)?
Sounds a bit risky but this will not be a consumer product, not
initially at least, so it does not have to be the most abuse
proof unit in the galaxy (but I don't want it to be too easy to
be killed either... I am just looking for people's experience
in the area).
Which way should I go? The tools must be free, I guess this
narrows the choice, we are not a large company.
I will have to do plenty of iterations until I have the thing
work obviously so I want the processor to be able to initialize
the FPGA logic from a file (it has a disk, ethernet, tcp/ip etc.).

I guess I would prefer lower power, too - if I have multiple
choices of similar devices.
 From what I saw there are FPGA-s which come with some hardwired
DDRAM interface and PCIe, I'd go for one of these (doing DDRAM
myself sounds like a waste of effort unless it proves necessary,
having to do PCIe myself would probably make me look at other
options).

Thanks,

Dimiter

======================================================
Dimiter Popoff, TGI             http://www.tgi-sci.com
======================================================
http://www.flickr.com/photos/didi_tgi/

Thanks everyone for the pointers and suggestions.
It will take a while of looking and head scratching until I
can say anything with certainty but at the moment I am
looking at spartan 6 and spartan 7 (yet to look at artix).

Looks like spartan 7 does not have a hardwired DDRAM thingie;
how much of a problem will that be?
I have yet to evaluate the tools but I suppose I will be able
to write low level logic, sort of this.d = that.q & whatever,
I have no idea what the syntax will be but I am sure everyone
gets what I mean. Once I am there I'll find my way (and I
fear getting there will not be easy, especially talking to
hardwired stuff like DDR and PCIe).
But "not easy"is not a problem, I fear the "not possible",
especially finding out the latter too late (a friend once quoted
a friend of his - both engineers - about the "oh shit" factor
being applicable to every project; you either say it at the beginning
or at the end... :-).

As you see I am wondering about the basics at this stage,
I'll be grateful for any hints from you people with experience
before I start downloading toolchains and wrestling to
evaluate which and how...

Thanks,

Dimiter

Michael Kellett <mk@mkesc.co.uk> wrote:
> On 09/08/2020 17:05, Dimiter_Popoff wrote:
> 
> snipped
> 
> If you don't need the RAM to be that fast or that big then you could use 
> SDRAM, it'll save you a lot of trouble, both in board layout and FPGA work.
> 
> I wrote my own SDRAM controller a long time ago (when quite new to 
> FPGAs) - not too big a deal at all.
> 
> DDRAM is a different thing altogether (reading and writing data in a 
> 300ps window - its a miracle that it ever works !).
> 
> Using a pair of 16 bit wide SDRAMs at 100MHz gives you 400 Mbytes/s - 
> chicken feed by DDRAM standards but maybe enough.

Just about - 1080p/60Hz/24bpp is 373MB/s.  If you cut the colour depth down
you can reduce that bandwidth.

However you also need bandwidth to write into that RAM - you'll need to
measure how much you need for that.

On PCIe, that means you're in mid-level FPGA territory as it needs high-speed
transceivers.  So not the bottom-end Cyclone V E but the fancier Cyclone V
GX.  And similar across all the vendors lines - that means you're heading
towards the top end of Lattice's offerings.

One thing to be wary of is that Intel/Altera at least offer time-limited
demos of IP cores that you don't have licences for.  The device will work
while plugged into the programmer, but not work standalone.  There's
warnings about this, but you may be able to successfully synthesise despite
not having a licence (which might actually be fine for proof-of-concept/eval
purposes).

On the system-on-module front there are lots of vendors but I've personally
worked with https://www.enclustra.com/ who have a decent range, although
possibly higher-end than you want.

For LVDS I'd think about buffering - you might want a proper line driver to
drive a long cable, rather than FPGA I/Os which aren't designed to drive
into a long capacitance.  We used a third-party HDMI module once and had a
lot of problems because the registers in the driver chip (made by ITE)
weren't documented - in the end we recorded a log of what the demo code set
registers to and replayed that in the same order in our code, a hack but it
just about worked.  Instead of proper HDMI (audio etc) you might think about
DVI-D: HDMI monitors can accept it but it's a simpler protocol.  You can
also get chips which take in parallel RGB (6-8 bits per channel), Hsync,
Vsync, pixel clock and output DVI or HDMI.  That means you just generate
something that looks like pre-DAC VGA and the chip handles the rest.
You might also consider EDID monitor detection, depending on the
application.

What I'd do is look for a PCIe-card-shaped dev board, which should come with
examples for driving that.  For the video side, worst case you can make a
resistive-DAC VGA port off some GPIO pins, but you could look at other
options - for example wiring a parallelRGB-DVI chip off GPIOs.  Maybe the
board will come with HDMI or Displayport already (and some demo come), but
that's rare on PCIe-card boards.  I think at that point you have to live
with whatever RAM type the dev board gives you - if SDRAM works for
you it'll save some troubles, but I've seen a few where there's only one 16
bit SDRAM, which is low on the bandwidth stakes.

Dev boards sometimes come with a one-seat licence for the tools too.
You might also be able to get access by speaking to a sales rep.

Personally I have a dislike of Xilinx tools and I'd prefer Intel or Lattice,
but I have more experience of Intel in particular, so I may be biased.
On the Intel front, 'Quartus Lite' is the free tools and supports Cyclone,
so I'd be looking at a Cyclone IV or V in GX version.  For example:
https://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=167&No=1159

Meanwhile, in Lattice land (tools licence free only for this board):
http://www.latticesemi.com/en/Products/DevelopmentBoardsAndKits/LatticeECP3VersaDevelopmentKit.aspx

Theo

More thanks to everyone for the hints.

Looks like I am going to use some of the Artix devices (Spartan 7
have no PCIe as far as I get it, unless they can do it "soft").
I would not go old style SDRAM, the bandwidth would be limiting
(I need at least twice the bandwidth needed for refresh if the
update via PCIe will work without visible artifacts; much more
if I go to make alpha etc.).
DDRAM3 is fast enough and as Mike suggests at 800 MHz clock
it is a miracle things work but here we are, I have to use that
or fall too far behind. Then there will be DDR-4 or 3l on that
board for the CPU so it has to work anyway.
Last time I used SDRAM was .... 20 years ago, can't really believe
it was that long ago.
http://tgi-sci.com/misc/PICT3084.JPG - another 5 (just 4 mounted)
SDRAMS on the bottom side, 64 bit wide in total - this is the second
board put together, the first one worked for may be 3 months
and fell apart, I had reflown it at least 30 times, was my first
board with BGAs on it).

Doing straight RGB as Theo suggests might come to rescue during
the design of course, but since HDMI is doable it will have to be
done. No MIPI on the agenda yet, they are too secretive so I'll
live without a camera at least initially. Or use a USB one.

I downloaded the VivaLdo (I really spelt it Vivaldo having encountered
the name first just here in Mike's message, got corrected by google...
did not ask for any seasons, luckily :), got a free license for
their webpack. At first glance it looks like it is sufficient and
free but I will not route in an fpga before I have it at least
compile without asking for fees etc., as Hans suggested (or something in 
that line). Was an adventure of its own,took about 2 hours to download,
but it seems to work (not that I know yet what the difference is between
vitis HLS, Xilinx Vitis, VivaLdo... DocNav - well, I think I understand
what this is :).

Thanks again for the hints, please keep them coming.
And please keep your thumbs pressed, I have done crazier projects
(at their time) than that (which is by far not just its fpga part),
but I don't know if I still have the drive it takes - hopefully I
can find it.

Dimiter

======================================================
Dimiter Popoff, TGI             http://www.tgi-sci.com
======================================================
http://www.flickr.com/photos/didi_tgi/

On Monday, 8/10/2020 1:44 PM, Dimiter_Popoff wrote:
> More thanks to everyone for the hints.
> 
> Looks like I am going to use some of the Artix devices (Spartan 7
> have no PCIe as far as I get it, unless they can do it "soft").
> I would not go old style SDRAM, the bandwidth would be limiting
> (I need at least twice the bandwidth needed for refresh if the
> update via PCIe will work without visible artifacts; much more
> if I go to make alpha etc.).
> DDRAM3 is fast enough and as Mike suggests at 800 MHz clock
> it is a miracle things work but here we are, I have to use that
> or fall too far behind. Then there will be DDR-4 or 3l on that
> board for the CPU so it has to work anyway.
> Last time I used SDRAM was .... 20 years ago, can't really believe
> it was that long ago.
> http://tgi-sci.com/misc/PICT3084.JPG - another 5 (just 4 mounted)
> SDRAMS on the bottom side, 64 bit wide in total - this is the second
> board put together, the first one worked for may be 3 months
> and fell apart, I had reflown it at least 30 times, was my first
> board with BGAs on it).
> 
> Doing straight RGB as Theo suggests might come to rescue during
> the design of course, but since HDMI is doable it will have to be
> done. No MIPI on the agenda yet, they are too secretive so I'll
> live without a camera at least initially. Or use a USB one.
> 
> I downloaded the VivaLdo (I really spelt it Vivaldo having encountered
> the name first just here in Mike's message, got corrected by google...
> did not ask for any seasons, luckily :), got a free license for
> their webpack. At first glance it looks like it is sufficient and
> free but I will not route in an fpga before I have it at least
> compile without asking for fees etc., as Hans suggested (or something in 
> that line). Was an adventure of its own,took about 2 hours to download,
> but it seems to work (not that I know yet what the difference is between
> vitis HLS, Xilinx Vitis, VivaLdo... DocNav - well, I think I understand
> what this is :).
> 
> Thanks again for the hints, please keep them coming.
> And please keep your thumbs pressed, I have done crazier projects
> (at their time) than that (which is by far not just its fpga part),
> but I don't know if I still have the drive it takes - hopefully I
> can find it.
> 
> Dimiter
> 
> ======================================================
> Dimiter Popoff, TGI             http://www.tgi-sci.com
> ======================================================
> http://www.flickr.com/photos/didi_tgi/
> 
> 
> 
> 
> 
> 
PCIe is not something you'd want a soft core for.  Spartan7 not only has 
no PCIe, it has no high-speed transceivers.  Artix-7 would be the better 
choice from Xilinx.  I believe the tools are better and the cost lower 
for a device that has the resources you're looking for.  It is supported 
by the free tools as I recall.  If you go with Xilinx, you'd want Vivado 
for this project.  Other tools are more oriented toward special 
applications like AI (neural networks, deep learning...).  Also the 
latest tools are really made to support the really expensive newer chips 
in the UltraScale++ family or whatever they're up to now.

Good Luck!


-- 
Gabor