Lattice ECP5: opinion?

[SiliconWizard]

I'm considering the Lattice ECP5 for new designs, and I'd like to get some opinions from people who have experience with this series. Also, to get an idea of its capabilities, how it would approximately compare to the Xilinx Spartan 6/7 or Artix 7 series...
(From this post, it appears there is at least someone: https://www.eevblog.com/forum/fpga/am-i-the-only-one-who-thinks-vivadovitas-is-a-muddled-mess/msg3173596/#msg3173596 )

Also, do you know of any decent and not too expensive dev board? There are the Lattice dev boards, which are either expensive or are not what I expect (such as the basic Lattice eval board). Then I basically know of a couple other options, such as the OrangeCrab (too small, not enough IOs, only the -25 part), or the ULX3S ( https://radiona.org/ulx3s/ ), which is better, although I'd have liked DDR RAM instead of just SDRAM, and also it only seems to be available on pre-order as of now... so if you know of anything else, preferably with a -85 part, that would be great...

[abyrvalg]

I’ve seen an ECP5 devboard with many features (DDR3L, HDMI, GbE etc) from LambdaConcept.com team (btw, they are from Paris), but have no personal experience with it.

[ebclr]

It's not that obvious, But this can easily  be used as an ECP5 dev board

http://aliexpress.com/item/1005001330347620.html?spm=a2g0o.cart.0.0.14a83c00o9jOP8&mp=1

https://github.com/kholia/Colorlight-5A-75B

[tchicago]

It's not that obvious, But this can easily  be used as an ECP5 dev board

http://aliexpress.com/item/1005001330347620.html?spm=a2g0o.cart.0.0.14a83c00o9jOP8&mp=1

https://github.com/kholia/Colorlight-5A-75B

that board seems to be way too specialized. No direct access to pins, only via output buffers...

[tchicago]

Speaking of Lattice in general, I've had a reasonably good experience with MachXO2-7000. The Lattice Diamond is pretty intuitive, and makes it easy to run your edit-synthesize-reflash loop.

I also ordered this board https://www.tindie.com/products/tinyvision_ai/upduino-v30-low-cost-lattice-ice40-fpga-board/ to try out a more modern chip from low power ICE40UP series. That is of course intended for a small project not requiring external RAM and only needing a low pin count.

[kony]

Careful about what vedor provided IP cores are free, and which cost quite a lot for what the overall ecosystem quality is.
I have several Lattice devboards left as paperweight, as I am unable to use its PCIe and DDR3 interfaces (and hell no I'd pay 3k$ just for the DDR3 core) - for smaller volume production projects, the silicon price difference is grossly offset by overheads in either development time, or SW/IP costs.
They have their niche usecases (MIPI D-PHY capable in some families), but otherwise I'd look elsewhere.

[SiliconWizard]

I’ve seen an ECP5 devboard with many features (DDR3L, HDMI, GbE etc) from LambdaConcept.com team (btw, they are from Paris), but have no personal experience with it.

Thanks, that doesn't look too shabby indeed. https://shop.lambdaconcept.com/home/46-1-ecpix-5.html#/1-ecpix_5_fpga-ecpix_5_45f

The not-so-good (for my use) is that it comes with a 5G part - which means it can't be used with the free version of Diamond (and, I don't need 5Gb/s serdes, which those parts provide). Sure this board is promoted as being usable with an open-source toolchain, but at this point I'm not interested for various reasons, including the fact there's no support for VHDL.

But for people interested in using open source tools with FPGAs, that's an interesting option.

[SiliconWizard]

It's not that obvious, But this can easily  be used as an ECP5 dev board

http://aliexpress.com/item/1005001330347620.html?spm=a2g0o.cart.0.0.14a83c00o9jOP8&mp=1

https://github.com/kholia/Colorlight-5A-75B

I had seen it. Doesn't seem too practical to me, but could be put to some use I guess.

But there's actually a derivative from (apparently) the same product line on Aliexpress: https://www.aliexpress.com/item/1005001686186007.html?spm=a2g0s.12269583.0.0.2e0d1034AHZNIg
in the form of a SODIMM module with an ECP5U-25F (supported by free Diamond), an SDRAM chip (8Mbytes, which is not huge but usable, and on 32-bit data, which is a plus), 2 ethernet PHY, and a comfortable amount of IOs broken out. And there's also a simple baseboard for it. Not exactly what I was looking for, but should be usable. I ordered one.

[laugensalm]

The ECP5 VIP (EVDK) is used here quite productively, but it was purchased for a promo price back then, might be much higher now.
Also interesting is the ECP5 Versa 5G kit. The somewhat painful thing with the Diamond toolchain is the requirement for yearly license renewals, but you always have the yosys option (which works just fine for portable IP cores). So, there is a full open source toolchain for ECP5, backed by a community (unlike Spartan6). For build-and-test cycles, the OS tools work way faster (one minute for a full RISC-V SoC, compared to ~five using Diamond).

[Omega Glory]

Careful about what vedor provided IP cores are free, and which cost quite a lot for what the overall ecosystem quality is.
I have several Lattice devboards left as paperweight, as I am unable to use its PCIe and DDR3 interfaces (and hell no I'd pay 3k$ just for the DDR3 core) - for smaller volume production projects, the silicon price difference is grossly offset by overheads in either development time, or SW/IP costs.
They have their niche usecases (MIPI D-PHY capable in some families), but otherwise I'd look elsewhere.

I'm a noob, so this might be a dumb question, but is there anything preventing you from writing your own DDR3 controller? Or is the DDR3 core a hard IP block that you have to somehow buy access to in order to synthesize a design with it?

[asmi]

I'm a noob, so this might be a dumb question, but is there anything preventing you from writing your own DDR3 controller?

Nothing prevents you from doing your own, at least for ECP5 it seems. The problem is this is a major endeavor in and of itself, and will likely be very specialized for your specific use case (bus width, physical pinout, etc.). The problem is even minimal DDR3 frequency (303 MHz) is very fast for these FPGAs, and so closing timing is going to be a big pain in the butt. In my 30 minute-long play around with Diamond I was able to generate DDR3 PHY (it seems that this part is free), but there are much more pieces to this puzzle yet to be designed - initialization, write/read leveling, refresh management, bank state machines, as well as higher level stuff like transaction reordering/combining to improve efficiency.
The more fundamental problem is that not many people would choose to invest a ton of time into designing infrastructure stuff like this, rather than working on actual designs. I've done some memory controller designs in the past, but they were specialized for specific project's needs and would not work very well as general-purpose controllers for, say, CPU. And the difference between achieved bandwidth between "naive" implementation ("open-read/write-close-repeat") and the one taking advantage of DDR3 pipelining capabilities for hiding access latency can be an order of magnitude or more.

[ale500]

I also ordered this board https://www.tindie.com/products/tinyvision_ai/upduino-v30-low-cost-lattice-ice40-fpga-board/ to try out a more modern chip from low power ICE40UP series. That is of course intended for a small project not requiring external RAM and only needing a low pin count.

Ohh, anew upduino version, looks very nice. I got 6 upduinos 1 and 1 upduino v2. Nice formfactor.

[SiliconWizard]

I have a Upduino v2 and it's a nice board for evaluating the iCE40UP series. Nice series for simple designs that do not need high Fmax, and cheap as well.

But this thread was about the ECP5.

Anyway, I have received the board I mentioned ( https://www.aliexpress.com/item/1005001686186007.html?spm=a2g0s.12269583.0.0.2e0d1034AHZNIg ) a while ago, and I've started using it. As I said, it includes an ECP5-25 and SDRAM memory (also 2 ethernet PHYs that I haven't used yet.) I've written an SDRAM controller for it and used it to design and evaluate a N-way associative cache. Further goal is to port a RISC-V core I've designed and implemented on Xilinx parts earlier.

I like Lattice tools that are fast and non-bloated. Of course, Diamond doesn't have nearly the same amount of features than Xilinx Vivado for instance. This is a different world.
What I noticed so far, and that I fully expected, is that compared to Xilinx Spartan (even 6), the same code will usually get lower Fmax and more LUTs on the ECP5. That was expected. The ECP5 has 4-input LUTs whereas Xilinx uses 6-input LUTs, for instance.

As to writing a DDR3 controller, that was already talked about in another thread recently. As asmi said, it's a big challenge. I wrote a SDRAM controller, but this is infinitely simpler. And yet, setting up proper timing constraints was already not that easy! Lattice has IPs for DDR controllers, but they are unfortunately not free. Since there are a couple open-source boards with ECP5 and DDR RAM (such as the ULX3S), I was wondering how they managed to use it, and this is what I found out: their examples using DDR RAM are implemented using nMigen: https://github.com/m-labs/nmigen

Although I'm not interested in using such a tool, it doesn't look too shabby. nMigen allows to generate full SOCs including DDR3 controllers. You could have a look - obviously they managed to do it. No clue how efficient their DDR3 controller is though. It may have poor performance.

[asmi]

What kind of board would you like? What device? What peripherals? What connectors/interfaces to the outside world? Let us know what your dream board would be, and it might just appear

[SiliconWizard]

What kind of board would you like? What device? What peripherals? What connectors/interfaces to the outside world? Let us know what your dream board would be, and it might just appear

Well, the Lattice eval board is not expensive but it has no external RAM.
https://www.latticesemi.com/en/Products/DevelopmentBoardsAndKits/ECP5EvaluationBoard

They have a Versa board which has more to offer, but it's a lot more expensive and I don't need PCIe.
https://www.latticesemi.com/Products/DevelopmentBoardsAndKits/ECP5VersaDevelopmentKit.aspx

The LambdaConcept board mentioned earlier looked good, but too few IOs for my needs, and all broken out on PMOD connectors as far as i've seen, so that's limiting.

One thing to note that applies to all 3 boards above is that they have ECP5UM parts. That's the ECP5 with SERDES. Which is nice. Except that those aren't supported by the free license for Diamond. (Lattice boards, I think, come with a 1-year license for Diamond, after 1 year, you'll have to pay...) Between this and the limited free IP catalog, at this point you may say that Lattice is rubbish...

There's an open source alternative to Diamond though, which is yosys. It supports the ECP5. I wasn't considering this, but that's always an option.

Anyway, at this point, the board I found at Aliexpress will do the job for my evaluation needs. But ideally, a dev board for my needs would include:

- Available with ECP5U or UM from -12 to -85,
- LPDDR or DDR3 RAM, a 32-bit data bus would be nice (either as a single chip or two chips combined), at least 1Gbits (128MBytes),
- Alternatively LPSDR RAM (also 32-bit data bus, 512Mbits min - but I think that's the maximum available per chip these days),
- HDMI output,
- JTAG connector (no onboard programmer!),
- FT232H or FT2232H with all bus pins routed to FPGA (so we can use it in async and sync parallel FIFO modes),
- Alternatively, a FT6xx chip for USB 3.0 SS interfacing,
- About 100 I/Os broken out, with a number of them decently routed as differential pairs.
- A couple LEDs for good measure.

[filssavi]

I have used the ice40 ultraPlus line, not the ECP5, while they are smaller and have less high end features (no transceivers, PCIe etc) however it is fairly close (4 input LUTE).

When compared with the Spartan 7 line they are much, much less capable, both in term of amount of stuff you can fit in them, and also in term of frequency.

In my opinion they are two different parts for different applications, lattice parts are cheaper, however with Xilinx you can scale much higher.

[asmi]

- Available with ECP5U or UM from -12 to -85,

The only package which provides that kind of range is caBGA381, it offers from 197 to 205 user IO balls depending on density.

- LPDDR or DDR3 RAM, a 32-bit data bus would be nice (either as a single chip or two chips combined), at least 1Gbits (128MBytes),
- Alternatively LPSDR RAM (also 32-bit data bus, 512Mbits min - but I think that's the maximum available per chip these days),

That will fully consume 3 IO banks (1, 2 and 3 in my test design). Bank 8 contains config pins, so I'd leave it alone as well. That leaves 27 (Bank 0) + 33 (Bank 6) + 32 (Bank 7) = 92 user IO pins available to us.

- HDMI output,

These devices do not support TMDS directly, but in all differential modes the max frequency is only 400 MHz, so a dedicated HDMI TX chip needs to be used. Depending on device used and it's mode, up to 38 IO pins might be required.

- JTAG connector (no onboard programmer!),

What are you going to use to program device? I assume you will want some QSPI flash device onboard, right?

- FT232H or FT2232H with all bus pins routed to FPGA (so we can use it in async and sync parallel FIFO modes),
- Alternatively, a FT6xx chip for USB 3.0 SS interfacing,

FT601 requires 44 user IO pins, FT600 - 28 (but gives only half of FT601's bandwidth).

- About 100 I/Os broken out, with a number of them decently routed as differential pairs.
- A couple LEDs for good measure.

As you can see, we're kind of short on IO pins. Going for larger packages limits the density migration path to only 45 and 85 devices (for 554 package and 245/259 IO balls respectively) or just 85 device (for 756 package and 365 IO balls).
That said, the 756 package still has a reasonable pinout (see attachment) and can be fully routed out on a 6 layer board. 6 layer boards are significantly more expensive than 4 layer ones (though I'm not convinced yet that 2x16 bit DDR3 flyby interface can be accomplished on a 4 layer board), even if the device itself is not that expensive compared to other vendor's devices of similar density, but that comparison is not entirely fair for a whole host of reasons, which we won't go into over here.

[BrianHG]

- HDMI output,

These devices do not support TMDS directly, but in all differential modes the max frequency is only 400 MHz, so a dedicated HDMI TX chip needs to be used. Depending on device used and it's mode, up to 38 IO pins might be required.

Differential is 800mbps tops, within spec.  This means 720p60Hz, or 1080p30Hz easy, or 1024x768, 1152x864@60hz, 1280x1024@60hz. (Really reduced blanking, some TVs might not work, but most monitors will.)  We've used a 90cent NXP IC which is a 3GHz differential DVI/HDMI cable amp/driver with built in ESD protected output plus a 5V to 3.3v level translator for the EDID lines & +5v hotplug detect.  We had no problem driving 1080mbps on a Cyclone IV which had a spec limit of 640mbps.

Out of spec, well, looking into adapting lattice diamond into the DVI/HDMI transmitter I'm working on, they have an issue with setting up the PLL where you need to specify the source frequency as an ASCII number in quotes in the comments for 'exemplar'? ? ? ?  WTF, come on Lattice, what stupidity is this.  Well, I have to make something like a huge lookup table of 'generate' and 'if' just to do what in Altera (and I suspect in Xilinx) is nothing more than passing that 'parameter' into the function's module's setting.

Right now, I promised a tri-platform DDR3 controller first and I'm getting there, only few days left..  Once that works, I'll get back to the HDMI to make it work on Lattice and Xilinx.

Example Lattice Diamond EHXPLLL:

Code: [Select]

    EHXPLLL HPLL0     (.CLKI(clk_in),           .CLKFB(PLL0_clk_out[0]), // was an assigned wire (CLKOP_t)
                       .PHASESEL1(scuba_vlo0),  .PHASESEL0(scuba_vlo0),   .PHASEDIR(scuba_vlo0), .PHASESTEP(scuba_vlo0), .PHASELOADREG(scuba_vlo0),
                       .STDBY(scuba_vlo0),      .PLLWAKESYNC(scuba_vlo0), .RST(scuba_vlo0),
                       .ENCLKOP(scuba_vlo0),    .ENCLKOS(scuba_vlo0),     .ENCLKOS2(scuba_vlo0), .ENCLKOS3(scuba_vlo0),
                       .CLKOP(PLL0_clk_out[0]), .CLKOS(),                 .CLKOS2(),             .CLKOS3(),
                       .LOCK(LOCK0),            .INTLOCK(),               .REFCLK(REFCLK0),      .CLKINTFB())
             /* synthesis FREQUENCY_PIN_CLKOP  = real'(PLL0_OUT_TRUE_KHZ/1000) */
             /* synthesis FREQUENCY_PIN_CLKI   = real'(HDPLL_CLK_KHZ_IN/1000) */
             /* synthesis ICP_CURRENT="6" */
             /* synthesis LPF_RESISTOR="16" */;
 defparam
 HPLL0.CLKOS3_DIV       = 1,          HPLL0.CLKOS2_DIV     = 1,          HPLL0.CLKOS_DIV       = 1,
 HPLL0.CLKOP_DIV        = PLL0_div,   HPLL0.CLKFB_DIV      = PLL0_mult,  HPLL0.CLKI_DIV        = 1,
 
 HPLL0.CLKOS3_FPHASE    = 0,          HPLL0.CLKOS3_CPHASE  = 0,
 HPLL0.CLKOS2_FPHASE    = 0,          HPLL0.CLKOS2_CPHASE  = 0,
 HPLL0.CLKOS_FPHASE     = 0,          HPLL0.CLKOS_CPHASE   = 0,
 HPLL0.CLKOP_FPHASE     = 0,          HPLL0.CLKOP_CPHASE   = (PLL0_div-1),

 HPLL0.FEEDBK_PATH      = "CLKOP",    HPLL0.PLL_LOCK_MODE  = 0,

 HPLL0.OUTDIVIDER_MUXD  = "DIVD",     HPLL0.CLKOS3_ENABLE  = "DISABLED",
 HPLL0.OUTDIVIDER_MUXC  = "DIVC",     HPLL0.CLKOS2_ENABLE  = "DISABLED",
 HPLL0.OUTDIVIDER_MUXB  = "DIVB",     HPLL0.CLKOS_ENABLE   = "DISABLED",
 HPLL0.OUTDIVIDER_MUXA  = "DIVA",     HPLL0.CLKOP_ENABLE   = "ENABLED",
 HPLL0.PLLRST_ENA       = "DISABLED", HPLL0.INTFB_WAKE     = "DISABLED", HPLL0.STDBY_ENABLE     = "DISABLED", HPLL0.DPHASE_SOURCE  = "DISABLED",
 HPLL0.CLKOS_TRIM_DELAY = 0,          HPLL0.CLKOS_TRIM_POL = "FALLING",  HPLL0.CLKOP_TRIM_DELAY = 0,          HPLL0.CLKOP_TRIM_POL = "FALLING";

    // exemplar begin
    // exemplar attribute PLLInst_0 FREQUENCY_PIN_CLKOP real'(PLL0_OUT_TRUE_KHZ/1000)
    // exemplar attribute PLLInst_0 FREQUENCY_PIN_CLKI real'(HDPLL_CLK_KHZ_IN/1000)
    // exemplar attribute PLLInst_0 ICP_CURRENT 6
    // exemplar attribute PLLInst_0 LPF_RESISTOR 16
    // exemplar end
This wont work, but change the 'synthesis' and 'exemplar' lines at the end of the function to this:

Code: [Select]

             /* synthesis FREQUENCY_PIN_CLKOP  = "74.250000" */
             /* synthesis FREQUENCY_PIN_CLKI   = "27.000000" */
             /* synthesis ICP_CURRENT="6" */
             /* synthesis LPF_RESISTOR="16" */;
---------------------------------------------------------------------------------------------
    // exemplar begin
    // exemplar attribute PLLInst_0 FREQUENCY_PIN_CLKOP "74.250000"
    // exemplar attribute PLLInst_0 FREQUENCY_PIN_CLKI "27.000000"
    // exemplar attribute PLLInst_0 ICP_CURRENT 6
    // exemplar attribute PLLInst_0 LPF_RESISTOR 16
    // exemplar end
And that will compile...  WTF?  (This is the way Lattice Diamond configures the PLL automatically.)
I can simulate the first code, but the Diamond environment will only allow the true real ASCII number in quotes to recognize the settings.

[asmi]

Differential is 800mbps tops, within spec.  This means 720p60Hz, or 1080p30Hz easy, or 1024x768, 1152x864@60hz, 1280x1024@60hz. (Really reduced blanking, some TVs might not work, but most monitors will.)  We've used a 90cent NXP IC which is a 3GHz differential DVI/HDMI cable amp/driver with built in ESD protected output plus a 5V to 3.3v level translator for the EDID lines & +5v hotplug detect.  We had no problem driving 1080mbps on a Cyclone IV which had a spec limit of 640mbps.

Sorry, but this board is not a Z80 platform. And in my book, no 1080p@60 - fail. So transceiver it is.
I honestly would love to go even higher (to say 1440p), but for that we'll need MGTs, which do not exist in U devices, and we can't use those which do have them due to Lattice's stupid licensing restrictions. Still - would be kind of cool to have 1440p@60 or even 4k@60 via DisplayPort or HDMI 2.0.

Right now, I promised a tri-platform DDR3 controller first and I'm getting there, only few days left..

I'm willing to bet you won't be able to make it work on Artix/S7, unless you reuse MIG PHY. The reason is that the latter uses some undocumented silicon blocks to do write/read leveling, unless you are willing to invest time trying to learn how to work with these blocks while having zero documentation. I actually don't even know if Xilinx provides simulation models for them. I know you can simulate MIG and it generates non-encrypted HDL which you can theoretically study. But just using MIG is so much easier and free so that it's hardly worth the trouble, unless you really itch for challenge.

[SiliconWizard]

- Available with ECP5U or UM from -12 to -85,

The only package which provides that kind of range is caBGA381, it offers from 197 to 205 user IO balls depending on density.

Yes. As you said, the amount of required I/Os in the end might restrict the choice to the -45 and -85 parts anyway. Which after all would be fine.

- LPDDR or DDR3 RAM, a 32-bit data bus would be nice (either as a single chip or two chips combined), at least 1Gbits (128MBytes),
- Alternatively LPSDR RAM (also 32-bit data bus, 512Mbits min - but I think that's the maximum available per chip these days),

That will fully consume 3 IO banks (1, 2 and 3 in my test design). Bank 8 contains config pins, so I'd leave it alone as well. That leaves 27 (Bank 0) + 33 (Bank 6) + 32 (Bank 7) = 92 user IO pins available to us.

Yep... but due to the lack of a free DDR controller IP anyway and my relatively modest needs in terms of bandwidth, using LPSDR RAM would be fine if it simplifies things - it would probably not require 3 banks.

- HDMI output,

These devices do not support TMDS directly, but in all differential modes the max frequency is only 400 MHz, so a dedicated HDMI TX chip needs to be used. Depending on device used and it's mode, up to 38 IO pins might be required.

I've only looked at and used the ECP5U so far. The ECP5UM has SERDES up to 3Gbits/s (and 5Gbits/s for the -5G). I had maybe stupidly assumed there was a way to pump out data this fast with differential outputs? If not, how can you make use of SERDES that can be clocked this fast? This puzzles me.

But yes, I've looked at the schematic of this board: https://www.latticesemi.com/products/developmentboardsandkits/embeddedvisiondevelopmentkit
and for HDMI output, they actually provide an additional board with an HDMI TX (Sil1136). I admit I'm confused with how the SERDES can be put to use on this part at their rated max clock rate.

As to HDMI with the on-chip differential modes, that would limit it to very low resolutions. I think 640x480 would be the max you could do with it. I've seen some demos like that. Anyway, a dedicated TX could be added. Fortunately, those Sil chips are not expensive and the result is probably more rugged than directly going from FPGA to the HDMI connector as well... (Edit about this: for the very low resolution, I was thinking of the ECP5U without SERDES. I don't think you can do better than about 640x480 with it. But with the ECP5UM, BrianHG should be right.)

That said, if you have any idea how we can use 5Gbit/s SERDES without getting differential, please explain. I may be missing something stupidly obvious here...

- JTAG connector (no onboard programmer!),

What are you going to use to program device? I assume you will want some QSPI flash device onboard, right?

Well, it should not matter. I have various JTAG probes. The connector could be directly compatible with a Digilent HS2/3, then one can always make adapters for other probles. Or, it could sport a mini JTAG connector (the 10-pin, 50 mil, male, version). Much smaller than the original 20-pin standard JTAG connector and I happen to have a probe that exactly has cables for this one. It has the benefit of being standard, whereas other approaches would be more like ad-hoc options.

And yes, the board should have a Flash chip to store configuration.

For the rest, as said, supporting -45 and -85 only would be fine if we'd be too short on I/Os with the smaller ones.

[BrianHG]

Right now, I promised a tri-platform DDR3 controller first and I'm getting there, only few days left..

I'm willing to bet you won't be able to make it work on Artix/S7, unless you reuse MIG PHY. The reason is that the latter uses some undocumented silicon blocks to do write/read leveling, unless you are willing to invest time trying to learn how to work with these blocks while having zero documentation. I actually don't even know if Xilinx provides simulation models for them. I know you can simulate MIG and it generates non-encrypted HDL which you can theoretically study. But just using MIG is so much easier and free so that it's hardly worth the trouble, unless you really itch for challenge.

Do not underestimate me.  However, yes, wiring to the DDR3 does use one (3 times) of Altera's phy, Lattice's phy and will use one of Xilinx's DDR phys, one of 3 selected by the first line parameter.  The only issue with Lattice is that it supposed to translate a .sdc file into it's own 'newer' format at compile, but when I played with it on the HDMI module, it always skipped the file.  If Xilinx does take into account a normal .sdc file, that will help a lot.

[asmi]

Yep... but due to the lack of a free DDR controller IP anyway and my relatively modest needs in terms of bandwidth, using LPSDR RAM would be fine if it simplifies things - it would probably not require 3 banks.

Evaluation version of DD3 controller which they provide can be ran for up to "approximately 4 hours" (quote from the user guide). That's plenty to perform hardware checkout during bring-up. And after that - design your own LPDDR1 will not take dramatically less pins - they use SE DQS as opposed to differential, and will have a bit less address lines, but that's about it. Unless you're talking about LPDDR2 or 3 - but I never used those, so I don't really know much about how they work.

I've only looked at and used the ECP5U so far. The ECP5UM has SERDES up to 3Gbits/s (and 5Gbits/s for the -5G). I had maybe stupidly assumed there was a way to pump out data this fast with differential outputs? If not, how can you make use of SERDES that can be clocked this fast? This puzzles me.

You can only use U devices with free license.

and for HDMI output, they actually provide an additional board with an HDMI TX (Sil1136). I admit I'm confused with how the SERDES can be put to use on this part at their rated max clock rate.

These transceivers have wide parallel bus from FPGA to transmit color information, which they then format, serialize and output via HDMI. So if you use any of those external chips, your FPGA will only need to be able output pixels via wide (typically 24bit) parallel bus at a pixel clock (which is only 148.5 MHz for 1080p@60).

As to HDMI with the on-chip differential modes, that would limit it to very low resolutions. I think 640x480 would be the max you could do with it. I've seen some demos like that. Anyway, a dedicated TX could be added. Fortunately, those Sil chips are not expensive and the result is probably more rugged than directly going from FPGA to the HDMI connector as well... (Edit about this: for the very low resolution, I was thinking of the ECP5U without SERDES. I don't think you can do better than about 640x480 with it. But with the ECP5UM, BrianHG should be right.)

This is why I said we're going to have to use external TX chip.

That said, if you have any idea how we can use 5Gbit/s SERDES without getting differential, please explain. I may be missing something stupidly obvious here...

Like I said above, unless you fancy paying for the license (every. single. year. as it's time-limited, unlike Xilinx license, which is version-limited so you can use the version you have a license for forever) - you might as well just forget these devices exist. Which is a shame really, but it is what it is.

[asmi]

Do not underestimate me.  However, yes, wiring to the DDR3 does use one (3 times) of Altera's phy, Lattice's phy and will use one of Xilinx's DDR phys, one of 3 selected by the first line parameter.

I still don't see a point in using your controller over standard MIG. I think you should focus more on Antel and Lattice platforms as they don't provide free one.

[SiliconWizard]

Yep... but due to the lack of a free DDR controller IP anyway and my relatively modest needs in terms of bandwidth, using LPSDR RAM would be fine if it simplifies things - it would probably not require 3 banks.

Evaluation version of DD3 controller which they provide can be ran for up to "approximately 4 hours" (quote from the user guide). That's plenty to perform hardware checkout during bring-up. And after that - design your own LPDDR1 will not take dramatically less pins - they use SE DQS as opposed to differential, and will have a bit less address lines, but that's about it. Unless you're talking about LPDDR2 or 3 - but I never used those, so I don't really know much about how they work.

No no, I was talking about LPSDR as an alternative. I know LPDDR is probably very similar to regular DDR. LPSDR is just SDR SDRAM, but lower power. Much easier to use than DDR. Of course not the same kind of bandwidth, but if you go for large data busses such as 32-bit, or even 64-bit in 2 chips, you can still get a pretty usable bandwidth with them. It will eat up a lot of I/Os though.

You can have a look there: https://www.alliancememory.com/products/low-power-mobile-synchronous-dram-sdr/
or at Micron.

I've only looked at and used the ECP5U so far. The ECP5UM has SERDES up to 3Gbits/s (and 5Gbits/s for the -5G). I had maybe stupidly assumed there was a way to pump out data this fast with differential outputs? If not, how can you make use of SERDES that can be clocked this fast? This puzzles me.

You can only use U devices with free license.

I know, I already mentioned that. But the UM devices are actually supported by yosys (although not sure I would use this for any serious work, this option can be mentioned.)

and for HDMI output, they actually provide an additional board with an HDMI TX (Sil1136). I admit I'm confused with how the SERDES can be put to use on this part at their rated max clock rate.

These transceivers have wide parallel bus from FPGA to transmit color information, which they then format, serialize and output via HDMI. So if you use any of those external chips, your FPGA will only need to be able output pixels via wide (typically 24bit) parallel bus at a pixel clock (which is only 148.5 MHz for 1080p@60).

Yes I know that. But they also have a clever mode in which you can also use a 12-bit bus only and feed pixel data in DDR mode. So that's not too bad, and perfectly doable with an ECP5U.

That said, if you have any idea how we can use 5Gbit/s SERDES without getting differential, please explain. I may be missing something stupidly obvious here...

Like I said above, unless you fancy paying for the license (every. single. year. as it's time-limited, unlike Xilinx license, which is version-limited so you can use the version you have a license for forever) - you might as well just forget these devices exist. Which is a shame really, but it is what it is.

Yeah, again I know about this. (And again there would be the yosys option, or actually buying a Lattice dev board which gets you a 1-year license as all their dev boards have ECP5UM devices AFAIK.)

That was more of a technical question here, because looking at the datasheet, I haven't indeed seen any differential I/Os that support over 400MHz, for all parts, so I don't know how the SERDES can be used in ECP5UM parts.

[asmi]

No no, I was talking about LPSDR as an alternative. I know LPDDR is probably very similar to regular DDR. LPSDR is just SDR SDRAM, but lower power. Much easier to use than DDR. Of course not the same kind of bandwidth, but if you go for large data busses such as 32-bit, or even 64-bit in 2 chips, you can still get a pretty usable bandwidth with them. It will eat up a lot of I/Os though.

You can have a look there: https://www.alliancememory.com/products/low-power-mobile-synchronous-dram-sdr/
or at Micron.

No, that's too slow. Let's hope Brain will design working DDR3 controller by the time the board will actually exist

That was more of a technical question here, because looking at the datasheet, I haven't indeed seen any differential I/Os that support over 400MHz, for all parts, so I don't know how the SERDES can be used in ECP5UM parts.

That's simple - they use dedicated pins. Look closer at pinout diagram in one of my previous posts, see that bottom section with a bunch of "RESERVED" balls - that's there transceiver TX and RX balls are on non-U devices. The same deal is in Xilinx devices - they also have dedicated balls for MGTs, as signals are just too fast to allow any kind of internal routing. And a ton of grounds around it help shielding these lines from digital noise caused by nearby balls.