New FPGAs from Renesas - Page 1
Forum section: electronics / general

author: ataradov
author_rank: Super Contributor
timestamp: November 18, 2021, 06:46:06 pm
content: Renesas is releasing new FPGAs via Dialog Semiconductor that they've acquired some time ago.Here is a press releasehttps://www.renesas.com/us/en/about/press-room/renesas-enters-fpga-market-first-ultra-low-power-low-cost-family-addressing-low-density-high-volumeQuoteQuoteQuoteI wonder if they plan to make them easily accessible to general public. Neither Dialog or Renesas were particularly hobby-friendly.

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 18, 2021, 07:32:17 pm
content: They could "compete" with the Lattice iCE40 series for instance (more precisely, iCE40 LP.)Curious to see more.

author: ataradov
author_rank: Super Contributor
timestamp: November 18, 2021, 07:39:24 pm
content: It all really depends on the availability of tools and documentation to common public. Lattice is very good in this respect.But "Winning Combinations" suggest that marketing team was heavily involved, so in reality things may not be as great as described.

author: DiTBho
author_rank: Super Contributor
timestamp: November 18, 2021, 08:18:58 pm
content: or vhdlor nothing

author: mon2
author_rank: Frequent Contributor
timestamp: November 18, 2021, 09:26:38 pm
content: Cool. Download the latest toolchain to start developing with the FPGA. Have emailed our local rep @ factory for more details. Unless protected under NDA, will share the details once received.See attached from the latest tool just downloaded.

author: ataradov
author_rank: Super Contributor
timestamp: November 18, 2021, 09:49:25 pm
content: Yep, works with Linux too. Supplied as a normal package, no node locks or anything like this. Download form accepts bogus info, including email.If the devices are indeed cheap and available this will be a very interesting device.And synthesis is done with Yosys. This is great!The default 16-bit PWM module synthesized and reports 73 MHz as a maximum achievable frequency. This would require a bit of poking around, but it looks like the performance is close to similar lattice devices.Not a huge fan of a separate VDDIO/VDDCORE supplies. I guess as long as there are no stupid sequencing requirements.

author: ataradov
author_rank: Super Contributor
timestamp: November 18, 2021, 10:12:43 pm
content: One thing I can't figure out is the package. I really hope it is not some weird proprietary nonsense. There seem to be 24 pins, but presence of pins 7/GrP2, 8/GrP1 and 9/GrP0 makes me suspicious.Although device picture seemingly shows QFN-24 and the dimensions are shown as 3x3 mm, which matches QFN-24-0.4mm.Also, in the part selector (where you can only select one part for now), it says that it is an OTP device. I assume it is possible to load SRAM configuration many times though the interface and only embedded memory is OTP, but still sounds like a limitation. Looking at other devices, there will probably be an MTP version.

author: nctnico
author_rank: Super Contributor
timestamp: November 18, 2021, 10:28:54 pm
content: These devices look extremely interesting and the tools not needing any node locked license nonsense is a big plus. Any support for VHDL?

author: ataradov
author_rank: Super Contributor
timestamp: November 18, 2021, 10:34:15 pm
content: Yosys only fully supports Verilog. There is some work on VHDL, but I'm not fully sure of its status, but I'm sure it is not production ready. And since they are using Yosys, I would not expect VHDL. I see no obvious mentions of VHDL in the IDE anywhere.But the devices are not that complicated, you can't write too much code anyway.The tools look great. Clean and fast. For now this looks like a beginner-friendly IDE that also does not limit professionals should look like.Although just like with Yosys workflow for Lattice, I see no way to specify constraints. It looks like it the the case of "you get what you get".

author: tszaboo
author_rank: Super Contributor
timestamp: November 18, 2021, 10:40:43 pm
content: I'm going to guess:- NDA required- not available from Digikey, Mouser or anyone- No license fee, but yiou have to sign up for the free license- 2/3 row flipchip BGA- Pricing based on how much you want it

author: ataradov
author_rank: Super Contributor
timestamp: November 18, 2021, 10:53:25 pm
content: NDA for what? We are already playing with the IDE, it is free to download and it generates bit files just fine. The devices are too small to have some extensive library of IP that needs to be licensed.The package is QFN-24 for the first device that is supposed to be available.It is also the best IDE I've seen from any FPGA vendor. And given yosys workflow, I assume command line would not be a problem either.

author: YurkshireLad
author_rank: Frequent Contributor
timestamp: November 19, 2021, 01:33:33 am
content: I know next to nothing about FPGAs, but I'm very interested in these. It'll be a great entry point for me if they turn out to be half usable with a good tool chain. Exciting!

author: EEVblog
author_rank: Unknown
timestamp: November 19, 2021, 01:57:39 am
content: Who do I have to contact to get one of these kits?EDIT: Found an old contact at Dialog who wanted to do sponsored content on the blog, have asked them about the dev kit.

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 19, 2021, 02:04:52 am
content: Quote from: ataradov on November 18, 2021, 10:53:25 pmDoes it really use yosys? That'd be the first commercial tool doing this that I know of.

author: ataradov
author_rank: Super Contributor
timestamp: November 19, 2021, 02:07:59 am
content: Quote from: SiliconWizard on November 19, 2021, 02:04:52 amYep. And it is not some rebranded stuff, it says it everywhere in the logs.I bet they did not want to bother inventing tools for small FPGAs like this. Too much effort for too little benefit.

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 19, 2021, 02:22:46 am
content: Quote from: ataradov on November 19, 2021, 02:07:59 amThat's interesting. And it's not really about inventing tools either: a lot of vendors actually use Synopsys Synplify for synthesis - so they do not design their own synthesis tool. Some have - XIlinx has XST, for instance - while others don't (IIRC, but I haven't used that in a few years, Actel/Microsemi only had Synplify), and yet some others have both (Lattice offers both their own tool, LSE, and Synplify...)It probably has a lot to do with licensing and cost reasons. Synplify is not free.Now I wonder what tool they use for place-and-route. Is this nextpnr (the "de facto" friend of yosys), or is it their own tool?

author: ataradov
author_rank: Super Contributor
timestamp: November 19, 2021, 02:32:00 am
content: Quote from: SiliconWizard on November 19, 2021, 02:22:46 amThey use something called "eda-palcer". The tool does not accept any standard version or help parameters (-h, --help, -v), saying "Incorrect Input" and does not print any information when launched. So I assume it is something custom.

author: Cerebus
author_rank: Super Contributor
timestamp: November 19, 2021, 02:45:23 am
content: Quote from: ataradov on November 18, 2021, 10:53:25 pmDepends what they use for place and route, and bitstream generation. Theycouldhave made thosenoncommand line accessible - it would be stupid with yosys in front, but I've seen dumber mistakes made. It would be a shame have they gone down that route, and on the flip side it would be very cool if they've also leveraged NextPNR or similar for the place and route and just not mentioned it. (Literally immediately before I read the above and typed this I've been bashing away on an iCE40, all with the open source tool chain without a vendor tool in sight. Bliss, edit the source, save it, type "make prog" and hit the reboot switch once it's finished flashing the eeprom.)Edit: crossed with Alex's post but can't be bothered to edit.

author: ataradov
author_rank: Super Contributor
timestamp: November 19, 2021, 02:48:23 am
content: The placer is a standalone tool, but it does not accept any random parameters, and in the logs they don't show what parameters they are supplying. But I'm sure this is not out of malice, the tool is just new. It would not be too hard to figure that out anyway - just make a dummy tool that prints all the arguments.I did the tool, and it looks like they are trying to hide something. The tool takes two parameters - one encrypted looking string and then a number:Code:AAABqnjafY1BS8MwGIaj4tmDuJOg4EUPaZP5C7IsdqFZGrIUttPHdKkWNltYhf58s5nepIeH9/u+9yFBCE0QQteBp8BV4DnmS+A+cBF4jDnsDzFvY05i3gUuAzenN7Df1VX61Rx8ut37Pq3az236/lPvd9D5Y5d2hzY5KbhqR6w3kzGaA+1pUrW4bkbUuoFj6z+g/k66vsNCs5kSMJNu5axgSyhKZ0oHbC3pWAnccjIIC5ktYC70SroNGMZzqTP6bymLoSeYqxx4oXlprdAOCuMoNopxAUzPwVnJFNjwoyDYaBsP0okwFo6pKcFLtv4zzudXQn4BAyBssQ==and 23111.The string is the same for the same inputs though. And this string includes full paths. So running the tool from a completely different directory with this string as a parameter successfully produces the bitstream file.

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 19, 2021, 02:58:06 am
content: Well, now I'm a little less surprised, then...

author: ataradov
author_rank: Super Contributor
timestamp: November 19, 2021, 03:05:41 am
content: I hope they are doing it for the sake of not having to deal with encoding of slashes in the path for different OSes or something like this, and not some evil reason. I really see no point in hiding that stuff, since all you have to do is run the IDE once on a specific PC with a specific path location and you will get the string for the Makefile.But also, if those devices are available, there will be support added to open source tools.

author: asmi
author_rank: Super Contributor
timestamp: November 19, 2021, 03:07:05 am
content: Quote from: ataradov on November 19, 2021, 02:48:23 amThis string looks like a base64 encoded binary data. So it could be just a bunch of parameters passed into the tool. I've seen this approach used when you want to pass some complex data structure which does not easily map to a regular parameter string.

author: ataradov
author_rank: Super Contributor
timestamp: November 19, 2021, 03:08:12 am
content: Yes, but all base 64 decoders I tried fail to decode it. I have not tried too hard though.Changing a single number in the settings results in a lot of changes in the output, but not entire output is changing. And changes are in chunks spread over the string.And the number changes too, so it might be some sort of check sum, but the tool just ignores it, any number or string works as a second parameter. It just must be present.

author: asmi
author_rank: Super Contributor
timestamp: November 19, 2021, 04:01:24 am
content: These parts would be great as a system controller for my FPGA boards. Right now I have to use micros, but they are overkill as the only thing I need from them is to bang in some initialization data via I2C or SPI to PMICs, and control power rail sequencing. I hope they will make them available in reasonable packages, like 0.8+ mm BGA with say 40-50 GPIO split into two Vccio banks and the rest for power/gnd. Something like a full-matrix 64 ball (8x8) BGA would be ideal for my needs.

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 19, 2021, 05:33:10 pm
content: The smallest iCE40 and MachXO2/3 from Lattice are good fits for similar applications. It's not like the products don't exist yet.

author: YurkshireLad
author_rank: Frequent Contributor
timestamp: November 19, 2021, 06:10:40 pm
content: Quote from: SiliconWizard on November 19, 2021, 05:33:10 pmGood to know - there are so many out there it's hard to know what to look for.

author: mon2
author_rank: Frequent Contributor
timestamp: November 19, 2021, 06:22:53 pm
content: ICE40UL1K is nice but requires via-in-pad PCB layout (HDI) to bond out every ball in the WLCSP package. This can be very expensive, real fast. To conserve on the I/O pins, the internal OTP must be used - much like the Renesas FPGA.Renesas is stating their device will be QFN-24 which then allows to be friendly with JLCPCB specs and reduced costs.Gowin / Efinix have internal flash to boot your custom firmware. Respectively, could be used for upgrades out in the field after the product ships.It will be nice if Renesas documents how their kit deploys the SRAM spec for development purposes. The same method could be used in a similar fashion for unlimited upgrades.

author: asmi
author_rank: Super Contributor
timestamp: November 19, 2021, 07:07:19 pm
content: Quote from: SiliconWizard on November 19, 2021, 05:33:10 pmNot even close. Their packages options are TERRIBLE. I want something like 7x7 mm 64 ball BGA 0.8 mm pitch. There is nothing in their lineup of that kind of size - either you get much smaller part (with super-expensive HDI tech required to use them, no thank you), or you go for a ridiculous overkill of 256 ball version. There is also ICE40HX8K-BG121 in BGA-121 0.8 mm pitch package, but it's been out of stock everywhere I looked for a while. So no dice here either. Leaded packages are not good for me because they take too much space, and space on 6+ layer boards is expensive so I'd rather not waste it if it can be helped.Right now I use STM32H723VGH6 MCUs (which is the gross overkill) because they were the only ones I was able to get my hands on at the time. Hopefully availability will improve soon, so that I will be able to use something more fitting for my needs, but for now I'm forced to use whatever I can manage to procure.

author: mon2
author_rank: Frequent Contributor
timestamp: November 19, 2021, 10:07:52 pm
content: @asmi - feel your pain. As we are somewhat still new to the world of FPGA devices, there is a high risk to bed down with a single vendor. Often finding documentation issues (errors) as we dig deeper into the development cycle. Respectively we know that we will not get it right on the first try. HDI quotes are crazy high - for the WLCSP project, we had quotes of $1200-$1800 USD from China for 30 PCBs. Finally settled on one repeat PCB shop we have used with success who considered the HDI process as a norm and we paid ~ $600 for the HDI PCB lot. Much better but still quite high as compared to standard 4L pcb designs.You may want to review the QFN packaged Gowin devices with the hard M3 CPU (about 4800 LUTS). Their package can be deployed with JLCPCB specs which will be a huge cost reduction. Contact Edge Electronics (USA) for the best pricing but have the goods shipped directly from Asia to you in Canada. We did this from their HK warehouse of Gowin to avoid the Trump tariffs on Chinese goods. For our pending consumer space widgets, the QFN package is the wisest choice for us.

author: asmi
author_rank: Super Contributor
timestamp: November 20, 2021, 01:31:00 am
content: Quote from: mon2 on November 19, 2021, 10:07:52 pmBeing vendor-independent is a noble goal, but unfortunately it's not very practical especially when you deal with larger devices (say 50K+ LUTs) because you will be forced to use device-specific primitives to utilize the full potential of these devices. I use large-ish Xilinx devices as my main processing chip because I've learnt them well over years, and because they provide the best development resources on the market, including tons of free IPs which others charge big money for.However here we are talking about smaller secondary utility devices, requirements for them are not very high, so here it should not be a big problem to switch between device families and vendors.Quote from: mon2 on November 19, 2021, 10:07:52 pmThat is another reason why I prefer to stick with devices I worked with in the past - I've already invested time and money into figuring these things out, at the very least I know that regardless of the specifics of a board, I can be certain that I would at least be able to connect to and program device, and it will come online. So this way I simply retire a lot of risks related with getting some of the basics of connecting FPGA right, and so I reduce area where I can screw things up to peripheral connections. And these risks can often be retired by building a prototype extension module for some of my FPGA devboards (I always try to design a devboard for every major FPGA I plan to use in such a way as to cover as much of a ground as possible for porential peripheral connections).So basically, as counterintuitive as it sounds, sticking to devices you are familiar with saves money.Quote from: mon2 on November 19, 2021, 10:07:52 pmCan you please share that fab? I have few ideas about few breakout-style boards for a few of WLCSP-class devices, so I'm curious what would it cost to have it implemented.Quote from: mon2 on November 19, 2021, 10:07:52 pmThanks for the advice - I will take a look. Like I said, I prefer working with reasonable-pitch BGAs because they are much more space-efficient, which both saves money on PCB manufacturing and makes my final devices more compact. So if they have something that would suit my requirements - that would be great. Because using $20/pop MCU where a $0.5 would do (if only they can be actually procured) feels very wrong to me, but sometimes you've gotta do what you've gotta do...

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 20, 2021, 01:40:31 am
content: Yes, unfortunately Lattice parts either come in large packages or very-fine pitch ones.There are some QFN packages, but the number of IOs may be too limited for a particular use (I think their largest QFN is 48 pins?) So of course all depends on your particular project... Now when you have nothing else available with similar features and price range, you may go for the ~200-pin, 0.8mm BGAs, even when that means using only 1/3 of the pins...I'm sure curious to see when those new chips from Renesas will be available, and if they will be at the prices and packages that have been announced...

author: mon2
author_rank: Frequent Contributor
timestamp: November 20, 2021, 01:41:18 am
content: Sure..for fair prices on HDI boards, contact Daphne. Her details are posted here:https://www.eevblog.com/forum/manufacture/euna-vs-chinese-difference-between-servicesproducts/For larger density FPGA devices, review the new Titanium line from Efinix. Contact Roger or Rochelle for more details. To be in stock in a few weeks at Digikey.

author: asmi
author_rank: Super Contributor
timestamp: November 20, 2021, 01:45:06 am
content: Quote from: SiliconWizard on November 20, 2021, 01:40:31 amUnderutilizing IO resources is one thing (and I'm not that worried about that), but they are also physically large, which kind of defeats the very purpose I do for BGAs in the first place (which is saving space).Quote from: SiliconWizard on November 20, 2021, 01:40:31 amSo am I. I'm sure the prices they've quoted are going to be for bulk purchases, but even if they will be $5 a pop for singular quantities, that would still be a net win for my purposes.

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 20, 2021, 02:02:12 am
content: Quote from: asmi on November 20, 2021, 01:45:06 amCertainly, those packages are 14x14 mm... But my point here is not about size, it's just that at the moment, if you need this kind of small FPGAs, at a low price point (a couple $) and with *low* power consumption, you don't really have many other options, that I know of anyway. Sure those new FPGAs may become a game changer, but until then, if you need low cost and low power, you may have to sacrifice on size... (Oh but if anyone knows of similar parts from other vendors, I'll gladly have a look.)

author: ali_asadzadeh
author_rank: Super Contributor
timestamp: November 21, 2021, 07:56:37 am
content: Guys has anyone get these? any price info would be nice.

author: ataradov
author_rank: Super Contributor
timestamp: November 21, 2021, 08:56:09 am
content: I doubt they will be available to general public for at least a year. I would not ge too excited. And getting retail price in current conditions is even more problematic.

author: hans
author_rank: Super Contributor
timestamp: November 27, 2021, 08:58:44 am
content: Quote from: SiliconWizard on November 20, 2021, 01:40:31 amCrosslink-NX has a 72QFN package. Comes as a 17K or 39K 4-input LUT FPGA, with additional large block RAM similar to ice40. The logic density gets it up there with some of the ECP5 stuff (I also believe similar architecture), but without the BGA stuff. Unfortuntely.. I think they're also out of stock.Anyway, these small FPGAs also attract my attention. Lattice also has low quiescent power listed for their MachXO(2/3) series of FPGAs in freeze mode, especially on the low logic density ones. I'm actually looking at a new application that would benefit from an (nearly) always-on FPGA with some amount of logic (say 1-4K LUTs) to act as an experimental IOT design. However, for the larger Lattice chips, their quiescent current ramps to nearly 100uA.20uA quiescent supply current at e.g 1 or 1.1V would do the job. But I'll have to see (or look up) if that also is a figure for only their smallest FPGAs (I believe their datasheet was inconclusive at best about it)

author: EEVblog
author_rank: Unknown
timestamp: November 29, 2021, 11:54:21 am
content: Quote from: ataradov on November 21, 2021, 08:56:09 amThey got back to me about the dev kit.They are rare as hens teeth and they could possibly loan me one for a short time if I really wanted it. But I said I'll wait until it's generally available otherwise there isn't much point doing a video on it on something no one can get.

author: nctnico
author_rank: Super Contributor
timestamp: November 29, 2021, 05:05:31 pm
content: Quote from: EEVblog on November 29, 2021, 11:54:21 amA teaser which shows actual hardware would be nice

author: ataradov
author_rank: Super Contributor
timestamp: November 29, 2021, 05:14:34 pm
content: Quote from: nctnico on November 29, 2021, 05:05:31 pmIt is just an IC in QFN-24 package. I doubt the kit would be too exciting. Probably just a simple breakout board with a couple voltage regulators and an LED.

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 29, 2021, 05:42:31 pm
content: Quote from: ataradov on November 29, 2021, 05:14:34 pmIndeed, and with such a package, you actually have Lattice products. So... (well, the MachXO2 is available in 32-pin QFN and ice40 as 48-pin QFN...)One of the points of asmi was that anything with 64 pins or beyond was difficult to work with in Lattice products due to pitch. Apart from a cute kit indeed, there would be nothing much to see here.

author: ataradov
author_rank: Super Contributor
timestamp: November 29, 2021, 06:21:15 pm
content: The only thing that makes me excited about this specific product is simplicity and ease of use. Unlike most FPGAs where dealing with the IDEs is the whole ordeal, this one is very simple and straightforward to use.If the price ends up being good, it may be just a good device for a bit of programmable logic.But yes, it is not revolutionary in any way. And we'll have to see real performance.

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 29, 2021, 06:30:04 pm
content: Quote from: ataradov on November 29, 2021, 06:21:15 pmI don't want to sound like a Lattice salesman - I'm absolutely not affiliated in any way - but both Lattice Diamond and Lattice Radiant (for some of the newer iCE40 and Certus parts) are very simple and straightforward to use. At least compared to Quartus or Vivado or...

author: nctnico
author_rank: Super Contributor
timestamp: November 29, 2021, 06:41:51 pm
content: Quote from: ataradov on November 29, 2021, 05:14:34 pmAt least it shows the chip is real and not vapourware. And Dave could give the software a whirl. I hope VHDL support gets added quickly or maybe it already is.

author: ataradov
author_rank: Super Contributor
timestamp: November 29, 2021, 06:59:44 pm
content: Quote from: SiliconWizard on November 29, 2021, 06:30:04 pmNot at all. I too like Diamond the most from all. It is still a node locked full blown IDE. And every year you have to ask them for the license. In this case "IDE" is more like Arduino compared to big IDEs for MCUs. It is bare-minimum that just works. And super fast synthesis times are also pretty cool. It is probably not something you want for a device with more than 1K LUTs though. So I don't know how it will scale.Also, as I noted with yosys for ICE40, there is seemingly no way to specify any timing constraints. So, I'm not sure how that would work in practice. I'd be interested to try though.Quote from: nctnico on November 29, 2021, 06:41:51 pmI would not wait for VHDL in this case.

author: nctnico
author_rank: Super Contributor
timestamp: November 29, 2021, 07:24:09 pm
content: Without VHDL they'll miss a big chunk of the market. Gowin also added VHDL to their tools. I'm certainly not going to mess around with Verilog.

author: ataradov
author_rank: Super Contributor
timestamp: November 29, 2021, 07:40:50 pm
content: The devices are so small and have so little going for them that the language does not really matter. Some people will not use it out of principle or preference, but I don't think it will affect industry acceptance at all.

author: asmi
author_rank: Super Contributor
timestamp: November 29, 2021, 08:13:57 pm
content: Quote from: nctnico on November 29, 2021, 07:24:09 pm2.5 stubborn engineers are not a big chunk of a market.

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 29, 2021, 09:51:14 pm
content: As explained in other threads about yosys, VHDL has been supported for a while using ghdl-yosys-plugin. I don't know if their distribution of yosys includes it, but I would suspect it does. If not, it should be doable to add it yourself.

author: nctnico
author_rank: Super Contributor
timestamp: November 29, 2021, 10:22:02 pm
content: Quote from: ataradov on November 29, 2021, 07:40:50 pmSee the Gowin example...They have similar sized FPGAs and yet they did add VHDL. And why should I suddenly use a different language for a small device? It doesn't make sense. I'm not going to program in ASM because a microcontroller has 2k of flash memory and use C on a microcontroller which has more. It is not about principles but it is simply not efficient in terms of time spend on knowing several languages (or try to come up with something half baked in a language you barely know).@SiliconWizard: That looks promising but it says the plugin is still experimental.

author: julian1
author_rank: Frequent Contributor
timestamp: November 29, 2021, 10:22:30 pm
content: Quote from: ataradov on November 29, 2021, 06:59:44 pmDo you mean per net/pin? icetime will report global propagation time, and max clk speed of the design.

author: ataradov
author_rank: Super Contributor
timestamp: November 30, 2021, 01:19:16 am
content: It will report maximum frequency, but there is no way to specify the limits so that design can be driven by those limits. And there is no way to specify desired setup/hold times. You just get what you get.

author: rstofer
author_rank: Super Contributor
timestamp: November 30, 2021, 02:39:29 am
content: Quote from: EEVblog on November 29, 2021, 11:54:21 amIt seems to me that the most important selection criteria is development software with an unlimited license. I went through the debacle when UCSD canceled the Pascal licenses and it was ugly. I stayed away from Atmel for years because the terms of the license included a clause where they could cancel the license at any time for any reason or no reason at all. I'm not going to spend any time or money on a device that uses a toolchain that can be yanked at any time.The next criteria would be the availability of several levels of development boards - exactly like what I can get from Digilent. I can get an Artix 7 board in several flavors with varying amounts of IO and gadgets. Personally, I want a LOT of gadgets: 7 segment displays, pushbuttons, slide switches, GPIO and, by all means, onboard programming via USB.In a distant third place is price. Yes, the boards I select are expensive but I'm only going to buy one (maybe two) and they can be serially reused for future projects. I look at the cost as 'future proofing'. But that's just me.Yes, I'm stuck in the Xilinx camp but I have played with the Lattice ICE40HX1K-STICK-EVN and it's a nice, albeit small, board for $49 (Out Of Stock at DigiKey).https://www.digikey.com/en/products/detail/lattice-semiconductor-corporation/ICE40HX1K-STICK-EVN/4289604I prefer the Digilent A7 board even though it is 4 times as expensive. It has more than 4 times the the utility as well and I buy the 100T variant.https://digilent.com/shop/boards-and-components/system-boards/fpga-boards/I also have the Basys 3 and Arty boards along with the Cmod A7 but the Cmod is only available in a 35T variant. I like the virtual dumpster idea and prefer the larger chips even though I don't really need them.I seem to be stuck in Xilinx land...As I said above, price is my 3rd place selection criteria.

author: asmi
author_rank: Super Contributor
timestamp: November 30, 2021, 05:36:25 am
content: I use Xilinx chips as a main processing device as well, but here we're talking about small auxiliary chips for supporting the main one, like bootstrapping programmable DC-DC converters, controlling power-up/power-down rail sequencing, generating reset pulse, things like that. You needs must be really modest for these devices to work as main processing unit.

author: ebclr
author_rank: Super Contributor
timestamp: November 30, 2021, 05:52:12 am
content: Forget Renesas, The only thing they do well, it's ignore you

author: DiTBho
author_rank: Super Contributor
timestamp: November 30, 2021, 10:08:06 am
content: Very bad experience with their MPUs

author: gnuarm
author_rank: Super Contributor
timestamp: December 07, 2021, 03:33:50 pm
content: Quote from: ataradov on November 18, 2021, 09:49:25 pmThen you should stick to PLDs. I don't know of any complex device in the last 20 years that wasn't dual supply or more.

author: gnuarm
author_rank: Super Contributor
timestamp: December 07, 2021, 03:47:33 pm
content: Quote from: tszaboo on November 18, 2021, 10:40:43 pmPeople seem to be keying in on Renesas and ignoring Dialog. Dialog has been selling the GreenPak programmable device line for some time now and while their business model is for them to supply production quantities by preprogramming the chips, they have always been supportive of users. You can buy devices from Mouser, so I expect to see the FGPAs from Mouser as well.Of course pricing is based on quantity. Who doesn't do that??? We will see what packaging they provide. If they are shooting for the mobile device market where miniaturization is king, I expect they will be in flip chip, but they sell the GreenPak devices in QFN and also TSSOP, so we may be surprised by packaging supporting simple soldering and low cost board fab.

author: gnuarm
author_rank: Super Contributor
timestamp: December 07, 2021, 03:53:55 pm
content: Quote from: ataradov on November 19, 2021, 02:07:59 amTools are the expensive part of selling FPGAs. Only the big suppliers write their own tools. Everyone else licenses synthesis software which costs them for every copy they supply. Now you know why many companies don't want to support no-profit hobbyists.Has anyone looked at simulation? I'm not familiar with Yosys, but I assume that is just synthesis. Are they also supplying open source simulation or are you on your own to figure that out? When using Gowin they punted on the simulation.

author: ataradov
author_rank: Super Contributor
timestamp: December 07, 2021, 04:32:03 pm
content: Quote from: gnuarm on December 07, 2021, 03:33:50 pmMAX10 from Intel/Altera, Lattice XO2.MAX10 specifically has a version with internal core voltage regulator and with external. And that's a good way of doing things. While some designs may need flexibility with bank voltages and core supplies, many are just strictly 3.3V and having a convenience of dealing with just one supply is nice. And all they need to do for this is include an LDO inside the device. It may need external passives, that's fine, of course.

author: nctnico
author_rank: Super Contributor
timestamp: December 07, 2021, 04:36:09 pm
content: Quote from: gnuarm on December 07, 2021, 03:53:55 pmYou can use GHDL which works OK. I did run into funny effects though when assigning a clock to a different signal; in that case GHDL likes to delay the new signal as well as if it is registered by the clock. But this could be a bug in an older version.

author: woofy
author_rank: Frequent Contributor
timestamp: December 07, 2021, 04:42:24 pm
content: Quote from: gnuarm on December 07, 2021, 03:53:55 pmyosys for synthesis, nextpnr for place n route.for verification I use iverilog/vvp and gtkwave.

author: gnuarm
author_rank: Super Contributor
timestamp: December 07, 2021, 04:42:43 pm
content: Quote from: asmi on November 19, 2021, 07:07:19 pmSo you want a Goldilocks BGA part. Fair enough. We all want what's optimal for our work.QuoteI've never considered that BGAs are any better for board space than leaded parts. It is very hard to place BGAs close to one another as they often require space for breakout and routing. A leaded part typically has room under the part to help breakout and routing, so little extra room is needed on the board. I've had to consider replacing a 20 pin TSSOP with a 24 pin QFN and it's not really much different, especially with a grounded thermal pad. The part becomes a roadblock for routing. BGAs are often the same sort of thing since the inner balls require vias under the part to break out. So even if they are smaller than a similar leaded part, they end up using similar board space.QuoteI'm not familiar with this concept... MCUs outside of an FPGA. What do you put IN your FPGAs? lol

author: gnuarm
author_rank: Super Contributor
timestamp: December 07, 2021, 04:59:49 pm
content: Quote from: hans on November 27, 2021, 08:58:44 amI don't often care so much about "freeze mode" specs. I'm looking for low quiescent power as well as low per MHz power so clocking at low speeds gets you about quiescent power levels. Some logic in various designs can run from a 32 kHz clock with virtually no dissipation... if the chip properly supports it. Things like "freeze mode" typically require the entire chip to be shut down.QuoteI believe some of the newer Lattice iCE40 devices get close to that number, less than 50 uA anyway. The original SiliconBlue 65 nm devices had below 100 uA quiescent current and the iCE40 parts were supposed to be even lower, but when Lattice bought them and they moved to 40 nm the current went up. Don't know if that was because they were never going to be able to achieve the really low currents they talked about or if Lattice imposed some restriction that required the number to be higher. Heck, it could be as simple as the parts were exactly what they expected, but Lattice wanted more margin in the spec so it wouldn't be the cause of rejecting any parts or maybe they no longer needed to bother testing that spec with a relaxed figure.

author: asmi
author_rank: Super Contributor
timestamp: December 07, 2021, 05:07:00 pm
content: Quote from: gnuarm on December 07, 2021, 04:42:43 pmWell just compare 64/100 pin QFN/QFP package size with BGA with the same ball count, and you will see the difference very clearly. It's even worse for higher pin count.Quote from: gnuarm on December 07, 2021, 04:42:43 pmFPGA is the main processing device, but a board often requires a sort of system controller which would orchestrate all HW pieces together - like programming DC-DC converters, power rail sequencing, cooling management, etc., which are either impossible or impractical to implement inside FPGA. FPGA itself typically does the actual functionality - video processing, DSP, etc - whatever is the main function of a board.

author: ataradov
author_rank: Super Contributor
timestamp: December 07, 2021, 05:12:02 pm
content: Quote from: gnuarm on December 07, 2021, 03:53:55 pmI just tried. They have simulation functionality in the "IDE", but I could not make it work. I'll have a closer look.It asks you to create a test bench to run the simulation, but after that nothing happens. I don't see any outputs or waveforms.At the same time I noticed one more thing. Your code is not actually stored as files. It it stored in the same "encrypted" form as a string inside the main project file. So the whole project is just one file, including test benches. This further shows that they are not going after "grown up" FPGAs.

author: gnuarm
author_rank: Super Contributor
timestamp: December 07, 2021, 05:37:47 pm
content: Quote from: ataradov on November 29, 2021, 06:59:44 pmI've used the Diamond software for a long time and have a current product I have to support that was developed with it. But didn't they end support for the older software or something? I recall that about a year ago I downloaded my last possible license file and I suppose that is running out about as we speak. I have a new computer now so it probably won't work anymore anyway. I think it was locked to the hard drive ID which I want to say can be rewritten.This is the sort of crap you get into with licensed software even if they give it away.Quote from: ataradov on November 29, 2021, 06:59:44 pmI would have said the same thing about Gowin, but their VHDL came out and works fine. But I suppose they were at least talking about it coming soon. Does Dialog mention any plans for VHDL? I don't think they ever considered it for their GreenPak parts.

author: gnuarm
author_rank: Super Contributor
timestamp: December 07, 2021, 05:42:51 pm
content: Quote from: ataradov on November 29, 2021, 07:40:50 pmIt depends on the markets they are after. The telecomms market is Verilog pretty much 100%. Some European markets and US defense are VHDL. I doubt this will get much use in the US defense market no matter what. I don't know enough about European VHDL use to know if there might be much market acceptance with this part or not.While I would not avoid a part because of the language support, I've never had to use anything other than VHDL except for a short stint working at a telecomm test gear manufacturer. Describing RTL functionality doesn't take much knowledge of either language.

author: gnuarm
author_rank: Super Contributor
timestamp: December 07, 2021, 05:52:00 pm
content: Quote from: ataradov on December 07, 2021, 04:32:03 pmI don't know about the Altera devices, but the Lattice parts are dual voltage, they just allow you to use internal regulators for the core voltage or not. I have a design using the XP devices and when I needed to switch from a single voltage part to a dual voltage part I found out they are the same die. They add a bond wire that tells the part to enable/disable the regulators and you have to twiddle a bit in the programming files so the programmer recognizes the ID which also changes a bit.My point is you might only need one regulator voltage, but the parts have at least two sets of voltage pins and sometimes more.

author: gnuarm
author_rank: Super Contributor
timestamp: December 07, 2021, 05:57:45 pm
content: Quote from: nctnico on December 07, 2021, 04:36:09 pmNot sure what you mean by "assigning a clock to a different signal". If you mean literally just writingCode:clk1 <= clk2;in VHDL that will create a delta delay which will in essence be a new clock domain slightly out of sync with the first. So register outputs will be updated on clk2 before clk1 gets it's edge and cause unexpected results.This is not a bug, it's a feature... really!

author: ataradov
author_rank: Super Contributor
timestamp: December 07, 2021, 06:02:02 pm
content: Quote from: gnuarm on December 07, 2021, 05:52:00 pmAnd that's fine. I just don't care to have more power supplies on the board that need to be sequenced correctly for things to work.

author: gnuarm
author_rank: Super Contributor
timestamp: December 07, 2021, 06:03:40 pm
content: Quote from: asmi on December 07, 2021, 05:07:00 pmThat's my point. If you only compare package size you aren't doing a fair comparison. The entire area around the BGA used for breakout routing needs to be considered. The BGA ends up being a big road block to other routing while the QFP has room under it for vias, etc.Quote from: asmi on December 07, 2021, 05:07:00 pmI tend to design systems where the FPGA is the SoC doing all the work. Besides, it was a rhetorical question. Didn't you see the lol?

author: gnuarm
author_rank: Super Contributor
timestamp: December 07, 2021, 06:06:51 pm
content: Quote from: ataradov on December 07, 2021, 05:12:02 pmThat makes no sense. You are saying the test bench file is not stored as text? Or that all of the source files are not stored as text? Either way there must be a way to have text files instead. I can't imagine any company being willing to write IP and not be able to port it to some other device if these parts aren't suitable for any of a variety of reasons down the road.

author: gnuarm
author_rank: Super Contributor
timestamp: December 07, 2021, 06:11:47 pm
content: Quote from: ataradov on December 07, 2021, 06:02:02 pmThe board I designed with the Lattice part was designed for either chip. So it has a second power regulator, a tiny 6 pin package and ways to wire up either version. This has served me well allowing me to use whichever version of the part was available. At this point both versions are going away, so I'm building the last 10,000 units. The first 2,000 of these are dual voltage and the last 8,000 will be single voltage. Arrow is the last source of these parts and after some 5 or more years they are reaching the point of running out... and prices are going up.

author: ataradov
author_rank: Super Contributor
timestamp: December 07, 2021, 06:15:11 pm
content: Quote from: gnuarm on December 07, 2021, 06:06:51 pmNothing is stored as text. The whole project is just one file that contains everything. I think this supports their business model where you do the design, send it to them and they ship you the programmed devices.There is no way to edit text files. You get the IDE and that's it.Again, this feels more like Arduino that any other FPGA IDE. This is designed for very simple things.So, yes, the whole thing makes less and less sense. Hopefully this device will just be supported by open source tools to make it usable.

author: asmi
author_rank: Super Contributor
timestamp: December 07, 2021, 06:36:38 pm
content: Quote from: gnuarm on December 07, 2021, 06:03:40 pmOf course I am doing a fair comparison. Typical BGA-64 only requires one or two signal layers for a full breakout, as the rest of the balls (which typically are in the middle) only connect to the power/ground planes, heck 1 mm 196 ball BGA can be fully routed on 2 signal layers even with generous 0.1 mm tolerances (see a project in my signature for example of that), and entire breakout almost always fits underneath BGA so it's more compact (nevermind other advantages like SI) than QFP/QFN (especially the latter as it typically has an exposed pad underneath leaving no space for any routing, which leads to more wasted space outside part's perimeter for signal vias to internal layers). On a 6 layer board that leaves two more signal layers for any "thru" routing. Practically I can't think of a case when I had routing issues with BGA system controllers - the part I mentioned (STM32H723VGH6) is a 100 ball 0.8 mm pitch BGA part, which can be fully routed on just two signal layers without requiring any advanced tolerances.

author: ataradov
author_rank: Super Contributor
timestamp: December 08, 2021, 03:27:03 am
content: I figured out the test bench situation. At least the Linux version simply calls iverilog for simulation. And they don't even package it with the IDE, it just calls the system one. My minimal dummy VM did not have one installed, so it failed to do anything. As soon as I installed it, it worked. It produces VCD file and automatically launched GTKWave on it. Again, the system GTKWave.It also needed VCD file to be located in the default directory.All of this starts to look more and more like amateur hour put together with sticks and sticky tape. If you are going to use OSS tools, just do it right.

author: Bassman59
author_rank: Super Contributor
timestamp: December 08, 2021, 05:13:21 pm
content: Quote from: gnuarm on December 07, 2021, 05:57:45 pmThis is entirely correct.You will get the same thing in Verilog.

author: nctnico
author_rank: Super Contributor
timestamp: December 08, 2021, 08:07:26 pm
content: But it still sucks that it behaves differently when synthesized (absorbed into a single net) versus being simulated.

author: gnuarm
author_rank: Super Contributor
timestamp: December 11, 2021, 02:43:58 am
content: Quote from: ataradov on December 07, 2021, 06:15:11 pmI would not compare this to any other IDE tool. I've never heard of one that did not store the source code as separate text files. The only exception is generators that use graphical input. That is no longer text by definition.I don't recall ever hearing that the Arduino didn't store source code as text files.

author: ataradov
author_rank: Super Contributor
timestamp: December 11, 2021, 02:51:43 am
content: Quote from: gnuarm on December 11, 2021, 02:43:58 amI compare it to Arduino in a sense of capabilities of the IDE itself. It is essentially a text editor with a few extra buttons to generate binary files.Storage of the files inside the project files makes no sense to me, but I don't think this is going to change.Basically, unless those devices are <~$1.5 / 100pcs, then it is easier to ignore them and just use Lattice.

author: gnuarm
author_rank: Super Contributor
timestamp: December 11, 2021, 02:57:40 am
content: Quote from: asmi on December 07, 2021, 06:36:38 pmI think we are going to go around in circles all day about this. You say the BGA can break out by putting vias all around under the chip and I'm saying these vias create a road block, which you aren't hearing or seeing. The QFP doesn't do that. There is room under the package to routeothersignals than the FPGA signals, so it doesn't use the entire space you are counting as "used".The board I'm shipping now uses a 100QFP which fits on the board with a few mm to spare. Signals need to route under it to get past. By using vias under the package, layers can be changed and still have room to route the signals that need to get past. With the BGA, it might be slightly smaller (a 256BGA just fits, the 196BGA is a bit smaller), but it requires vias densely packed under the part creating a traffic jam that other signals have to route around. Sure, you can use more layers, but that's the point, you have to useotherlayers and increase the cost of the PWB.With the 100 QFP there's enough room that I put three 8 element resistor packs on the other side of the board from the FPGA as well as the decoupling caps, about 8 I think. I've never seen a BGA used without significant space left open around it and nothing on the side opposite other than perhaps decoupling caps. The thermal tab of QFN packages causes the same sort of routing restrictions.

author: asmi
author_rank: Super Contributor
timestamp: December 11, 2021, 04:41:21 am
content: Quote from: gnuarm on December 11, 2021, 02:57:40 amThere is no road block just from vias as they leave plenty of space between them for 1 mm pitch (enough to route two 0.1 mm traces), unless you have enough signals to fill entire area, but in that case QFP would take more than triple the area of equivalent BGA (BGA-256 is 17x17 vs QFP-208 is 30.6x30.6, or even more if you count entire footprint, and not just the chip itself).Quote from: gnuarm on December 11, 2021, 02:57:40 amLOL - QFP 100 is going to have about half the amount of IO compared to BGA-196, and yet still take more area than that BGA. So if you would only route out about half of IO balls of BGA-196, you will have a lot of space under the chip to place all kinds of stuff. AND still end up with using less PCB space.Quote from: gnuarm on December 11, 2021, 02:57:40 amIt kind of seems to me that you haven't actually ever routed BGAs. They are very easy for routing compared to any other package with similar amount of pins/balls, again, taking into account the amount of area those other packages would take.Oh, and will haven't touched an elephant in the room - namely, horrible SI of QFP packages. That's the reason there are no DDR2 and above memory chips in non-BGA packages. So for anything more complex that LED blinkers you will have to use BGAs, which kind of makes the whole discussion moot.

author: gnuarm
author_rank: Super Contributor
timestamp: December 11, 2021, 08:47:20 am
content: Quote from: nctnico on December 08, 2021, 08:07:26 pmYes, but you just stated the distinction. The simulation has two nets and the real design has but one. This does not happen with signals passed into processes or functions, etc. This only happens when you have a signal assignment of a clock. So that should be avoided same as in the real world. An assignment should be thought of as a buffer which could cause similar problems in an actual design.I have not verified this, but if all the inputs to the same registers are also buffer delayed, you should not see this problem. The register outputs will have an extra delta delay, but that should not be a problem. That's why delta delays are there, to prevent the outputs that change from a clock from impacting any of the inputs captured by the same clock. More delta delay in an output is fine, it's the inputs you have to worry about.

author: nctnico
author_rank: Super Contributor
timestamp: December 11, 2021, 12:36:59 pm
content: Quote from: gnuarm on December 11, 2021, 08:47:20 amThat is all nice and dandy, however in some cases you have a different name for a clock in a test bench and assigning it to basically rename it doesn't work in simulation. It is just something to be aware off when creating test benches.

author: Someone
author_rank: Super Contributor
timestamp: December 11, 2021, 11:34:37 pm
content: Quote from: nctnico on December 11, 2021, 12:36:59 pmJust to derail this thread some more, when VHDL delta cycles are making pain: get yourself analias! (and then watch all your colleagues complain they don't like it).

author: gnuarm
author_rank: Super Contributor
timestamp: December 19, 2021, 12:02:22 pm
content: Quote from: nctnico on December 11, 2021, 12:36:59 pmI don't think that is the same thing. Using a name in a test bench that is different from the name in the UUT does not create a delta delay if the connection is made at the instantiation. One name on one side and another name on the other side does not constitute an assignment, so no delta delay. It's only in assignments that delta delays are created. So they are explicitly created and easily avoided.

author: nctnico
author_rank: Super Contributor
timestamp: December 19, 2021, 07:12:42 pm
content: Quote from: gnuarm on December 19, 2021, 12:02:22 pmThat is not the case if you want to mix & match some VHDL code quickly.

author: Bassman59
author_rank: Super Contributor
timestamp: December 21, 2021, 12:02:54 am
content: Quote from: nctnico on December 19, 2021, 07:12:42 pmHuh? I don't understand what you mean. What gnuarm says about port formals and actuals is correct.

author: nctnico
author_rank: Super Contributor
timestamp: December 21, 2021, 12:12:29 am
content: But it is totally besides the point. If you copy & paste some code between projects, test benches, etc, the (clock) signal names may not match. This will work for synthesis, but not for simulation.

author: gnuarm
author_rank: Super Contributor
timestamp: December 21, 2021, 01:29:14 am
content: Quote from: nctnico on December 19, 2021, 07:12:42 pmSorry, I don't know what "mix and match" means in VHDL.It is simple. Assignments create delta delays. Signal connections through instantiation or procedure calls do not. Don't assign clock signals to other clock signals unless every use of clock signals has the same number of assignments in the path. That's pretty simple, no?Maybe you are talking about using existing code that you don't look at. Yeah, that can cause all sorts of trouble. A lack of attention to detail when reusing code was what brought down an Ariane rocket if I recall.

author: gnuarm
author_rank: Super Contributor
timestamp: December 21, 2021, 01:30:04 am
content: Quote from: nctnico on December 21, 2021, 12:12:29 amI don't follow. What is different about simulation?

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 21, 2021, 02:56:54 am
content: Quote from: gnuarm on December 21, 2021, 01:30:04 amI think you guys can run in circles forever discussing this. We don't know anything about nctnico's bad experience here, but I'm willing to bet it was an ill-done test bench with assignments instead of just properly instantiating entities and passing them signals (which does not suffer from the same issue obviously), which is the right way of doing it. Maybe they just inserted some of the code under test directly in a test bench code without encapsulating in separate entities. And so needed to assign signals to make it "compile" for simulation (but not work obviously). (But yeah they could have used aliases in this case, even if this is the bad way of tackling it.)After which, the experience lingered on in nctnico's head because it was apparently traumatizing. But instead of being "traumatized" by assignments, we could wish it was an opportunity for encapsulating code in entities properly, which is neater, easier to test and easier to reuse. We can hope that's what happened, but I'm not sure.

author: nctnico
author_rank: Super Contributor
timestamp: December 21, 2021, 08:51:06 am
content: Quote from: SiliconWizard on December 21, 2021, 02:56:54 amOfcourse you can encapsulate but I usually only simulate very small pieces of VHDL. Hardly worth putting into an entity due to the amount of typing involved. And I wouldn't call it traumatized; it is just something to be aware off. When it bit me I quickly realized that it had to be related to how simulation of VHDL works. I'm just used to synthesizers absorbing the signals into a single net. I agree that using aliases would make things even more messy.Quote from: gnuarm on December 21, 2021, 01:29:14 amMix & match = throw some pieces together and make something out of it that works.

author: Cerebus
author_rank: Super Contributor
timestamp: December 21, 2021, 01:32:11 pm
content: Quote from: nctnico on December 21, 2021, 08:51:06 amUs Verilog types don't have that problem, or get repetitive strain injury from coding up a little bit of logic.

author: gnuarm
author_rank: Super Contributor
timestamp: December 23, 2021, 04:22:13 am
content: Quote from: Cerebus on December 21, 2021, 01:32:11 pmPerhaps you are not aware that VHDL has delta delays (the cause of this issue) to prevent another problem which is much worse, the logical result of clocked assignments depending on the arbitrary order of execution of the assignments. I believe Verilog doesn't use delta delays and so can have issues regarding this. Or maybe they've done something to resolve this problem?

author: BrianHG
author_rank: Super Contributor
timestamp: December 23, 2021, 04:29:18 am
content: In SystemVerilog, the 'assign' has no delta/order delays where as logic implemented inside the 'always_comb' will follow the order it is written in. At least, this is how Modelsim seems to treat the logic in a procedural always_comb decoding loop in my DDR3 multi-port selection decoder which requires the recognition of A before B to operate properly. Quartus seems to interpret the code properly as function matches my simulations while altering the order of my code in this instance will prevent cycling of my multi-port priority selection decoder.Writing such combinational logic out of order does generate 'Warnings' in Modelsim and the simulation may take values out of order in such circumstances. This does not happen with 'assigns'.

author: Cerebus
author_rank: Super Contributor
timestamp: December 23, 2021, 02:47:06 pm
content: Quote from: gnuarm on December 23, 2021, 04:22:13 amI made no comment on that,readwhat I quoted to comment on andreadthe smiley afterward.

author: nctnico
author_rank: Super Contributor
timestamp: December 23, 2021, 02:48:46 pm
content: That is your punishment for trying to derail the thread into another VHDL versus Verilog debateBesides that, creating a Verilog module definition is pretty much the same work as for VHDL.

author: Cerebus
author_rank: Super Contributor
timestamp: December 23, 2021, 02:52:07 pm
content: Ha! May a thousand mismatched entity and architecture statements plague your code!

author: asmi
author_rank: Super Contributor
timestamp: December 23, 2021, 03:09:14 pm
content: Quote from: nctnico on December 23, 2021, 02:48:46 pmUsing VHDL is an alright punishment for stubbornness and arrogance that VHDLers tend to demonstrate.Quote from: nctnico on December 23, 2021, 02:48:46 pmNot even close. Creating a module in Verilog/SV is not a work at all. It's a single line of code. While in VHDL it's a real work writing a wall of useless text. Again, yet another punishment for stubbornness.

author: gnuarm
author_rank: Super Contributor
timestamp: December 23, 2021, 05:33:21 pm
content: Quote from: asmi on December 23, 2021, 03:09:14 pmI think he meant the total amount of work including debugging the inevitable mismatched items in the positional parameter list. If you are a masochist you can do that in VHDL, but they typically use the form with names that have to match the names in the interface definition (I can't recall the terminology).Oh, crap! I'm in the debate mode. Sorry.

author: gnuarm
author_rank: Super Contributor
timestamp: December 23, 2021, 05:39:56 pm
content: Quote from: BrianHG on December 23, 2021, 04:29:18 amSorry, I don't recall my Verilog well enough to debate this. The issue is not the statements within a process (module). It's the ordering of the execution of the clocked logic in different modules.Consider module A assigns output X on the clock edge CLK. Module B assigns output Y on clock edge CLK. If X depends on Y and Y depends on X, you get different results depending on which process is executed first.I don't recall how this is resolved in Verilog, but it isn't through delta delays and I've been warned how to prevent being caught by it, I just don't recall how.

author: asmi
author_rank: Super Contributor
timestamp: December 23, 2021, 06:23:45 pm
content: Quote from: gnuarm on December 23, 2021, 05:33:21 pmBeing a masochist is pretty much a requirement for using VHDL.

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 23, 2021, 06:25:10 pm
content: Quote from: nctnico on December 21, 2021, 08:51:06 amAny piece of code not worth making a component out of is not worth using, at least in any serious project and environment. (Except for just "glue" code, of course.)Not doing it means using copy-and-paste, and not only not having something reusable, but not having something really testable in the true sense. If what you test is not the same code as what is used in production, then something is wrong. As soon as you start copy and pasting, you have no guarantee they are in sync, then one modification requires modifying in the test bench as well... Awful. I really advise against doing things this way.And don't talk about the amount of typing. I find this 100% irrelevant in most cases. It's not like you're asked to write a 1000-page book for every project you do. It's just a few more lines of code to make things tidy - and the time you'll spend is never while typing. It's designing stuff and... debugging it when you didn't design properly in the first place. That's something that applies to software as well and that is discussed every once in a while. If you care about the amount of "typing", and it's actually significant enough, relative to the time you spend on a project, then something is probably wrong.And if, on top of that, you waste significant time "debugging" because you wanted to save a few minutes in the first place, while making things less maintainable, yeah. I don't think we'll ever agree on the process.Quote from: nctnico on December 21, 2021, 08:51:06 amKnowing the differences between simulation and synthesis when using HDLs (whatever they are) is very important. No doubt about it and not something to be taken lightly.

author: Bassman59
author_rank: Super Contributor
timestamp: December 25, 2021, 05:05:02 am
content: Quote from: gnuarm on December 23, 2021, 05:39:56 pmThat is not true, in either language (assuming non-blocking assignments in Verilog).Remember how assignments work:On the event that triggers the process -- the rising edge of the clock -- all right-hand-sides of assignments are captured. Remember a "right-hand-side" also includes the conditions inifstatements, the expressions incasestatements, and the like. Then each line in all of the processes sensitive to the clock are evaluated. In a given process the lines are evaluated in order. After each evaluation, the result of that evaluation is scheduled to be assigned to the target on the left-hand-side. Only after all assignments are evaluated and scheduled do the left-hand-sides actually update.Let's look at a simple example:Code:Swap1 : process (clk, rst_l) isbeginif rst_l = '0' thenX <= '1';Y <= '0';elsif rising_edge(clk) thenX <= Y;Y <= X;end if;end process Swap1;Now the same process but with the assignments after the clock edge test reversed:Code:Swap2 : process (clk, rst_l) isbeginif rst_l = '0' thenX <= '1';Y <= '0';elsif rising_edge(clk) thenY <= X;X <= Y;end if;end process Swap2;If the assertion, "you get different results depending on which process is executed first" was true, then you'd get different results with these two processes.But you don't. They are identical. Which is as you would expect.And that is because at the clock edge, the current values on X and Y are both captured. Then (since the evaluation is trivial) we simply assign the current value of X to Y, and the current value of Y to X. On the next clock edge, you have new current values on X and Y. And so forth.Simulate the two examples. Prove to yourself that what I say here is correct. And yes, I realize that the example is trivial.If you are using VHDL variables, then yes, the order in which the statements in the process are written absolutely matters, because a variable updates immediately after evaluation, instead of having the evaluation result scheduled for assignment. For example:Code:Swap3 : process (clk, rst_l) isvariable v_foo : std_logic;beginif rst_l = '0' thenv_foo := '0';X <= '0';Y <= '0';elsif rising_edge(clk) thenX <= v_foo;v_foo := BAR or BLETCH;Y <= v_foo;end if;end process Swap3;versus:Code:Swap4 : process (clk, rst_l) isvariable v_foo : std_logic;beginif rst_l = '0' thenv_foo := '0';X <= '0';Y <= '0';elsif rising_edge(clk) thenv_foo := BAR or BLETCH;X <= v_foo;Y <= v_foo;end if;end process Swap4;In Swap3, the current value of v_foo is assigned to X, then v_foo gets a new value, and that new value is assigned to Y. On the next clock, the value we assigned to Y -- the current value of v_foo -- on the previous clock is assigned to X, and then again v_foo gets a new value which we assign to Y.In Swap4, v_foo is assigned a new value on the clock edge, and that value is assigned to both X and Y.So for variables the order of evaluation in the process matters.As for Verilog: the assignment semantics are identical to what I describe above if you use non-blocking assignments in your always block. If you use blocking assignments, then the evaluation and updating are the same as for VHDL variables, which means the order in which assignments are evaluated matters and you will get different results depending on how you write the block.Hope this helps.

author: gnuarm
author_rank: Super Contributor
timestamp: December 26, 2021, 04:13:47 am
content: Bassman, you don't seem to have understood what I wrote.First, this is not at all about the order of assignments within a process. So please don't continue to discuss that. The swap examples are not relevant. That is about blocking vs. non-blocking assignments (signals vs. variables in VHDL, not respectively). This is about the ordering of processes.I am saying Verilog can have a problem, not VHDL. This is exactly the reason why VHDL uses delta delays. Delta delays are just like time delays, except they add zero time. They just provide ordering. Events that are scheduled from a rising edge of a clock at time 20 ns are all evaluated. Then once all evaluations are complete in all processes, the updated values are assigned to the respective signals.If these changed signal values trigger other events through assignments with zero time delay, these events are scheduled for time 20 ns plus 1 delta delay. Now the time is advanced to 20 ns + 1d and the processing continues. So the assignments from all clocked processes are scheduled for 1 delta delay after the time of the clock and so the assignments can not affect any clocked processes at time 20 ns.In Verilog, there is no delta delay. So when a clocked process is run the results of the assignments are updated at time 20 ns. When another process is run subsequently, those assignments are evaluated and if one of the variables assigned in the prior process is an input, the assignment uses the updated value, not the value prior to the clock time. This can result in different assignment values depending on the sequence of execution of the processes which may or may not be related to the order they appear in the source code.I am sure there is something in Verilog to prevent this from being a problem. I was told about this a long time ago. But the point is this is why delta delays are used and why assignments should not be made for clocked signals unless you are careful to mitigate the impacts.I'm very rusty in both Verilog and VHDL, so I may not be using the terminology correctly. I think this is one of the technical issues where it can be important to use terminology precisely, so I apologize for any confusion I create.

author: Cerebus
author_rank: Super Contributor
timestamp: December 26, 2021, 02:13:02 pm
content: Quote from: gnuarm on December 26, 2021, 04:13:47 amWhy are you arguing about something that, by your own admission, you are largely ignorant?Quote from: gnuarm on December 23, 2021, 05:39:56 pmAnd for evidence that you are correct in that assertion:Quote from: gnuarm on December 23, 2021, 05:33:21 pmVerilog hasn't relied on positional parameters since before the 2001 version of the standard.By all means make definitive statements about what VHDL does and doesn't do, can and can't do, if that is your area of expertise. But making statements about what Verilog does and doesn't do, can and can't do, when you're twenty years out of date and you admit to poor recall of the subject matter seems a bit like skating on thin ice.Vis:Quote from: gnuarm on December 26, 2021, 04:13:47 amQuote from: IEEE Std 1364-2005 11.3

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 26, 2021, 06:48:53 pm
content: You'll find a more detailed answer here:https://electronics.stackexchange.com/questions/99223/relation-between-delta-cycle-and-event-scheduling-in-verilog-simulation

author: gnuarm
author_rank: Super Contributor
timestamp: December 26, 2021, 07:00:38 pm
content: Quote from: Cerebus on December 26, 2021, 02:13:02 pmWhen you say "hasn't relied on" I think you are playing word games. Every bit of Verilog code I've ever seen used positional parameters. There is also frequently very little white space used to facilitate organization of the code for easy reading. Yeah, not part of the language, but common use. That equals more time debugging.QuoteI'm not clear on what that statement implies. Are you saying Verilog does include the delta delay concept? If so, I suppose my information preceded the 2005 standard. I did start using HDL in the 1990s. The important aspect of this is that the variable values are not updated until all assignments have been evaluated. That's the part that prevents using a new value in a current assignment.

author: gnuarm
author_rank: Super Contributor
timestamp: December 26, 2021, 07:04:02 pm
content: Quote from: SiliconWizard on December 26, 2021, 06:48:53 pmThanks for that info. Looks like Verilog accomplishes the same thing in averydifferent way. I hope the user doesn't need to know any of this.

author: Cerebus
author_rank: Super Contributor
timestamp: December 26, 2021, 08:09:20 pm
content: Quote from: gnuarm on December 26, 2021, 07:00:38 pmNo, I'm not playing word games. That you haven't seen a well written bit of contemporary Verilog, but have only ever seen stuff that uses a style that went out years ago underlines how poorly qualified you are to comment on how Verilog is actually used.QuoteWell it's probably not clear for three reasons: (1) that's an isolated quote from a standard , (2) "delta delay" is from the VHDL lexicon, not a general term, (3) that you don't understand basic Verilog - standard Verilog behaviour for non-blocking assignments has always been that prior evaluation of all right hand sides that happen in the same simulation "event" happens before any assignments are made . Vis:Code:`timescale 1ns / 100psmodule example;reg A, B, C, D;initial begin$dumpfile ("example.lxt");$dumpvars (0, example);A <= 1;B <= 0;#30 $finish();endinitial begin// The initial delay is just to make a clear timing diagram#10 B <= A; // assignment happens at time 10, using value of A from just before time 10A <= #10 B; // assignment happens at time 20, using value of B from just before time 10endendmoduleYields:

author: gnuarm
author_rank: Super Contributor
timestamp: December 26, 2021, 11:10:52 pm
content: Quote from: Cerebus on December 26, 2021, 08:09:20 pmThis is getting old fast. Ok, fine. I know nothing about Verilog. But if you don't use positional notation, you get the same typing as VHDL.QuoteDelta delays (regardless of what you call them) are a good way to order assignments preserving causality. Verilog seems to make this very complex. To the best of my knowledge a simulation event is exactly one assignment. But that's VHDL, don't know what you are referring to in Verilog.SiliconWizard posted some good info that addresses the appropriate subject.

author: ataradov
author_rank: Super Contributor
timestamp: December 27, 2021, 12:29:52 am
content: There are no parts, not going to be for a long time. It is not even clear with their business model if the blank parts will be available.

author: Cerebus
author_rank: Super Contributor
timestamp: December 27, 2021, 04:44:59 am
content: Quote from: gnuarm on December 26, 2021, 11:10:52 pmI don't think that it has dawned on your yet that the "typing thing" was ajoke!QuoteThat's the whole point. You quite clearly don't know Verilog, but you seem to qualified to hold forth on the matter and make definitive statements about Verilog. Surely you must realise that's not the way to generate light on the subject. Verilog makes it quite easy to order assignments, should one want to make one's design reliant on that; whether that's a good design choice is another discussion entirely.

author: Cerebus
author_rank: Super Contributor
timestamp: December 27, 2021, 04:49:43 am
content: Quote from: ataradov on December 27, 2021, 12:29:52 amGiven that currently one can only get parts that have been extant for several years only if you're prepared to wait until next year I don't hold out much hope for seeing these new parts available next year, possibly even the one after. That does have the upside that it gives a bit of time for feedback on issues like tooling to filter through, and perhaps when one can get parts to play with the toolchain will also have been made more to the liking of folks here that have expressed discontent.

author: gnuarm
author_rank: Super Contributor
timestamp: December 27, 2021, 03:28:49 pm
content: Quote from: ataradov on December 27, 2021, 12:29:52 amLike virtually every company, they will release info in due time as they see fit.

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 27, 2021, 06:18:47 pm
content: And due to the fab congestion these days, releasing a brand new line of ICs is likely to take longer than usual.

author: mark03
author_rank: Frequent Contributor
timestamp: December 27, 2021, 06:29:49 pm
content: Quote from: Cerebus on December 27, 2021, 04:49:43 amCrosslink-NX parts are sort-of available now (at least last time I checked at DK/Mouser), and they are new. I have been wondering if the really new parts might be *more* available than the sort-of new, because they haven't been designed into as many products yet. Especially if they are just entering production and only available in hobbyist quantities to begin with.

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 27, 2021, 06:37:22 pm
content: Quote from: mark03 on December 27, 2021, 06:29:49 pmYeah, but not nearly as "new". Crosslink-NX was announced in very early 2020, so, that's almost 2 years ago. =)

author: gnuarm
author_rank: Super Contributor
timestamp: December 27, 2021, 07:40:10 pm
content: Quote from: mark03 on December 27, 2021, 06:29:49 pmI don't think it works quite that way. When new parts are being introduced they already have users lined up... large volume users. They have a schedule they want to meet, so unless they are lucky and are ahead of schedule, there are no extra parts waiting for someone to buy them. I'm not saying Digikey won't have parts. I'm saying Digikey will have ordered them previously and when they come in will be uncertain.

author: LostTime77
author_rank: Contributor
timestamp: January 03, 2022, 07:24:34 pm
content: I work for a very big name in the industry and I can say I am very excited about these chips. I have already contacted my FAE about them and have gotten some initial information. However, I am under NDA and cannot share much.What I will share is that my company has been using a CPLD (Max series) in our designs for many years now. There are several reasons for it, but power consumption, NVM, and <$1.00 cost are a part of it. We recently tried to start a fresh design and use something modern only to find the current market laughable for any comparable device, thus we were forced back to using a Max V. The Lattice ice40 series was the closest match, but Lattice's treatment of the device when we were interested, was laughable.A word on Lattice. When we started searching for a new PLD (CPLD / FPGA / whatever) for this project, Lattice's name obviously came up so we contacted them. I have PLD experience from previous jobs, so I am very up to date with what devices every major manufacturer provides - packages, logic, power, etc.. I specifically keyed in to the ice40 to our rep, saying that was the only device even close to what we might want. What I got in response was that the ice40 devices are red headed step child's in Lattice's view. They are a design that they bought around 2010 and it's just kind of there. They have decided to not spend many resources on expanding the series or making them better in terms of packages and cost for the last decade. I suspect it was a huge marketing stunt, just so that they could say they are the leader in low power devices. Basically our reps told us "Yeah... those are old. We don't want you using those as we kind of don't support them. How about this Mach XO class device over here? We are willing to work with you on the price." I basically laughed at my rep and told him: "I don't care how you work with us on the price. I have been in this industry awhile and know about price breaks and "special" pricing, because I have been involved in those dealings before. Unless you are willing to take a massive cost hit, which we will still be expecting to have in 5 or 10 years on these devices, there is no other way you are going to cut your cheapest device price from like $4 to less than $1, which is what we get now."The ice40 series is a tale of something that could have been great for Lattice, but like many companies, such as Intel, Lattice decided to sit on their laurels for the last 10 years doing nothing with it, even going as far to tell customers not to use it. "Nobody can ever dethrone this market segment from us". After hearing the announcement from Dialog of the new devices and seeing some of the information on what they can do first hand, we get to see the joke play out in real time. Dialog will be eating a large portion of Lattice's lunch in this segment. Again, Lattice has been trying to get in the pants of my company, because it is a huge name. I will be talking to my reps in the next months and am going to tell them to tell Lattice to shove it. Seriously. They lost the battle before it even began, by having Intel mentality. I have to tell you, it grinds my gears when corporate tom foolery screws up something like the ice40 series, which had tons of potential. They had a decade to do something with the series. Does not compute. Gross negligence. Instead, they still want to claim "lowest in class power", yet no new devices and are focusing on this high power NX crap.The ice40 series is kind of laughable in terms of logic and package. You either get these tiny packages with like 5 I/O pins that cost $1.25 or you get these bigger packages where the price balloons into the >$2.5 range. Nothing in between. Our application calls for a good number of I/O and not so much logic at all.As others have alluded to, I have seen the pinout and some of the specs for the QFN24. It exists. As I have a huge part in part selection at my job, the amount of I/O in this device fits our application like a glove. Even if we need more I/O, we can just slap more of these devices in there with how cheap they are supposed to be. I do hope Dialog will be providing larger package devices in the future though. I don't have full roadmap information yet. However, I believe these first entries are going to blow the flood gates open for many possibilities now and in the future. I mainly look at Lattice devices for low power devices and when I need something like a "real" device, I look to xilinx for something like a Spartan 7. I have a feeling that Lattice will be wiped from my vocabulary in the near future as there will really be nothing left for me to look at them for.Next up: Me making a very similar angry, time squandering forum post on the Saleae logic forum, likening Saleae to Lattice. No new devices in 8 years. No USB C connector, even though its a 5 minute hardware change. Instead, we get a doubling of price because their 10 engineers can't figure out a crypto handshake to their software due to Chinese knock offs. In 2014, when we bought the PRO16s, they cost $399 or $499 IIRC. Anyhow, that's a story for another time.

author: gnuarm
author_rank: Super Contributor
timestamp: January 05, 2022, 07:45:58 am
content: Quote from: barycentric on January 05, 2022, 06:49:29 amThat's always a specious statement that Gowin is copying the iCE40 line. They have virtually nothing in common other than being LUT based FPGAs. The Gowin parts are more like the other Lattice parts.Theyhaveadded products to the line which you just mentioned. You call them "stupidly tiny", but that is the target market for those parts, small devices to fill cracks in designs omitted by the ASICs.QuoteYou mean like Intel? I bought Xilinx stock since they are merging with AMD at a 1.7 to one stock swap. Both stocks have gone up nearly 100% and Xilinx will get another 20% boost from the merger. Meanwhile Intel has been sucking wind for 3 years now. Who would have thought Intel would stumble on process technology and end up at least a year behind!? I wonder how this will impact the Altera FPGA products. Did they ever port to the Intel process or are they still using Taiwanese fabs?

author: LostTime77
author_rank: Contributor
timestamp: January 05, 2022, 06:48:03 pm
content: I just poked my FAE again last night to get more information. Again, under NDA, so I can't reveal much. However, theroadmaplooks extremely interesting. The LUT implementation is also very interesting. Yes, they will be eatingallof Lattice's lunch with regards to the ice40 series in the near future. Very excited.

author: nctnico
author_rank: Super Contributor
timestamp: January 05, 2022, 08:55:28 pm
content: Quote from: LostTime77 on January 05, 2022, 06:48:03 pmHow about tooling? Any indication they are going to add support for VHDL?

author: LostTime77
author_rank: Contributor
timestamp: January 06, 2022, 12:43:51 am
content: I have not had the pleasure of playing with the software associated with the GreenPAKs or the Forge FPGAs yet, as I just really dug into them this past year. I knew about the GreenPAKs awhile ago, but my new job has direct application for them. Unfortunately, we just have not gotten to the point of actually buying chips and developing with them.I was under the impression that the new GreenPAK software suite or whatever could already do HDL? Otherwise, the information that I have says you can develop for the new FPGAs in "HDL". I didn't know what HDL was referring to, so I specifically asked what they would be supporting: verilog, VHDL 2008, etc.. Have not gotten a response yet on that one. I am a VHDL guy myself. I can develop with the old VHDL versions, but I really enjoy / want to use at least VHDL 2008. PLD implementation is not my main occupation like it is for some people, I only do it on the side as my projects require it.

author: ataradov
author_rank: Super Contributor
timestamp: January 06, 2022, 01:42:57 am
content: Was LostTime77 a salesman from Renesas or something? He sure sounded like one.Edit: I've got email from LostTime77:Quote

author: gnuarm
author_rank: Super Contributor
timestamp: January 06, 2022, 03:54:08 am
content: I had a problem like that in the Tesla forums. I was giving my views on the stock price and because I was not a cheerleader a bunch of members jumped on me accusing me of being a short, etc. One of them reported me for spamming which made no sense as that is promotion of a product and I promoted nothing. I was banned. I could not get on to communicate with anyone who might explain to me what happened, so I created a second account to contact them. When I acknowledged having a second account (pretty hard not to in that case) they banned me for having two accounts! WTF!!!???So of course, I created a third, fourth and fifth accounts lol! Members in the Tesla forums really don't like when you say *anything* negative even if it's your personal experience with repair work. The funny thing is eventually I stopped posting there for a year or so and when I returned things had changed. Most importantly, the original account was no longer banned and I can use it now. Go figure!Sounds like something along these lines happened to LostTIme77. Sometimes admins can make mistakes too. Sometimes they are honest mistakes. Other times an admin can let the power go to his/her head.

author: Cerebus
author_rank: Super Contributor
timestamp: January 06, 2022, 04:27:23 pm
content: Quote from: gnuarm on January 06, 2022, 03:54:08 amWell, judging from your photo in your avatar you're only about 18" tall so was it an unfair observation?QuoteIn this case I don't think it has anything to do with human admin actions but with the horrifically buggy nature of the SMF forum software. "The computer said no" rather than Dave, or Simon, or Halcyon actively doing something to make it happen. I've flagged ataradov's message for moderator attention with a request for help.

author: Simon
author_rank: Unknown
timestamp: January 06, 2022, 08:02:15 pm
content: I'm not aware of losttime77 or any reports but as far as I know SMF is not that buggy that people get randomly banned. I can't say much as I am under NDA* but what little I can share is that his email address would get me suspicious.......I'll leave the report as open so that Dave and Halcyon become aware when they are next on.*Obviously as moderator I can see email addresses but basic common sense not to mention GDPR or local equivalents mean I cannot divulge personal contact details.

author: Cerebus
author_rank: Super Contributor
timestamp: January 06, 2022, 08:06:14 pm
content: Cool, thanks for taking a look Simon.

author: up8051
author_rank: Frequent Contributor
timestamp: April 05, 2022, 05:58:48 pm
content: Any new information on chip availability?

author: free_electron
author_rank: Super Contributor
timestamp: April 05, 2022, 06:10:31 pm
content: The website mentions GreenPak. those are Silego devices. ( mixed signal FPGA ) ... interesting

author: chris_leyson
author_rank: Super Contributor
timestamp: April 05, 2022, 07:35:06 pm
content: Silego were acquired by Dialog Semiconductor. GreenPAK devices offer about 25 CLBs at most and most of them have only two or three inputs. There is a lot of useful analog functionality and external digital communications is limited to SPI or similar, no serial UART hardware available. Still interesting devices.

author: free_electron
author_rank: Super Contributor
timestamp: April 05, 2022, 08:43:28 pm
content: i know . i have used many silego parts in the past.what i meant is: it is interesting that silego -> dialog -> renesas and all of a sudden now we have fpgas ...

author: gnuarm
author_rank: Super Contributor
timestamp: April 06, 2022, 02:31:59 am
content: Quote from: Cerebus on January 06, 2022, 04:27:23 pmActually, that's is pretty funny. lol

author: gnuarm
author_rank: Super Contributor
timestamp: April 06, 2022, 02:34:55 am
content: Quote from: free_electron on April 05, 2022, 06:10:31 pmOne downside, or maybe an upside, is that the devices are intended to be factory programmed. Maybe they've changed some of this, but I don't know that they support anything other than lab programming.Now that I think about it, this might make the devices useful security chips to prevent your board from being counterfeited.

author: kleiner Rainer
author_rank: Regular Contributor
timestamp: April 06, 2022, 03:16:57 pm
content: Quote from: gnuarm on April 06, 2022, 02:34:55 amSome are in system (re-)programmable via I2C due to an internal EEPROM: SLG46824, SLG46826 and SLG47004.I already did a design with SLG46826 - its nice to reprogram on the fly with the design kit. My use was as a reset controller / power supply monitor and on/off controller for an SBC, with status display via duo LEDs in the on/off button. Setting UVLO levels and delays for different voltage rails is easy: simply select a voltage divider with sensible levels and fine-tune the comparator thresholds in 32mV steps via programming. No soldering, no pots. Adjusting delays is equally easy. Just change a register and test.The OTP versions can be used for development as long as you write the resulting design file into RAM, not OTPROM. This requires a connection to the programming pins and the development board, and keep in mind that powering down the application board clears the RAM. The design can then be burned into the chip when everything works.Greetings,Rainer

author: uer166
author_rank: Super Contributor
timestamp: April 07, 2022, 02:43:03 am
content: Quote from: kleiner Rainer on April 06, 2022, 03:16:57 pmCool devices, I've looked into doing some SMPS controllers (or use them as part of a sub-circuit), but found that they had quite limited functionality that could be reproduced with ~3 chips anyway, sort of like GALs that were not worth it in the end. I think they would be a good fit for FMEA designs where you have the pin-to-pin short test cases, and keeping IC count down helps immensely.

author: gnuarm
author_rank: Super Contributor
timestamp: April 22, 2022, 12:12:11 pm
content: FMEA?

author: josuah
author_rank: Regular Contributor
timestamp: April 22, 2022, 12:43:39 pm
content: Thebig news head-upsays "Q2 2022".The problem with Financial year quarters is they are different on Japan.In this announcement, Renesas announces the results for Q1 2022 at the end of April:https://www.renesas.com/sg/en/about/investor-relations/event/presentationThat would matchJapanese's financial yearschedule:Estimated launch date:Aug/Sep/Oct/Nov 2022.

author: mac.6
author_rank: Regular Contributor
timestamp: April 23, 2022, 10:20:55 am
content: Quote from: gnuarm on April 22, 2022, 12:12:11 pmFailure Mode and Effect Analysis. Functional safety stuff.

author: gnuarm
author_rank: Super Contributor
timestamp: April 26, 2022, 01:44:55 am
content: Quote from: josuah on April 22, 2022, 12:43:39 pmActually, the fiscal year is whatever the company chooses. For example, the US government has a fiscal year of Oct to Sept. Correspondingly, many government contractors have a fiscal year of Nov to Oct so they can include easily all the end of year and start of year government spending in their year end results.

author: josuah
author_rank: Regular Contributor
timestamp: May 12, 2022, 02:41:51 pm
content: Quote from: gnuarm on April 26, 2022, 01:44:55 amFromhttps://www.renesas.com/sg/en/about/investor-relations/event/presentation/archivepast dates for Q2:Financial Results for 2nd Quarter 2021 (July 29, 2021)Financial Results for 2nd Quarter 2020 (July 30, 2020)Financial Results for 2nd Quarter 2019 (August 6, 2019)Financial Results for 2nd Quarter 2018 (July 31, 2018)Financial Results for 2nd Quarter 2017 (July 28, 2017)Indeed, before August if that follows that pattern.There might be some more time between the release and when it is out on Walmart too.

author: axemaster
author_rank: Contributor
timestamp: May 13, 2022, 06:52:34 pm
content: I've worked with Dialog Semiconductor microcontrollers before... their documentation is just awful. So many outright mistakes, missing information. Even worse some of the hardware architectures have truly baffling design decisions. Like being unable to wake from an RTC interrupt.So forgive me for not being excited about these FPGAs.

author: josuah
author_rank: Regular Contributor
timestamp: May 13, 2022, 09:53:47 pm
content: Quote from: axemaster on May 13, 2022, 06:52:34 pmToo bad! I was glad to see a lower-end FPGA, but the iCE40 is probably already that to some extent...

author: brouhaha
author_rank: Newbie
timestamp: May 24, 2022, 06:57:09 pm
content: Some people have criticized the ForgeFPGA product offering for using OTP memory, but they are SRAM-based. The use of the OTP memory is optional, to support cost-sensitive production without requiring external configuration memory. The chip can be configured by loading the SRAM from an external SPI flash memory, or from a microcontroller using a SPI interface. That is very helpful in development because you don't have to throw away a bunch of OTP chips as you refine your Verilog code. The drawback is that the SPI interface takes up four of the nineteen GPIO pins, though the SPI interrface does not have to be connected after the internal SRAM is loaded.The SLG7DVKFORGE development board is rather fancy and costs $249. It requires a socket adapter board for the specific device package (24-pin 3x3mm, or 20-pin 1.85x1.64mm). The socket adapters are $37.50, and come with 50 sample parts, so the parts are under $0.75 each even in low volume. The socket adapter board can be used by itself for prototyping, if you supply power, and have your own means of programming the chip (via SPI).Mouser Electronics has listed the development board and the two different socket adapters for a while, with a claimed one week factory lead time. I ordered these on April 26, but don't have them yet. On April 27, Mouser sent me an order status update, changing the estimated shipment date to "Will Advise". I haven't been advised yet.The bottom of the ForgeFPGA web page says "Find out more" with a button "Contact Us". The button is just a mailto: link, and I sent requests for a preliminary datasheet twice, on April 26th and May 4th, and have received no response. Other people have apparently been succesful at getting datasheets, including a "target" data sheet dated 2021-11-23. I'm not sure why they don't respond to me, unless it is bias against my email address, which is @gmail.com. I suppose that wouldn't surprise me, as some other semiconductor vendors, e.g. Xilinx, also do that.

author: ataradov
author_rank: Super Contributor
timestamp: May 24, 2022, 08:00:34 pm
content: The device appears trivial to use. I guess $250 dev kit is a nice way to make extra cash, but I don't understand why it is necessary.The ROM itself was not a criticism, it is actually good. As long as there is a well documented way of programming them yourself. From the marketing material and the IDE options, it looks like they want to program them on their side as a special order. It is just a guess in the absence of any real information.It would be nice to get the actual devices and then it would be clear what they are useful for.

author: brouhaha
author_rank: Newbie
timestamp: May 24, 2022, 09:24:42 pm
content: The $250 gets you a programmer, and some auxilliary stuff like three programmable power supplies, a digital pattern generator, an 8-channel arbitrary waveform generator, and logic analysis that might be useful for testing your design. If you already have comparable test equipment, then you won't need that.No one said that the $250 development board is necessary, but without it you will have to come up with your own tools to download the FPGA image, and (optionally) to program the OTP. Having a programming setup that "just works" (hopefully) seems worth $250 compared to having to cobble something together; I'm sure that I could develop my own, but it would probably take a lot more than $250 worth of my time.I'm sure there will be alternative programmers available not too long after the chips become available. All of the hardware that's needed is a USB-to-SPI interface, but existing USB-to-SPI interfaces won't likely be plug-and-play with the Renesas development software.

author: josuah
author_rank: Regular Contributor
timestamp: May 25, 2022, 02:44:51 pm
content: I wonder if it is frequent, or even possible to use these OTP ROM for loading a bootloader on it:For instance, a button would switch from the FLASH chip to the OTP ROM with [EDIT: TinyFPGA's Bootloader] on it for driving an USB DFU interface, loading the user design onto the FLASH.On next reboot, it would load the (now updated) design from FLASH as a normal operation.

author: ataradov
author_rank: Super Contributor
timestamp: May 25, 2022, 03:33:09 pm
content: There are configuration bits and once SPI is disabled via OTP programming, it remains disabled.But I also don't get overall idea you propose. Who would write the data into the flash and why you can't do the same directly and not involve FPGA at all?

author: josuah
author_rank: Regular Contributor
timestamp: May 27, 2022, 02:20:57 pm
content: My previous post was a bit unclear...The idea was: since the OTP cannot be reprogrammed but will be there anyway, why not put a boot-loader in here. A bit like whatFOMUandTinyFPGAdid, but using the OTP storage for the bootloader instead...Booting with "BOOT" button pressed:Code:┏━━━━bootloader━━━━ OTP storage (bootloader)vUSB port ───────X─────── FPGA (empty) ──────X─────── FLASH (empty)│X│rest of thehardwareCode:┌─────────X──────── OTP storage (bootloader)│USB port ━━━design━━━> FPGA (bootloader) ━━design━━> FLASH (design)│X│rest of thehardwareBooting with "BOOT" button released:Code:┌─────────X──────── OTP storage (bootloader)│USB port ───────X─────── FPGA (empty) <━━━design━━━━ FLASH (design)│X│rest of thehardwareCode:┌─────────X──────── OTP storage (bootloader)│USB port ───────X─────── FPGA (design) ───────X───── FLASH (design)^┃vrest of thehardwareA bootloader is typically a piece of code that sits there there untouched for the entire life of the device, even across firmware upgrades, so I wondered if it would be a good fit for an OTP storage.

author: ataradov
author_rank: Super Contributor
timestamp: May 27, 2022, 04:01:56 pm
content: Depending on how your USB is connected, it may be way easier to just connect the flash to the USB and program it directly. If it is a simple USB to UART, then your logic makes sense, but I don't think this will be supported (just guessing based on nothing really).There is not enough logic capacity in that device that you would normally want it to be connected to the USB for applications. It is really a glue logic device.

author: josuah
author_rank: Regular Contributor
timestamp: May 27, 2022, 06:32:43 pm
content: Understood.A traffic cop such as a tiny FPGA chip is no fit for a highway like USB.Thank you for the feedback.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: August 03, 2022, 07:04:14 pm
content: The IDE is very fast when synthesizing and generating a bitstream. Orders of magnitude faster than Vivado.One thing I found curious in the synthesis log: 2. Executing SYNTH_XILINX pass.

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 03, 2022, 07:15:51 pm
content: Isn't it based on open source tools (or do I confuse this with some other vendor?) like Yosys?

author: ataradov
author_rank: Super Contributor
timestamp: August 03, 2022, 08:05:37 pm
content: Quote from: Sal Ammoniac on August 03, 2022, 07:04:14 pmHave you seen the size of this device? It is trivial to synthesize that much.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: August 03, 2022, 11:02:17 pm
content: Quote from: ataradov on August 03, 2022, 08:05:37 pmI tried synthesizing a tiny bit of Verilog -- about 16 lines... Took 46 seconds in Vivado, 1.5 seconds in this Renesas IDE.

author: ataradov
author_rank: Super Contributor
timestamp: August 04, 2022, 12:02:56 am
content: It is not about the size of the code, but about the size of the target device. No matter how small the design is, you need to process the whole device database in order to know how to fit your design into that device.Plus those open tools do not even try to figure out constraints other than pin mapping (bare minimum for any tool).

author: josuah
author_rank: Regular Contributor
timestamp: November 17, 2022, 10:25:51 am
content: Someone received the dev board from Mouser:https://hackaday.io/project/184088-goforge-a-renesas-fpga-boardSee the comments:Quote from: EricSmith

author: scotcob
author_rank: Newbie
timestamp: December 21, 2022, 06:44:14 pm
content: I was getting really frustrated with the availability of the FPGA's and development kits from Renesas that I contacted them direct for status, basically they replied stating that middle of 2023 parts and kits will be available.Full details as follows:https://community.renesas.com/gpak-gfet/f/greenpak-greenfet/29049/forgefpga-availabilityHope this helps others on status of these devices.

author: gnuarm
author_rank: Super Contributor
timestamp: December 21, 2022, 08:48:58 pm
content: That's bad news. I was planning to use one of their parts. If I can't get anything for six months, I can't design it in.

author: DCW
author_rank: Newbie
timestamp: March 06, 2023, 09:35:11 pm
content: This is my first post to EEVblog.Maybe someone else already mentioned this, but Renesas/Dialog didn't design the FPGA fabric in their ForgeFPGA -- it was licenced from Flex Logix:https://semiengineering.com/micro-fpgas-and-embedded-fpgas/

author: zapta
author_rank: Super Contributor
timestamp: January 27, 2024, 03:22:05 am
content: What is the expected price of the SLG47910, e.g. compared to a SLG46826?Not available yet, but I could find a preliminary PDF (below) and the latest GreenPAK tool release included fixes related to it so seems to be still alive.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: January 27, 2024, 06:19:50 am
content: Looks like it competes with the iCE40, so the price has to be in that ball park.It looks a bit slower, so maybe that means a bit cheaper too ?

author: up8051
author_rank: Frequent Contributor
timestamp: January 27, 2024, 01:51:13 pm
content: Quote from: zapta on January 27, 2024, 03:22:05 amRenesas has not been able to produce these chips over two years (12/2021, date of announcement of the chips).They also cannot determine when they will be available. You can find information on the Renesas forum.Until they are mass-available, it's just a waste of time.