Electronics > Projects, Designs, and Technical Stuff
Timing constraints in open workflow for iCE40UP5K
(1/3) > >>
ataradov:
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.
AndyC_772:
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.
iMo:
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").
ataradov:

--- Quote from: imo 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.

--- End quote ---
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.



--- Quote from: imo on May 12, 2019, 08:10:16 am ---Btw, I think they have got a new pnr already in the Icestorm ("nextpnr").

--- End quote ---
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.
iMo:
Lattice has changed the naming convention for the primitives in Radiant (supports UP5k) therefore better go directly with Radiant.
Navigation
Message Index
Next page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod