s_frit has quit [Remote host closed the connection]
s_frit has joined #yosys
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
proteusguy has joined #yosys
fsasm has joined #yosys
jakobwenzel has joined #yosys
emeb_mac has quit [Ping timeout: 245 seconds]
m4ssi has joined #yosys
alcorn has quit [Ping timeout: 244 seconds]
togo has joined #yosys
wifasoi has joined #yosys
fsasm has quit [Ping timeout: 244 seconds]
fsasm has joined #yosys
s_frit has quit [Remote host closed the connection]
rohitksingh_work has quit [Ping timeout: 246 seconds]
MoeIcenowy has quit [Quit: ZNC 1.6.5+deb1+deb9u1 - http://znc.in]
MoeIcenowy has joined #yosys
rohitksingh_work has joined #yosys
vup2 is now known as vup
wifasoi has quit [Ping timeout: 252 seconds]
proteusguy has quit [Remote host closed the connection]
wifasoi has joined #yosys
rohitksingh_work has quit [Ping timeout: 268 seconds]
rohitksingh_work has joined #yosys
rohitksingh_work has quit [Client Quit]
proteusguy has joined #yosys
danieljabailey has quit [Quit: ZNC 1.6.6+deb1ubuntu0.1 - http://znc.in]
mirage335 has quit [Ping timeout: 252 seconds]
m4ssi has quit [Quit: Leaving]
wifasoi has quit [Ping timeout: 246 seconds]
mirage335 has joined #yosys
m4ssi has joined #yosys
m4ssi has quit [Ping timeout: 250 seconds]
wifasoi has joined #yosys
kuldeep_ is now known as kuldeep
indy has quit [Ping timeout: 248 seconds]
emeb has joined #yosys
maikmerten has joined #yosys
fsasm has quit [Ping timeout: 255 seconds]
citypw has quit [Ping timeout: 258 seconds]
jevinski_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<maikmerten>
I have a problem in my FPGA design where depending on the random seed the design is either stable or unstable (simulation is always fine). This smells like a metastability problem and I wonder if there are e.g. some hints I can get out of nextpnr on violated setup/hold times
<ZipCPU>
maikmerten: It could also be an issue associated with where outputs are driven from. Outputs registered at the appropriate output driver locations within a chip will have reliable performance.
qu1j0t3 has left #yosys ["WeeChat 0.4.3"]
<ZipCPU>
Outputs driven from combinatorial logic, or driven from somewhere within the chip, are known to produce unstable results such as you have just suggested, since the timing of those results can then be dependent upon the placement of the design.
<tnt>
also output from luts are not glitch free ... which external chips might not like depending on what you drive with them.
<ZipCPU>
+1
<maikmerten>
interesting.
<maikmerten>
so outputs should always be wired through a register?
<ZipCPU>
Not just any register, but one of the IO buffers supplied on the chip
<ZipCPU>
Which chip are you working with, ice40?
<maikmerten>
yup, hx8k
<maikmerten>
on the eval board
<ZipCPU>
Use the SB_IO primitive then
<ZipCPU>
Are you doing anything special with your outputs? DDR or such?
<maikmerten>
no, nothing fancy
<ZipCPU>
Hmm ... a reg should work then.
<maikmerten>
well, the SRAM controller is fancy, but I also got problems just using BRAM for RAM
<ZipCPU>
I think the last I heard, nextpnr was "smart" enough to route registers to the edge of the fabric, but I haven't verified this yet myself
<ZipCPU>
Ooohh, SRAM, nifty!
<ZipCPU>
Need a working SRAM controller? ;)
<tnt>
ZipCPU: it most definitely isn't.
<tnt>
maikmerten: what's the board ? What's the design ?
<ZipCPU>
tnt: It's not smart enough yet?
<tnt>
nope
<ZipCPU>
;/
<ZipCPU>
Okay
<maikmerten>
ZipCPU, hehe, I'm pretty sure your controllers would be quite verified, I suppose ;-)
<tnt>
Also ... your design _does_ meet timing right ? Your clock are constrained ? (because that'd be the first thing to check ...)
<ZipCPU>
Well, gosh <blushes>
<maikmerten>
the f_max according to nextpnr is ~35 MHz, I clock it at 25.125 MHz
<tpb>
Title: GitHub - maikmerten/spu32: Small Processing Unit 32: A compact RV32I CPU written in Verilog (at github.com)
<maikmerten>
(it's more than a CPU core, it can now present its own slides)
<ZipCPU>
Heheh ... nice!
<maikmerten>
and I'm pretty sure my naive approach to Verilog sloppyness and untidyness and overall horror is haunting it
* ZipCPU
considers playing some spooooooky music from Scooby Doo
<maikmerten>
I should totally create a minimal design of just BRAM, boot-ROM, UART and CPU for debugging
<maikmerten>
this currently is a kitchen-sink of features
<ZipCPU>
Don't forget to stuff any debugging code in there as well.
<ZipCPU>
It's hard to debug what you can't see.
<maikmerten>
yeah, although I wonder what that means in terms of hardware. In simulation, I can see everything (the useful horror), but once synthesized, what's debug code there?
<maikmerten>
I don't assume there's a logic analyzer in the FPGA fabric?
<maikmerten>
(with Cyclones it's apparently possible to instrument the FPGA design and read out register state and whatnot)
<ZipCPU>
Not in the fabric itself, but I usually place one into the fabric that I can then use
<tpb>
Title: Getting Started with the Wishbone Scope (at zipcpu.com)
<maikmerten>
meh, my cheap logic analyzer is only 8 channels @ 24 MHz - the usual cheap chinese Cypress-SoC based thing (at least it's well supported in pulseview)
<maikmerten>
perhaps this is finally my excuse to get more serious gear
<maikmerten>
(yeah, I could just use a slower clock, but where's the fun in that)
<ZipCPU>
Add a logic analyzer to your design
<ZipCPU>
Stick it on the bus, and let the CPU operate it
<maikmerten>
yeah, but it's the CPU that in the unstable situations just seems to get awry in interesting ways ;-)
<ZipCPU>
It'd work if there was enough block RAM for both the scope *and* the CPU's instructions
<ZipCPU>
On the other hand, when I debugged the SRAM on my iCE40 iCO board, I left the CPU idle.
wifasoi has quit [Remote host closed the connection]
<tpb>
Title: [WIP] timing: Add minimum delay and hold analysis by daveshah1 · Pull Request #204 · YosysHQ/nextpnr · GitHub (at github.com)
<daveshah>
A rewritten version should come soon. But there's no realistic chance of hold issues on an iCE40
<daveshah>
iCE40 has a lot of hold margin, I've ran picorv32 fine without any global clock routing and loads of skew
<maikmerten>
oh, so it's a robust little fella?
alexhw has quit [Remote host closed the connection]
<maikmerten>
an interesting but annoying observation: Plugged into my notebook at work the HX8K eval board would only successfully start up my design after several tries. At home (plugged into my desktop) it just starts up normally
<maikmerten>
wonder if the notebook is very limiting regarding USB power delivery
<maikmerten>
too bad I didn't have a multimeter with me to check voltages
<maikmerten>
<ZipCPU> maikmerten: It could also be an issue associated with where outputs are driven from. Outputs registered at the appropriate output driver locations within a chip will have reliable performance. <-- soooo, just to make sure my understanding is somewhat correct: By default, signals to "the outside world" are not driven by SB_IO?
<maikmerten>
I assumed (oh, these horrible assumptions!) that SB_IO would be instantiated as needed, and I assumed (oh....) that any signals to pins would need to go through output buffers
<maikmerten>
I further assumed (oh, the pattern!) that by choosing a pin <-> signal assignment, there's no choice on the placement of that buffer
<maikmerten>
(currently, I only instantiate SB_IO for the SRAM data connections to ensure that is set up properly for bidirectional communication)
alcorn has joined #yosys
Jybz has joined #yosys
Forty-Bot has joined #yosys
Laksen has joined #yosys
Jybz has quit [Quit: Konversation terminated!]
<maikmerten>
okay, looking at the iCE Tech library SB_IO has its own flipflops. Using those will yield predictable performance. I figure having other parts of the design drive the output may yield more unpredictable timing depending on placement.