Lattice ECP5: opinion? - Page 1
Forum section: electronics / general

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 15, 2020, 01:09:12 am
content: 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...

author: abyrvalg
author_rank: Frequent Contributor
timestamp: December 24, 2020, 11:20:19 pm
content: 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.

author: ebclr
author_rank: Super Contributor
timestamp: December 25, 2020, 04:25:45 am
content: It's not that obvious, But this can easily be used as an ECP5 dev boardhttp://aliexpress.com/item/1005001330347620.html?spm=a2g0o.cart.0.0.14a83c00o9jOP8&mp=1https://github.com/kholia/Colorlight-5A-75B

author: tchicago
author_rank: Regular Contributor
timestamp: December 25, 2020, 04:46:54 am
content: Quote from: ebclr on December 25, 2020, 04:25:45 amthat board seems to be way too specialized. No direct access to pins, only via output buffers...

author: tchicago
author_rank: Regular Contributor
timestamp: December 25, 2020, 08:19:07 am
content: 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 boardhttps://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.

author: kony
author_rank: Regular Contributor
timestamp: December 25, 2020, 01:32:52 pm
content: 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 25, 2020, 05:01:41 pm
content: Quote from: abyrvalg on December 24, 2020, 11:20:19 pmThanks, that doesn't look too shabby indeed.https://shop.lambdaconcept.com/home/46-1-ecpix-5.html#/1-ecpix_5_fpga-ecpix_5_45fThe 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 25, 2020, 05:09:53 pm
content: Quote from: ebclr on December 25, 2020, 04:25:45 amI 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.2e0d1034AHZNIgin 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.

author: laugensalm
author_rank: Regular Contributor
timestamp: December 27, 2020, 10:55:54 am
content: 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).

author: Omega Glory
author_rank: Regular Contributor
timestamp: February 28, 2021, 06:25:00 am
content: Quote from: kony on December 25, 2020, 01:32:52 pmI'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?

author: asmi
author_rank: Super Contributor
timestamp: February 28, 2021, 08:38:51 am
content: Quote from: Omega Glory on February 28, 2021, 06:25:00 amNothing 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.

author: ale500
author_rank: Frequent Contributor
timestamp: February 28, 2021, 03:57:02 pm
content: QuoteOhh, anew upduino version, looks very nice. I got 6 upduinos 1 and 1 upduino v2. Nice formfactor.

author: SiliconWizard
author_rank: Super Contributor
timestamp: February 28, 2021, 04:32:08 pm
content: 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/nmigenAlthough 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.

author: asmi
author_rank: Super Contributor
timestamp: February 28, 2021, 06:18:28 pm
content: 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

author: SiliconWizard
author_rank: Super Contributor
timestamp: February 28, 2021, 07:09:31 pm
content: Quote from: asmi on February 28, 2021, 06:18:28 pmWell, the Lattice eval board is not expensive but it has no external RAM.https://www.latticesemi.com/en/Products/DevelopmentBoardsAndKits/ECP5EvaluationBoardThey 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.aspxThe 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.

author: filssavi
author_rank: Frequent Contributor
timestamp: February 28, 2021, 07:20:10 pm
content: 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.

author: asmi
author_rank: Super Contributor
timestamp: March 01, 2021, 12:30:14 am
content: Quote from: SiliconWizard on February 28, 2021, 07:09:31 pmThe only package which provides that kind of range is caBGA381, it offers from 197 to 205 user IO balls depending on density.Quote from: SiliconWizard on February 28, 2021, 07:09:31 pmThat 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.Quote from: SiliconWizard on February 28, 2021, 07:09:31 pmThese 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.Quote from: SiliconWizard on February 28, 2021, 07:09:31 pmWhat are you going to use to program device? I assume you will want some QSPI flash device onboard, right?Quote from: SiliconWizard on February 28, 2021, 07:09:31 pmFT601 requires 44 user IO pins, FT600 - 28 (but gives only half of FT601's bandwidth).Quote from: SiliconWizard on February 28, 2021, 07:09:31 pmAs 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.

author: BrianHG
author_rank: Super Contributor
timestamp: March 01, 2021, 02:37:40 am
content: Quote from: asmi on March 01, 2021, 12:30:14 amDifferential 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:EHXPLLL HPLL0 (.CLKI(clk_in), .CLKFB(PLL0_clk_out), // 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), .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" */;defparamHPLL0.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 endThis wont work, but change the 'synthesis' and 'exemplar' lines at the end of the function to this:Code:/* 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 endAnd 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.

author: asmi
author_rank: Super Contributor
timestamp: March 01, 2021, 02:53:50 am
content: Quote from: BrianHG on March 01, 2021, 02:37:40 amSorry, 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.Quote from: BrianHG on March 01, 2021, 02:37:40 amI'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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 01, 2021, 02:56:35 am
content: Quote from: asmi on March 01, 2021, 12:30:14 amYes. 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.Quote from: asmi on March 01, 2021, 12:30:14 amYep... 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.Quote from: asmi on March 01, 2021, 12:30:14 amI'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/embeddedvisiondevelopmentkitand 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...Quote from: asmi on March 01, 2021, 12:30:14 amWell, 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.

author: BrianHG
author_rank: Super Contributor
timestamp: March 01, 2021, 03:07:18 am
content: Quote from: asmi on March 01, 2021, 02:53:50 amDo 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.

author: asmi
author_rank: Super Contributor
timestamp: March 01, 2021, 03:09:37 am
content: Quote from: SiliconWizard on March 01, 2021, 02:56:35 amEvaluation 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 ownLPDDR1 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.Quote from: SiliconWizard on March 01, 2021, 02:56:35 amYou can only use U devices with free license.Quote from: SiliconWizard on March 01, 2021, 02:56:35 amThese 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).Quote from: SiliconWizard on March 01, 2021, 02:56:35 amThis is why I said we're going to have to use external TX chip.Quote from: SiliconWizard on March 01, 2021, 02:56:35 amLike 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.

author: asmi
author_rank: Super Contributor
timestamp: March 01, 2021, 03:13:26 am
content: Quote from: BrianHG on March 01, 2021, 03:07:18 amI 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 01, 2021, 03:24:43 am
content: Quote from: asmi on March 01, 2021, 03:09:37 amNo 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.Quote from: asmi on March 01, 2021, 03:09:37 amI 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.)Quote from: asmi on March 01, 2021, 03:09:37 amYes 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.Quote from: asmi on March 01, 2021, 03:09:37 amYeah, 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.

author: asmi
author_rank: Super Contributor
timestamp: March 01, 2021, 03:32:30 am
content: Quote from: SiliconWizard on March 01, 2021, 03:24:43 amNo, that's too slow. Let's hope Brain will design working DDR3 controller by the time the board will actually existQuote from: SiliconWizard on March 01, 2021, 03:24:43 amThat'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.

author: BrianHG
author_rank: Super Contributor
timestamp: March 01, 2021, 03:32:47 am
content: The limits colored in green foralmost every IO on the IC.That's almost every IO on the left and right side of the device.Obviously the dedicated transceiver devices & their pins will do the high GHz...

author: BrianHG
author_rank: Super Contributor
timestamp: March 01, 2021, 03:42:11 am
content: Quote from: asmi on March 01, 2021, 03:13:26 amYes, mine has limitations being built around all the different FPGAs, but this is not the point. I doing this for the puzzle fun and to make something which may not reach Altera's hardware phy on their slower parts, but it has functions which roast their software phy and are more capable than their dedicated hardware phy. It is designed to operate uniformly across any FPGA and it is properly documented so that it can be adapted to others I haven't written for. I'm not trying to sell or profit from this. Having 3 FPGA vendors just demonstrates how the 2 sections which needs plugging into another vendor's compiler & my explanations in the code will allow meaningful changes anyone desires.

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 01, 2021, 03:17:39 pm
content: Quote from: BrianHG on March 01, 2021, 03:32:47 amI guessed so but I think it's not particularly clear in the datasheet. Where are those dedicated pins described? (And sorry if I missed it!)And that said, can't you use those dedicated pins for HDMI?

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 01, 2021, 03:31:06 pm
content: Quote from: asmi on March 01, 2021, 03:32:30 amI guess this was kind of ironical or something. So 1/ no it's not "too slow", it's actually fine for many purposes - and so much simpler; 2/ you seem to doubt BrianHG here, and I agree a DDR3 controller is not a simple task, but it's definitely doable. As I said earlier, others have done it. One may take a look at the controller that's implemented in nMigen. I know it works. Now whether you'd manage in reasonable time to design one that is as efficient as the commercial/vendor IPs, that will remain to be seen.For point 1/, it really depends on what your use case is. As it happens, the current board I'm using has a SDRAM chip with a 32-bit databus, 166MHz max. Many FPGA dev boards only have a single DDR3 chip with a 16-bit data bus. Although DDR3 has a few access optimizations, the effective throughput will not be that far apart between the two at the same frequency. But the main benefit was that I can actually use it. If it had a DDR memory chip, it would be as good as dead beef to me at this point.

author: asmi
author_rank: Super Contributor
timestamp: March 01, 2021, 04:39:28 pm
content: Quote from: SiliconWizard on March 01, 2021, 03:31:06 pmNo, I don't doubt him, but it's going to take a while no matter how good he (or anyone really) is. And then there is always a question of what UI is supposed to look like. For example Lattice's DDR3 controller is fairly barebones - you send in address/command, it passes it along, and at some point it asks for data (for writes) or make data available (for reads). There is no reordering, no burst merging, no pipelining, the only "optimization" it's got is that it keeps track of opened rows for each bank, and also sends in bursts of REFRESH commands when required.Compare that to advanced controller provided with MIG - it's got reordering, request pipelining, in and out FIFOs, and even optional AXI4 slave interface block.I expect homegrown controller to be closer to the former rather than to latter.Quote from: SiliconWizard on March 01, 2021, 03:31:06 pmDDR3 can be ran at 400 MHz for SG8, which gives 400*2*16 = 12800 Mbps for 16 bit data bus, 32 bit bus doubles that. SDRAM running at 166 MHz gives 166*32=5312 Mbps for 32 data bus, or less than half of what 16bit DDR3 provides. Crucially though, a single 1080p@60 stream requires 1920*1080*32*60/(1024^2) ~ 3800 Mbps, so 32 bit SDRAM will not be sufficient for a framebuffer as you need to read and write at the same time at the very minimum (realistically write bandwidth needs to be much higher if you want to implement any sort of GPU functions). 16 bit DDR3 at 400 MHz is enough for basic double-framebuffer implementation with some bandwidth to spare for CPU cache reads/writes. 32 bit gives you some headroom for GPU functions like layer composition and maybe some basic texturing/3D graphics pipeline, but for advanced GPU functions you will likely need 64 bit DDR3.

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 01, 2021, 04:54:11 pm
content: No doubt about using DDR3 @400MHz and its usefulness, but most of the basic dev boards only sport a 200MHz max chip. Also, as you said, Lattice's DDR3 controller is not even that good and the probability of getting/writing something better is doubtful, at least if you don't have years ahead of you and/or big bucks to shell out.I'm not looking to develop the kind of applications you mentioned, at least not with such a board and an ECP5. So that would be much more modest.

author: asmi
author_rank: Super Contributor
timestamp: March 01, 2021, 06:03:05 pm
content: Quote from: SiliconWizard on March 01, 2021, 04:54:11 pm200 MHz DDR3? Such chips don't exist. DDR3 standard defines a minimum frequency of 303 MHz, in reality you won't be able to find chip slower than 800 MHz for sale (at least not via official channels).Quote from: SiliconWizard on March 01, 2021, 04:54:11 pmIf PHY that Clarity generates is any good, I don't doubt that it's possible to design a full controller yourself. It will take some time for sure, but it seems that Brian is determined to make it happen (and his track record for achieving stuff he wants is excellent if Z80 thread is anything to go by), so if we all help him out a little, we can have something really good in the end. In fact this board might be a good platform for hardware validation of this project.Quote from: SiliconWizard on March 01, 2021, 04:54:11 pmThat's why I think 2 x16 bit DDR3 is the optimal choice. Regular SDRAM is too much of a stone age tech for me to seriously consider.Another choices are DDR2 or LPDDR1, which are a bit simpler it a sense that they don't require write/read leveling, but they require balanced tree layout for address/command and clock, so no way this can be accomplished on 4 layers. As a matter of fact, at this point I'm not convinced that it's possible to do a DDR3 flyby on 4 layers, but that is definitely easier than balanced tree.

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 01, 2021, 07:22:22 pm
content: Quote from: asmi on March 01, 2021, 06:03:05 pmYou're right, I was probably thinking of DDR2 instead here... Regarding availability, the lowest grade DDR3 available at Digikey is listed as 533MHz, but no stock, the lowest in stock are 667MHz chips.That said, whatever DDR3 chip you use, I highly doubt you'll manage to get higher than 400MHz on an ECP5. Lattice's DDR3 controller IP states that 400MHz is the highest clock rate achievable, and with the highest speed grade ECP5...And with a hand-written controller, I wouldn't be hugely surprised if you really struggled to reach those 400MHz.We're again talking about the ECP5 here. If I want to be able to use DDR3 at 800MHz+, I'll go see elsewhere.Quote from: asmi on March 01, 2021, 06:03:05 pmI don't doubt it either, as I said it has already been done (and with 100% open-source tools on top of that.) But it's going to take time, and performance and Fmax are likely going to be a little disappointing.Quote from: asmi on March 01, 2021, 06:03:05 pmI get it that SDR SDRAM is not for you. But it's still useful for a range of applications, and I for one see no reason to switch to a MUCH complex overall design if I don't need the performance.Note that I'm now figuring YOU would actually be interested in designing such a board yourself (I remember you've designed other FPGA boards before, the latest being a Spartan 7 one?) It's obvious that if you embark on this project, the choice will be entirely yours. I was just listing what *I* would currently be happy with, but I'm not going to make those choices for you!

author: BrianHG
author_rank: Super Contributor
timestamp: March 01, 2021, 08:44:50 pm
content: A sneak peek: (Yes, this is putting my ass on the line)(I need a few days of concentration to finish, so no questions...)

author: BrianHG
author_rank: Super Contributor
timestamp: March 01, 2021, 08:56:58 pm
content: Quote from: SiliconWizard on March 01, 2021, 03:17:39 pmIn the Diamond's Pin Planner, clicking on the ram DQpins, and Show 'Differential Pairs' will show you the IO pins you can achieve 800megabaud. For HDMI, you only need 4 pairs. With the NXP IC, we got it to work even ignoring the EDID, but you should still wire those on cheap IOs so you may query the display if you like.

author: asmi
author_rank: Super Contributor
timestamp: March 01, 2021, 09:01:10 pm
content: Quote from: SiliconWizard on March 01, 2021, 07:22:22 pm200 MHz DDR2 are nowhere to be found either. Maybe they were available like 15 years ago (or whenever DDR2 became a thing), but now I think they start at 400 MHz.Quote from: SiliconWizard on March 01, 2021, 07:22:22 pmLattice's controller guarantees 400 MHz on the top speed grade for 64bit DIMM, that means there is quite a bit of margin and hence I don't think there will be a lot of problems achieving that since we only want half of bus width and soldered-on memory chips (so traces are much shorter than typical DIMM + connector).Quote from: SiliconWizard on March 01, 2021, 07:22:22 pmWell nobody here talks about 800 MHz DDR3, Artix-7 can't do that either, you will need to go for Kintex and use HP banks to achieve up to 933 MHz DDR3.Quote from: SiliconWizard on March 01, 2021, 07:22:22 pmBut that's a nice challenge isn't it?Also knowing how controller works inside out will allow using it more efficiently.Quote from: SiliconWizard on March 01, 2021, 07:22:22 pmThis will be a serious limitation - you have 1080p@60 HDMI Out, but you can't do a framebuffer due to insufficient bandwidth. If I were to see such a board, this oddity would jump right out. And what are you going to output via HDMI if you can't implement a framebuffer?Quote from: SiliconWizard on March 01, 2021, 07:22:22 pmI am interested, though I'm leaning towards going all in and using the largest package and a largest density because the top SG parts in 554 package are kind of hard to find in stock. Or going the opposite way - halving DDR3 bus to 16 bit and using FT600 instead of 601. This should leave enough pins for a nice expansion port, though we'll have to think about what kind of connector to use to make sure it won't be yet another pain in the butt a-la FMC.The fact that I'm doing the design doesn't mean I can't ask other opinions and they might change my mind, and/or find a way to accommodate various requirements as long as they don't conflict.

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 01, 2021, 09:46:30 pm
content: Quote from: asmi on March 01, 2021, 09:01:10 pmPretty much everywhere?https://www.digikey.com/en/products/filter/memory/774?s=N4IgjCBcoBwAxyqAxlAZgQwDYGcCmANCAPZQDaIATAgLIASAXiALpEAOALlCAKoB2ASw4B5NDTwYcAVwBOeEAF8FRSuRAATdTNXMFQABut anyway, those are just figures I had in mind. Not saying we should use DDR2 at all.Quote from: asmi on March 01, 2021, 09:01:10 pmYeah. I'll be curious to see that though.Quote from: asmi on March 01, 2021, 09:01:10 pmSure is.Quote from: asmi on March 01, 2021, 09:01:10 pmOr use lower resolutions... (In particular, I have specific ideas using industrial panels that are not Full HD. But other than this, HDMI would just be a bonus. So admittedly for people willing to do Full HD graphics, that would be a problem.)

author: asmi
author_rank: Super Contributor
timestamp: March 01, 2021, 10:10:30 pm
content: Quote from: SiliconWizard on March 01, 2021, 09:46:30 pmI meant to say "Micron parts" as I only ever use their parts for reasons I described elsewhere.Whatever - it's not really important for this discussion as we're talking 400 MHz max, and there are both DDR2 and DDR3 parts available supporting this (or higher) frequency.Quote from: SiliconWizard on March 01, 2021, 09:46:30 pmI think you have a very good chance to see thatHonestly part of me wants to just jump to the 756 package and route a full 64bit SODIMM connector. That package has a ton of IO pins (365), there will be enough for everything.Quote from: SiliconWizard on March 01, 2021, 09:46:30 pmI'm currently on a contract with one of major automakers (as software developer) supporting their production-related IT systems, and I can say that they use regular COTS 1080p TVs hanged to a ceiling all over the shop floor. So 1080p is an important resolution to support. Also that's the reason I would really like to have 4k support, as 4K TVs now cost dime a dozen, so they recently started deploying those. But that's not going to happen for this FPGA as it requires MGTs, and pretty fast ones at that, at least four DisplayPort HBR2-capable at 5.4 Gpbs per lane, or three 5.23 Gpbs ones for HDMI 2.0.

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 02, 2021, 05:34:09 pm
content: Quote from: asmi on March 01, 2021, 10:10:30 pmI probably missed it. I know it's not the thread to discuss this - would you have some link to another so I can understand why?Quote from: asmi on March 01, 2021, 10:10:30 pmWell, as far as I saw, there are a few HDMI TX over there that support 4K, such as the Sil1136. That would definitely be a case for using one here. Additionally, as I mentioned earlier, I'd be more confident using that as a PHY for HDMI rather than directly route FPGA I/Os to the HDMI connector...

author: asmi
author_rank: Super Contributor
timestamp: March 02, 2021, 06:19:51 pm
content: Quote from: SiliconWizard on March 02, 2021, 05:34:09 pmIt's very simple really - they provide excellent HDL models for their parts without going through seven circles of bureaucracy, and for that I'm grateful to them. So me using their parts is my way of thanking them for supporting small guys like me.Quote from: SiliconWizard on March 02, 2021, 05:34:09 pm4k@60 has a pixel clock of over 500 MHz, so ECP5 can't output even parallel pixels (unless you use DDR and half pixel clock) as their IO limit is 400 MHz.

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 02, 2021, 06:25:39 pm
content: Quote from: asmi on March 02, 2021, 06:19:51 pmWell, I do think this transmitter (and some others) supports DDR. So that should be ok using DDR? I didn't count though - maybe you have and have figured there wouldn't be enough DDR blocks inside the ECP5 for both DDR3 memory and HDMI?

author: asmi
author_rank: Super Contributor
timestamp: March 02, 2021, 07:01:25 pm
content: Quote from: SiliconWizard on March 02, 2021, 06:25:39 pmNo, I did not look that far yet. The reason I'd rather go with MGT's direct drive approach is that HDMI transmitters have unique challenges to them because of HDCP, so you can't even buy certain parts unless you are a member of HDMI org. But in this case we simply don't have a choice. Another challenge is that 4k@60 stream requires 3840*2160*32*60/(1024^2) ~ 15188 Mpbs of bandwidth, which is A LOT and pretty much requires 64 bit DDR3 if controller can only reach 400 MHz (800 MT/s). That is, unless you are OK with streaming lower-resolution image from memory and upscaling it in real time. So for this board I think 4K is going to be a bit too much because other components are going to be the limiting factor, even if we ignore the memory for a moment - what exactly are you going to display, and where this data is going to come from? Also part availability might be a problem - for example that Sil1136 you've mentioned is not stocked by Mouser nor DK as far as I can tell, so it might as well don't exist for practical purposes.

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 02, 2021, 07:33:06 pm
content: The Sil1136 is available at Digikey:https://www.digikey.fr/product-detail/fr/SII1136CTU/220-2183-ND/6596585The only transmitter I coud find at Mouser is the TDA19988, but it's much more limited - it can do Full HD, but not 4K.But yes anyway, not sure what you would do with 4K@60 on such a board? That goal may be a bit too much.

author: BrianHG
author_rank: Super Contributor
timestamp: March 06, 2021, 11:44:54 am
content: DDR3 update:https://www.eevblog.com/forum/fpga/fpga-vga-controller-for-8-bit-computer/msg3497050/#msg3497050