Efinix

[glenenglish]

Oh, well if you are a hobbyist or a student I guess the built in simulator is important.

For serious project syou need a serious simulator. I have a Modelsim maintenance seat but I have let it lapse and will move over to ALDEC. Modelsim seems to have stood still for 15 years ....
glen

[asmi]

Oh, well if you are a hobbyist or a student I guess the built in simulator is important.

For serious project syou need a serious simulator. I have a Modelsim maintenance seat but I have let it lapse and will move over to ALDEC. Modelsim seems to have stood still for 15 years ....
glen

I'm both hobbyist and professional, and Vivado's simulator has been enough for me thus far. I guess real-time image/video processing and signal processing boards I've designed for my commercial customers are not serious enough to warrant "serious" simulator

[Neilm]

NEIL- xilinx cores do that also. that is pretty normal stuff. expect loads of warnings from cores.
-glen

I have not noticed errors from other manufacturers in the past (Xilinx and Altera).

For me the lack of built-in simulator is a big problem.

I have been using a free copy of Modelsim that came with Altera - it seems to work OK. Unfortunatly I am updating a design that didn't have any gate level simulaitons so who knows how well that would work.

Was able to sort out the timing constraints reasonably easily - just have to get it in silicon and test it.

Neil

[glenenglish]

Hi Neil
no errors per say, but warnings certainly. (in cores).
So, you got your timing stuff to close. I have not yet seen any high speed interface demo on efinix, lots of video centric stuff using the MIPI hard blocks which is a pretty much non event for timing since you connect it up externally  and it works. I think the fastest I have seen is the RGMII 1Gbit interface on the eval board which unless you;ve being quite precise with the layout, you do need to ensure the clock is late. I've been using $1 RTL8211FS (because the usually suspects are unobtanium) and that's worked quite well but has no timing tweaks like the $10 TI device.
actually I guess the 200 meg DDR HyperRam eval board interface is getting up there.
like you say, the support is very good.
Neil how fast are your interfaces ? source synch or async ? regards, glen.   

[AndyC_772]

Has anyone looked at the quality of the PLL clocks on a Trion device?

Pk-to-pk jitter seems considerably worse than the data sheet spec, at least on my first board to ever use one. I'd like to know whether it's my layout, my test methodology, or the chip just not meeting the 200ps tOPJIT (PK - PK) spec.

[glenenglish]

Andy does the Trion config  in your application use any sort of wacky divide ? I had a look at the Trion specs and it didnt qualify the measurement configuration.

I would think you can get this looked at very quickly by the Efinix support/factory. Their online forum software setup needs a lift eh ? I've told them....

I have some of these Ti180 devices.. logic cell, for the money they're monsters. The Sapphire RISCV custom instruction setup is useful and easy to use. Bit slower (clock and DMIPS)  than my multicore A53s and R5s on the MPSoC , but I am used to MicroBlaze so similar ecosystem. glen

[AndyC_772]

It's 16M in (which is nice and clean), x48 = 768M for the VCO, then /8 to give 96M out with about 600ps pk-pk jitter.

[KE5FX]

Are these still fabbed at SMIC?

[glenenglish]

Andy, maybe for diagnostic, do your 96 meg generation on two PLLs in the device, bring them out through unrelated clock trees, to pins  then into each side of a mixer and observe on a scope the result....  see if that helps you learn anything about behaviour.

17 years ago I found any clock routed through fabric was hopelessly noisy for driving high speed DACs.
HOWEVER ! - what you are seeing in jitter is ENORMOUS.  600ps ptp on 96 MHz severe.

yes get onto factory support. If you have difficulty finding the right people I know someone.

[ejeffrey]

NEIL- xilinx cores do that also. that is pretty normal stuff. expect loads of warnings from cores.
-glen

I have not noticed errors from other manufacturers in the past (Xilinx and Altera).

Not errors, but I just built basically trivial project for a xilinx FPGA (just a memory block attached to the zynq processor and a couple of IOs) and it produced over 600 warnings.  Altera/Intel is the same way, they actually have a separate class of "critical warnings" that are not hard errors but warnings that maybe you should really pay attention to because normal warnings are so common in vendor code that they are not even worth looking at.  It's maddening, and while I understand some of the reasons why it is different than the software world, but it's still embarrassing and frankly unacceptable, but it is also the reality of FPGA development.

[glenenglish]

Hi ej
yeah same with mpsoc etc /axi/amb connectors.
anyway, so far, so good with Efinix.

WHat can it do for me ? Well currently I seek to deal with the heat. it costs fancy metalwork to deal with the heat,  and the completed Efinix design *will likely *  be lower power, according to power estimator. about half !   
Still, what you pay for with Xilinx is the absolute benchmark  superb quality of the documentation, tools and logicores. Unbeatable.  (disclaimer I am a Xilinx alliance partner) 
Efinix device are low comparative cost, and the tool chain is improving quite quickly. and they seem to listen. 

It will take me a little while to go to being efficient and effective with high level language design which I will need on the Efinix. Fortunately, gates are cheap.  How is it for getting timing closure on a external 64 lane wide 1200 Msps LVDS bus, I dunno yet.

I used to use Microblaze alot. Then I got used to having an A53 core (admittidly running down at 600 megs) and 16 bits of DDR4 attached (600 meg clock) for an otherwise 2 Mbyte requirement.... and being rather haphazard with code efficiency, rooms for giant deug buffers, whole of program updating, etc (I use FreeRTOS+TCP) and having the neon cores if I wanted them- IE that much horsepower in hand gives me upgrade proof capability.  At a heat and complexity cost. The MPSoC is a complex beast- not to be underestimated whatever your skill.

Technique on the efinix will be more high level synthesised cores, and custom instructions on the 200 meg Sapphire RISC-V and  32 MB of HyperRAM.  (200 megs is about what it will do with complex configuration)  .

My feeling is that I am abotu a year ahead from where I really want the Efinix toolchain to be in terms of performance/stability. But if you dont use it and dont push them, it will not advance...
[attach=1]

[AndyC_772]

yes get onto factory support. If you have difficulty finding the right people I know someone.

Thanks to Harald at Efinix (Europe) for help on this one. He suggested updating to the latest patch (3.17) which has some improvements in this area.

He also mentioned that the jitter depends on VCO speed, so I tried reconfiguring the PLL to run the VCO as fast as possible.

It's *much* better now 

[Someone]

He also mentioned that the jitter depends on VCO speed, so I tried reconfiguring the PLL to run the VCO as fast as possible.

Pretty standard across all FPGA vendors.

[glenenglish]

did you see NOV27 another patch out

*** 2022.1.226.3.# patch notes
    -- [Trion] Addresses functionality issues with PLL phase-shifted output
       clocks and post divider = 1 PLL setting [PT-1695, PT-1207, SIP-264, DOC-1019, DOC-1026]
    -- [Trion] Significantly increases F_VCO, F_PFD maximum frequencies for Trion PLLs (not
       including T4, T8F49 & T8F81 devices) [PT-1695, DOC-1026]   
    -- [Titanium] Use classic router (same as used in Efinity 2021.2) by default
    -- [Titanium] Fixes small number of cases where global clocks incorrectly routed
       edge destinations [VPR-1716]
    -- [Titanium] Fixes instantiation of DSP48 with different MODE values [SYN-632]
    -- [Titanium] Fixes functionality issue in certain DSP cascaded cases [SIP-252]
    -- Fixes issue where IP Manager mistakenly deletes Sapphire standalone applications
       folder upon Sapphire IP regeneration [IPM-425]
    -- Fixes jtag_bridge read flash error on MX25L device [PROG-417]
    -- Fixes issue with programmer's JTAG clock speed control [PROG-411]

[AndyC_772]

Yes, that's v2022.1.226.3.17. Seems my support enquiry was timely...!

[glenenglish]

Efinix seems very good at listening.

[AndyC_772]

Bump for this thread now I'm working on another project...

Has anyone seen any issues with temperature stability on Trion devices?

My prototype is working fine on my bench, but falls over when I heat the FPGA with warm air. The underlying problem appears to be that data being clocked into a dual port FIFO is getting corrupted.

Since both sides of the FIFO are clocked from the same PLL output, and all the data and control lines go into the rest of the FPGA core, there's not a great deal I can do w.r.t. timing margins. In any case, I expect the synthesis tool to take care of timing within the device fabric, and provided I keep within the reported Fmax, every chip should work across its entire rated temperature range. That is, after all, the entire purpose of the device timing model that's built into the synthesis tools for any FPGA.

Slowing the design down won't work if the problem is a hold time violation, so although that might be a fix, it's not guaranteed.

I've emailed Efinix support asking for help, but in the meantime, has anyone else encountered any such issues please?

[glenenglish]

how fast are you talking ?
what if you register the data each side ?

almost like its being clocked on the wrong edge.... everything becomes hairy.

[Someone]

My prototype is working fine on my bench, but falls over when I heat the FPGA with warm air. The underlying problem appears to be that data being clocked into a dual port FIFO is getting corrupted.

Since both sides of the FIFO are clocked from the same PLL output,

Obvious/stupid question, but is that instance set for Synchronous clocking?

[AndyC_772]

Update... it wasn't the FIFO after all. Instead it was the SPI interface, which ironically is much slower. Set up on falling edges, sample on rising, so it should 'just work' provided the clock isn't too fast - except it was.

It turns out there are significant differences in the delays getting signals on and off the chip, depending on which pins are used for the clock and/or where the output signal is registered.

I gained about 5ns of additional setup time at the CPU by registering MISO in the I/O ring of the Efinix FPGA, and moving the SPI clock to one of the pins that supports the GCLK input type. You have to do this in order for the clock to be available to the registers in the I/O ring; they can't accept a clock from just anywhere.

I know it's early days and I'm still learning, but it's also quite apparent that there are hardware limitations in the Efinix architecture compared to the Altera parts I've been using for many years. The separate I/O ring is a PITA, frankly, and I can't help but feel that such a new device architecture should have fewer limitations, not more, compared to one that's been around since 2009 (Cyclone IV).

Although I/O pins can just be configured as transparent, there's significant propagation delay through the ring which means it may be necessary to modify the core logic and use the registers in the I/O ring instead just to meet timing. Portability definitely takes a hit; my VHDL code is now logically different from how it was before, and no longer describes the behaviour of the physical device in full.

It's not entirely clear whether the clear distinction between the core logic and the I/O ring is truly architectural (ie. the chip itself is physically different from other FPGAs in this respect), or whether it's a software thing. Why should the synthesis tool NOT be able to see that a logic output is registered, and make use of the register physically located in the I/O ring? Why would the option even exist to register it in the core, then add the delay through an I/O buffer configured to transparent mode?

Waiting patiently (ish) for a new version of the Efinity tool chain to get a tick box for "configure I/O clocks & registers automatically to make best use of them given the design of the core logic".

[glenenglish]

Hi Andy
really good comment , well written
I have pinged my Efinix FAE on this with your message referenced.
It really does affect portability. The tool CAN know, it has all the information to know this.
-glen