| *** tpb has joined #yosys | 00:00 | |
| *** luismarques has joined #yosys | 00:10 | |
| *** emeb_mac has joined #yosys | 00:36 | |
| *** digshadow has quit IRC | 01:15 | |
| *** pie__ has joined #yosys | 01:38 | |
| *** promach_ has quit IRC | 01:39 | |
| *** pie_ has quit IRC | 01:42 | |
| *** luismarques has quit IRC | 01:43 | |
| *** pie___ has joined #yosys | 02:11 | |
| *** pie__ has quit IRC | 02:14 | |
| promach | By the way, ZipCPU, did you faced any issue regarding tcl85 during yosys installation ? | 02:15 |
|---|---|---|
| *** m_w has quit IRC | 02:19 | |
| ZipCPU | No. I had no issues. | 02:22 |
| ZipCPU | Or at least none that I can remember. | 02:22 |
| promach | Should I create a github issue on this because I am not sure if this is really problem with yosys makefile because I only have problem in Ubuntu but not in arch linux ? | 02:31 |
| ZipCPU | I had no problems in Ubuntu 16 or 18. | 02:32 |
| ZipCPU | I'd be hesitant to create a github issue yet. | 02:32 |
| promach | ok, let me check this again over the weekend. Probably I made some mistake | 02:32 |
| ZipCPU | One other thing ... .I have tcl8.6 installed, not tcl85 | 02:33 |
| promach | me too | 02:33 |
| ZipCPU | Do you have libtcl8.6 installed? | 02:34 |
| promach | yes | 02:35 |
| promach | libtcl8.6 is already installed at the requested version (8.6.8+dfsg-3) | 02:35 |
| ZipCPU | How about tcl-dev and tcl8.6-dev ? | 02:35 |
| promach | already installed | 02:37 |
| promach | tcl-dev is already installed at the requested version (8.6.0+9) | 02:37 |
| promach | tcl8.6-dev is already installed at the requested version (8.6.8+dfsg-3) | 02:37 |
| ZipCPU | So .... what issue are you struggling with? | 02:38 |
| promach | [100%] Building yosys | 02:38 |
| promach | /usr/bin/x86_64-linux-gnu-ld: cannot find -ltcl8.5 | 02:38 |
| promach | collect2: error: ld returned 1 exit status | 02:38 |
| promach | Makefile:458: recipe for target 'yosys' failed | 02:38 |
| ZipCPU | Is this an older yosys, with build remains around from a prior build? | 02:39 |
| ZipCPU | As in, might your yosys have been built at one time when your system had tcl8.5? | 02:40 |
| promach | no | 02:41 |
| promach | phung@UbuntuHW15:~/Downloads/yosys$ git log -1 | 02:41 |
| promach | commit 8b92ddb9d2635c30636b17ff3d24bc09a44b8551 (HEAD -> master, origin/master, origin/HEAD) | 02:41 |
| promach | Author: Clifford Wolf <[email protected]> | 02:41 |
| promach | Date: Fri Jun 29 19:24:58 2018 +0200 | 02:41 |
| promach | Fix verific eventually handling | 02:41 |
| promach | 02:41 | |
| ZipCPU | For example, if I grep tcl yosys-config, I only get references to tcl8.6, and -ltcl8.6 ... no references to tcl8.5. | 02:41 |
| promach | Signed-off-by: Clifford Wolf <[email protected]> | 02:41 |
| promach | phung@UbuntuHW15:~/Downloads/yosys$ | 02:41 |
| *** proteus-guy has quit IRC | 02:43 | |
| ZipCPU | Another question: If you run "tclsh", and then type "info tclversion" at the command line, what response does it give? | 02:44 |
| promach | it gave 8.5 | 02:45 |
| ZipCPU | Your tcl install is 8.5 then, not 8.6. What's broken? | 02:46 |
| ZipCPU | Perhaps you need to reinstall tcl8.6? | 02:46 |
| promach | just finish reinstallation of tcl8.6 | 02:49 |
| promach | but still having 8.5 | 02:49 |
| promach | as the output of "info tclversion" | 02:50 |
| ZipCPU | What does /usr/bin/tclsh point to? | 02:50 |
| promach | phung@UbuntuHW15:~/Downloads/yosys$ whereis /usr/bin/tclsh | 02:51 |
| promach | tclsh: /usr/bin/tclsh /usr/bin/tclsh8.6 /opt/Xilinx/SDK/2017.2/bin/tclsh /opt/Xilinx/14.7/ISE_DS/ISE/bin/lin64/tclsh /opt/intelFPGA/17.1/quartus/bin/tclsh /usr/share/man/man1/tclsh.1.gz | 02:51 |
| ZipCPU | Try instead "ls -l `which tclsh` | 02:51 |
| promach | phung@UbuntuHW15:~/Downloads/yosys$ ls -l `which tclsh` | 02:52 |
| promach | -rwxr-xr-x 1 root root 1290 Jun 16 2017 /opt/Xilinx/SDK/2017.2/bin/tclsh | 02:52 |
| ZipCPU | Perhaps you might wish to adjust your path. | 02:52 |
| promach | yes | 02:52 |
| promach | the issue comes from /opt/Xilinx/SDK/2017.2/.settings64-Software_Development_Kit__SDK_.sh | 02:59 |
| promach | thanks | 02:59 |
| ZipCPU | See ... you didn't need to submit a yosys github issue after all! | 03:00 |
| promach | yeah | 03:02 |
| *** pie___ has quit IRC | 03:26 | |
| *** _whitelogger has quit IRC | 04:01 | |
| *** _whitelogger has joined #yosys | 04:03 | |
| *** danieljabailey has quit IRC | 04:07 | |
| *** cr1901_modern has quit IRC | 04:28 | |
| *** seldridge has joined #yosys | 04:36 | |
| *** emeb has quit IRC | 04:37 | |
| *** proteus-guy has joined #yosys | 04:49 | |
| *** seldridge has quit IRC | 05:12 | |
| *** cr1901_modern has joined #yosys | 05:57 | |
| *** dys has joined #yosys | 06:18 | |
| *** jaafar has quit IRC | 06:32 | |
| *** Guest16831 has left #yosys | 06:52 | |
| *** emeb_mac has quit IRC | 07:01 | |
| *** dys has quit IRC | 07:41 | |
| *** proteus-guy has quit IRC | 07:44 | |
| *** proteus-guy has joined #yosys | 07:45 | |
| *** digshadow has joined #yosys | 07:57 | |
| *** proteus-guy has quit IRC | 08:00 | |
| *** grummel has quit IRC | 08:05 | |
| *** grummel has joined #yosys | 08:06 | |
| *** X-Scale has quit IRC | 08:15 | |
| *** jwhitmore has joined #yosys | 08:17 | |
| *** cr1901_modern has quit IRC | 08:27 | |
| *** cr1901_modern has joined #yosys | 08:29 | |
| *** jwhitmore has quit IRC | 08:52 | |
| *** cr1901_modern1 has joined #yosys | 08:57 | |
| *** cr1901_modern has quit IRC | 08:58 | |
| *** maartenBE has quit IRC | 09:47 | |
| *** maartenBE has joined #yosys | 09:50 | |
| *** ZipCPU has quit IRC | 10:36 | |
| *** ZipCPU has joined #yosys | 10:53 | |
| *** pie___ has joined #yosys | 11:17 | |
| *** m_t has joined #yosys | 11:20 | |
| *** jwhitmore has joined #yosys | 11:51 | |
| *** X-Scale has joined #yosys | 11:58 | |
| *** jwhitmore has quit IRC | 12:34 | |
| *** jwhitmore has joined #yosys | 12:50 | |
| *** luismarques has joined #yosys | 12:52 | |
| *** ric96 has joined #yosys | 13:11 | |
| ric96 | I have just started to use the ice stick and only a couple of weeks since i've written my first verilog. | 13:11 |
| ric96 | Had a question regarding BRAM.... I am able to get 1 block working win MODE0 (256x16), what is the best way to get all 16 blocks working? | 13:11 |
| ric96 | my current code: https://t.co/cxJJbrl0Pp | 13:12 |
| tpb | Title: module ram1( input clk, input [7:0] addr, input [15:0] din, input write_en - Pastebin.com (at t.co) | 13:12 |
| daveshah | ric96: if you increase address or data width, Yosys should infer multiple blocks | 13:14 |
| ric96 | daveshah: i did, for some reason it limits to only 5 block and goes into READ/WRITE Mode 3 | 13:15 |
| ric96 | https://pastebin.com/5hp1i8Lw | 13:15 |
| tpb | Title: module ram1( input clk, input [7:0] addr, input [15:0] din, input write_en - Pastebin.com (at pastebin.com) | 13:15 |
| daveshah | ric96: is that not working then? | 13:15 |
| daveshah | what error/problem are you seeing? | 13:16 |
| ric96 | daveshah: no its not, i guess | 13:17 |
| ric96 | I am looking for 256x16 configuration on 16block that gives me my 64k of BRAM | 13:17 |
| ric96 | this is the yosys output that i am getting instead | 13:18 |
| daveshah | ric96: going into mode3 is the correct solution here afaics, as it results in less extra decoding logic | 13:18 |
| daveshah | it functions correctly, right? | 13:18 |
| ric96 | https://pastebin.com/vwTBbxh1 | 13:18 |
| tpb | Title: Parameter \WRITE_MODE = 3 Parameter \READ_MODE = 3 Parameter \INIT_0 = 256'000 - Pastebin.com (at pastebin.com) | 13:18 |
| daveshah | ric96: why do you thing mode 3 is a problem? | 13:19 |
| daveshah | *think | 13:19 |
| ric96 | daveshah: even if i go to mode 3, still limits me to only 5 blocks | 13:19 |
| ric96 | instead of full 16 blocks | 13:20 |
| daveshah | ric96: first of all mode 3 is correct behaviour, not a problem, if you think about the resultant output it will require less decoding logic than mode 0. limiting to 5 blocks seems to be a separate problem | 13:20 |
| daveshah | what happens when you go above 5 blocks. what error do you get? is it in Yosys or arachne-pnr? | 13:20 |
| ric96 | i can use mode 3, not an issue. issue is limiting to 5 block, sorry wasn't clear | 13:21 |
| daveshah | ric96: yes. what is the problem you see when you exceed 5 blocks. what is producing the error? yosys or arachne-pnr? | 13:21 |
| ric96 | daveshah: don't know new to this... posted the output above if you can figure out | 13:23 |
| daveshah | ric96: are you resizing your address input to the module? it looks like the address input to the module is only 8 bits. This means the top parts of your memory are never accessed, so Yosys will optimise them away | 13:24 |
| ric96 | daveshah: yes i am resizing > https://pastebin.com/5hp1i8Lw | 13:25 |
| tpb | Title: module ram1( input clk, input [7:0] addr, input [15:0] din, input write_en - Pastebin.com (at pastebin.com) | 13:25 |
| daveshah | ric96: no you are not, have a look at line 4 | 13:26 |
| daveshah | this means that the address to the memory, however wide the internal address signal is, can only be between 0 and 256 | 13:26 |
| daveshah | *0 and 255 | 13:26 |
| daveshah | so yosys will optimise away any unused memory above that | 13:26 |
| ric96 | daveshah: oh.... ok let me try again after resizing | 13:27 |
| mattvenn | yosys optimising things away has caught me out many times too! But if you capture the output of the synthesis, you can grep for remove and see all the stuff not being used | 13:29 |
| mattvenn | also, yosys show gives you a visualisation of what is actually inferred | 13:30 |
| mattvenn | very useful http://www.clifford.at/yosys/files/yosys_appnote_011_design_investigation.pdf | 13:31 |
| ric96 | daveshah: nope... still stuck at 5 | 13:39 |
| daveshah | ric96: can you post your design now? | 13:40 |
| daveshah | also, make sure you are actually checking the Yosys output netlist or the arachne-pnr resource count | 13:40 |
| daveshah | the Yosys command line output you posted before was more about elaborating module configurations and may not be repeated for every BRAM in the design, I'm not sure | 13:41 |
| ric96 | https://pastebin.com/3a3qKARp | 13:46 |
| tpb | Title: module ram1( input clk, input [11:0] addr, input [15:0] din, input write_e - Pastebin.com (at pastebin.com) | 13:46 |
| ric96 | https://pastebin.com/tXPVMiLE | 13:47 |
| tpb | Title: After packing: IOs 15 / 96 GBs 0 / 8 GB_IOs 0 / 8 LC - Pastebin.com (at pastebin.com) | 13:47 |
| daveshah | ric96: clearly by the number of IO something is using that BRAM module. Where is the BRAM module being used? How much memory is actually being used (I'll guess less than 20kBit...) | 13:52 |
| ric96 | daveshah: just writing zero in the initial block | 13:55 |
| daveshah | ric96: what top level module contains ram1? | 13:55 |
| ric96 | And writing one bit in the top module... Yes it does. | 13:55 |
| daveshah | ric96: if you only write one bit, Yosys will optimise away the other bits | 13:56 |
| ric96 | daveshah: yikes... Ok I'll write to all blocks and see if that works.. thanks | 13:58 |
| daveshah | ric96: Yosys can be pretty smart, at least some of the time :-P | 13:59 |
| mattvenn | I still have questions about this | 14:09 |
| *** emeb has joined #yosys | 14:09 | |
| mattvenn | most recently I was working on an FFT project, and I hadn't used the output of the FFT for anything | 14:09 |
| mattvenn | so I could simulate it and show it worked | 14:09 |
| mattvenn | but couldn't get an understanding of LUT usage as I changed the number of FFT bins | 14:10 |
| mattvenn | because I couldn't convince yosys I was using it! | 14:10 |
| mattvenn | I'd like to know what rules yosys uses to know if something should be optimised out | 14:11 |
| *** seldridge has joined #yosys | 14:13 | |
| *** promach_ has joined #yosys | 14:13 | |
| awygle | I don't know what the specific rules are, but in general, anything attached to a top-level port will be kept | 14:35 |
| ric96 | daveshah: BRAMs 16 / 16 FINALLY!!! Thanks for the help | 14:40 |
| ric96 | daveshah: one more thing, better way to zero all ram bits without the for loop, that takes too long to process in yosys | 14:42 |
| daveshah | ric96: I think the only other option is to use $readmemh and a file full of zeros | 14:44 |
| ric96 | ok, i'll give that a go, anything is better than a for loop that takes forever | 14:44 |
| *** xa0 has quit IRC | 14:54 | |
| *** xa0 has joined #yosys | 15:01 | |
| *** jaafar has joined #yosys | 15:16 | |
| *** maikmerten has joined #yosys | 15:30 | |
| *** m_t has quit IRC | 15:33 | |
| maikmerten | I'm trying to design a board to attach 512Kx8 SRAM to the Lattice HX8K breakout board - it doesn't come with any RAM. Now, sadly none of the 40-pin connectors (one for each I/O-Bank fo thh FPGA) have enough I/O-pins to drive the 30 signals I need (19 address, 8 data, 3 control), so I need to spread over two headers | 15:34 |
| maikmerten | which means two I/O-banks being involved | 15:35 |
| maikmerten | I wonder if this introduces some timing skew, e.g., with one bank being offset slightly | 15:35 |
| maikmerten | which means I wonder if I should take some care to make sure that, e.g., all address, data and control lines are assigned to one bank only - and not smeared across | 15:36 |
| daveshah | maikmerten: I doubt it will be significant compared to other sources of skew tbh | 15:37 |
| daveshah | what speed are you planning on running at? | 15:37 |
| maikmerten | well, between 20 and 40 MHz, whatever ends up being stable | 15:37 |
| maikmerten | (it's 10ns SRAM, but I don't trust the signal routing on the breakout, the pin headers, and whatever board design I come up with) | 15:38 |
| awygle | yeah i don't see why the bank used would be significant in this case, except maybe for your own sanity | 15:38 |
| maikmerten | okay, thanks | 15:39 |
| maikmerten | I guess I'll still try to keep the same "class" of signal on one single bank | 15:39 |
| maikmerten | but perhaps the routing will make me reconsider ;-) | 15:40 |
| awygle | yeah don't put a spoon in your eye over it | 15:43 |
| maikmerten | for reference: This is a board I designed for one of those very cheap Cyclone-II boards: https://pasteboard.co/Hu8fHAY.png | 15:44 |
| tpb | Title: Pasteboard Uploaded Image (at pasteboard.co) | 15:44 |
| maikmerten | that worked for 50 MHz | 15:44 |
| maikmerten | (didn't try higher) | 15:44 |
| awygle | yeah i've run 100 MHz over 100-mil headers before | 15:45 |
| awygle | i would have put some series termination on the board though. unless the i/o are slew rate adjustable | 15:46 |
| maikmerten | they are not ;-) | 15:48 |
| maikmerten | not sure if there's a "one size fits not all, but most" approach to series-termination though. I guess for a proper value one would have to make some educated guesses on the impedance and whatnot | 15:49 |
| maikmerten | https://www.diodes.com/assets/App-Note-Files/AB023.pdf | 15:50 |
| maikmerten | "In most designs, a value of R = 25 Ω to 30 Ω is recommended" | 15:51 |
| maikmerten | aha | 15:51 |
| awygle | for 50 Ohm lines (which is what i almost always use for impedance control) 22 or 27 ohms is a decent guess for most drivers | 15:51 |
| awygle | lol oh hey look at that | 15:52 |
| awygle | yeah that matches my intuition/experience | 15:53 |
| maikmerten | :-) | 15:53 |
| awygle | i wish IC manufacturers spec'd output impedance | 15:54 |
| maikmerten | surprisingly, apparently, in many cases intuition seems to work just fine as long as frequencies remain "low" | 15:54 |
| awygle | intuition works OK at higher frequencies too, it's just different intuition :p | 15:55 |
| awygle | the most valuable intuition to have is knowing when you need to run the simulation tbh | 15:55 |
| *** mjoldfield has quit IRC | 15:57 | |
| *** mjoldfield has joined #yosys | 15:57 | |
| maikmerten | I'm a computer scientist, not an electronic engineer, and when it comes to PCB stuff, I usually end up being lucky, I guess. I may be doing some ill-conceived hocus-pocus in some cases though. For instance, keeping as much GND-fill on the board as possible (no islands allowed), which might be counter-productive in some cases, I guess. | 15:57 |
| mattvenn | 19 address for 512kx8? | 15:59 |
| maikmerten | (and yeah, simulation rocks. As long as one has enough data - or intuition - to get the parameters right) | 16:00 |
| maikmerten | mattvenn, yup | 16:00 |
| mattvenn | oh yeah | 16:00 |
| maikmerten | 2^19 = 524288 | 16:00 |
| mattvenn | sounds like loads of pins for only 512k! | 16:00 |
| ric96 | daveshah: anyway to force yosys to use different read/write mode... Its seems to be only happy with mode 3 | 16:01 |
| maikmerten | no col/row multiplexing there ;) | 16:01 |
| daveshah | ric96: it's picking mode 3 for a good reason | 16:01 |
| ric96 | Defaults to that mode no matter what | 16:01 |
| daveshah | if you want to use another mode, instantiate the primitive yourself. But I don't know why you need mode 0, this sounds like an XY problem tbh | 16:01 |
| mattvenn | I've just been testing Kevin Hubbard's hyperram breakout | 16:01 |
| awygle | maikmerten: ground fills are fine as long as they're well stitched and you pull them back from anything you're analyzing with microstrip formulae | 16:03 |
| maikmerten | (as for other hocus-pocus (i.e. stuff I do that is not backed up by proper data): Avoiding routing signals through vias if possible, although this doesn't appear to be a problem per-se - BGA escape-routing usually relies heavily on vias) | 16:03 |
| maikmerten | ah, thanks :) | 16:05 |
| awygle | vias add inductance but aren't a big problem in themselves. and sometimes they're unavoidable, and sometimes going too far out of the way to avoid them adds *more* inductance. what you really want to look at is reference planes, but that's a more complicated topic. | 16:06 |
| * awygle is making a list of future blogs... | 16:07 | |
| *** proteus-guy has joined #yosys | 16:19 | |
| *** dys has joined #yosys | 16:48 | |
| *** tinyfpga has quit IRC | 16:52 | |
| *** tinyfpga has joined #yosys | 16:54 | |
| *** pie___ has quit IRC | 16:58 | |
| *** emeb has quit IRC | 17:04 | |
| *** mjoldfield has quit IRC | 17:10 | |
| *** mjoldfie_ has joined #yosys | 17:10 | |
| *** emeb has joined #yosys | 17:18 | |
| maikmerten | one of the weird features of the HX8K breakout board: On the four headers, the VCCIO{0-3} for the respective I/O-bank is accessible, but only on one the VCC33 line is available. The VCCIO-lines are derived from VCC33 via a filter-arrangement (an inductance, an 1-Ohm resistor, some capacitors) and it feels "wrong" to derive power for the SRAM from there... that one can source up to 180 mA when in full swing | 17:19 |
| daveshah | personally I'd replace at least the 1-ohm resistor with a 0-ohm resistor, if you are comfortable replacing an SMD resistor | 17:20 |
| daveshah | i'm not convinced the 1-ohm resistor will be doing much anyway | 17:20 |
| maikmerten | yeah, but OTOH I guess someone put some thought into that... | 17:22 |
| maikmerten | also, given that I need to spread over two headers, I can just take VCC33 from the one that I'll occupy anyways | 17:22 |
| maikmerten | it's just funny that on all headers, in the schematics, there is a very clear note: "MAKE PWR TRACES CAPABLE OF 1A" | 17:23 |
| daveshah | tbh Lattice, thought and development boards don't always go together | 17:23 |
| daveshah | there've been critical errors with PLL supplies before now | 17:23 |
| maikmerten | even on those that don't expose VCC33 | 17:23 |
| maikmerten | (and the linear regulator for VCC33 can deliver like 650 mA max) | 17:24 |
| maikmerten | (okay, continuous current - and that note may be for spikes or whatever) | 17:24 |
| maikmerten | yeah, I've heard of one particularly inexpensive board that just forgot decoupling on the PLL supply completely | 17:25 |
| maikmerten | despite there being a hardware design checklist that isn't even hard to read | 17:25 |
| maikmerten | (and not being very long) | 17:25 |
| daveshah | yeap | 17:26 |
| daveshah | and then people copy them because they think they are a golden reference (which they should be) ... | 17:26 |
| maikmerten | yay, VPP2V5 is derived from the 3.3 Volts supply... relying on a diode to drop 0.7 Volts | 17:27 |
| maikmerten | (I think that 2.5 Volts is only used for the NVCM stuff, which I'll sure never use) | 17:28 |
| maikmerten | I would think the voltage drop of the diode would be current-dependant, though, and the current here should be very low... | 17:29 |
| daveshah | if you look in detail, many of their boards use a schottky diode that drops nowhere near 0.7v... | 17:29 |
| maikmerten | I'll just take this as a hint that their chips are somewhat robust ;-) | 17:30 |
| daveshah | yeap | 17:30 |
| maikmerten | ooooh, I think that "filter arrangement" (inductor, resistor, capacitors) for the VCCIO-lines might be a valiant effort to ensure a proper power-on sequence | 17:33 |
| daveshah | maybe, sounds a bit dodgy | 17:35 |
| maikmerten | because, /me being naive, I wouldn't expect there to be much noise to filter out from a linear voltage regulator | 17:35 |
| daveshah | I've never seen an iCE40 fail due to bad power up sequencing TBH | 17:35 |
| daveshah | I suspect it could be to stop noise getting in from external devices | 17:36 |
| maikmerten | yeah, hmmm... | 17:37 |
| awygle | the 1 ohm resistor is probably for power measurements. | 17:56 |
| awygle | and the filtering could be an attempt to keep the VCCIOs from cross-contaminating | 17:57 |
| daveshah | yes, power measurement makes sense | 17:57 |
| awygle | it does sound a bit weird though tbh | 17:58 |
| awygle | any standard 1R resistor should handle 180 mA from a power dissipation perspective though. and dropping 0.18 V should be fine. | 17:59 |
| *** jwhitmore has quit IRC | 18:16 | |
| *** jwhitmore has joined #yosys | 18:17 | |
| *** pie___ has joined #yosys | 18:18 | |
| mjoldfie_ | It would be easy enough to solder a bit of wire across the resistor or pads even if you don't like SMD soldering. | 18:21 |
| *** promach_ has quit IRC | 18:34 | |
| *** pie___ has quit IRC | 18:45 | |
| *** m_w has joined #yosys | 19:34 | |
| *** cr1901_modern1 has quit IRC | 19:58 | |
| *** cr1901_modern has joined #yosys | 19:58 | |
| *** jwhitmore has quit IRC | 20:11 | |
| *** maikmerten has quit IRC | 20:22 | |
| mithro | So, when I run "proc" in yosys I'm getting the following | 20:45 |
| mithro | Warning: Replacing memory \storage with list of registers. See ../../../../vpr/mem/vpr_sp_ram.sim.v:18 | 20:46 |
| mithro | And yosys becomes very slow.... | 20:46 |
| daveshah | mithro: most likely you're doing something that Yosys does not support generating a memory for | 20:48 |
| daveshah | This means is explodes to lots of registers | 20:48 |
| mithro | I'm obviously doing something really stupid :-P | 20:48 |
| mithro | And it's probably because I've divided the hierarchy to much | 20:49 |
| daveshah | mithro: yeah, memory recognition is probably done before flattening | 20:51 |
| mithro | daveshah: https://github.com/mithro/symbiflow-arch-defs/blob/xml-no-parent/utils/vlog/tests/fig43-single_port_ram_mixed/single_port_ram_mixed.sim.v -- trying to emulate this -> http://vtr-verilog-to-routing.readthedocs.io/en/latest/tutorials/arch/timing_modeling/index.html#mixed-sequential-combinational-block | 20:54 |
| tpb | Title: symbiflow-arch-defs/single_port_ram_mixed.sim.v at xml-no-parent · mithro/symbiflow-arch-defs · GitHub (at github.com) | 20:54 |
| daveshah | mithro: yeah, I don't think Yosys would support an async write port if that's what's going on | 20:55 |
| mithro | daveshah: Yeah - I think it's because https://github.com/mithro/symbiflow-arch-defs/blob/xml-no-parent/vpr/mem/vpr_sp_ram.sim.v -- that is "just" the combinational part of the mem | 20:56 |
| tpb | Title: symbiflow-arch-defs/vpr_sp_ram.sim.v at xml-no-parent · mithro/symbiflow-arch-defs · GitHub (at github.com) | 20:56 |
| daveshah | mithro: yeah, that's nowhere near what Yosys would be expecting or able to deal with | 20:57 |
| daveshah | Also, a nice synthesis/simulation mismatch in that always block | 20:57 |
| mithro | daveshah: Yeah, I feel like if I did more verilog I would know WTF I'm doing here :-) | 20:58 |
| mithro | daveshah: But I don't do it that much | 20:58 |
| mithro | I have the gut feeling that it is a very strange way to do a memory cell :-P | 20:59 |
| daveshah | mithro: I've never seen a async write memory cell in HDL before | 21:00 |
| daveshah | It's not something you'd ever see in an ASIC or FPGA | 21:00 |
| shapr | is there a collection of things you can do in FPGA that you can't do in an asic? | 21:01 |
| daveshah | Unclocked read ports are extant though | 21:01 |
| daveshah | shapr: yeah, initialised RAM and DFFs mostly | 21:01 |
| daveshah | Partial reconfiguration too | 21:01 |
| daveshah | Although you can do that in an ASIC with a eFPGA | 21:01 |
| shapr | neat, thanks | 21:03 |
| daveshah | shapr: as far as I know, initial statements are ignored in ASIC synthesis | 21:04 |
| daveshah | Everything must be reset if you want it to be at a known value | 21:04 |
| mithro | daveshah: So you recon that the issue is the WE code...? | 21:06 |
| daveshah | mithro: I think if you add a clock to the write port it will work | 21:07 |
| shapr | makes sense, that's the part bunnie described in his risc-v vs meltdown/spectre blog post. I was unaware of that previously. | 21:12 |
| mithro | daveshah: This would be a more normal way of describing this memory | 21:18 |
| mithro | https://www.irccloud.com/pastebin/ahV0embG/ | 21:18 |
| tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 21:18 |
| daveshah | mithro: No, that mix of blocking and non blocking assignments is still horrible | 21:19 |
| daveshah | Let me find a good example | 21:19 |
| *** jwhitmore has joined #yosys | 21:20 | |
| daveshah | https://www.irccloud.com/pastebin/0599yYSp | 21:27 |
| tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 21:27 |
| daveshah | mithro: couldn't find a good example of this to hand but this above should be vaguely correct | 21:28 |
| daveshah | For a single port ram with clocked write and unclocked read, if that's what you want | 21:28 |
| awygle | it looks like in order to match the picture he sent that addr and wen and wedata all need to be registered | 21:29 |
| awygle | (inexplicably) | 21:29 |
| daveshah | Updated example accordingly | 21:30 |
| daveshah | I don't feel like the what the picture describes is really correct, it would be a race condition between wen and wdata/addr unless you were very careful | 21:32 |
| daveshah | I've never seen registered wen into an async memory as opposed to just a clocked write port with a wen input | 21:32 |
| awygle | out would definitely be very glitchy | 21:32 |
| awygle | i have no idea why you'd implement something that looked like that | 21:32 |
| daveshah | It seems to be a contrived example for VPR rather than anything you would practically want | 21:34 |
| awygle | yup | 21:35 |
| daveshah | They claim that the output port is combinational. But a combinational output port without any combinational inputs seems very odd | 21:35 |
| awygle | yup | 21:38 |
| mithro | You make async ram synchronous by adding registers? | 21:41 |
| daveshah | Yes, although the reality is a bit more complicated than just adding a register in front | 21:42 |
| mithro | So if the "cloud" is a combinational block | 21:43 |
| daveshah | Not least because of the we/data race we just discussed | 21:43 |
| daveshah | mithro: I think the example structure is simply from a timing point of view, rather than a real world implementation | 21:44 |
| daveshah | Or a sensible HDL implementation | 21:44 |
| mithro | Yes, that is correct - it is talking from a timing point of view | 21:45 |
| mithro | If you replace cloud with just some random combinational logic rather than memory (like a DSP hard logic) does it make more sense? | 21:48 |
| daveshah | mithro: yes, a DSP is a much better example | 21:49 |
| daveshah | The memory write port is by nature not purely combinational, which was the problem | 21:50 |
| *** jwhitmore has quit IRC | 21:50 | |
| daveshah | In a typical DSP structure you would have configurable registers at the input and output, plus configurable pipeline registers in the middle | 21:50 |
| daveshah | If only the input registers were enabled it would match that structure | 21:51 |
| mithro | How does a write port actually work? Is it more like a tristate? When WEN is low it doesn't drive anything into the cells? | 21:52 |
| daveshah | mithro: No, it would be closer to the enable input of a latch I suppose | 21:53 |
| daveshah | Of course it would be decoded so only a single location was selected | 21:53 |
| mithro | Really, I think what that diagram is trying to show is delay T after the clock edge the output is stable? | 21:53 |
| daveshah | mithro: yes | 21:54 |
| daveshah | Normally I've seen that implemented just using a high clock to Q time rather than the combined sequential and combinational approach | 21:55 |
| mithro | So the clock signal for the storage latches must be, wen & clk ? IE wen is working like a clock enable for a write clock? | 21:56 |
| daveshah | mithro: yeah, in a clocked write port it would look a bit like that | 21:56 |
| *** emeb has quit IRC | 22:30 | |
| *** dys has quit IRC | 22:34 | |
| *** emeb has joined #yosys | 22:44 | |
| *** promach_ has joined #yosys | 22:59 | |
| mithro | daveshah: I guess you should probably be asleep - but the dsp_XXX tests at https://github.com/mithro/symbiflow-arch-defs/tree/5ee753c532f567797984440ad92c1f9395fd0cb5/utils/vlog/tests feel a bit better... | 23:04 |
| tpb | Title: symbiflow-arch-defs/utils/vlog/tests at 5ee753c532f567797984440ad92c1f9395fd0cb5 · mithro/symbiflow-arch-defs · GitHub (at github.com) | 23:04 |
| *** seldridge has quit IRC | 23:23 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!
