Monday, 2019-05-13

*** tpb has joined #yosys00:00
*** emeb has left #yosys00:04
*** futarisIRCcloud has joined #yosys01:38
*** gsi__ has joined #yosys02:19
*** gsi_ has quit IRC02:22
*** PyroPeter has quit IRC02:57
*** PyroPeter has joined #yosys03:10
*** citypw has joined #yosys03:59
*** jevinski_ has joined #yosys04:46
*** jevinskie has quit IRC04:47
*** rohitksingh_work has joined #yosys04:51
*** Jybz has joined #yosys05:27
*** Jybz has quit IRC05:36
*** s_frit has quit IRC05:56
*** s_frit has joined #yosys05:56
*** futarisIRCcloud has quit IRC06:08
*** proteusguy has joined #yosys06:11
*** fsasm has joined #yosys06:46
*** jakobwenzel has joined #yosys07:03
*** emeb_mac has quit IRC07:19
*** m4ssi has joined #yosys07:24
*** alcorn has quit IRC07:26
*** togo has joined #yosys07:51
*** wifasoi has joined #yosys08:41
*** fsasm has quit IRC09:15
*** fsasm has joined #yosys09:25
*** s_frit has quit IRC09:38
*** rohitksingh_work has quit IRC10:22
*** MoeIcenowy has quit IRC10:24
*** MoeIcenowy has joined #yosys10:24
*** rohitksingh_work has joined #yosys10:25
*** vup2 is now known as vup10:57
*** wifasoi has quit IRC11:11
*** proteusguy has quit IRC11:45
*** wifasoi has joined #yosys11:59
*** rohitksingh_work has quit IRC12:03
*** rohitksingh_work has joined #yosys12:03
*** rohitksingh_work has quit IRC12:03
*** proteusguy has joined #yosys12:39
*** danieljabailey has quit IRC12:55
*** mirage335 has quit IRC13:08
*** m4ssi has quit IRC13:10
*** wifasoi has quit IRC13:28
*** mirage335 has joined #yosys13:31
*** m4ssi has joined #yosys13:32
*** m4ssi has quit IRC13:49
*** wifasoi has joined #yosys13:49
*** kuldeep_ is now known as kuldeep13:56
*** indy has quit IRC14:17
*** emeb has joined #yosys14:22
*** maikmerten has joined #yosys15:44
*** fsasm has quit IRC15:49
*** citypw has quit IRC16:04
*** jevinski_ has quit IRC16:30
maikmertenI 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 times16:32
ZipCPUmaikmerten: 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.16:33
*** qu1j0t3 has left #yosys16:33
ZipCPUOutputs 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.16:34
tntalso output from luts are not glitch free ... which external chips might not like depending on what you drive with them.16:34
maikmertenso outputs should always be wired through a register?16:36
ZipCPUNot just any register, but one of the IO buffers supplied on the chip16:36
ZipCPUWhich chip are you working with, ice40?16:36
maikmertenyup, hx8k16:36
maikmertenon the eval board16:36
ZipCPUUse the SB_IO primitive then16:36
ZipCPUAre you doing anything special with your outputs?  DDR or such?16:36
maikmertenno, nothing fancy16:37
ZipCPUHmm ... a reg should work then.16:37
maikmertenwell, the SRAM controller is fancy, but I also got problems just using BRAM for RAM16:37
ZipCPUI 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 myself16:37
ZipCPUOoohh, SRAM, nifty!16:38
ZipCPUNeed a working SRAM controller?  ;)16:38
tntZipCPU: it most definitely isn't.16:38
ZipCPUtnt: It's not smart enough yet?16:38
tntmaikmerten: what's the board ? What's the design ?16:38
maikmertenZipCPU, hehe, I'm pretty sure your controllers would be quite verified, I suppose ;-)16:39
tntAlso ... your design _does_ meet timing right ? Your clock are constrained ?  (because that'd be the first thing to check ...)16:39
ZipCPUWell, gosh <blushes>16:39
maikmertenthe f_max according to nextpnr is ~35 MHz, I clock it at 25.125 MHz16:39
tntVGA ?16:40
maikmerten <-- that trainwreck16:40
tpbTitle: GitHub - maikmerten/spu32: Small Processing Unit 32: A compact RV32I CPU written in Verilog (at
maikmerten(it's more than a CPU core, it can now present its own slides)16:40
ZipCPUHeheh ... nice!16:41
maikmertenand I'm pretty sure my naive approach to Verilog sloppyness and untidyness and overall horror is haunting it16:42
* ZipCPU considers playing some spooooooky music from Scooby Doo16:44
maikmertenI should totally create a minimal design of just BRAM, boot-ROM, UART and CPU for debugging16:44
maikmertenthis currently is a kitchen-sink of features16:44
ZipCPUDon't forget to stuff any debugging code in there as well.16:44
ZipCPUIt's hard to debug what you can't see.16:44
maikmertenyeah, 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?16:46
maikmertenI don't assume there's a logic analyzer in the FPGA fabric?16:46
maikmerten(with Cyclones it's apparently possible to instrument the FPGA design and read out register state and whatnot)16:47
ZipCPUNot in the fabric itself, but I usually place one into the fabric that I can then use16:47
maikmertenI guess a poor man's version could be just to throw out some interesting signals to the GPIO headers16:49
tpbTitle: Building A Simple In-Circuit Logic Analyzer (at
ZipCPUThat's not necessarily a poor man's version.  This poor man didn't have an O-scope for many years16:49
tpbTitle: Getting Started with the Wishbone Scope (at
maikmertenmeh, 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)16:52
maikmertenperhaps this is finally my excuse to get more serious gear16:52
maikmerten(yeah, I could just use a slower clock, but where's the fun in that)16:53
ZipCPUAdd a logic analyzer to your design16:53
ZipCPUStick it on the bus, and let the CPU operate it16:53
maikmertenyeah, but it's the CPU that in the unstable situations just seems to get awry in interesting ways ;-)16:55
ZipCPUIt'd work if there was enough block RAM for both the scope *and* the CPU's instructions16:56
ZipCPUOn the other hand, when I debugged the SRAM on my iCE40 iCO board, I left the CPU idle.16:56
*** wifasoi has quit IRC17:04
maikmerten <-- hmmm, that looks fancy17:08
tpbTitle: [WIP] timing: Add minimum delay and hold analysis by daveshah1 · Pull Request #204 · YosysHQ/nextpnr · GitHub (at
daveshahA rewritten version should come soon. But there's no realistic chance of hold issues on an iCE4017:10
daveshahiCE40 has a lot of hold margin, I've ran picorv32 fine without any global clock routing and loads of skew17:10
maikmertenoh, so it's a robust little fella?17:10
*** alexhw has quit IRC17:31
maikmertenan 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 normally17:33
maikmertenwonder if the notebook is very limiting regarding USB power delivery17:33
maikmertentoo bad I didn't have a multimeter with me to check voltages17:34
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?18:07
maikmertenI 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 buffers18:08
maikmertenI further assumed (oh, the pattern!) that by choosing a pin <-> signal assignment, there's no choice on the placement of that buffer18:09
maikmerten(currently, I only instantiate SB_IO for the SRAM data connections to ensure that is set up properly for bidirectional communication)18:12
*** alcorn has joined #yosys18:36
*** Jybz has joined #yosys18:51
*** Forty-Bot has joined #yosys18:52
*** Laksen has joined #yosys19:00
*** Jybz has quit IRC19:25
maikmertenokay, 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.19:35
*** _whitelogger has quit IRC19:44
ZipCPUmaikmerten: Yes.  Using the FF within SB_IO will help to provide more predictable I/O performance20:02
ZipCPUThe big drawback is that it will delay the I/Os by one clock20:02
tntmaikmerten: well nextpnr will instanciate the SB_IO and place them at the right site ... but it won't enable the internal registers (because ... well that would change the logic duh).20:04
tntand in any case for any kind of external comm, I personally don't trust anything but instanciation of the IO primitives myself.  Relying on the tool magically doing "the right thing" for something so critical is wishful thinking.20:06
emebISE/Vivado/Quartus will allow a synthesis directive that lets you push an inferred register into the IOB. I've used that a lot.20:06
ZipCPUemeb: Personally, I think that should be the fault.  If a value is registered, and headed to an I/O port, then unless it has multiple consumers it should go directly into the SB_IO buffer20:07
tntyeah iob=true ... I know. And I don't trust it :p20:08
emebHeh. Well, it can cause some problems in very fast designs. I once had a ~250MHz data bus that had to be internally pipelined to make it to the IOB in time for the next clock.20:09
tntZipCPU: given the constrainst of the ice40 (with shared clk / ce), this is non-trivial and small changes might produce different results depending on what the tool can do validely ... and suddently you loose one afternoon debugging wtf your design stopped working all because you wanted to save 5 min not creating the SB_IO yourself.20:10
ZipCPU^ +1 and Lol20:10
ZipCPUWell said20:11
emebthe sharing constraints in Lattice make automatic stuff problematic20:11
emeband that goes extra for DDR registers. Definitely want to be careful how you handle those.20:12
maikmertenI guess it's hard to find a default that works everwhere (duh), but I'd sure welcome a way to specify "if a register is headed to an I/O port, use the register there" on-demand20:27
maikmertenbut okay, sharing constraints20:27
daveshahI think such an attribute would only be sensible if it errored out in case of a  conflict20:29
tntexactly what I was about to write.20:29
tntbut then ... fabric fifo have a bunch of option that IO FF don't have either (reset ...)20:29
maikmerten(and yeah, error, not warning)20:29
tntAlso ATM, if you put an attribute on a signal ('reg') is that propagted by yosys to the 'FF' ?20:30
daveshahNo, I don't think so, although I think there might be some kind of pass for this already20:30
tntbecause for things like 'BEL' attribute I often ended up instanciating the FF primitives just to put attributes which is ... inconvenient at best.20:31
tnthaving something like (* FF.BEL="xxx" *) or something would be useful.20:31
maikmertenbtw, can a "normal" flipflop from a logic cell that is "next by" the SB_IO stand in for the flipflop of the I/O port? Of course, the placer would need to pin the placement down20:32
maikmertenas in "don't use the flipflop in the I/O, but choose an adjacent cell"20:32
maikmerten(and keep it there)20:32
daveshahattrmvcp -driven should work to copy attributes from net to driver20:33
daveshahNo just attrmvcp20:33
daveshah*without* -driven20:34
tntmaikmerten: yes.20:34
tntmaikmerten: I used that "trick" in a SPI design where I needed features on the FF that were not available on the IO FF. Lock the driver/input cel to a site near the IO.20:34
tntTiming isn't as good, but being locked, it's at least deterministic.20:35
maikmertendeterministic sounds good.20:36
tntYeah, that's how I like my fpga designs.20:36
tntIf I could, I would also have them non-causal, but didn't find any device that supports that yet.20:37
emebjust need deeper pipelines20:46
maikmertenokay, putting attrmvcp after synth_ice40 doesn't seem to do any immediately obvious harm ;-)20:51
maikmerten(by freak accident the first synthesis run even got a f_max of 37.5 MHz, which is unusually good)20:51
daveshahattrmvcp would not do anything by itself, it was mentioned in the context of moving BEL attributes from wires to registers20:56
maikmertenokay, that makes a lot of sense20:58
*** emeb_mac has joined #yosys20:59
*** maikmerten has quit IRC21:13
*** gnufan_home has quit IRC22:14
*** proteusguy has quit IRC22:36
*** proteusguy has joined #yosys22:49
*** Laksen has quit IRC22:50
*** TD-Linux has joined #yosys23:12
*** _whitelogger has joined #yosys23:40
*** emeb has quit IRC23:41
*** togo has quit IRC23:51

Generated by 2.13.1 by Marius Gedminas - find it at!