| *** tpb has joined #yosys | 00:00 | |
| *** emeb_mac has joined #yosys | 00:41 | |
| *** promach_ has joined #yosys | 01:22 | |
| *** promach_ has quit IRC | 01:47 | |
| promach | just came across https://github.com/akzare/Async_FIFO_Verification . What do you guys think about the difference between yosys-smtbmc and UVM ? | 03:11 |
|---|---|---|
| tpb | Title: GitHub - akzare/Async_FIFO_Verification: Presents a verification use case for a typical Asynchronous FIFO based on Systemverilog and UVM. (at github.com) | 03:11 |
| *** leviathan has joined #yosys | 03:21 | |
| *** digshadow has joined #yosys | 03:57 | |
| *** knielsen has quit IRC | 04:16 | |
| *** mazzoo_ is now known as mazzoo | 04:22 | |
| *** noname_Matt has quit IRC | 05:32 | |
| *** knielsen has joined #yosys | 05:41 | |
| *** emeb_mac has quit IRC | 06:15 | |
| *** pie_ has quit IRC | 06:23 | |
| *** GuzTech has joined #yosys | 06:44 | |
| *** ZipCPU has quit IRC | 06:51 | |
| *** qu1j0t3 has quit IRC | 07:42 | |
| *** qu1j0t3 has joined #yosys | 07:56 | |
| *** leviathan has quit IRC | 07:57 | |
| mattvenn | ZipCPU_: I didn't really understand your tweet about the 32bit multiplies | 08:23 |
| mattvenn | In my FFT implementation I just did a <= b * c; | 08:23 |
| mattvenn | which seemed to work OK | 08:23 |
| mattvenn | is it that you can write a more optimised multiplier than yosys can infer if you know what type of numbers the multipy will be handling? | 08:24 |
| daveshah | mattvenn: Yosys will always infer a single-cycle multiply if you do that | 08:28 |
| daveshah | ZipCPU_ wanted a multi-cycle multiplier | 08:28 |
| mattvenn | so that it could fit with a pipeline or some other multi cycle logic? | 08:28 |
| mattvenn | or uses less LUTs? | 08:29 |
| daveshah | in this case, the idea is one value is only needed every 32 cycles (for example), so far fewer LUTs are needed compared to a full single cycle multiplier | 08:35 |
| *** dys has joined #yosys | 08:37 | |
| *** dxld has quit IRC | 08:43 | |
| *** dxld has joined #yosys | 08:44 | |
| *** leviathan has joined #yosys | 08:53 | |
| *** dys has quit IRC | 10:41 | |
| *** dys has joined #yosys | 11:01 | |
| *** develonepi3 has joined #yosys | 12:04 | |
| *** quigonjinn has joined #yosys | 12:14 | |
| *** gyroninja has quit IRC | 14:20 | |
| *** jwhitmore has joined #yosys | 14:27 | |
| *** seldridge has joined #yosys | 14:31 | |
| *** gyroninja has joined #yosys | 14:35 | |
| *** seldridge0 has joined #yosys | 14:37 | |
| *** seldridge has quit IRC | 14:37 | |
| *** promach_ has joined #yosys | 14:38 | |
| *** seldridge0 has quit IRC | 14:42 | |
| *** emeb has joined #yosys | 15:12 | |
| *** maikmerten has joined #yosys | 15:15 | |
| maikmerten | hi there, I'd like to use the SRAM on my icoboard, for which I'd need a tristate in/outputs for the data lines. Some while I ago, I think I read that yosys only has limited tristate support. Is there some hint on what "limited" means in this case? I'd like to avoid instantiating the I/O manually if possible. | 15:19 |
| *** develonepi3 has quit IRC | 15:19 | |
| daveshah | It is generally best to instantiate IO if you want anything fancy | 15:24 |
| daveshah | The most basic tristate pattern hopefully works, a fix was even pushed a few hours ago | 15:24 |
| *** seldridge0 has joined #yosys | 15:24 | |
| *** seldridge0 has quit IRC | 15:34 | |
| *** GuzTech has quit IRC | 15:36 | |
| *** xerpi has joined #yosys | 15:40 | |
| *** seldridge0 has joined #yosys | 15:46 | |
| *** xerpi has quit IRC | 15:58 | |
| *** seldridge0 has quit IRC | 16:03 | |
| maikmerten | daveshah, thanks | 16:12 |
| maikmerten | completely unrelated: does anybody know how iCE40 HX devices compare against entry-level stuff from Altera (e.g., Cyclone IV) or Xilinx (Spartan?) speed wise? The RISC-V SoC I'm developing for fun has an icetime estimate of somewhere between 49 to 56 MHz, depending on placement luck. A similiar design usually went to ~ 80-90 MHz in Cyclone IV and I wonder how the FPGAs come into play here. | 16:15 |
| *** pie_ has joined #yosys | 16:29 | |
| mattvenn | daveshah: thanks | 16:34 |
| sorear | icestorm is known to be a fair amount worse than lattice tools at timing optimization | 16:34 |
| maikmerten | as far as I can see it's not timing driven, just tries to keep routes short - which of course strongly correlates | 16:38 |
| daveshah | maikmerten: the problem is, different routes have different "importances" in timing | 16:39 |
| daveshah | if a route is part of a timing path with lots of cells, it must be shorter than one in a path with few cells | 16:39 |
| awygle | arachne also doesn't prioritize the longest route or anything like that | 16:39 |
| awygle | i wonder if switching from HPWL to QWL would give better timing results... | 16:40 |
| maikmerten | daveshah, indeed - yeah | 16:40 |
| daveshah | awygle: it's something to investigate once we have a better framework for doing these kinds of experiments | 16:41 |
| awygle | daveshah: yup. although hopefully we can use better models at that point. | 16:41 |
| awygle | QWL is a one-function change to arachne | 16:41 |
| awygle | (to first order anyway) | 16:41 |
| maikmerten | just to be clear: I'm *very* happy with the whole icestorm experience and the synthesis results are more than just fast enough for my hobby applications | 16:42 |
| maikmerten | also the tools are fast... from "make clean" to a bitstream file including timing analysis in < 30 seconds on my Ryzen 2700 | 16:43 |
| awygle | maikmerten: glad to hear :) you didn't come off as unhappy, we just always want things to be better | 16:43 |
| maikmerten | :-) | 16:44 |
| maikmerten | as for the hardware itself: iCE40 seems to a simple, yet reasonably "fresh" design on 40nm, so at least from that vantage point it shouldn't be at an disadvantage compared to e.g., Cyclone IV | 16:45 |
| awygle | my understanding is that the altera LABs are much more powerful, and that the ice40 is generally optimized for power consumption rather than speed. but i'm not familiar with cyclone iv at all. | 16:47 |
| maikmerten | yeah, seems that Lattice is pushing the power aspect most | 16:48 |
| awygle | this is most clear with the UltraPlus, which is ~half the speed of the LP | 16:49 |
| maikmerten | I'd guess they're pushing that as "glue logic" for mobile applications | 16:50 |
| *** ZipCPU has joined #yosys | 16:54 | |
| *** digshadow has quit IRC | 16:59 | |
| *** leviathan has quit IRC | 17:02 | |
| *** leviathan has joined #yosys | 17:05 | |
| *** promach_ has quit IRC | 17:15 | |
| maikmerten | seems yosys has no problem instantiating tristate buffers for my application: https://pasteboard.co/HqDZ6rg.png | 17:23 |
| tpb | Title: Pasteboard Uploaded Image (at pasteboard.co) | 17:23 |
| maikmerten | (code: https://pastebin.com/hJUDGMtg - completely untested, of course. Some weirdness because of my data bus being 8 bits wide, while the SRAM is 16 bits wide) | 17:24 |
| tpb | Title: [VeriLog] module sram64kx16_wb8 ( // Wishbone signals input CLK_I, input STB_I, - Pastebin.com (at pastebin.com) | 17:24 |
| ZipCPU | Shouldn't they then be connected to SB_IO's? | 17:25 |
| maikmerten | I didn't yet throw things into my toplevel, so it's just this single file with no pin assignments | 17:26 |
| daveshah | ZipCPU: arachne_pnr inserts SB_IOs, not Yosys | 17:26 |
| awygle | that's a bit weird. arachne maps yosys TBUFs to SB_IOs? | 17:29 |
| daveshah | Yeap | 17:29 |
| awygle | huh. that seems firmly in the realm of synthesis to me. but i'm sure there's a good reason | 17:29 |
| ZipCPU | Yeah, that was my thought to --- that seems like a Synthesis task: mapping logic to generic resource types within a device. | 17:32 |
| daveshah | yeah, there's no real reason it couldn't be done in Yosys | 17:34 |
| *** sklv has joined #yosys | 18:15 | |
| *** sklv has quit IRC | 18:45 | |
| *** sklv has joined #yosys | 18:46 | |
| *** seldridge0 has joined #yosys | 18:53 | |
| *** m_w has quit IRC | 19:12 | |
| *** sklv has quit IRC | 19:14 | |
| *** sklv has joined #yosys | 19:14 | |
| *** maikmerten has quit IRC | 19:19 | |
| *** leviathan has quit IRC | 19:53 | |
| *** develonepi3 has joined #yosys | 20:03 | |
| develonepi3 | Hello All anyone interested in bare metal for the RPi & icoboard see https://gist.github.com/develone/e8de5745e1f8daa979b789ad7bd366e1#file-yosysinfo-txt | 20:23 |
| tpb | Title: notes.txt · GitHub (at gist.github.com) | 20:23 |
| develonepi3 | tpb yes there is a file yosysinfo.txt | 20:46 |
| develonepi3 | see https://github.com/develone/Ultibo_Projects/blob/master/fpganetport/RPi3/Srv.lpr & https://github.com/develone/Ultibo_Projects/blob/master/fpganetport/RPi3/ufpga.pas | 20:51 |
| tpb | Title: Ultibo_Projects/Srv.lpr at master · develone/Ultibo_Projects · GitHub (at github.com) | 20:51 |
| *** develonepi3 has quit IRC | 21:04 | |
| *** develonepi3 has joined #yosys | 21:07 | |
| *** digshadow has joined #yosys | 21:10 | |
| *** develonepi3 has quit IRC | 21:19 | |
| *** develonepi3 has joined #yosys | 21:21 | |
| *** seldridge0 has quit IRC | 21:22 | |
| *** jwhitmore has quit IRC | 21:38 | |
| *** develonepi3 has quit IRC | 21:57 | |
| *** develonepi3 has joined #yosys | 22:00 | |
| *** sklv has quit IRC | 22:38 | |
| *** sklv has joined #yosys | 22:39 | |
| *** dys has quit IRC | 22:43 | |
| *** quigonjinn has quit IRC | 23:08 | |
| *** sklv has quit IRC | 23:36 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!
