| *** tpb has joined #yosys | 00:00 | |
| *** emeb has left #yosys | 00:04 | |
| *** futarisIRCcloud has joined #yosys | 01:38 | |
| *** gsi__ has joined #yosys | 02:19 | |
| *** gsi_ has quit IRC | 02:22 | |
| *** PyroPeter has quit IRC | 02:57 | |
| *** PyroPeter has joined #yosys | 03:10 | |
| *** citypw has joined #yosys | 03:59 | |
| *** jevinski_ has joined #yosys | 04:46 | |
| *** jevinskie has quit IRC | 04:47 | |
| *** rohitksingh_work has joined #yosys | 04:51 | |
| *** Jybz has joined #yosys | 05:27 | |
| *** Jybz has quit IRC | 05:36 | |
| *** s_frit has quit IRC | 05:56 | |
| *** s_frit has joined #yosys | 05:56 | |
| *** futarisIRCcloud has quit IRC | 06:08 | |
| *** proteusguy has joined #yosys | 06:11 | |
| *** fsasm has joined #yosys | 06:46 | |
| *** jakobwenzel has joined #yosys | 07:03 | |
| *** emeb_mac has quit IRC | 07:19 | |
| *** m4ssi has joined #yosys | 07:24 | |
| *** alcorn has quit IRC | 07:26 | |
| *** togo has joined #yosys | 07:51 | |
| *** wifasoi has joined #yosys | 08:41 | |
| *** fsasm has quit IRC | 09:15 | |
| *** fsasm has joined #yosys | 09:25 | |
| *** s_frit has quit IRC | 09:38 | |
| *** rohitksingh_work has quit IRC | 10:22 | |
| *** MoeIcenowy has quit IRC | 10:24 | |
| *** MoeIcenowy has joined #yosys | 10:24 | |
| *** rohitksingh_work has joined #yosys | 10:25 | |
| *** vup2 is now known as vup | 10:57 | |
| *** wifasoi has quit IRC | 11:11 | |
| *** proteusguy has quit IRC | 11:45 | |
| *** wifasoi has joined #yosys | 11:59 | |
| *** rohitksingh_work has quit IRC | 12:03 | |
| *** rohitksingh_work has joined #yosys | 12:03 | |
| *** rohitksingh_work has quit IRC | 12:03 | |
| *** proteusguy has joined #yosys | 12:39 | |
| *** danieljabailey has quit IRC | 12:55 | |
| *** mirage335 has quit IRC | 13:08 | |
| *** m4ssi has quit IRC | 13:10 | |
| *** wifasoi has quit IRC | 13:28 | |
| *** mirage335 has joined #yosys | 13:31 | |
| *** m4ssi has joined #yosys | 13:32 | |
| *** m4ssi has quit IRC | 13:49 | |
| *** wifasoi has joined #yosys | 13:49 | |
| *** kuldeep_ is now known as kuldeep | 13:56 | |
| *** indy has quit IRC | 14:17 | |
| *** emeb has joined #yosys | 14:22 | |
| *** maikmerten has joined #yosys | 15:44 | |
| *** fsasm has quit IRC | 15:49 | |
| *** citypw has quit IRC | 16:04 | |
| *** jevinski_ has quit IRC | 16:30 | |
| 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 | 16:32 |
|---|---|---|
| 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. | 16:33 |
| *** qu1j0t3 has left #yosys | 16:33 | |
| 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. | 16:34 |
| tnt | also output from luts are not glitch free ... which external chips might not like depending on what you drive with them. | 16:34 |
| ZipCPU | +1 | 16:35 |
| maikmerten | interesting. | 16:35 |
| maikmerten | so outputs should always be wired through a register? | 16:36 |
| ZipCPU | Not just any register, but one of the IO buffers supplied on the chip | 16:36 |
| ZipCPU | Which chip are you working with, ice40? | 16:36 |
| maikmerten | yup, hx8k | 16:36 |
| maikmerten | on the eval board | 16:36 |
| ZipCPU | Use the SB_IO primitive then | 16:36 |
| ZipCPU | Are you doing anything special with your outputs? DDR or such? | 16:36 |
| maikmerten | no, nothing fancy | 16:37 |
| ZipCPU | Hmm ... a reg should work then. | 16:37 |
| maikmerten | well, the SRAM controller is fancy, but I also got problems just using BRAM for RAM | 16:37 |
| 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 | 16:37 |
| ZipCPU | Ooohh, SRAM, nifty! | 16:38 |
| ZipCPU | Need a working SRAM controller? ;) | 16:38 |
| tnt | ZipCPU: it most definitely isn't. | 16:38 |
| ZipCPU | tnt: It's not smart enough yet? | 16:38 |
| tnt | maikmerten: what's the board ? What's the design ? | 16:38 |
| tnt | nope | 16:38 |
| ZipCPU | ;/ | 16:38 |
| ZipCPU | Okay | 16:38 |
| maikmerten | ZipCPU, hehe, I'm pretty sure your controllers would be quite verified, I suppose ;-) | 16:39 |
| tnt | Also ... your design _does_ meet timing right ? Your clock are constrained ? (because that'd be the first thing to check ...) | 16:39 |
| ZipCPU | Well, gosh <blushes> | 16:39 |
| maikmerten | the f_max according to nextpnr is ~35 MHz, I clock it at 25.125 MHz | 16:39 |
| tnt | VGA ? | 16:40 |
| maikmerten | yup | 16:40 |
| maikmerten | https://github.com/maikmerten/spu32 <-- that trainwreck | 16:40 |
| tpb | Title: GitHub - maikmerten/spu32: Small Processing Unit 32: A compact RV32I CPU written in Verilog (at github.com) | 16:40 |
| maikmerten | (it's more than a CPU core, it can now present its own slides) | 16:40 |
| ZipCPU | Heheh ... nice! | 16:41 |
| maikmerten | and I'm pretty sure my naive approach to Verilog sloppyness and untidyness and overall horror is haunting it | 16:42 |
| * ZipCPU considers playing some spooooooky music from Scooby Doo | 16:44 | |
| maikmerten | I should totally create a minimal design of just BRAM, boot-ROM, UART and CPU for debugging | 16:44 |
| maikmerten | this currently is a kitchen-sink of features | 16:44 |
| ZipCPU | Don't forget to stuff any debugging code in there as well. | 16:44 |
| ZipCPU | It's hard to debug what you can't see. | 16:44 |
| 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? | 16:46 |
| maikmerten | I 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 |
| ZipCPU | Not in the fabric itself, but I usually place one into the fabric that I can then use | 16:47 |
| maikmerten | interesting. | 16:48 |
| ZipCPU | http://zipcpu.com/blog/2017/06/08/simple-scope.html | 16:49 |
| maikmerten | I guess a poor man's version could be just to throw out some interesting signals to the GPIO headers | 16:49 |
| tpb | Title: Building A Simple In-Circuit Logic Analyzer (at zipcpu.com) | 16:49 |
| ZipCPU | That's not necessarily a poor man's version. This poor man didn't have an O-scope for many years | 16:49 |
| ZipCPU | http://zipcpu.com/blog/2017/07/08/getting-started-with-wbscope.html | 16:50 |
| tpb | Title: Getting Started with the Wishbone Scope (at zipcpu.com) | 16:50 |
| 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) | 16:52 |
| maikmerten | perhaps this is finally my excuse to get more serious gear | 16:52 |
| maikmerten | (yeah, I could just use a slower clock, but where's the fun in that) | 16:53 |
| ZipCPU | Add a logic analyzer to your design | 16:53 |
| ZipCPU | Stick it on the bus, and let the CPU operate it | 16:53 |
| maikmerten | yeah, but it's the CPU that in the unstable situations just seems to get awry in interesting ways ;-) | 16:55 |
| ZipCPU | It'd work if there was enough block RAM for both the scope *and* the CPU's instructions | 16:56 |
| ZipCPU | On the other hand, when I debugged the SRAM on my iCE40 iCO board, I left the CPU idle. | 16:56 |
| *** wifasoi has quit IRC | 17:04 | |
| maikmerten | https://github.com/YosysHQ/nextpnr/pull/204 <-- hmmm, that looks fancy | 17:08 |
| tpb | Title: [WIP] timing: Add minimum delay and hold analysis by daveshah1 · Pull Request #204 · YosysHQ/nextpnr · GitHub (at github.com) | 17:08 |
| daveshah | A rewritten version should come soon. But there's no realistic chance of hold issues on an iCE40 | 17:10 |
| daveshah | iCE40 has a lot of hold margin, I've ran picorv32 fine without any global clock routing and loads of skew | 17:10 |
| maikmerten | oh, so it's a robust little fella? | 17:10 |
| *** alexhw has quit IRC | 17:31 | |
| 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 | 17:33 |
| maikmerten | wonder if the notebook is very limiting regarding USB power delivery | 17:33 |
| maikmerten | too bad I didn't have a multimeter with me to check voltages | 17: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 |
| 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 | 18:08 |
| maikmerten | I further assumed (oh, the pattern!) that by choosing a pin <-> signal assignment, there's no choice on the placement of that buffer | 18: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 #yosys | 18:36 | |
| *** Jybz has joined #yosys | 18:51 | |
| *** Forty-Bot has joined #yosys | 18:52 | |
| *** Laksen has joined #yosys | 19:00 | |
| *** Jybz has quit IRC | 19:25 | |
| 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. | 19:35 |
| *** _whitelogger has quit IRC | 19:44 | |
| ZipCPU | maikmerten: Yes. Using the FF within SB_IO will help to provide more predictable I/O performance | 20:02 |
| ZipCPU | The big drawback is that it will delay the I/Os by one clock | 20:02 |
| tnt | maikmerten: 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 |
| tnt | and 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 |
| emeb | ISE/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 |
| ZipCPU | emeb: 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 buffer | 20:07 |
| tnt | yeah iob=true ... I know. And I don't trust it :p | 20:08 |
| emeb | Heh. 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 |
| tnt | ZipCPU: 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 |
| emeb | *nod* | 20:10 |
| ZipCPU | ^ +1 and Lol | 20:10 |
| ZipCPU | Well said | 20:11 |
| emeb | the sharing constraints in Lattice make automatic stuff problematic | 20:11 |
| emeb | and that goes extra for DDR registers. Definitely want to be careful how you handle those. | 20:12 |
| maikmerten | I 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-demand | 20:27 |
| maikmerten | but okay, sharing constraints | 20:27 |
| daveshah | I think such an attribute would only be sensible if it errored out in case of a conflict | 20:29 |
| tnt | +1 | 20:29 |
| tnt | exactly what I was about to write. | 20:29 |
| maikmerten | indeed | 20:29 |
| tnt | but 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 |
| tnt | Also ATM, if you put an attribute on a signal ('reg') is that propagted by yosys to the 'FF' ? | 20:30 |
| daveshah | No, I don't think so, although I think there might be some kind of pass for this already | 20:30 |
| tnt | because for things like 'BEL' attribute I often ended up instanciating the FF primitives just to put attributes which is ... inconvenient at best. | 20:31 |
| tnt | having something like (* FF.BEL="xxx" *) or something would be useful. | 20:31 |
| maikmerten | btw, 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 down | 20:32 |
| maikmerten | as in "don't use the flipflop in the I/O, but choose an adjacent cell" | 20:32 |
| maikmerten | (and keep it there) | 20:32 |
| daveshah | attrmvcp -driven should work to copy attributes from net to driver | 20:33 |
| daveshah | No just attrmvcp | 20:33 |
| daveshah | *without* -driven | 20:34 |
| tnt | maikmerten: yes. | 20:34 |
| tnt | maikmerten: 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 |
| tnt | Timing isn't as good, but being locked, it's at least deterministic. | 20:35 |
| maikmerten | deterministic sounds good. | 20:36 |
| tnt | Yeah, that's how I like my fpga designs. | 20:36 |
| tnt | If I could, I would also have them non-causal, but didn't find any device that supports that yet. | 20:37 |
| emeb | just need deeper pipelines | 20:46 |
| maikmerten | okay, 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 |
| daveshah | attrmvcp would not do anything by itself, it was mentioned in the context of moving BEL attributes from wires to registers | 20:56 |
| maikmerten | okay, that makes a lot of sense | 20:58 |
| *** emeb_mac has joined #yosys | 20:59 | |
| *** maikmerten has quit IRC | 21:13 | |
| *** gnufan_home has quit IRC | 22:14 | |
| *** proteusguy has quit IRC | 22:36 | |
| *** proteusguy has joined #yosys | 22:49 | |
| *** Laksen has quit IRC | 22:50 | |
| *** TD-Linux has joined #yosys | 23:12 | |
| *** _whitelogger has joined #yosys | 23:40 | |
| *** emeb has quit IRC | 23:41 | |
| *** togo has quit IRC | 23:51 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!