Being Stuck with Efinix

[gnuarm]

I'm redesigning a rather small board because the FPGA was EOL 8 years ago and I just can't build them anymore.  I wanted to use a Gowin part, but the customer who does business with the US government said "no" to the Chinese company. 

The Trion T13 should do the job, but it's a bit hard to tell because of the use of logic cells for routing.  The T13 is way oversized from the 3 klut part the design was squeezed into, so it should work fine. 

But... I don't like the packaging.  The packaging choices are F256 on 0.8 mm centers and F169 on 0.65 mm centers.  So bad and worse from my perspective.  Both packages are upward compatible with the T20, and not downward compatible at all, so more reason to go with the T13 and not the T8. 

Any advice on routing a 0.8 mm BGA?  I seem to recall this being discussed and someone had laid out a board for JLCPCB and managed to make it work with their design rules, but I'm thinking they got it to work, but the via pads were shrunk or chopped or something.  Anyone remember that thread?

I also really don't like the fact that they make you pay to try out the tools.  I know, you aren't buying the software, you are buying some hardware, but what's the diff?  It's goofy and that makes me wonder about them.

Anyone using their parts?  Do they support VHDL well?  Do they have their own tools or is it a mainline HDL supplier?

[asmi]

Any advice on routing a 0.8 mm BGA?  I seem to recall this being discussed and someone had laid out a board for JLCPCB and managed to make it work with their design rules, but I'm thinking they got it to work, but the via pads were shrunk or chopped or something.  Anyone remember that thread?

No need for any threads, one just need to look at their published capabilities. 0.8 mm pitch BGAs are absolutely not a problem, even with 0.1 mm trace/spacing (their limit is 0.09 mm) you can easily fit a trace between their standard 0.2/0.45 mm vias at 0.8 mm pitch (they have a premium option of 0.2/0.4 mm via if you absolutely require it), not to mention between pads.
If you want a specific example, look at the project in my signature - DDR2 memory module has a pitch of 0.8 mm, it was manufactured by JLCPCB 3 years ago and as you can see there are no manufacturing problems whatsoever.

[woofy]

The Trion T13 should do the job, but it's a bit hard to tell because of the use of logic cells for routing.

Some time ago I ran a custom cpu out on the Xyloni module (Digikey 2134-XYLONI-ND) with a small program to increment a counter, output to the leds, delay and repeat.
It uses 753 LE's and runs at 47MHz.  For comparison, the ice40 HX8k using yosys/nextpnr uses 618 LC's and runs at 80MHz.
The C2 speed grade on the Xyloni board is the slowest one. The C3/C4 grades available on the 144 pin QFP may equal the HX, but I never tried them.

[gnuarm]

The Trion T13 should do the job, but it's a bit hard to tell because of the use of logic cells for routing.

Some time ago I ran a custom cpu out on the Xyloni module (Digikey 2134-XYLONI-ND) with a small program to increment a counter, output to the leds, delay and repeat.
It uses 753 LE's and runs at 47MHz.  For comparison, the ice40 HX8k using yosys/nextpnr uses 618 LC's and runs at 80MHz.
The C2 speed grade on the Xyloni board is the slowest one. The C3/C4 grades available on the 144 pin QFP may equal the HX, but I never tried them.

When you say the Efinix used 753 LEs, does that include the ones used for routing?  My understanding is they don't have dedicated routing, right?  Or am I mixing this up with another brand? 

The iCE40 parts are not so efficient for density.  They provide bare minimums in many ways.  Like no multipliers, 8 bit only memory and the bare minimum in the logic cells.  So I'm not surprised they use more logic elements.

I ran Efinix up the customer flag pole.  I'm not sure anyone is going to salute that either.  Looking one more time at Digikey I found a Xilinx Spartan 7 part in a 196 BGA (1.0 mm) that had a bit of inventory with claimed more arriving in April.  Mouser has inventory on a Lattice ECP5 part in a 256 pin BGA (0.8 mm).  Both will require a separate flash memory.  I think the Lattice part will accept an SPI flash.  I don't know if Xilinx has relaxed their interfaces.  Many years ago, it would only work with special Xilinx compatible flash parts. 

In theory, I could push the responsibility for configuration back to the host motherboard.  Someone else would have to write that code.  But I'd have to set up my test fixtures to do the same thing.  I plan to design a new test fixture for this, that would test eight UUTs at once.  I'd like to use the same FPGA for both the new board and the test fixture. 

[asmi]

  I don't know if Xilinx has relaxed their interfaces.  Many years ago, it would only work with special Xilinx compatible flash parts.

Oh man, you've got to look at a calendar and realize that it's 2023 now, not 2003 anymore

[kmike]

Xilinx now supports a lot of (Q)SPI flash parts:
https://docs.xilinx.com/r/en-US/ug908-vivado-programming-debugging/Spartan-7-Configuration-Memory-Devices

[AndyC_772]

I'm using Efinix now, and probably for the same reason - availability of Altera has simply dried up.

VHDL support is fine, it works without issue.

Availability is remarkably good, under the circumstances, Digi-key have stock of many different device variants, and they're getting more stock all the time which is great to see. You may get a better price elsewhere, though - their European distributor TRS-Star has better pricing.

Re: the tools, just buy the Xyloni dev board, register the serial number and forget all about it. It's a vanishingly tiny expense and complete non-issue; they're just trying to weed out people who will request support but never actually buy any significant number of chips, and I don't blame them.

The tools are basic, clearly still under development, but seem to work OK.

The main quirk seems to be that the core and I/O ring are completely separate, like having two physically distinct devices in the same package. Your VHDL configures the core, but all connections to the outside world go through the I/O ring which must also be set up. In particular, it contains registers that can (optionally) be used on each pin, and connected to any clock which is available at the I/O ring. This means clocks that originate outside the chip on physical pins, or which are outputs from a PLL.

Logically, the PLLs are part of the I/O ring, not the core, and they too must be configured independently of your VHDL. That's a significant difference from other (Altera) devices I've used in the past.

There's a significant difference between speed grades - IIRC grade '2' is very slow and intended for minimum power consumption, but '3' and '4' are closer together and both much faster than '2'.

[asmi]

Xilinx now supports a lot of (Q)SPI flash parts:
https://docs.xilinx.com/r/en-US/ug908-vivado-programming-debugging/Spartan-7-Configuration-Memory-Devices

This list only applies if you want to use indirect programming feature of Vivado to program the memory. For production programming you can use any QSPI memory device which is capable of executing a read command. That said, this list is quite extensive, so there is always something available from it.

[gnuarm]

Any advice on routing a 0.8 mm BGA?  I seem to recall this being discussed and someone had laid out a board for JLCPCB and managed to make it work with their design rules, but I'm thinking they got it to work, but the via pads were shrunk or chopped or something.  Anyone remember that thread?

No need for any threads, one just need to look at their published capabilities. 0.8 mm pitch BGAs are absolutely not a problem, even with 0.1 mm trace/spacing (their limit is 0.09 mm) you can easily fit a trace between their standard 0.2/0.45 mm vias at 0.8 mm pitch (they have a premium option of 0.2/0.4 mm via if you absolutely require it), not to mention between pads.
If you want a specific example, look at the project in my signature - DDR2 memory module has a pitch of 0.8 mm, it was manufactured by JLCPCB 3 years ago and as you can see there are no manufacturing problems whatsoever.

Sorry, what are you assuming for the pad dimensions?  Every layout guide I find for this information seems to be unique, including documents from the same vendor!  Lattice has two different sets of numbers in the SAME document!  Obviously I'm not reading that right.

PCB Layout Recommendations for BGA Packages March 2017 Technical Note TN1074
pages 1 and 3.  The ca256 and BG256 are the same package.  One is the package reference name and the other is the ordering suffix for the part number.  They sure love to make this simple, no??

[gnuarm]

I'm using Efinix now, and probably for the same reason - availability of Altera has simply dried up.

I managed to find a Lattice part with 2,000 in stock and a Xilinx part (1.0 mm package!) with 1,000 in stock.  I'm being told I should use the Lattice part. 

This pisses me off a bit.  It's not like I'm an employee.  They aren't paying me for the redesign.  I'm paying for it just so I have autonomy.  I guess that's not working too well. 

VHDL support is fine, it works without issue.

Availability is remarkably good, under the circumstances, Digi-key have stock of many different device variants, and they're getting more stock all the time which is great to see. You may get a better price elsewhere, though - their European distributor TRS-Star has better pricing.

Re: the tools, just buy the Xyloni dev board, register the serial number and forget all about it. It's a vanishingly tiny expense and complete non-issue; they're just trying to weed out people who will request support but never actually buy any significant number of chips, and I don't blame them.

Yeah, I know, but it's strange.  Support?  They have support???  What is this "support" thing?  I'm not familiar with that.

The tools are basic, clearly still under development, but seem to work OK.

The main quirk seems to be that the core and I/O ring are completely separate, like having two physically distinct devices in the same package. Your VHDL configures the core, but all connections to the outside world go through the I/O ring which must also be set up. In particular, it contains registers that can (optionally) be used on each pin, and connected to any clock which is available at the I/O ring. This means clocks that originate outside the chip on physical pins, or which are outputs from a PLL.

That's not unusual, other than calling it a "ring".  Are you saying FFs in the VHDL can't be in the I/O ring?  They have to be added manually?  That would be very strange.  What about I/O control, like tristate drivers?

Logically, the PLLs are part of the I/O ring, not the core, and they too must be configured independently of your VHDL. That's a significant difference from other (Altera) devices I've used in the past.

I don't know how I would configure a PLL in VHDL.  I guess there are modules to be instantiated?  I believe this design has a PLL.  It's only been 10 years, so it should still be fresh in my mind, right?

There's a significant difference between speed grades - IIRC grade '2' is very slow and intended for minimum power consumption, but '3' and '4' are closer together and both much faster than '2'.

Ok, that's useful to know, even if I don't get to use the part.  Thanks

[gnuarm]

Xilinx now supports a lot of (Q)SPI flash parts:
https://docs.xilinx.com/r/en-US/ug908-vivado-programming-debugging/Spartan-7-Configuration-Memory-Devices

This list only applies if you want to use indirect programming feature of Vivado to program the memory. For production programming you can use any QSPI memory device which is capable of executing a read command. That said, this list is quite extensive, so there is always something available from it.

For a brief microsecond, I thought I could eliminate the flash and let the host board program the FPGA, but I forgot the very first thing - the daughercard has to identify itself.  There can be multiple card types.  So the FPGA has to be programmed to some default state to at least provide the control/status interface.  So that means a flash.  That's why, even a one time programmable FPGA would suit me better.

I assume there are docs that show how to wire this all up to allow the flash to be programmed via a JTAG interface?  Do the tools support programming the flash?

In production the flash would be preprogrammed... but in development the flash will need to be programmed repeatedly and there needs to be provision for updates, if required.  I managed to make this board for 14 years without any field updates, but luck only lasts so long. 

[asmi]

I assume there are docs that show how to wire this all up to allow the flash to be programmed via a JTAG interface?  Do the tools support programming the flash?

Yes, of course they do, but only devices from the list of supported devices which I linked above.

In production the flash would be preprogrammed... but in development the flash will need to be programmed repeatedly and there needs to be provision for updates, if required.  I managed to make this board for 14 years without any field updates, but luck only lasts so long.

Then just stick to whatever flash devices which are supported by the current version of Vivado you are using for your production as well. Take a look at this list, there is quite a lot to choose from, and from multiple vendors so no vendor lock-in either. Remember this indirect programming thing is a feature of Vivado and has nothing to do with FPGA itself. The way it works is they program a temporary bitstream into FPGA which contain a bridge of sorts between JTAG and QSPI memory, and then software uses that bridge to execute commands in the memory like erase, write, read and perhaps some others.

[gnuarm]

I assume there are docs that show how to wire this all up to allow the flash to be programmed via a JTAG interface?  Do the tools support programming the flash?

Yes, of course they do, but only devices from the list of supported devices which I linked above.

In production the flash would be preprogrammed... but in development the flash will need to be programmed repeatedly and there needs to be provision for updates, if required.  I managed to make this board for 14 years without any field updates, but luck only lasts so long.

Then just stick to whatever flash devices which are supported by the current version of Vivado you are using for your production as well. Take a look at this list, there is quite a lot to choose from, and from multiple vendors so no vendor lock-in either. Remember this indirect programming thing is a feature of Vivado and has nothing to do with FPGA itself. The way it works is they program a temporary bitstream into FPGA which contain a bridge of sorts between JTAG and QSPI memory, and then software uses that bridge to execute commands in the memory like erase, write, read and perhaps some others.

I've been using Flash based FPGAs for a long time now and the RAM based programming has changed.  It used to be the configuration interface had to be done in a way that allowed it to also program the flash without the FPGA getting in the way.  Now, the FPGA is taken over, like a virus, allowing the JTAG interface to program the Flash through the FPGA?

Any idea how long that would take for a XC7S15?  I guess it's not that big a deal, since it's only development updates that are important.  As long as this can all be done from Vivado, and not requiring any software work from me, that's fine. 

To update the flash in the field, is there support to put this in software, or to be controlled by another FPGA?  The motherboard has an FPGA (not sure of the type) which is controlled by software under some OS on a CPU board.  We never developed anything to support field updates, but they may get more interested in this.  I don't want to do it.  I just want to design my board and get into production.  I have to redesign the test fixtures and software as it is.   The customer would need to program this. 

[asmi]

I've been using Flash based FPGAs for a long time now and the RAM based programming has changed.  It used to be the configuration interface had to be done in a way that allowed it to also program the flash without the FPGA getting in the way.  Now, the FPGA is taken over, like a virus, allowing the JTAG interface to program the Flash through the FPGA?

Indirect programming via JTAG is a convenience feature, not neccessity. You can still program flash directly if you prefer - just hold FPGA in reset and it won't get in the way as it tristates all IO pins. Of course you will need to devise some sort of jig or connector to connect to flash lines for programming to external programmer, as well as said programmer itself. IMHO it's more trouble than it's worth, unless you have large enough volume to order your QSPI flash devices pre-programmed from the factory, of you use some kind of third-party service provider for that (I seem to recall that Digikey offers such service if you order memory devices from them).

Any idea how long that would take for a XC7S15?  I guess it's not that big a deal, since it's only development updates that are important.  As long as this can all be done from Vivado, and not requiring any software work from me, that's fine. 

I'm not exactly sure, but it's usually tens of seconds, unless you select an option to pre-erase entire memory array, in that case programming time will depend on capacity of that memory device. But it's usually fairly quick unless your JTAG clock is super-slow and/or your target FPGA is large, or you're programming more than just a bitstream - for example, some softcore-based designs store application code in the region of QSPI flash "above" (address-wise) the bitstream. Software-wise you only need Vivado (Lab Edition will be enough for programming) for indirect programming.

To update the flash in the field, is there support to put this in software, or to be controlled by another FPGA?  The motherboard has an FPGA (not sure of the type) which is controlled by software under some OS on a CPU board.  We never developed anything to support field updates, but they may get more interested in this.  I don't want to do it.  I just want to design my board and get into production.  I have to redesign the test fixtures and software as it is.   The customer would need to program this.

Once FPGA programs itself and starts up design, it releases all pins used to talk to QSPI such that you can access them in your design and do whatever you want (including a field update). But for that you need to provide a new bistream somehow. That of course is very application-specific, so it's hard to provide any examples.

Along with field update it's strongly recommended to implement a multiboot to recover in case update fails for some reason. Configuration logic in 7 series FPGAs supports using two bitstreams - one "golden bitstream" which will always contain a "known good" production bitstream, and a second one which will be programmed into the flash during updade. Config logic will first attempt to configure FPGA using updated stream, but if it fails, it will automatically fall back to the "golden" stream. See XAPP1247 for a practical discussion regarding that topic. Of course you will need to ensure your QSPI flash capacity is large enough to store both of those bitstreams at the same time.

[gnuarm]

Programming the flash has to be in system.  Most likely I will have the parts preprogrammed for production, but as updates the customer has to be able to do this in their system from there CPU. 

I'm not looking for complexity.  I like simple.  The flash FPGAs are simple. 

Looking at some designs that use external flash (the Efinix Xyloni board) they simply drive the signals with the FPGA disconnected by a buffer.  The tristate enable is controlled by the FT4232H chip.

In reality, I only have four signals in the interface to program the SPI chip, and a board reset.  The board reset drives the FPGA PROG_N signal (or equivalent).  That should hold the FPGA tristated I would assume (including the SPI signals).  Not easy to dig out of the documentation.  If that's true, then the daughtercard flash could be programmed while in reset, and run normally otherwise, as long as the programming signals are tristated while out of reset.  Or I can add a four bit buffer chip that disconnects the FPGA and the SPI flash when programming (reset asserted).  I just need the main board to hold those signals quiet, or tristate when in reset.

[glenenglish]

0.8mm is easy for standard JLCPCB .

make the vias under the FPGA  0.2mm / 0.48mm and use 0.1mm trace and space to route under FPGA
use 1mm or 1.2mm for 6 layer PCB to keep capacitances between layers high (embedded capacitance) . Preferably  0.1mm between VCCcore and GND.
and extend beyond FPGA region a bit to maximize decoupling.

dont pour tight on inner layers (extra pullback)  --- IE dont make it hard for yourself or the vendor un-necessarily.
relax everyone otherwise FPGA region. can be done in 6 layers if you are smart with VCCIO regions.

[adamarrrrr]

I echo 0.8mm BGA being easily achievable with the standard JLCPCB process (and as a bonus if your board is under 5x5cm, you can get a 6 layer board for under $5 with ENIG and via-in-pad for prototypes). You can also get away with a 4 layer board by routing power smartly on the bottom/3rd layer, or just dedicating the entire 3rd layer to power. Obviously you lose out on any inter-plane capacitance and bottom layer routing/SI becomes a lot trickier because not everything is referenced to ground anymore.

I've only worked with their Ti60 series, but I got my prototype PCB pretty much working 100% first try based on their app notes and reference board, and I NEVER get things right. So +1 to them! The only thing I wasn't able to confirm working was programming the flash through SPI directly. I tried using their 'active' SPI programming method where the FPGA provides the clock signal, and the FT2232 is treated like a slave device (so you don't have to do any disconnecting), but no such luck. I expect this is my fault, as my module uses 0.5mm BTB connectors that seem very averse to hand soldering and alignment and working in general.

Their weird and very-not-streamlined JTAG-bridge solution seemed to work though. It basically involves their software pushing two separate files to the FPGA via JTAG - one is the JTAG bridge that you have to manually generate for your specific design for some reason(?), and the other being your actual file you want to flash to your memory device. I've worked with Lattice/Xilinx parts where the bridge method is literally only one click, so it seems a bit odd. Their software is also VERY SLOW, yet very basic. The synthesis speed is fine, just that opening any menu takes literally 10-30 seconds for some reason, especially the interface designer.

For reference: 0.65mm BGA on a 4 layer board (with 0.35mm vias) from JLCPCB. Unfortunately the smaller vias cost extra $$$ from their standard process.

[gnuarm]

I had decided to go with the T13F256/T20F256 (not a big difference in price).  Then, recently I've read they are now coming out with 100QFP parts!  But... the engineering samples aren't even available until Oct.  Too late for my project.

[AndyC_772]

100QFP? I like that idea, much easier to deal with than the FBGA169 which is the package I've ended up using.

Let's just hope they don't waste half the pins on a MIPI interface this time.

[Edit]: the updated data sheet is on the web site, no MIPI, and there's an internal SPI Flash too.

[gnuarm]

I didn't notice the Flash.  That's pretty sweet!  I just can't wait until October to even get engineering samples. 

[AndyC_772]

Check with Digi-key, their web site says 22nd June for most variants. Just use the I4 variant and you can be up and running next week.

[NorthGuy]

For a brief microsecond, I thought I could eliminate the flash and let the host board program the FPGA, but I forgot the very first thing - the daughercard has to identify itself.  There can be multiple card types.  So the FPGA has to be programmed to some default state to at least provide the control/status interface.  So that means a flash.  That's why, even a one time programmable FPGA would suit me better.

Your FPGA may have one-time programmable fuses which you can read through JTAG, then you don't need flash if your only goal is identification.

Also JTAG allows to build a chain of devices. You can add a small MCU to the chain for identification purposes.

Xilinx will generally work with any QSPI flash. They're all standard. The list of supported flashes is more like product placement thing. Even if Xilinx software refuses working with flash, you can create your own design for flash programming - it's only few hours of work, may be a day ...

Programming flash requires lots of waiting for every row, flash erase also takes time. So you cannot make it faster than the flash chip allows.

[asmi]

Xilinx will generally work with any QSPI flash. They're all standard. The list of supported flashes is more like product placement thing. Even if Xilinx software refuses working with flash, you can create your own design for flash programming - it's only few hours of work, may be a day ...

Xilinx will boot off just about any qspi flash, but if you want to do indirect programming via Vivado/Vitis, you will have to use one of supported parts. To be fair they've recently added a whole bunch of ISSI devices, so it's absolutely not a problem to procure compatible parts.

[gnuarm]

Check with Digi-key, their web site says 22nd June for most variants. Just use the I4 variant and you can be up and running next week.

Digikey is where I'm finding my info.  But I checked again and see that of the six variants in the QFP100 package, the three less expensive variants are not available until October, while the three most expensive variants claim they will have approximately 200 in a week, and the rest in October.

Still, I have an order to fill.  I don't know if I want to put my trust in a supplier.  I had far too much trouble with the last order.

[glenenglish]

Just be careful of which FLASH start in 3 or 4 byte addressing mode and ensure that is compatible with your kit.
Some maintain  a mode change  only until some other instruction gets executed, some maintain the mode change until power cycle or some hardware reset cmd .