<janrinze>
having a strange problem. when I run yosys and arachne-pnr it seems that often i need to re run to get a working binary. are there tools to find out what happened and why some give failing binaries?
<daveshah>
janrinze: are you running icetime? Sounds like a design that is failing timing, or possibly suffering from metastability
<janrinze>
icetime reports that the result is properly within timing requirements.
<janrinze>
any trick to track metastability?
<lutsabound>
Metastability shouldn't keep the design from building
<lutsabound>
Are you getting a binary both ways?
<janrinze>
no of course not. but usually is caused by using different clock domains.
<janrinze>
only using one clock domain here.
<janrinze>
and it is only 30 MHz.
<lutsabound>
Metastability can also be caused by asynchronous inputs
<lutsabound>
How Are you generatinf your 30mhz clock? Did you use icepll?
<janrinze>
I use as many register latching as necessary. doing things in 'always@(posedge clk)'
<janrinze>
icepll for 120 Mhz and then divide by 4
<daveshah>
It's possibly the divide by four that's causing problems
<daveshah>
What board are you using BTW?
<janrinze>
icoboard
<daveshah>
Great, that doesn't have any known issues (some boards have dodgy PLL supplies causing these kind of issues)
<janrinze>
hx8k + 1MB SRAM board
<daveshah>
Roughly, what is your design?
<janrinze>
often re running arachne-pnr with -r fixes the issue
<daveshah>
Yeah. That normally happens in cases where timing is a bit marginal
<janrinze>
design is a 16 bit CPU plus I/O (vga and keyboard.)
<daveshah>
Are you doing anything like negative edge clocks, etc, internally?
<janrinze>
Yes, as a matter of fact I do.
<daveshah>
icetime won't analyse them well
<daveshah>
I suspect the timing is marginal
<daveshah>
Best to try and run at a reduced clock frequency, and see if every design works
<daveshah>
Ideally using a clock straight from the PLL, without a divider
<janrinze>
This already is the reduce frequency .. used to be able to run at 36 MHz easily.
<daveshah>
Personally I'd try and get everything running on the same clock edge
<lutsabound>
Might need a timing optimiEd placer ...
<daveshah>
My guess is it is the negative edge clocks causing the problems
<janrinze>
yes, i understand. I will try to find an alternate solution.
<janrinze>
Would it be smarter to clock everything with the pll at 120 MHz and add a 4 phase coding?
<janrinze>
the code would be one hot.
<daveshah>
120MHz is really pushing the ice40
<daveshah>
Personally I'd clock everything at 30MHz, positive edge
<daveshah>
That's going to be by far the easiest approach
<janrinze>
I had a design working very well at 65 MHz
<janrinze>
other type of system though
<janrinze>
hx8k breakout board
<daveshah>
Yeah, for a CPU I think that's really the upper limit
<janrinze>
i hear about 100MHz cpu designs on hx8k.. bogus, you think?
<janrinze>
could very well be.. unless heavily pipelined system maybe?
<janrinze>
After placement:
<janrinze>
BRAMs 0 / 32
<janrinze>
PLBs 739 / 960
<janrinze>
PIOs 67 / 206
<daveshah>
Maybe, if you're really careful with design. VexRiscv goes up to about 80MHz, but in a small config with low instructions per clock
<janrinze>
i can do 1 instruction/clock mostly.
<janrinze>
exceptions are the 2 word instructions , jumps, branches and of course multiply and divide.
<daveshah>
Do you have any pipelining?
<janrinze>
if prefetching the instruction counts then yes ;-)
<daveshah>
Otherwise, sounds like 30-40MHz is probably a realistic target
<janrinze>
load/store and jumps all will be a second stage.
<janrinze>
and it runs of the external SRAM.
<janrinze>
VexRiscv smallest (RV32I, 0.52 DMIPS/Mhz) that's what you mean, right?
<janrinze>
it has a 32 bit bus to the block ram, i guess..
<daveshah>
Yeap that's the config I was looking at
<daveshah>
Not having external ram makes things a lot faster and easier
<janrinze>
at first I worried that the 16 x 16bit registers were the culprit but that seems to be hardly a problem
<janrinze>
time sharing the bus with vga is no big issue either, it only needs to fetch a word once every 16 clock cycles.
<janrinze>
So i lose only 6.25 % of the bandwidth to the vga at 512x384@60Hz.
<daveshah>
Yeah, although the resulting multiplexers will increase the critical path delay
<janrinze>
10 ns SRAM.. that has a bit of leeway.
<janrinze>
when using 30 MHz the memory cycle is 33.3 ns
<daveshah>
Yeah, but you have logic around that, bus turnaround time, etc
<janrinze>
pin delay is about 5 ns, right? so that still is more than 20 ns for the SRAM
<daveshah>
There's logic delay too of course
<janrinze>
yes but that is a lot less, at least according to icetime.
<daveshah>
But remember that icetime does not take into account the SRAM delay, nor does it consider negative edge clocks properly
<janrinze>
true. I only use the negative edge for the write enable signal because it requires the address to settle first.
<janrinze>
i know that some FPGA have multi phase clock outputs. That could be a lot more stable.
<janrinze>
lutsabound: the nwr signal is supposed to be low during the last half of the memory cycle. So only on negative edge would stretch it into the second half of the next memory cycle.
<janrinze>
daveshah: it seems that icepll choses not to use global output but pllcore. would that affect the system adversely too?
<daveshah>
Possibly, but the core signal will be routed straight onto a global anyway