Lattice iCE40 Ultra internal oscillator

[davorin]

Stupid me...it doesn't start with the first byte or word, but with the last one in a row....

The order of the hex bytes have to be swapped ;-)

So:

Code: [Select]

defparam rg_ram.INIT_0 = 256'h00000004001000150019001d0026002a002e0033003f0043004800540059005d;
becomes:

Code: [Select]

defparam rg_ram.INIT_0 = 256'h005d0059005400480043003f0033002e002a0026001d00190015001000040000;

[jonnyb]

The INIT_* is a bit weird...and undocumented. See Clifford's reply here https://stackoverflow.com/questions/41499494/how-can-i-use-ice40-4k-block-ram-in-512x8-read-mode-with-icestorm

[davorin]

Also works now on a iCE40UL-1K board with plenty of space left...well...UART RX/TX is missing

And best of all...can also use iceprog wo program the onboard SPI flash (o;

Here a short clip what it is actually doing, a rotary encoder with pushbutton controlling a WS2812 RGB led ring:




BTW: Is there a standalone SPI flash programmer which works with "iceprog" ?

[iMo]

BTW: Is there a standalone SPI flash programmer which works with "iceprog" ?

Any cheapo FT232H board works

[daveshah]

This is interesting, and relates to how the internal oscillators work.

If you look into the detail, the internal oscillators are actually trimable and on the FPGA I tested go from about 30MHz to 75MHz. Normally, the trim is loaded from OTP at power up, but if you tell iCECUBE that Vpp2V5 is connected to 1.8V (so the OTP is not available), it will connect the oscillator trim to the fabric and hard code it to a middling value instead. If you know what you're doing, you can also manually trim the oscillators (in Radiant or icestorm, but not iCEcube2).

Thus I suspect what is happening is the OTP is either corrupted or not being read correctly (could be QA failure, due to overheating from the rework, Vpp2V5 not being connected, or bad power-up cycles), so the trim values are stuck at all 1s so the oscillator is rammed to its maximum possible frequency, which is about 75MHz for the HFOSC (I haven't analysed the LFOSC in detail, but 16.49kHz sounds like a plausible maximum too).

If you're using iCEcube2, try setting the VPP_2V5_TO_1P8V attribute on the top level module as described on page 170 of the iCEcube2 user guide. This will hardcode the trim values to the midpoint, instead of trying to read them from OTP, and should get the oscillators within 10% at least.

The oscillators are officially specified to be within +/- 5%. Because of the trimming, at room temperature they should actually be considerably better than this, within 1% or so.

[iMo]

I did a measurement on the ice40UP5k with its internal 48MHz oscillator.
UPduino board v2.
The frequency (48MHz/2) was 23.960MHz +/-30kHz jitter (25degC, 3.3V/1.2V).
No trimming.
Running 115k2 uart based on that (forth cpu), no issues seen..

Could it be you've done your measurement on a different pin? Double check your wiring and verilog.

[SiliconWizard]

Haven't thoroughly read all answers, so maybe it has been mentioned, but just in case: a lot of primitives have different names with Radiant compared to icecube. So for those using Radiant:

For instance, the primitive for the low freq osc is now: LSOSC.
You can find that in the online docs for Radiant in "Alphanumeric Primitives List" category.

[iMo]

This should work with Radiant (here is UP5k, it may work with your chip as well provided it is an UP3k or UP5k):

Code: [Select]

module top(
        output wire CLK24,
        output wire NCLK24
);

wire clk;

HSOSC #( .CLKHF_DIV ("0b01") ) // 48MHz DIVIDED by 2
      myOSC(
                     .CLKHFEN(1'b1),
                     .CLKHFPU(1'b1),
                     .CLKHF(clk)
       );
       
assign CLK24   = clk;
assign NCLK24  = !clk;

endmodule

I suppose those signals aren't supposed to be routed outside the chip.

You can route those signals out of the chip, via a standard pin. You have to see a nice square wave.

BTW, Radiant supports UP3/5K chips only, afaik. What chip do you use?

PS: it may happen Radiant places the outputs at different pins when running PAR. You must have the .pdc file (post synthesis constraint file with pin assignments) created and placed properly (.pdc visible in bold in "Post Synthesis Constraint Files" folder in your project manager view; .pdc has to be created in DCE).

Also open the DCE (Device Constraint Editor) in Radiant, go to View menu and then check "Display IO Placement".
Otherwise you will see empty fields with no pin assignments after a regular build (when no .pdc file available).
L. tech support says it is not a bug but a feature, they will enable it by default in the next release..

[daveshah]

To try hardcoded rather than OTP trim in Radiant, just change HSOSC to HSOSC_1P8V in the code.

[iMo]

Hopefully Lattice comes with UP32k soon