Timing constraints in open workflow for iCE40UP5K - Page 1
Forum section: electronics / projects

author: ataradov
author_rank: Super Contributor
timestamp: May 12, 2019, 07:08:22 am
content: 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.

author: AndyC_772
author_rank: Super Contributor
timestamp: May 12, 2019, 08:00:33 am
content: 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.

author: iMo
author_rank: Super Contributor
timestamp: May 12, 2019, 08:10:16 am
content: My observation Icestorm's tools vs Icecube/Radiant (2018):1. the Icestorm's builds are up to 30% larger2. 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").

author: ataradov
author_rank: Super Contributor
timestamp: May 12, 2019, 07:32:56 pm
content: Quote from: imo on May 12, 2019, 08:10:16 amI 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.Quote from: imo on May 12, 2019, 08:10:16 amIt does not seem like it supports timing constraints either. And it does not seem like it is being widely used. Whatever constitutes "widely" here.

author: iMo
author_rank: Super Contributor
timestamp: May 12, 2019, 07:56:19 pm
content: Lattice has changed the naming convention for the primitives in Radiant (supports UP5k) therefore better go directly with Radiant.

author: ataradov
author_rank: Super Contributor
timestamp: May 12, 2019, 10:01:15 pm
content: 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:SLICE (est.) 86/2640 3% usedLUT 163/5280 3% usedREG 102/5280 1% usedFrom clk_i | Target | 16.000 ns | 62.500 MHz| Actual (all paths) | 20.315 ns | 49.225 MHzIcestorm:Code:LCs 176 / 5280DFF 53CARRY 38CARRY, DFF 38DFF PASS 7CARRY 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.

author: ataradov
author_rank: Super Contributor
timestamp: May 13, 2019, 05:20:18 am
content: I just ported a bigger project and the results are:Icestorm:Code:LCs 2229 / 5280BRAMs 10 / 30// Timing estimate: 1000064.39 ns (0.00 MHz)Radiant:Code:LUT 2238/5280 42% usedEBR 20/30 66% usedCLK1: 38.078 ns | 26.262 MHzCLK2: 32.367 ns | 30.896 MHzTarget 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.

author: iMo
author_rank: Super Contributor
timestamp: May 13, 2019, 06:06:01 am
content: 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.

author: ataradov
author_rank: Super Contributor
timestamp: May 13, 2019, 06:19:16 am
content: Quote from: imo on May 13, 2019, 06:06:01 amSynplify 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:LUT 1448/5280 27% usedEBR 10/30 33% usedCLK1: 29.689 ns | 33.683 MHzCLK2: 30.924 ns | 32.337 MHzThe 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.

author: iMo
author_rank: Super Contributor
timestamp: May 13, 2019, 06:24:43 am
content: 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:HEREis an example of a more complex design built in all three tools - IceStorm, IceCube and Radiant.

author: iMo
author_rank: Super Contributor
timestamp: May 17, 2019, 08:07:24 pm
content: There is v1.1 of Radiant available, btw.They claim some improvements.