Author Topic: Timing constraints in open workflow for iCE40UP5K  (Read 2950 times)

0 Members and 2 Guests are viewing this topic.

Online ataradovTopic starter

  • Super Contributor
  • ***
  • Posts: 11904
  • Country: us
    • Personal site
Timing constraints in open workflow for iCE40UP5K
« on: May 12, 2019, 07:08:22 am »
I've got the IceBreaker FPGA board from CrowdSupply yesterday. The board is using iCE40UP5K FPGA, which is supported by the free and open tools.

And so far it all works pretty much as you would expect, except much faster and less yucky than vendor tools.

But one thing became obvious pretty fast - arachne-pnr (Place and Route tool) does not support timing constraints. It looks like the only type of constraint it supports is signal to pin assignment.

So I was wondering, does anyone use the open workflow for anything involved? How do you do that without timing constraints?

I did quick and dirty port of one of my reasonably complex projects that works on MAX10 at 60+ MHz, and the tools successfully generated the binary after some messing around, but the timing report literally said "Timing estimate: 1000064.39 ns (0.00 MHz)" :) And without timing constraints, I would not even know how to approach solving that.

Any other opinions on the open tools are welcome as well.

After looking closer at all the tools, I can see that the amount of work that went into designing all of that is huge.
Alex
 

Offline AndyC_772

  • Super Contributor
  • ***
  • Posts: 4315
  • Country: gb
  • Professional design engineer
    • Cawte Engineering | Reliable Electronics
Re: Timing constraints in open workflow for iCE40UP5K
« Reply #1 on: May 12, 2019, 08:00:33 am »
This is a major, potentially show-stopping question about non-OEM FPGA software that I've never seen addressed.

FPGA manufacturers' software contains a complete timing model of the die. During fitting, every path is analysed to ensure it meets the worst-case timing specifications for the silicon, under all corner cases for voltage, temperature and process variation. Once fitting is complete, the timing analyser can produce a specification for Fmax for each clock, compare it against the requirements you've supplied in the .SDC file, and give a 'yes/no' indication as to whether or not the device is guaranteed to function at the necessary speed.

Without that timing model, it's impossible to know for sure what clock frequency a given design might be able to run at. Even if it works in one device on the lab bench, there's no guarantee that another device from another batch will work without error, or that any device will continue to work when it gets hot, or cold, or if the core voltage varies within the limits of the spec.

Worse: there's no way to ensure that hold time requirements are met, and these don't depend on the clock frequency. Without the ability to check the hold time, it's impossible to know that a given design will work reliably at *any* frequency.

Timing specifications are such an integral part of FPGA design, it beggars belief that anyone might consider trying to reverse-engineer the configuration data format for an FPGA and produce 3rd party tools without first establishing how timing analysis will be done. Without knowledge of the manufacturer's guaranteed timing specs for the die, the best you could ever hope to do would be to demonstrate a device apparently working under lab conditions, but with no way to know if it'll ever work when mass produced.

Ask the tool's author where they got the detailed timing model of the FPGA from, and how they use it. I'm curious to see if you get a satisfactory answer.

Offline iMo

  • Super Contributor
  • ***
  • Posts: 5570
  • Country: va
Re: Timing constraints in open workflow for iCE40UP5K
« Reply #2 on: May 12, 2019, 08:10:16 am »
My observation Icestorm's tools vs Icecube/Radiant (2018):
1. the Icestorm's builds are up to 30% larger
2. the Icestorm's max clock's freqs are up to 30% lower.

Btw, I think they have got a new pnr already in the Icestorm ("nextpnr").
« Last Edit: May 12, 2019, 08:13:06 am by imo »
Readers discretion is advised..
 

Online ataradovTopic starter

  • Super Contributor
  • ***
  • Posts: 11904
  • Country: us
    • Personal site
Re: Timing constraints in open workflow for iCE40UP5K
« Reply #3 on: May 12, 2019, 07:32:56 pm »
My observation Icestorm's tools vs Icecube/Radiant (2018):
1. the Icestorm's builds are up to 30% larger
2. the Icestorm's max clock's freqs are up to 30% lower.
I just experimented a bit with iCEcube2 and this does seem to be the case. But I would not trust Icestorm's timings at all at this point.


Btw, I think they have got a new pnr already in the Icestorm ("nextpnr").
It does not seem like it supports timing constraints either. And it does not seem like it is being widely used. Whatever constitutes "widely" here.
Alex
 

Offline iMo

  • Super Contributor
  • ***
  • Posts: 5570
  • Country: va
Re: Timing constraints in open workflow for iCE40UP5K
« Reply #4 on: May 12, 2019, 07:56:19 pm »
Lattice has changed the naming convention for the primitives in Radiant (supports UP5k) therefore better go directly with Radiant.
Readers discretion is advised..
 

Online ataradovTopic starter

  • Super Contributor
  • ***
  • Posts: 11904
  • Country: us
    • Personal site
Re: Timing constraints in open workflow for iCE40UP5K
« Reply #5 on: May 12, 2019, 10:01:15 pm »
Ok, so I tried the same project in Radiant and Icestorm. The project is very - simple UART TX with 1Kbyte FIFO buffer plus some reset circuitry.  Exact same Verilog code in both cases.

With radiant I've got:
Code: [Select]
   SLICE (est.)      86/2640          3% used
     LUT            163/5280          3% used
     REG            102/5280          1% used

From clk_i                             |             Target |          16.000 ns |         62.500 MHz
                                        | Actual (all paths) |          20.315 ns |         49.225 MHz

Icestorm:
Code: [Select]
LCs          176 / 5280
  DFF        53
  CARRY      38
  CARRY, DFF 38
  DFF PASS   7
  CARRY PASS 17

// Timing estimate: 25.66 ns (38.97 MHz)

I'm slightly disappointed by both (or by the device). The slowest speed grade MAX10 device with the slowest simulation conditions manages to place this thing at ~70 MHz. And 100+ MHz with typical conditions.

Icestorm is very cool. And it would be absolutely usable, even accepting some performance loss. But without timing constraints, it is just a toy, unfortunately.
Alex
 

Online ataradovTopic starter

  • Super Contributor
  • ***
  • Posts: 11904
  • Country: us
    • Personal site
Re: Timing constraints in open workflow for iCE40UP5K
« Reply #6 on: May 13, 2019, 05:20:18 am »
I just ported a bigger project and the results are:

Icestorm:
Code: [Select]
LCs          2229 / 5280
BRAMs        10 / 30

// Timing estimate: 1000064.39 ns (0.00 MHz)

Radiant:
Code: [Select]
LUT           2238/5280         42% used
EBR               20/30           66% used

CLK1:     38.078 ns |         26.262 MHz
CLK2:     32.367 ns |         30.896 MHz

Target for both clocks is 60 MHz. So they are pretty close in utilization. And it looks like Icestorm's timing estimate is very conservative or just plain wrong. There are only so many ways to build the same logic from the same amount of resources. They can't be that different in speed.

It also looks like Radiant failed to properly infer dual-port BRAMs and used 2x more than necessary. But that's a common problem between different tool vendors.
Alex
 

Offline iMo

  • Super Contributor
  • ***
  • Posts: 5570
  • Country: va
Re: Timing constraints in open workflow for iCE40UP5K
« Reply #7 on: May 13, 2019, 06:06:01 am »
In Radiant/IceCube you can use LSE or Synplify Pro - that gives sometimes slightly different results. The Synplify is pretty hidden, you have to set up it in the tools/properties such it works as the synthesis tool. Also after clicking on the Synplify icon in the top bar the Synplify Pro dev environment opens. I've been using SP almost always.

It could be SP will infer the BRAM size properly.
« Last Edit: May 13, 2019, 06:18:27 am by imo »
Readers discretion is advised..
 

Online ataradovTopic starter

  • Super Contributor
  • ***
  • Posts: 11904
  • Country: us
    • Personal site
Re: Timing constraints in open workflow for iCE40UP5K
« Reply #8 on: May 13, 2019, 06:19:16 am »
In Radiant/IceCube you can use LSE or Synplify Pro - that gives sometimes slightly different results. The Synplify is pretty hidden, you have to set up it in the tools such it works as the synthesis tool. Also after clicking on the Synplify icon in the top bar the Synplify Pro environment opens. I've been using SP almost always.

Synplify gives significant utilization reduction, but not much in terms of clock speeds. I guess the chips are just slow. Also Synplify inferred the BRAMs correctly.

Code: [Select]
LUT           1448/5280         27% used
EBR               10/30           33% used

CLK1:        29.689 ns |         33.683 MHz
CLK2:        30.924 ns |         32.337 MHz

The reductions is actually suspicious. I think it may have removed some logic. But I don't really care to investigate, since it is clear that this project will not work at 60 MHz, which is a must here.

Otherwise, it looks like open tools are good enough actually. 
« Last Edit: May 13, 2019, 06:21:02 am by ataradov »
Alex
 

Offline iMo

  • Super Contributor
  • ***
  • Posts: 5570
  • Country: va
Re: Timing constraints in open workflow for iCE40UP5K
« Reply #9 on: May 13, 2019, 06:24:43 am »
The chips are slower than native Lattice one or Xilinx. The speed/utilization penalty against Spartan 6 for example is huge.
The iCE chips come from a 3rd party Lattice acquired some years back. Their architecture is the most simple one you may find in the FPGA world.

With more complex designs ported 1:1 to iCE40 you can hardly plan to go over 30MHz clock reliably. It could be after some optimization 40.

One of the UP5k's positive points is it includes 128kB of single port ram, 8xDSP blocks and 2xSPI + 2xI2C hardened interfaces.

The big drawback is it has got only 15kB of BRAM and therefore sizes >8kB cannot be inferred directly.

PS: HERE is an example of a more complex design built in all three tools - IceStorm, IceCube and Radiant.
« Last Edit: May 13, 2019, 06:50:20 am by imo »
Readers discretion is advised..
 

Offline iMo

  • Super Contributor
  • ***
  • Posts: 5570
  • Country: va
Re: Timing constraints in open workflow for iCE40UP5K
« Reply #10 on: May 17, 2019, 08:07:24 pm »
There is v1.1 of Radiant available, btw.
They claim some improvements.
Readers discretion is advised..
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf