<dpiegdon>
I was able to get this running with arachnepnr easily,
<dpiegdon>
but on nextpnr, which is timing driven, I always get the error: ERROR: timing analysis failed due to presence of combinatorial loops, incomplete specification of timing ports, etc.
<dpiegdon>
which makes sense, I guess. but is there a way to tell nextpnr to ignore timing here? or alltogether?
<dpiegdon>
(I have tried --no-tmdriv)
lutsabound has joined #yosys
<daveshah>
dpiegdon: use --force
<dpiegdon>
daveshah: ok, then the error is reduced to a warning, but no output file is generated.
<daveshah>
You need --asc output.asc to create any output
<dpiegdon>
damn - copy and paste error
<dpiegdon>
thanks!
<dpiegdon>
yes, that works. ringing at 322MHz :)
brasilino has joined #yosys
<MoeIcenowy>
by the way is it a way to evalulate the frequency of such a ring oscillator?
<MoeIcenowy>
can icetime do it?
<sorear>
with the icetime database it is possible to produce a conservative lower limit for the frequency (upper bound on delay of the closed-loop path)
<sorear>
ring oscillators are very sensitive to things like temperature (and are frequently used as sensors)
<sorear>
a more sophisticated timing analysis (for hold times) would also give you a lower bound on the delay → upper limit for the frequency over the operating voltage/temperature range
m4ssi has quit [Remote host closed the connection]
fsasm has joined #yosys
<dpiegdon>
but icetime does not produce valid results here. neither for nextpnr nor for arachnepnr. it *did* produce some valid results for an earlier example. i am going to look into this a bit.
<dpiegdon>
so for the original version from clifford, icetime shows the (~correct) value of 8.92 MHz. but only when using arachnepnr, not for nextpnr. also when reducing the delay line, the value is rougly the lower bound, as described by sorear.
<dpiegdon>
but when i strip the example to only the ring oscillator (remove freq counter and control), icetime is clueless and shows 0MHz.
<dpiegdon>
the oscillator *does* work, though
<dpiegdon>
so i assume icetime does somehow uses the freq-counter logic loop to count the generated frequency.