Author Topic: New FPGAs from Renesas  (Read 38535 times)

0 Members and 1 Guest are viewing this topic.

Online ataradovTopic starter

  • Super Contributor
  • ***
  • Posts: 11260
  • Country: us
    • Personal site
New FPGAs from Renesas
« on: November 18, 2021, 06:46:06 pm »
Renesas is releasing new FPGAs via Dialog Semiconductor that they've acquired some time ago.

Here is a press release https://www.renesas.com/us/en/about/press-room/renesas-enters-fpga-market-first-ultra-low-power-low-cost-family-addressing-low-density-high-volume

Quote
The ForgeFPGA Family will serve applications that require less than 5,000 gates of logic, with initial device sizes of 1K and 2K Look Up Tables (LUTs). Standby power of less than 20 microamps is projected for the first devices, about half the power of competing devices. Users will be able to download the development software at no cost and with no license fees. The software offers two development modes to accommodate both new and experienced FPGA developers: a “macrocell mode” that uses a schematic capture-based development flow, and an “HDL” mode that provides a familiar Verilog environment for FPGA veterans.

Quote
Key Features of the ForgeFPGA Family
* Very low power as low as 20 microamps standby
* Very low price in volume of well under US$ 0.50
* Free, downloadable software with no license fees that includes both schematic capture and HDL modes
* Proven ability to deliver very high volumes
* Renesas is preparing to offer multiple Winning Combinations featuring the new ForgeFPGA devices with complementary MCU, analog, power and timing devices. Winning Combinations provide an easy to use architecture, simplifying the design process and significantly reducing design risk for customers in a wide variety of applications.

Quote
ForgeFPGA engineering samples are available now, along with beta design software and a prototype development kit. The first ForgeFPGA device, the 1K LUT offering, is expected to be available in production quantities in Q2 2022. Interested designers can visit https://www.dialog-semiconductor.com/products/greenpak/low-power-low-cost-forgefpga to find out more.

I wonder if they plan to make them easily accessible to general public. Neither Dialog or Renesas were particularly hobby-friendly.
Alex
 
The following users thanked this post: oPossum, paf, nctnico, Omega Glory, mon2

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14476
  • Country: fr
Re: New FPGAs from Renesas
« Reply #1 on: November 18, 2021, 07:32:17 pm »
They could "compete" with the Lattice iCE40 series for instance (more precisely, iCE40 LP.)
Curious to see more.
 

Online ataradovTopic starter

  • Super Contributor
  • ***
  • Posts: 11260
  • Country: us
    • Personal site
Re: New FPGAs from Renesas
« Reply #2 on: November 18, 2021, 07:39:24 pm »
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.
Alex
 

Offline DiTBho

  • Super Contributor
  • ***
  • Posts: 3915
  • Country: gb
Re: New FPGAs from Renesas
« Reply #3 on: November 18, 2021, 08:18:58 pm »
or vhdl
or nothing
 :o
The opposite of courage is not cowardice, it is conformity. Even a dead fish can go with the flow
 

Offline mon2

  • Frequent Contributor
  • **
  • Posts: 463
  • Country: ca
Re: New FPGAs from Renesas
« Reply #4 on: November 18, 2021, 09:26:38 pm »
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.
« Last Edit: November 18, 2021, 09:36:32 pm by mon2 »
 
The following users thanked this post: nctnico, Omega Glory

Online ataradovTopic starter

  • Super Contributor
  • ***
  • Posts: 11260
  • Country: us
    • Personal site
Re: New FPGAs from Renesas
« Reply #5 on: November 18, 2021, 09:49:25 pm »
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.
« Last Edit: November 18, 2021, 10:01:49 pm by ataradov »
Alex
 

Online ataradovTopic starter

  • Super Contributor
  • ***
  • Posts: 11260
  • Country: us
    • Personal site
Re: New FPGAs from Renesas
« Reply #6 on: November 18, 2021, 10:12:43 pm »
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.
« Last Edit: November 18, 2021, 10:27:20 pm by ataradov »
Alex
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26906
  • Country: nl
    • NCT Developments
Re: New FPGAs from Renesas
« Reply #7 on: November 18, 2021, 10:28:54 pm »
These devices look extremely interesting and the tools not needing any node locked license nonsense is a big plus. Any support for VHDL?
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Online ataradovTopic starter

  • Super Contributor
  • ***
  • Posts: 11260
  • Country: us
    • Personal site
Re: New FPGAs from Renesas
« Reply #8 on: November 18, 2021, 10:34:15 pm »
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".
« Last Edit: November 18, 2021, 10:38:01 pm by ataradov »
Alex
 

Offline tszaboo

  • Super Contributor
  • ***
  • Posts: 7388
  • Country: nl
  • Current job: ATEX product design
Re: New FPGAs from Renesas
« Reply #9 on: November 18, 2021, 10:40:43 pm »
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
 

Online ataradovTopic starter

  • Super Contributor
  • ***
  • Posts: 11260
  • Country: us
    • Personal site
Re: New FPGAs from Renesas
« Reply #10 on: November 18, 2021, 10:53:25 pm »
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.
« Last Edit: November 18, 2021, 10:55:53 pm by ataradov »
Alex
 

Offline YurkshireLad

  • Frequent Contributor
  • **
  • Posts: 365
  • Country: ca
Re: New FPGAs from Renesas
« Reply #11 on: November 19, 2021, 01:33:33 am »
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!
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 37740
  • Country: au
    • EEVblog
Re: New FPGAs from Renesas
« Reply #12 on: November 19, 2021, 01:57:39 am »
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.
« Last Edit: November 19, 2021, 01:59:55 am by EEVblog »
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14476
  • Country: fr
Re: New FPGAs from Renesas
« Reply #13 on: November 19, 2021, 02:04:52 am »
And given yosys workflow,

Does it really use yosys? That'd be the first commercial tool doing this that I know of.
 

Online ataradovTopic starter

  • Super Contributor
  • ***
  • Posts: 11260
  • Country: us
    • Personal site
Re: New FPGAs from Renesas
« Reply #14 on: November 19, 2021, 02:07:59 am »
Does it really use yosys? That'd be the first commercial tool doing this that I know of.
Yep. 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.
Alex
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14476
  • Country: fr
Re: New FPGAs from Renesas
« Reply #15 on: November 19, 2021, 02:22:46 am »
Does it really use yosys? That'd be the first commercial tool doing this that I know of.
Yep. 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.

That'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?
 

Online ataradovTopic starter

  • Super Contributor
  • ***
  • Posts: 11260
  • Country: us
    • Personal site
Re: New FPGAs from Renesas
« Reply #16 on: November 19, 2021, 02:32:00 am »
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?
They 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.
Alex
 

Offline Cerebus

  • Super Contributor
  • ***
  • Posts: 10576
  • Country: gb
Re: New FPGAs from Renesas
« Reply #17 on: November 19, 2021, 02:45:23 am »
best IDE I've seen from any FPGA vendor. And given yosys workflow, I assume command line would not be a problem either.

Depends what they use for place and route, and bitstream generation. They could have made those non command 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.
Anybody got a syringe I can use to squeeze the magic smoke back into this?
 

Online ataradovTopic starter

  • Super Contributor
  • ***
  • Posts: 11260
  • Country: us
    • Personal site
Re: New FPGAs from Renesas
« Reply #18 on: November 19, 2021, 02:48:23 am »
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: [Select]
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.
« Last Edit: November 19, 2021, 03:01:51 am by ataradov »
Alex
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14476
  • Country: fr
Re: New FPGAs from Renesas
« Reply #19 on: November 19, 2021, 02:58:06 am »
Well, now I'm a little less surprised, then... ;D
 

Online ataradovTopic starter

  • Super Contributor
  • ***
  • Posts: 11260
  • Country: us
    • Personal site
Re: New FPGAs from Renesas
« Reply #20 on: November 19, 2021, 03:05:41 am »
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.
Alex
 

Online asmi

  • Super Contributor
  • ***
  • Posts: 2733
  • Country: ca
Re: New FPGAs from Renesas
« Reply #21 on: November 19, 2021, 03:07:05 am »
Code: [Select]
AAABqnjafY1BS8MwGIaj4tmDuJOg4EUPaZP5C7IsdqFZGrIUttPHdKkWNltYhf58s5nepIeH9/u+9yFBCE0QQteBp8BV4DnmS+A+cBF4jDnsDzFvY05i3gUuAzenN7Df1VX61Rx8ut37Pq3az236/lPvd9D5Y5d2hzY5KbhqR6w3kzGaA+1pUrW4bkbUuoFj6z+g/k66vsNCs5kSMJNu5axgSyhKZ0oHbC3pWAnccjIIC5ktYC70SroNGMZzqTP6bymLoSeYqxx4oXlprdAOCuMoNopxAUzPwVnJFNjwoyDYaBsP0okwFo6pKcFLtv4zzudXQn4BAyBssQ== and 23111.
This 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.
 
The following users thanked this post: nctnico

Online ataradovTopic starter

  • Super Contributor
  • ***
  • Posts: 11260
  • Country: us
    • Personal site
Re: New FPGAs from Renesas
« Reply #22 on: November 19, 2021, 03:08:12 am »
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.
« Last Edit: November 19, 2021, 03:22:17 am by ataradov »
Alex
 

Online asmi

  • Super Contributor
  • ***
  • Posts: 2733
  • Country: ca
Re: New FPGAs from Renesas
« Reply #23 on: November 19, 2021, 04:01:24 am »
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.
« Last Edit: November 19, 2021, 03:43:01 pm by asmi »
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14476
  • Country: fr
Re: New FPGAs from Renesas
« Reply #24 on: November 19, 2021, 05:33:10 pm »
The smallest iCE40 and MachXO2/3 from Lattice are good fits for similar applications. It's not like the products don't exist yet.
 
The following users thanked this post: YurkshireLad

Offline YurkshireLad

  • Frequent Contributor
  • **
  • Posts: 365
  • Country: ca
Re: New FPGAs from Renesas
« Reply #25 on: November 19, 2021, 06:10:40 pm »
The smallest iCE40 and MachXO2/3 from Lattice are good fits for similar applications. It's not like the products don't exist yet.

Good to know - there are so many out there it's hard to know what to look for.
 

Offline mon2

  • Frequent Contributor
  • **
  • Posts: 463
  • Country: ca
Re: New FPGAs from Renesas
« Reply #26 on: November 19, 2021, 06:22:53 pm »
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.
 

Online asmi

  • Super Contributor
  • ***
  • Posts: 2733
  • Country: ca
Re: New FPGAs from Renesas
« Reply #27 on: November 19, 2021, 07:07:19 pm »
The smallest iCE40 and MachXO2/3 from Lattice are good fits for similar applications. It's not like the products don't exist yet.
Not 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.

Offline mon2

  • Frequent Contributor
  • **
  • Posts: 463
  • Country: ca
Re: New FPGAs from Renesas
« Reply #28 on: November 19, 2021, 10:07:52 pm »
@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.
 

Online asmi

  • Super Contributor
  • ***
  • Posts: 2733
  • Country: ca
Re: New FPGAs from Renesas
« Reply #29 on: November 20, 2021, 01:31:00 am »
@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.
Being 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.

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.
That 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.

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.
Can 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.

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.
Thanks 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...
« Last Edit: November 20, 2021, 01:40:55 am by asmi »
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14476
  • Country: fr
Re: New FPGAs from Renesas
« Reply #30 on: November 20, 2021, 01:40:31 am »
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...
 

Offline mon2

  • Frequent Contributor
  • **
  • Posts: 463
  • Country: ca
Re: New FPGAs from Renesas
« Reply #31 on: November 20, 2021, 01:41:18 am »
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.
 
The following users thanked this post: asmi

Online asmi

  • Super Contributor
  • ***
  • Posts: 2733
  • Country: ca
Re: New FPGAs from Renesas
« Reply #32 on: November 20, 2021, 01:45:06 am »
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...
Underutilizing 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).

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...
So 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.
« Last Edit: November 20, 2021, 01:48:00 am by asmi »
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14476
  • Country: fr
Re: New FPGAs from Renesas
« Reply #33 on: November 20, 2021, 02:02:12 am »
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...
Underutilizing 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).

Certainly, 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.)
 

Offline ali_asadzadeh

  • Super Contributor
  • ***
  • Posts: 1905
  • Country: ca
Re: New FPGAs from Renesas
« Reply #34 on: November 21, 2021, 07:56:37 am »
Guys has anyone get these? any price info would be nice.
ASiDesigner, Stands for Application specific intelligent devices
I'm a Digital Expert from 8-bits to 64-bits
 

Online ataradovTopic starter

  • Super Contributor
  • ***
  • Posts: 11260
  • Country: us
    • Personal site
Re: New FPGAs from Renesas
« Reply #35 on: November 21, 2021, 08:56:09 am »
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.
Alex
 

Offline hans

  • Super Contributor
  • ***
  • Posts: 1640
  • Country: nl
Re: New FPGAs from Renesas
« Reply #36 on: November 27, 2021, 08:58:44 am »
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...

Crosslink-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)
« Last Edit: November 27, 2021, 09:04:06 am by hans »
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 37740
  • Country: au
    • EEVblog
Re: New FPGAs from Renesas
« Reply #37 on: November 29, 2021, 11:54:21 am »
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.

They 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.
 
The following users thanked this post: nctnico, gnuarm, ch_scr, SiliconWizard

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26906
  • Country: nl
    • NCT Developments
Re: New FPGAs from Renesas
« Reply #38 on: November 29, 2021, 05:05:31 pm »
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.

They 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.
A teaser which shows actual hardware would be nice
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Online ataradovTopic starter

  • Super Contributor
  • ***
  • Posts: 11260
  • Country: us
    • Personal site
Re: New FPGAs from Renesas
« Reply #39 on: November 29, 2021, 05:14:34 pm »
A teaser which shows actual hardware would be nice
It 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.
Alex
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14476
  • Country: fr
Re: New FPGAs from Renesas
« Reply #40 on: November 29, 2021, 05:42:31 pm »
A teaser which shows actual hardware would be nice
It 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.

Indeed, 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.
 

Online ataradovTopic starter

  • Super Contributor
  • ***
  • Posts: 11260
  • Country: us
    • Personal site
Re: New FPGAs from Renesas
« Reply #41 on: November 29, 2021, 06:21:15 pm »
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.
Alex
 
The following users thanked this post: Someone

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14476
  • Country: fr
Re: New FPGAs from Renesas
« Reply #42 on: November 29, 2021, 06:30:04 pm »
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.

I 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...
 
The following users thanked this post: Bassman59

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26906
  • Country: nl
    • NCT Developments
Re: New FPGAs from Renesas
« Reply #43 on: November 29, 2021, 06:41:51 pm »
A teaser which shows actual hardware would be nice
It 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.
At 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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Online ataradovTopic starter

  • Super Contributor
  • ***
  • Posts: 11260
  • Country: us
    • Personal site
Re: New FPGAs from Renesas
« Reply #44 on: November 29, 2021, 06:59:44 pm »
I don't want to sound like a Lattice salesman
Not 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.

At 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.
I would not wait for VHDL in this case.
Alex
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26906
  • Country: nl
    • NCT Developments
Re: New FPGAs from Renesas
« Reply #45 on: November 29, 2021, 07:24:09 pm »
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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Online ataradovTopic starter

  • Super Contributor
  • ***
  • Posts: 11260
  • Country: us
    • Personal site
Re: New FPGAs from Renesas
« Reply #46 on: November 29, 2021, 07:40:50 pm »
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.
Alex
 

Online asmi

  • Super Contributor
  • ***
  • Posts: 2733
  • Country: ca
Re: New FPGAs from Renesas
« Reply #47 on: November 29, 2021, 08:13:57 pm »
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.
2.5 stubborn engineers are not a big chunk of a market.

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14476
  • Country: fr
Re: New FPGAs from Renesas
« Reply #48 on: November 29, 2021, 09:51:14 pm »
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.
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26906
  • Country: nl
    • NCT Developments
Re: New FPGAs from Renesas
« Reply #49 on: November 29, 2021, 10:22:02 pm »
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.
See the Gowin example...  :palm: 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.
« Last Edit: November 29, 2021, 10:57:15 pm by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline julian1

  • Frequent Contributor
  • **
  • Posts: 735
  • Country: au
Re: New FPGAs from Renesas
« Reply #50 on: November 29, 2021, 10:22:30 pm »

Also, as I noted with yosys for ICE40, there is seemingly no way to specify any timing constraints.

Do you mean per net/pin?  icetime will report global propagation time, and max clk speed of the design.
 

Online ataradovTopic starter

  • Super Contributor
  • ***
  • Posts: 11260
  • Country: us
    • Personal site
Re: New FPGAs from Renesas
« Reply #51 on: November 30, 2021, 01:19:16 am »
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.
 
Alex
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9890
  • Country: us
Re: New FPGAs from Renesas
« Reply #52 on: November 30, 2021, 02:39:29 am »
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.

They 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.

It 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/4289604

I 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.



 

Online asmi

  • Super Contributor
  • ***
  • Posts: 2733
  • Country: ca
Re: New FPGAs from Renesas
« Reply #53 on: November 30, 2021, 05:36:25 am »
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.

Offline ebclr

  • Super Contributor
  • ***
  • Posts: 2328
  • Country: 00
Re: New FPGAs from Renesas
« Reply #54 on: November 30, 2021, 05:52:12 am »
Forget Renesas, The only thing they do well, it's ignore you
 

Offline DiTBho

  • Super Contributor
  • ***
  • Posts: 3915
  • Country: gb
Re: New FPGAs from Renesas
« Reply #55 on: November 30, 2021, 10:08:06 am »
Very bad experience with their MPUs
The opposite of courage is not cowardice, it is conformity. Even a dead fish can go with the flow
 

Offline gnuarm

  • Super Contributor
  • ***
  • Posts: 2218
  • Country: pr
Re: New FPGAs from Renesas
« Reply #56 on: December 07, 2021, 03:33:50 pm »
Not a huge fan of a separate VDDIO/VDDCORE supplies. I guess as long as there are no stupid sequencing requirements.

Then 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. 
Rick C.  --  Puerto Rico is not a country... It's part of the USA
  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209
 

Offline gnuarm

  • Super Contributor
  • ***
  • Posts: 2218
  • Country: pr
Re: New FPGAs from Renesas
« Reply #57 on: December 07, 2021, 03:47:33 pm »
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

People 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.
Rick C.  --  Puerto Rico is not a country... It's part of the USA
  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209
 

Offline gnuarm

  • Super Contributor
  • ***
  • Posts: 2218
  • Country: pr
Re: New FPGAs from Renesas
« Reply #58 on: December 07, 2021, 03:53:55 pm »
Does it really use yosys? That'd be the first commercial tool doing this that I know of.
Yep. 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.

Tools 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.
Rick C.  --  Puerto Rico is not a country... It's part of the USA
  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209
 

Online ataradovTopic starter

  • Super Contributor
  • ***
  • Posts: 11260
  • Country: us
    • Personal site
Re: New FPGAs from Renesas
« Reply #59 on: December 07, 2021, 04:32:03 pm »
Then 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. 
MAX10 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.
« Last Edit: December 07, 2021, 04:35:33 pm by ataradov »
Alex
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26906
  • Country: nl
    • NCT Developments
Re: New FPGAs from Renesas
« Reply #60 on: December 07, 2021, 04:36:09 pm »
Does it really use yosys? That'd be the first commercial tool doing this that I know of.
Yep. 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.

Tools 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.
You 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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline woofy

  • Frequent Contributor
  • **
  • Posts: 334
  • Country: gb
    • Woofys Place
Re: New FPGAs from Renesas
« Reply #61 on: December 07, 2021, 04:42:24 pm »
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?

yosys for synthesis, nextpnr for place n route.
for verification I use iverilog/vvp and gtkwave.

Offline gnuarm

  • Super Contributor
  • ***
  • Posts: 2218
  • Country: pr
Re: New FPGAs from Renesas
« Reply #62 on: December 07, 2021, 04:42:43 pm »
The smallest iCE40 and MachXO2/3 from Lattice are good fits for similar applications. It's not like the products don't exist yet.
Not 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.

So you want a Goldilocks BGA part.  Fair enough.  We all want what's optimal for our work. 


Quote
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.

I'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. 


Quote
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.

I'm not familiar with this concept... MCUs outside of an FPGA.  What do you put IN your FPGAs?  lol
Rick C.  --  Puerto Rico is not a country... It's part of the USA
  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209
 

Offline gnuarm

  • Super Contributor
  • ***
  • Posts: 2218
  • Country: pr
Re: New FPGAs from Renesas
« Reply #63 on: December 07, 2021, 04:59:49 pm »
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...

Crosslink-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.

I 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.


Quote
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)

I 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.
Rick C.  --  Puerto Rico is not a country... It's part of the USA
  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209
 

Online asmi

  • Super Contributor
  • ***
  • Posts: 2733
  • Country: ca
Re: New FPGAs from Renesas
« Reply #64 on: December 07, 2021, 05:07:00 pm »
I'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. 
Well 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.

I'm not familiar with this concept... MCUs outside of an FPGA.  What do you put IN your FPGAs?  lol
FPGA 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.

Online ataradovTopic starter

  • Super Contributor
  • ***
  • Posts: 11260
  • Country: us
    • Personal site
Re: New FPGAs from Renesas
« Reply #65 on: December 07, 2021, 05:12:02 pm »
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.
I 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.
Alex
 

Offline gnuarm

  • Super Contributor
  • ***
  • Posts: 2218
  • Country: pr
Re: New FPGAs from Renesas
« Reply #66 on: December 07, 2021, 05:37:47 pm »
I don't want to sound like a Lattice salesman
Not 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.

I'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. 

At 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.
I would not wait for VHDL in this case.

I 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.
Rick C.  --  Puerto Rico is not a country... It's part of the USA
  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209
 

Offline gnuarm

  • Super Contributor
  • ***
  • Posts: 2218
  • Country: pr
Re: New FPGAs from Renesas
« Reply #67 on: December 07, 2021, 05:42:51 pm »
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.

It 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.
Rick C.  --  Puerto Rico is not a country... It's part of the USA
  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209
 

Offline gnuarm

  • Super Contributor
  • ***
  • Posts: 2218
  • Country: pr
Re: New FPGAs from Renesas
« Reply #68 on: December 07, 2021, 05:52:00 pm »
Then 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. 
MAX10 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.

I 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. 
Rick C.  --  Puerto Rico is not a country... It's part of the USA
  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209
 

Offline gnuarm

  • Super Contributor
  • ***
  • Posts: 2218
  • Country: pr
Re: New FPGAs from Renesas
« Reply #69 on: December 07, 2021, 05:57:45 pm »
Tools 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.
You 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.

Not sure what you mean by "assigning a clock to a different signal".  If you mean literally just writing

Code: [Select]
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!
Rick C.  --  Puerto Rico is not a country... It's part of the USA
  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209
 
The following users thanked this post: Bassman59

Online ataradovTopic starter

  • Super Contributor
  • ***
  • Posts: 11260
  • Country: us
    • Personal site
Re: New FPGAs from Renesas
« Reply #70 on: December 07, 2021, 06:02:02 pm »
they just allow you to use internal regulators for the core voltage or not.
And 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.

Alex
 

Offline gnuarm

  • Super Contributor
  • ***
  • Posts: 2218
  • Country: pr
Re: New FPGAs from Renesas
« Reply #71 on: December 07, 2021, 06:03:40 pm »
I'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. 
Well 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.

That'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.


I'm not familiar with this concept... MCUs outside of an FPGA.  What do you put IN your FPGAs?  lol
FPGA 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.

I 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? 
Rick C.  --  Puerto Rico is not a country... It's part of the USA
  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209
 

Offline gnuarm

  • Super Contributor
  • ***
  • Posts: 2218
  • Country: pr
Re: New FPGAs from Renesas
« Reply #72 on: December 07, 2021, 06:06:51 pm »
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.
I 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.

That 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. 
Rick C.  --  Puerto Rico is not a country... It's part of the USA
  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209
 

Offline gnuarm

  • Super Contributor
  • ***
  • Posts: 2218
  • Country: pr
Re: New FPGAs from Renesas
« Reply #73 on: December 07, 2021, 06:11:47 pm »
they just allow you to use internal regulators for the core voltage or not.
And 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.

The 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.
Rick C.  --  Puerto Rico is not a country... It's part of the USA
  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209
 

Online ataradovTopic starter

  • Super Contributor
  • ***
  • Posts: 11260
  • Country: us
    • Personal site
Re: New FPGAs from Renesas
« Reply #74 on: December 07, 2021, 06:15:11 pm »
That 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?
Nothing 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.
« Last Edit: December 07, 2021, 06:17:16 pm by ataradov »
Alex
 

Online asmi

  • Super Contributor
  • ***
  • Posts: 2733
  • Country: ca
Re: New FPGAs from Renesas
« Reply #75 on: December 07, 2021, 06:36:38 pm »
That'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.
Of 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.

Online ataradovTopic starter

  • Super Contributor
  • ***
  • Posts: 11260
  • Country: us
    • Personal site
Re: New FPGAs from Renesas
« Reply #76 on: December 08, 2021, 03:27:03 am »
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.
« Last Edit: December 08, 2021, 03:29:16 am by ataradov »
Alex
 

Offline Bassman59

  • Super Contributor
  • ***
  • Posts: 2501
  • Country: us
  • Yes, I do this for a living
Re: New FPGAs from Renesas
« Reply #77 on: December 08, 2021, 05:13:21 pm »
Tools 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.
You 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.

Not sure what you mean by "assigning a clock to a different signal".  If you mean literally just writing

Code: [Select]
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!

This is entirely correct.

You will get the same thing in Verilog.
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26906
  • Country: nl
    • NCT Developments
Re: New FPGAs from Renesas
« Reply #78 on: December 08, 2021, 08:07:26 pm »
But it still sucks that it behaves differently when synthesized (absorbed into a single net) versus being simulated.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline gnuarm

  • Super Contributor
  • ***
  • Posts: 2218
  • Country: pr
Re: New FPGAs from Renesas
« Reply #79 on: December 11, 2021, 02:43:58 am »
That 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?
Nothing 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.

I 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.
Rick C.  --  Puerto Rico is not a country... It's part of the USA
  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209
 

Online ataradovTopic starter

  • Super Contributor
  • ***
  • Posts: 11260
  • Country: us
    • Personal site
Re: New FPGAs from Renesas
« Reply #80 on: December 11, 2021, 02:51:43 am »
I don't recall ever hearing that the Arduino didn't store source code as text files.
I 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.
« Last Edit: December 11, 2021, 02:53:15 am by ataradov »
Alex
 

Offline gnuarm

  • Super Contributor
  • ***
  • Posts: 2218
  • Country: pr
Re: New FPGAs from Renesas
« Reply #81 on: December 11, 2021, 02:57:40 am »
That'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.
Of 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.

I 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 route other signals 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 use other layers 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.
Rick C.  --  Puerto Rico is not a country... It's part of the USA
  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209
 

Online asmi

  • Super Contributor
  • ***
  • Posts: 2733
  • Country: ca
Re: New FPGAs from Renesas
« Reply #82 on: December 11, 2021, 04:41:21 am »
I 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 route other signals than the FPGA signals, so it doesn't use the entire space you are counting as "used". 
There 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).

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 use other layers 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. 
LOL - 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.

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.
It 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.

Offline gnuarm

  • Super Contributor
  • ***
  • Posts: 2218
  • Country: pr
Re: New FPGAs from Renesas
« Reply #83 on: December 11, 2021, 08:47:20 am »
But it still sucks that it behaves differently when synthesized (absorbed into a single net) versus being simulated.

Yes, 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.
Rick C.  --  Puerto Rico is not a country... It's part of the USA
  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26906
  • Country: nl
    • NCT Developments
Re: New FPGAs from Renesas
« Reply #84 on: December 11, 2021, 12:36:59 pm »
But it still sucks that it behaves differently when synthesized (absorbed into a single net) versus being simulated.

Yes, 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. 
That 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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 
The following users thanked this post: Someone

Offline Someone

  • Super Contributor
  • ***
  • Posts: 4531
  • Country: au
    • send complaints here
Re: New FPGAs from Renesas
« Reply #85 on: December 11, 2021, 11:34:37 pm »
But it still sucks that it behaves differently when synthesized (absorbed into a single net) versus being simulated.

Yes, 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. 
That 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.
Just to derail this thread some more, when VHDL delta cycles are making pain: get yourself an alias! (and then watch all your colleagues complain they don't like it).
 

Offline gnuarm

  • Super Contributor
  • ***
  • Posts: 2218
  • Country: pr
Re: New FPGAs from Renesas
« Reply #86 on: December 19, 2021, 12:02:22 pm »
But it still sucks that it behaves differently when synthesized (absorbed into a single net) versus being simulated.

Yes, 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. 
That 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.

I 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.
Rick C.  --  Puerto Rico is not a country... It's part of the USA
  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209
 
The following users thanked this post: Bassman59, SiliconWizard

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26906
  • Country: nl
    • NCT Developments
Re: New FPGAs from Renesas
« Reply #87 on: December 19, 2021, 07:12:42 pm »
But it still sucks that it behaves differently when synthesized (absorbed into a single net) versus being simulated.

Yes, 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. 
That 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.

I 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.
That is not the case if you want to mix & match some VHDL code quickly.
« Last Edit: December 20, 2021, 11:55:15 pm by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline Bassman59

  • Super Contributor
  • ***
  • Posts: 2501
  • Country: us
  • Yes, I do this for a living
Re: New FPGAs from Renesas
« Reply #88 on: December 21, 2021, 12:02:54 am »
But it still sucks that it behaves differently when synthesized (absorbed into a single net) versus being simulated.

Yes, 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. 
That 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.

I 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.
That is not the case if you want to mix & match some VHDL code quickly.

Huh? I don't understand what you mean. What gnuarm says about port formals and actuals is correct.
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26906
  • Country: nl
    • NCT Developments
Re: New FPGAs from Renesas
« Reply #89 on: December 21, 2021, 12:12:29 am »
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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline gnuarm

  • Super Contributor
  • ***
  • Posts: 2218
  • Country: pr
Re: New FPGAs from Renesas
« Reply #90 on: December 21, 2021, 01:29:14 am »
But it still sucks that it behaves differently when synthesized (absorbed into a single net) versus being simulated.

Yes, 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. 
That 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.

I 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.
That is not the case if you to mix & match some VHDL code quickly.

Sorry, 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. 
Rick C.  --  Puerto Rico is not a country... It's part of the USA
  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209
 

Offline gnuarm

  • Super Contributor
  • ***
  • Posts: 2218
  • Country: pr
Re: New FPGAs from Renesas
« Reply #91 on: December 21, 2021, 01:30:04 am »
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.

I don't follow.  What is different about simulation? 
Rick C.  --  Puerto Rico is not a country... It's part of the USA
  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14476
  • Country: fr
Re: New FPGAs from Renesas
« Reply #92 on: December 21, 2021, 02:56:54 am »
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.

I don't follow.  What is different about simulation?

I 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.
« Last Edit: December 21, 2021, 02:58:48 am by SiliconWizard »
 
The following users thanked this post: Bassman59

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26906
  • Country: nl
    • NCT Developments
Re: New FPGAs from Renesas
« Reply #93 on: December 21, 2021, 08:51:06 am »
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.

I don't follow.  What is different about simulation?

I 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.
Ofcourse 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.


Sorry, I don't know what "mix and match" means in VHDL. 
Mix & match = throw some pieces together and make something out of it that works.
« Last Edit: December 21, 2021, 09:06:10 am by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline Cerebus

  • Super Contributor
  • ***
  • Posts: 10576
  • Country: gb
Re: New FPGAs from Renesas
« Reply #94 on: December 21, 2021, 01:32:11 pm »
Hardly worth putting into an entity due to the amount of typing involved.

Us Verilog types don't have that problem, or get repetitive strain injury from coding up a little bit of logic.  :)
Anybody got a syringe I can use to squeeze the magic smoke back into this?
 

Offline gnuarm

  • Super Contributor
  • ***
  • Posts: 2218
  • Country: pr
Re: New FPGAs from Renesas
« Reply #95 on: December 23, 2021, 04:22:13 am »
Hardly worth putting into an entity due to the amount of typing involved.

Us Verilog types don't have that problem, or get repetitive strain injury from coding up a little bit of logic.  :)

Perhaps 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? 
Rick C.  --  Puerto Rico is not a country... It's part of the USA
  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 7737
  • Country: ca
Re: New FPGAs from Renesas
« Reply #96 on: December 23, 2021, 04:29:18 am »
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'.
« Last Edit: December 23, 2021, 04:35:11 am by BrianHG »
 

Offline Cerebus

  • Super Contributor
  • ***
  • Posts: 10576
  • Country: gb
Re: New FPGAs from Renesas
« Reply #97 on: December 23, 2021, 02:47:06 pm »
Hardly worth putting into an entity due to the amount of typing involved.

Us Verilog types don't have that problem, or get repetitive strain injury from coding up a little bit of logic.  :)

Perhaps 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?

I made no comment on that, read what I quoted to comment on and read the smiley afterward.  :palm:
Anybody got a syringe I can use to squeeze the magic smoke back into this?
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26906
  • Country: nl
    • NCT Developments
Re: New FPGAs from Renesas
« Reply #98 on: December 23, 2021, 02:48:46 pm »
That is your punishment for trying to derail the thread into another VHDL versus Verilog debate  >:D

Besides that, creating a Verilog module definition is pretty much the same work as for VHDL.
« Last Edit: December 23, 2021, 02:50:27 pm by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline Cerebus

  • Super Contributor
  • ***
  • Posts: 10576
  • Country: gb
Re: New FPGAs from Renesas
« Reply #99 on: December 23, 2021, 02:52:07 pm »
Ha! May a thousand mismatched entity and architecture statements plague your code!  :)
Anybody got a syringe I can use to squeeze the magic smoke back into this?
 

Online asmi

  • Super Contributor
  • ***
  • Posts: 2733
  • Country: ca
Re: New FPGAs from Renesas
« Reply #100 on: December 23, 2021, 03:09:14 pm »
That is your punishment for trying to derail the thread into another VHDL versus Verilog debate  >:D
Using VHDL is an alright punishment for stubbornness and arrogance that VHDLers tend to demonstrate.

Besides that, creating a Verilog module definition is pretty much the same work as for VHDL.
Not 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. :-DD
 
The following users thanked this post: free_electron

Offline gnuarm

  • Super Contributor
  • ***
  • Posts: 2218
  • Country: pr
Re: New FPGAs from Renesas
« Reply #101 on: December 23, 2021, 05:33:21 pm »
That is your punishment for trying to derail the thread into another VHDL versus Verilog debate  >:D
Using VHDL is an alright punishment for stubbornness and arrogance that VHDLers tend to demonstrate.

Besides that, creating a Verilog module definition is pretty much the same work as for VHDL.
Not 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. :-DD

I 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.
Rick C.  --  Puerto Rico is not a country... It's part of the USA
  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209
 

Offline gnuarm

  • Super Contributor
  • ***
  • Posts: 2218
  • Country: pr
Re: New FPGAs from Renesas
« Reply #102 on: December 23, 2021, 05:39:56 pm »
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'.

Sorry, 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. 
Rick C.  --  Puerto Rico is not a country... It's part of the USA
  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209
 

Online asmi

  • Super Contributor
  • ***
  • Posts: 2733
  • Country: ca
Re: New FPGAs from Renesas
« Reply #103 on: December 23, 2021, 06:23:45 pm »
I 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). 
Being a masochist is pretty much a requirement for using VHDL.

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14476
  • Country: fr
Re: New FPGAs from Renesas
« Reply #104 on: December 23, 2021, 06:25:10 pm »
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.

I don't follow.  What is different about simulation?

I 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.
Ofcourse 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.

Any 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. :)

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.

Knowing 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.
 

Offline Bassman59

  • Super Contributor
  • ***
  • Posts: 2501
  • Country: us
  • Yes, I do this for a living
Re: New FPGAs from Renesas
« Reply #105 on: December 25, 2021, 05:05:02 am »
Sorry, 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. 

That 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 in if statements, the expressions in case statements, 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: [Select]
Swap1 : process (clk, rst_l) is
begin
    if rst_l = '0' then
        X <= '1';
        Y <= '0';
    elsif rising_edge(clk) then
        X <= Y;
        Y <= X;
    end if;
end process Swap1;

Now the same process but with the assignments after the clock edge test reversed:

Code: [Select]
Swap2 : process (clk, rst_l) is
begin
    if rst_l = '0' then
        X <= '1';
        Y <= '0';
    elsif rising_edge(clk) then
        Y <= 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: [Select]
Swap3 : process (clk, rst_l) is
    variable v_foo : std_logic;
begin
    if rst_l = '0' then
        v_foo := '0';
        X <= '0';
        Y <= '0';
    elsif rising_edge(clk) then
        X <= v_foo;
        v_foo := BAR or BLETCH;
        Y <= v_foo;
    end if;
end process Swap3;

versus:

Code: [Select]
Swap4 : process (clk, rst_l) is
    variable v_foo : std_logic;
begin
    if rst_l = '0' then
        v_foo := '0';
        X <= '0';
        Y <= '0';
    elsif rising_edge(clk) then
        v_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.
 

Offline gnuarm

  • Super Contributor
  • ***
  • Posts: 2218
  • Country: pr
Re: New FPGAs from Renesas
« Reply #106 on: December 26, 2021, 04:13:47 am »
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.
Rick C.  --  Puerto Rico is not a country... It's part of the USA
  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209
 

Offline Cerebus

  • Super Contributor
  • ***
  • Posts: 10576
  • Country: gb
Re: New FPGAs from Renesas
« Reply #107 on: December 26, 2021, 02:13:02 pm »
I am saying Verilog can have a problem, not VHDL. 

Why are you arguing about something that, by your own admission, you are largely ignorant?

Sorry, I don't recall my Verilog well enough to debate this.

And for evidence that you are correct in that assertion:

I think he meant the total amount of work including debugging the inevitable mismatched items in the positional parameter list.

Verilog 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:

...
In Verilog, there is no delta delay.

Quote from: IEEE Std 1364-2005 11.3
An explicit zero delay (#0) requires that the process be suspended and added as an inactive event for the current time so that the process is resumed in the next simulation cycle in the current time.
Anybody got a syringe I can use to squeeze the magic smoke back into this?
 
The following users thanked this post: BrianHG

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14476
  • Country: fr
 

Offline gnuarm

  • Super Contributor
  • ***
  • Posts: 2218
  • Country: pr
Re: New FPGAs from Renesas
« Reply #109 on: December 26, 2021, 07:00:38 pm »
I am saying Verilog can have a problem, not VHDL. 

Why are you arguing about something that, by your own admission, you are largely ignorant?

Sorry, I don't recall my Verilog well enough to debate this.

And for evidence that you are correct in that assertion:

I think he meant the total amount of work including debugging the inevitable mismatched items in the positional parameter list.

Verilog hasn't relied on positional parameters since before the 2001 version of the standard.

When 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.


Quote
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:

...
In Verilog, there is no delta delay.

Quote from: IEEE Std 1364-2005 11.3
An explicit zero delay (#0) requires that the process be suspended and added as an inactive event for the current time so that the process is resumed in the next simulation cycle in the current time.

I'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.
Rick C.  --  Puerto Rico is not a country... It's part of the USA
  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209
 

Offline gnuarm

  • Super Contributor
  • ***
  • Posts: 2218
  • Country: pr
Re: New FPGAs from Renesas
« Reply #110 on: December 26, 2021, 07:04:02 pm »
You'll find a more detailed answer here: https://electronics.stackexchange.com/questions/99223/relation-between-delta-cycle-and-event-scheduling-in-verilog-simulation

Thanks for that info.  Looks like Verilog accomplishes the same thing in a very different way.  I hope the user doesn't need to know any of this.
Rick C.  --  Puerto Rico is not a country... It's part of the USA
  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209
 
The following users thanked this post: nctnico

Offline Cerebus

  • Super Contributor
  • ***
  • Posts: 10576
  • Country: gb
Re: New FPGAs from Renesas
« Reply #111 on: December 26, 2021, 08:09:20 pm »
When 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.

No, 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.



Quote
I'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.

Well 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: [Select]
`timescale 1ns / 100ps

module example;

    reg A, B, C, D;

    initial begin
        $dumpfile ("example.lxt");
        $dumpvars (0, example);
        A <= 1;
        B <= 0;
        #30 $finish();
    end
   
   
    initial 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 10
             A <= #10 B;    // assignment happens at time 20, using value of B from just before time 10
    end

endmodule

Yields:

Anybody got a syringe I can use to squeeze the magic smoke back into this?
 

Offline gnuarm

  • Super Contributor
  • ***
  • Posts: 2218
  • Country: pr
Re: New FPGAs from Renesas
« Reply #112 on: December 26, 2021, 11:10:52 pm »
When 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.

No, 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.

This 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. 


Quote
Quote
I'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.

Well 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 .

Delta 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.
Rick C.  --  Puerto Rico is not a country... It's part of the USA
  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209
 

Online ataradovTopic starter

  • Super Contributor
  • ***
  • Posts: 11260
  • Country: us
    • Personal site
Re: New FPGAs from Renesas
« Reply #113 on: December 27, 2021, 12:29:52 am »
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.
Alex
 

Offline Cerebus

  • Super Contributor
  • ***
  • Posts: 10576
  • Country: gb
Re: New FPGAs from Renesas
« Reply #114 on: December 27, 2021, 04:44:59 am »
When 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.

No, 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.

This 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. 

I don't think that it has dawned on your yet that the "typing thing" was a joke!

Quote
Quote
Quote
I'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.

Well 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 .

Delta 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.

That'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.
Anybody got a syringe I can use to squeeze the magic smoke back into this?
 

Offline Cerebus

  • Super Contributor
  • ***
  • Posts: 10576
  • Country: gb
Re: New FPGAs from Renesas
« Reply #115 on: December 27, 2021, 04:49:43 am »
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.

Given 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.
Anybody got a syringe I can use to squeeze the magic smoke back into this?
 

Offline gnuarm

  • Super Contributor
  • ***
  • Posts: 2218
  • Country: pr
Re: New FPGAs from Renesas
« Reply #116 on: December 27, 2021, 03:28:49 pm »
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.

Like virtually every company, they will release info in due time as they see fit. 
Rick C.  --  Puerto Rico is not a country... It's part of the USA
  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14476
  • Country: fr
Re: New FPGAs from Renesas
« Reply #117 on: December 27, 2021, 06:18:47 pm »
And due to the fab congestion these days, releasing a brand new line of ICs is likely to take longer than usual.
 

Offline mark03

  • Frequent Contributor
  • **
  • Posts: 711
  • Country: us
Re: New FPGAs from Renesas
« Reply #118 on: December 27, 2021, 06:29:49 pm »
Given 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.

Crosslink-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.
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14476
  • Country: fr
Re: New FPGAs from Renesas
« Reply #119 on: December 27, 2021, 06:37:22 pm »
Given 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.

Crosslink-NX parts are sort-of available now (at least last time I checked at DK/Mouser), and they are new.

Yeah, but not nearly as "new". Crosslink-NX was announced in very early 2020, so, that's almost 2 years ago. =)

 

Offline gnuarm

  • Super Contributor
  • ***
  • Posts: 2218
  • Country: pr
Re: New FPGAs from Renesas
« Reply #120 on: December 27, 2021, 07:40:10 pm »
Given 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.

Crosslink-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.

I 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. 
Rick C.  --  Puerto Rico is not a country... It's part of the USA
  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209
 

Offline LostTime77

  • Contributor
  • !
  • Posts: 13
  • Country: us
Re: New FPGAs from Renesas
« Reply #121 on: January 03, 2022, 07:24:34 pm »
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.
« Last Edit: January 03, 2022, 07:42:52 pm by LostTime77 »
 

Offline gnuarm

  • Super Contributor
  • ***
  • Posts: 2218
  • Country: pr
Re: New FPGAs from Renesas
« Reply #122 on: January 05, 2022, 07:45:58 am »
It's Not Invented Here syndrome. Lattice spent $65 million acquiring SiliconBlue years ago and forgot (intentionally, I suspect) to allocate any capital for new R&D. They made a few stupidly tiny chips - the UltraLite, LitePlus, whatever - but they refuse to port them to a newer process, add better features, or anything like that. Claire Wolf's contribution of icestorm+etc was the best thing that ever happened to Lattice and they did nothing in response to it. Now they're being blatantly ripped off by GOWIN.

That'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.

They have added 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.


Quote
Now they can't even keep their chips in proper production - try to buy a reel of any iCE40 other than the <2k LUT joke series.

In spite of that, I'm blown away by their stock price and valuation. They barely make any money, and yet they've gone from $5 when I bought and sold a couple shares in 2018 to $75 today. Seems like slightly growing revenue and the M&A factor are why they're priced so high.

I can't find the reference, but there's an old economic story or historical analysis of corporations that were notable in the 1920s or 1930s. All of the big performers tended not to stay successful for more than 3-4 years before fading back into mediocrity.

You 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?
Rick C.  --  Puerto Rico is not a country... It's part of the USA
  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209
 

Offline LostTime77

  • Contributor
  • !
  • Posts: 13
  • Country: us
Re: New FPGAs from Renesas
« Reply #123 on: January 05, 2022, 06:48:03 pm »
I just poked my FAE again last night to get more information. Again, under NDA, so I can't reveal much. However, the roadmap looks extremely interesting. The LUT implementation is also very interesting. Yes, they will be eating all of Lattice's lunch with regards to the ice40 series in the near future. Very excited.
« Last Edit: January 05, 2022, 06:52:10 pm by LostTime77 »
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26906
  • Country: nl
    • NCT Developments
Re: New FPGAs from Renesas
« Reply #124 on: January 05, 2022, 08:55:28 pm »
I just poked my FAE again last night to get more information. Again, under NDA, so I can't reveal much. However, the roadmap looks extremely interesting. The LUT implementation is also very interesting. Yes, they will be eating all of Lattice's lunch with regards to the ice40 series in the near future. Very excited.
How about tooling? Any indication they are going to add support for VHDL?
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline LostTime77

  • Contributor
  • !
  • Posts: 13
  • Country: us
Re: New FPGAs from Renesas
« Reply #125 on: January 06, 2022, 12:43:51 am »
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.
 

Online ataradovTopic starter

  • Super Contributor
  • ***
  • Posts: 11260
  • Country: us
    • Personal site
Re: New FPGAs from Renesas
« Reply #126 on: January 06, 2022, 01:42:57 am »
Was LostTime77 a salesman from Renesas or something? He sure sounded like one.

Edit: I've got email from LostTime77:
Quote
I am LostTIme77, and I am not sure what my username appears like on your end. There is probably “banned” somewhere. No, I am not a Renesas rep, I am genuinely just a very passionate / excited engineer especially towards the new FPGA situation. It’s unfortunate that sometimes you may look like a marketer if your views are biased one way. However, I believe my views are not biased and are based on fact. Dialog has some new parts coming out that I believe are vastly superior in a use case of mine and in this particular niche segment. Regardless, I will try and tone it down a bit in any subsequent posts.
 
As to why I am banned. There seems to be issues / bugs in the forums still or they are just cautious. I went to change my account email after my last post, because I noticed it was using an old email. After the change, it deactivated my account and asked me to reactivate it, so I tried. When I logged in, it said my account was banned. Not sure why. I am reaching out to eevblog-official. However, the last time I reached out to them for an issue, it took them 2 weeks to respond. Therefore, I won’t be able to post again for a while.
« Last Edit: January 06, 2022, 03:24:38 am by ataradov »
Alex
 

Offline gnuarm

  • Super Contributor
  • ***
  • Posts: 2218
  • Country: pr
Re: New FPGAs from Renesas
« Reply #127 on: January 06, 2022, 03:54:08 am »
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.
Rick C.  --  Puerto Rico is not a country... It's part of the USA
  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209
 

Offline Cerebus

  • Super Contributor
  • ***
  • Posts: 10576
  • Country: gb
Re: New FPGAs from Renesas
« Reply #128 on: January 06, 2022, 04:27:23 pm »
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.

Well, judging from your photo in your avatar you're only about 18" tall so was it an unfair observation?  :-DD

Quote
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.

In 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.
Anybody got a syringe I can use to squeeze the magic smoke back into this?
 

Offline Simon

  • Global Moderator
  • *****
  • Posts: 17816
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: New FPGAs from Renesas
« Reply #129 on: January 06, 2022, 08:02:15 pm »
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.
 
The following users thanked this post: nctnico

Offline Cerebus

  • Super Contributor
  • ***
  • Posts: 10576
  • Country: gb
Re: New FPGAs from Renesas
« Reply #130 on: January 06, 2022, 08:06:14 pm »
Cool, thanks for taking a look Simon.
Anybody got a syringe I can use to squeeze the magic smoke back into this?
 

Offline up8051

  • Frequent Contributor
  • **
  • Posts: 288
  • Country: pl
Re: New FPGAs from Renesas
« Reply #131 on: April 05, 2022, 05:58:48 pm »
Any new information on chip availability?
 

Offline free_electron

  • Super Contributor
  • ***
  • Posts: 8517
  • Country: us
    • SiliconValleyGarage
Re: New FPGAs from Renesas
« Reply #132 on: April 05, 2022, 06:10:31 pm »
The website mentions GreenPak. those are Silego devices. ( mixed signal FPGA ) ... interesting
Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 

Offline chris_leyson

  • Super Contributor
  • ***
  • Posts: 1541
  • Country: wales
Re: New FPGAs from Renesas
« Reply #133 on: April 05, 2022, 07:35:06 pm »
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.
 

Offline free_electron

  • Super Contributor
  • ***
  • Posts: 8517
  • Country: us
    • SiliconValleyGarage
Re: New FPGAs from Renesas
« Reply #134 on: April 05, 2022, 08:43:28 pm »
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 ...
Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 

Offline gnuarm

  • Super Contributor
  • ***
  • Posts: 2218
  • Country: pr
Re: New FPGAs from Renesas
« Reply #135 on: April 06, 2022, 02:31:59 am »
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.

Well, judging from your photo in your avatar you're only about 18" tall so was it an unfair observation?  :-DD

Actually, that's is pretty funny.  lol
Rick C.  --  Puerto Rico is not a country... It's part of the USA
  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209
 

Offline gnuarm

  • Super Contributor
  • ***
  • Posts: 2218
  • Country: pr
Re: New FPGAs from Renesas
« Reply #136 on: April 06, 2022, 02:34:55 am »
The website mentions GreenPak. those are Silego devices. ( mixed signal FPGA ) ... interesting

One 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.
Rick C.  --  Puerto Rico is not a country... It's part of the USA
  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209
 

Offline kleiner Rainer

  • Regular Contributor
  • *
  • Posts: 108
  • Country: de
  • Rainer DG1SMD JN48ts
Re: New FPGAs from Renesas
« Reply #137 on: April 06, 2022, 03:16:57 pm »
One 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.

Some 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
 
The following users thanked this post: barycentric

Offline uer166

  • Frequent Contributor
  • **
  • Posts: 892
  • Country: us
Re: New FPGAs from Renesas
« Reply #138 on: April 07, 2022, 02:43:03 am »
One 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.

Some 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

Cool 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.
 

Offline gnuarm

  • Super Contributor
  • ***
  • Posts: 2218
  • Country: pr
Re: New FPGAs from Renesas
« Reply #139 on: April 22, 2022, 12:12:11 pm »
FMEA?
Rick C.  --  Puerto Rico is not a country... It's part of the USA
  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209
 

Offline josuah

  • Regular Contributor
  • *
  • Posts: 119
  • Country: fr
    • josuah.net
Re: New FPGAs from Renesas
« Reply #140 on: April 22, 2022, 12:43:39 pm »
The big news head-up says "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/presentation

That would match Japanese's financial year schedule:

Estimated launch date: Aug/Sep/Oct/Nov 2022.
 

Offline mac.6

  • Regular Contributor
  • *
  • Posts: 225
  • Country: fr
Re: New FPGAs from Renesas
« Reply #141 on: April 23, 2022, 10:20:55 am »
FMEA?;;..
Failure Mode and Effect Analysis. Functional safety stuff.
 

Offline gnuarm

  • Super Contributor
  • ***
  • Posts: 2218
  • Country: pr
Re: New FPGAs from Renesas
« Reply #142 on: April 26, 2022, 01:44:55 am »
The big news head-up says "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/presentation

That would match Japanese's financial year schedule:

Estimated launch date: Aug/Sep/Oct/Nov 2022.

Actually, 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. 
Rick C.  --  Puerto Rico is not a country... It's part of the USA
  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209
 

Offline josuah

  • Regular Contributor
  • *
  • Posts: 119
  • Country: fr
    • josuah.net
Re: New FPGAs from Renesas
« Reply #143 on: May 12, 2022, 02:41:51 pm »
Actually, the fiscal year is whatever the company chooses.

From https://www.renesas.com/sg/en/about/investor-relations/event/presentation/archive past 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.
 

Offline axemaster

  • Contributor
  • Posts: 37
  • Country: us
Re: New FPGAs from Renesas
« Reply #144 on: May 13, 2022, 06:52:34 pm »
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.
 
The following users thanked this post: Smokey

Offline josuah

  • Regular Contributor
  • *
  • Posts: 119
  • Country: fr
    • josuah.net
Re: New FPGAs from Renesas
« Reply #145 on: May 13, 2022, 09:53:47 pm »
I've worked with Dialog Semiconductor microcontrollers before... their documentation is just awful. So many outright mistakes, missing information [...]

Too bad! I was glad to see a lower-end FPGA, but the iCE40 is probably already that to some extent...
 

Offline brouhaha

  • Newbie
  • Posts: 7
  • Country: us
ForgeFPGA configuration memory, and product availability
« Reply #146 on: May 24, 2022, 06:57:09 pm »
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.
 

Online ataradovTopic starter

  • Super Contributor
  • ***
  • Posts: 11260
  • Country: us
    • Personal site
Re: New FPGAs from Renesas
« Reply #147 on: May 24, 2022, 08:00:34 pm »
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.
Alex
 

Offline brouhaha

  • Newbie
  • Posts: 7
  • Country: us
Re: New FPGAs from Renesas
« Reply #148 on: May 24, 2022, 09:24:42 pm »
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.
 

Offline josuah

  • Regular Contributor
  • *
  • Posts: 119
  • Country: fr
    • josuah.net
Re: New FPGAs from Renesas
« Reply #149 on: May 25, 2022, 02:44:51 pm »
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.
« Last Edit: May 27, 2022, 01:41:14 pm by josuah »
 

Online ataradovTopic starter

  • Super Contributor
  • ***
  • Posts: 11260
  • Country: us
    • Personal site
Re: New FPGAs from Renesas
« Reply #150 on: May 25, 2022, 03:33:09 pm »
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?
Alex
 

Offline josuah

  • Regular Contributor
  • *
  • Posts: 119
  • Country: fr
    • josuah.net
Re: New FPGAs from Renesas
« Reply #151 on: May 27, 2022, 02:20:57 pm »
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 what FOMU and TinyFPGA did, but using the OTP storage for the bootloader instead...

Booting with "BOOT" button pressed:

Code: [Select]
                                 ┏━━━━bootloader━━━━ OTP storage (bootloader)
                                 v
USB port ───────X─────── FPGA (empty) ──────X─────── FLASH (empty)
                                 │
                                 X
                                 │
                            rest of the
                             hardware
Code: [Select]
                                 ┌─────────X──────── OTP storage (bootloader)
                                 │
USB port ━━━design━━━> FPGA (bootloader) ━━design━━> FLASH (design)
                                 │
                                 X
                                 │
                            rest of the
                             hardware

Booting with "BOOT" button released:

Code: [Select]
                                 ┌─────────X──────── OTP storage (bootloader)
                                 │
USB port ───────X─────── FPGA (empty) <━━━design━━━━ FLASH (design)
                                 │
                                 X
                                 │
                            rest of the
                             hardware
Code: [Select]
                                 ┌─────────X──────── OTP storage (bootloader)
                                 │
USB port ───────X─────── FPGA (design) ───────X───── FLASH (design)
                                 ^
                                 ┃
                                 v
                            rest of the
                             hardware

A 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.
« Last Edit: November 17, 2022, 02:04:00 pm by josuah »
 

Online ataradovTopic starter

  • Super Contributor
  • ***
  • Posts: 11260
  • Country: us
    • Personal site
Re: New FPGAs from Renesas
« Reply #152 on: May 27, 2022, 04:01:56 pm »
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.
Alex
 

Offline josuah

  • Regular Contributor
  • *
  • Posts: 119
  • Country: fr
    • josuah.net
Re: New FPGAs from Renesas
« Reply #153 on: May 27, 2022, 06:32:43 pm »
Understood.
A traffic cop such as a tiny FPGA chip is no fit for a highway like USB.
Thank you for the feedback.
 

Offline Sal Ammoniac

  • Super Contributor
  • ***
  • Posts: 1672
  • Country: us
Re: New FPGAs from Renesas
« Reply #154 on: August 03, 2022, 07:04:14 pm »
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.
Complexity is the number-one enemy of high-quality code.
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14476
  • Country: fr
Re: New FPGAs from Renesas
« Reply #155 on: August 03, 2022, 07:15:51 pm »
Isn't it based on open source tools (or do I confuse this with some other vendor?) like Yosys?
 

Online ataradovTopic starter

  • Super Contributor
  • ***
  • Posts: 11260
  • Country: us
    • Personal site
Re: New FPGAs from Renesas
« Reply #156 on: August 03, 2022, 08:05:37 pm »
The IDE is very fast when synthesizing and generating a bitstream. Orders of magnitude faster than Vivado.
Have you seen the size of this device? It is trivial to synthesize that much.
Alex
 
The following users thanked this post: nctnico

Offline Sal Ammoniac

  • Super Contributor
  • ***
  • Posts: 1672
  • Country: us
Re: New FPGAs from Renesas
« Reply #157 on: August 03, 2022, 11:02:17 pm »
The IDE is very fast when synthesizing and generating a bitstream. Orders of magnitude faster than Vivado.
Have you seen the size of this device? It is trivial to synthesize that much.

I tried synthesizing a tiny bit of Verilog -- about 16 lines... Took 46 seconds in Vivado, 1.5 seconds in this Renesas IDE.
Complexity is the number-one enemy of high-quality code.
 

Online ataradovTopic starter

  • Super Contributor
  • ***
  • Posts: 11260
  • Country: us
    • Personal site
Re: New FPGAs from Renesas
« Reply #158 on: August 04, 2022, 12:02:56 am »
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).
Alex
 

Offline josuah

  • Regular Contributor
  • *
  • Posts: 119
  • Country: fr
    • josuah.net
Re: New FPGAs from Renesas
« Reply #159 on: November 17, 2022, 10:25:51 am »
Someone received the dev board from Mouser: https://hackaday.io/project/184088-goforge-a-renesas-fpga-board
See the comments:

Quote from: EricSmith
I just receeived notice from Mouser that the SLG7DVKFORGE development board I ordered in April has shipped. The shipment is by UPS Ground, so I'll probably get it on Monday. David says he received his already and that it included the SLG47910V-SKT socket adapter and some sample chips. I already have two of the socket adapter and some sample chips, but presumably the DVK will include the newer version of the socket adapter. (Not that the differences are important.)

I still have two of the SLG47910C-SKT socket adapters (with samples) backordered for the 20-pad WCLSP part, but that's of much less interest.

The data sheets for the SLG47910 chip, the development board, the socket adapter, and (presumably) the low-cost evaluation board are still only available on request from Renesas. I've got the 2.1 data sheet and versions of the socket adapter manual for two different revisions of the socket adapter, but I have not yet been able to get the manual for the development board or the evaluation board. I have just emailed Renesas a request for this documentation, and an updated datasheet if there is one newer than revision 2.1 dated 3-Feb-2022.

A new release of the development software became available a few days ago. I use Fedora Linux, which isn't directly supported, so previously I'd installed their Ubuntu version into a virtual machine. With this new release, I tried runing their Debian dpkg through "alien" to convert it to an RPM. A little bit of elbow grease was required to avoid trivial directory ownership conflicts, but I was pleasantly surprised that the resulting RPM works fine on Fedora 36.
 

Offline scotcob

  • Newbie
  • Posts: 1
  • Country: gb
Re: New FPGAs from Renesas
« Reply #160 on: December 21, 2022, 06:44:14 pm »
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-availability

Hope this helps others on status of these devices.
 
The following users thanked this post: nctnico, asmi, josuah

Offline gnuarm

  • Super Contributor
  • ***
  • Posts: 2218
  • Country: pr
Re: New FPGAs from Renesas
« Reply #161 on: December 21, 2022, 08:48:58 pm »
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.
Rick C.  --  Puerto Rico is not a country... It's part of the USA
  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209
 

Offline DCW

  • Newbie
  • Posts: 1
  • Country: ca
    • Sardis Technologies
Re: New FPGAs from Renesas
« Reply #162 on: March 06, 2023, 09:35:11 pm »
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/
 
The following users thanked this post: colorado.rob, SiliconWizard

Online zapta

  • Super Contributor
  • ***
  • Posts: 6190
  • Country: us
Re: New FPGAs from Renesas
« Reply #163 on: January 27, 2024, 03:22:05 am »
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.
 

Online PCB.Wiz

  • Super Contributor
  • ***
  • Posts: 1545
  • Country: au
Re: New FPGAs from Renesas
« Reply #164 on: January 27, 2024, 06:19:50 am »
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 ?
 

Offline up8051

  • Frequent Contributor
  • **
  • Posts: 288
  • Country: pl
Re: New FPGAs from Renesas
« Reply #165 on: January 27, 2024, 01:51:13 pm »
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.

Renesas 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.
 
The following users thanked this post: nctnico, Muxr, scotcob


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf