| *** tpb has joined #yosys | 00:00 | |
| *** _whitelogger has quit IRC | 00:19 | |
| *** _whitelogger has joined #yosys | 00:21 | |
| *** emeb has quit IRC | 00:56 | |
| *** promach_ has quit IRC | 01:01 | |
| *** s_frit has quit IRC | 01:11 | |
| *** emeb_mac has joined #yosys | 01:12 | |
| *** AlexDaniel has quit IRC | 01:19 | |
| *** _whitelogger has quit IRC | 01:31 | |
| *** _whitelogger has joined #yosys | 01:33 | |
| *** X-Scale` has joined #yosys | 02:01 | |
| *** X-Scale has quit IRC | 02:03 | |
| *** X-Scale` is now known as X-Scale | 02:03 | |
| *** eightdot has quit IRC | 02:04 | |
| *** eightdot has joined #yosys | 02:06 | |
| *** gsi__ has joined #yosys | 02:28 | |
| *** gsi_ has quit IRC | 02:31 | |
| *** _whitelogger has quit IRC | 03:04 | |
| *** _whitelogger has joined #yosys | 03:06 | |
| *** pthomas has quit IRC | 03:20 | |
| *** leviathanch has joined #yosys | 03:45 | |
| *** flaviusb has quit IRC | 04:19 | |
| *** jevinskie has joined #yosys | 04:34 | |
| *** pie___ has joined #yosys | 04:38 | |
| *** pie__ has quit IRC | 04:42 | |
| *** chaseemory has quit IRC | 04:47 | |
| *** indy has quit IRC | 04:48 | |
| *** rohitksingh_work has joined #yosys | 04:54 | |
| *** indy has joined #yosys | 04:58 | |
| *** leviathanch has quit IRC | 05:51 | |
| *** emeb_mac has quit IRC | 06:26 | |
| *** jevinski_ has joined #yosys | 06:36 | |
| *** jevinskie has quit IRC | 06:38 | |
| *** MoeIcenowy has quit IRC | 07:12 | |
| *** MoeIcenowy has joined #yosys | 07:12 | |
| *** leviathanch has joined #yosys | 07:41 | |
| *** fsasm_ has joined #yosys | 08:37 | |
| *** fsasm_ has quit IRC | 08:40 | |
| *** m4ssi has joined #yosys | 09:20 | |
| *** MoeIcenowy has quit IRC | 09:24 | |
| *** MoeIcenowy has joined #yosys | 09:25 | |
| *** promach_ has joined #yosys | 10:17 | |
| *** rohitksingh_work has quit IRC | 10:31 | |
| promach_ | ZipCPU: Hmm... , I am really not sure why cover(in_valid); failed | 10:50 |
|---|---|---|
| promach_ | I have played around those lines with reference to in_valid | 10:50 |
| *** promach_ has quit IRC | 10:50 | |
| *** rohitksingh has joined #yosys | 10:53 | |
| *** finnb has joined #yosys | 10:58 | |
| *** rohitksingh_work has joined #yosys | 11:03 | |
| *** rohitksingh has quit IRC | 11:05 | |
| finnb | Hi - I'm planning on starting a project at work with a few colleagues. We want to be able to work on several different projects which share common components in the same repo. I'm trying to get an idea for a good project layout. Has anyone got any expamles? | 11:06 |
| *** rohitksingh_work has quit IRC | 11:41 | |
| *** rohitksingh has joined #yosys | 11:47 | |
| *** rohitksingh_work has joined #yosys | 11:53 | |
| *** rohitksingh has quit IRC | 11:55 | |
| ZipCPU | finnb: You mean ... how to organize your files? | 12:03 |
| ZipCPU | I might recommend each major component and each major get its own git repository. That way you can specifically include updates to your systems from component repositories in a managed fashion. | 12:05 |
| ZipCPU | i.e. nothing changes without a "git pull" on the component repository. (See git submodules for how to do this) | 12:05 |
| ZipCPU | Of the repositories I've seen, however, the solution(s) have been mixed. Not everyone does it this way. Some repos, such as the USRP repos, have a directory for common components and another directory for the various top level designs the components are used to build | 12:06 |
| ZipCPU | promach_: First two steps to dealing with any bug 1) add `default_nettype none, and 2) Make sure your design passes a verilator -Wall -cc multiply.v # check | 12:10 |
| ZipCPU | The more modern Verilator versions should be able to handle your formal stuffs to, so you might wish to try: verilator -Wall -DFORMAL -cc multiply.v | 12:10 |
| keesj | finnb: it used to be hard for people to collaborate but I think in 2019 it is safe to say that distributed versioning systems (git) pretty much solved this problem. Work separately in you on repo, when you are done rebase and create nice logical commits. that apply to the master branch. just avoid makefile that have different components on a single line. that is the defacto. now you are talking about using a | 13:01 |
| keesj | shared common components. ... if those are ready/tested/finished there is of course no problem but if they are still in develpoment.. treat them first like local comonents at the end of the project pick the good ones/spend the time merging | 13:01 |
| keesj | s/comonents/components/g all the difficulties you might get from using shared components (even with git submodules) are IMHO not worth the effort and creating the "base of common components" is also some kind of utopia. let the fitest of the survival survive | 13:04 |
| finnb | adding a bit of CI to make sure master is always fine isn't my problem | 13:05 |
| finnb | My problem is more... dependency management | 13:05 |
| keesj | it is more complex .. it is not because it is in master that it will apply/work on your local branch. of course some CI is great but that won't guard you against API changes and there you come to work on monday morning half way into solving a nice problem and you end up with a broken dependency because somebody had a different idea on how master should work. | 13:07 |
| *** danieljabailey has quit IRC | 13:08 | |
| keesj | I tried (not on VHDL/verilog) I must say many times but I find that the result are bulky systems that need to work in all previous and future edge cases. Creating a repo for shared code is I guess not that bad but deciding when to fetch code is a strategy that one can choose. | 13:10 |
| keesj | if you work locally (and use git) you are always free to pull and attempt a git rebase master. if it works .. great | 13:11 |
| keesj | there are a few possibilities described here to share code / release code and remain sane https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow | 13:12 |
| tpb | Title: Gitflow Workflow | Atlassian Git Tutorial (at www.atlassian.com) | 13:12 |
| finnb | I made a tool a while ago, albeit a very bad one, in which you listed the dependencies of a file. For example infra/fifo.v depends on infra/mem.v. Then if projects/foo/bar.v dpeneded on infra/fifo.v, it was fine because I had a yml file which would have a cfg file for bar.v which said it had a dependency on infra/fifo.v | 13:12 |
| finnb | I just wondered if there was anything like this out there alredy | 13:12 |
| finnb | s/I had a yml file which would have a cfg file/I had a cfg file | 13:13 |
| finnb | And it would generate the correct makefile for yosys / pnr / icestorm | 13:14 |
| finnb | Version controlling I have dealt with on bigger projects. This is just a team of 3 people. We won't be making API changes. I'd just like a way of controlling verilog dependencies | 13:14 |
| keesj | (with ghdl the same exists e.g but a bit more easy. you compile once using compile */*.v and then generate a makefile) don't know about yosys. but makefiles are often .. hell :P | 13:17 |
| keesj | vunit follows a similar approach https://vunit.github.io/user_guide.html | 13:18 |
| tpb | Title: User Guide VUnit documentation (at vunit.github.io) | 13:18 |
| keesj | (avoiding the makefiles in the first place) | 13:19 |
| finnb | I spotted a yosys -E flag earlier which I have yet to try out | 13:26 |
| keesj | omg.. I rembered my solution ... differently but.. it was an ugly shell script it worked and I did not think further https://github.com/keesj/can-hdl/blob/master/gen_desp.sh | 13:45 |
| tpb | Title: can-hdl/gen_desp.sh at master · keesj/can-hdl · GitHub (at github.com) | 13:45 |
| finnb | :| | 13:46 |
| *** proteusguy has quit IRC | 13:56 | |
| *** proteusguy has joined #yosys | 14:07 | |
| *** rohitksingh_work has quit IRC | 14:38 | |
| ZipCPU | finnb: Are you familiar with FuseSoC? | 14:41 |
| finnb | nope | 14:47 |
| ZipCPU | FuseSoC was designed to be / intended to be a configuration manager for FPGA designs composed of multiple parts from multiple separate distributions | 14:58 |
| ZipCPU | Feel free to ask about it on gitters #libresoc/fusesoc channel. You'll find olofk there. He should be able to help you get started | 15:00 |
| ZipCPU | I haven't tried it myself yet | 15:00 |
| keesj | https://www.youtube.com/watch?v=UMDcnwZA2YE also show "icosoc" that also looks nice (for ice40 boards) . I am currently learning migem/litex | 15:11 |
| finnb | Thanks :) | 15:12 |
| finnb | I'll likely be just targetting the ulx3s board for now anyway | 15:12 |
| finnb | Thanks for your help though and I will certainly look into this | 15:13 |
| *** proteusguy has quit IRC | 15:15 | |
| *** vup2 has quit IRC | 15:19 | |
| *** emeb has joined #yosys | 15:25 | |
| *** indy has quit IRC | 15:30 | |
| *** eightdot has quit IRC | 15:31 | |
| *** indy has joined #yosys | 15:34 | |
| *** eightdot has joined #yosys | 15:40 | |
| *** seldridge has joined #yosys | 15:46 | |
| *** maikmerten has joined #yosys | 16:04 | |
| *** jevinski_ has quit IRC | 16:05 | |
| *** tmbinc2 has joined #yosys | 16:11 | |
| *** emeb has quit IRC | 16:30 | |
| *** promach_ has joined #yosys | 16:43 | |
| promach_ | ZipCPU: I really hate c++ coding during verilator usage | 16:44 |
| ZipCPU | It must really be a struggle to have so much hatred within yourself | 16:44 |
| promach_ | I am not sure why all the commercial simulators in https://www.edaplayground.com/x/3TuQ does not work with 3D array in systemverilog | 16:45 |
| ZipCPU | Very few tools support multidimensional arrays. This is probably due to the fact that few (if any) hardware implementations support it | 16:46 |
| finnb | iverilog + gtkwave does :) | 16:46 |
| ZipCPU | You might wish to check your implementation against the standard, though --- I'm not sure that's how to implement a 3D array | 16:47 |
| finnb | I need to get into verilator | 16:50 |
| finnb | I'm still a "let's look at the waveform" kinda guy | 16:50 |
| ZipCPU | Verilator will support the "let's look at a waveform" philosophy | 16:52 |
| promach_ | ZipCPU: I know what went wrong | 16:52 |
| promach_ | thanks | 16:52 |
| ZipCPU | Glad I could help. You might want to thank finnb for his help as well. ;) | 16:52 |
| promach_ | thank finnb | 16:52 |
| finnb | no problem haha | 16:53 |
| promach_ | strange, reg [(NUM_OF_INTERMEDIATE_LAYERS-1):0][0:(SMALLER_WIDTH-1)][(A_WIDTH+B_WIDTH-1):0] middle_layers; works in Cadence, but not in iverilog | 16:55 |
| promach_ | iverilog systemverilog support is still ongoing | 16:56 |
| promach_ | the code also has no problem with vcs | 16:56 |
| promach_ | finnb : same problem with yosys-smtbmc | 16:57 |
| finnb | hmm sorry you're hitting the limit of my knowledge here | 16:59 |
| finnb | So you've tried the dumpvars function? | 16:59 |
| finnb | I think it's $dumpvars(0, filename) | 17:00 |
| promach_ | yeah | 17:00 |
| promach_ | see https://www.edaplayground.com/x/3TuQ | 17:00 |
| tpb | Title: multiply.v(1) - EDA Playground (at www.edaplayground.com) | 17:00 |
| finnb | ok I have one thing you can try | 17:01 |
| finnb | Have you tried using a generate statement? | 17:02 |
| promach_ | for what ? | 17:02 |
| finnb | oh wait a sec | 17:02 |
| finnb | $dumpvars(0, test_multiply); | 17:02 |
| promach_ | and ? | 17:03 |
| finnb | Is that the only place you dumpvars? | 17:03 |
| promach_ | yes | 17:03 |
| *** seldridge has quit IRC | 17:03 | |
| finnb | And your problem is you want to dump a 3d array? | 17:03 |
| finnb | Yeah ok I have dumped a 2D array with the following method as iverilog doesn't do it by default | 17:04 |
| promach_ | the problem does not exist in vcs or cadence | 17:04 |
| promach_ | but the problem exist in iverilog | 17:04 |
| finnb | https://pastebin.com/9eLgBhYy | 17:05 |
| tpb | Title: [VeriLog] integer k; initial begin $dumpfile("./bu - Pastebin.com (at pastebin.com) | 17:05 |
| finnb | Try adding something like this | 17:05 |
| finnb | It will puke up a load of warnings but just ignore them | 17:05 |
| finnb | you can adapt this to a 3d array I imagine | 17:05 |
| finnb | Though I haven't tried | 17:05 |
| promach_ | hmm... | 17:06 |
| finnb | have you tried that | 17:06 |
| finnb | change the filename to the filename you're using obviously | 17:06 |
| promach_ | no the problem is that the same testbench works with cadence and vcs | 17:06 |
| promach_ | but not iverilog | 17:06 |
| promach_ | do you get it ? | 17:06 |
| promach_ | and yosys-smtbmc seems to have issue with 3D array too, please correct me if wrong | 17:07 |
| finnb | Not really sorry, I thought your original problem was with 3d arrays and you wanted a workaround | 17:07 |
| promach_ | I should not say testbench, testbench is okay as far as I can see now | 17:08 |
| promach_ | I would say the souce code itself | 17:08 |
| finnb | So is your 3d array issue only in simulation or does it also not build? | 17:09 |
| promach_ | finnb : click the run button | 17:09 |
| promach_ | using cadence, vcs or iverilog | 17:09 |
| promach_ | then you will find that only iverilog gives you error | 17:10 |
| finnb | That requires me to create an account | 17:10 |
| promach_ | I mean the run button within https://www.edaplayground.com/x/3TuQ | 17:10 |
| tpb | Title: multiply.v(1) - EDA Playground (at www.edaplayground.com) | 17:10 |
| promach_ | a corporate company or educational institute email account will do | 17:11 |
| finnb | Can you paste in the error message instead? I'm neither corporate or in education | 17:13 |
| * promach_ had a preliminary conclusion that both iverilog and yosys-smtbmc do not support reg [(NUM_OF_INTERMEDIATE_LAYERS-1):0][0:(SMALLER_WIDTH-1)][(A_WIDTH+B_WIDTH-1):0] middle_layers; | 17:13 | |
| promach_ | multiply.v:96: error: A reference to a wire or reg (`pp_index') is not allowed in a constant expression. | 17:17 |
| promach_ | multiply.v:96: error: Array index expressions must be constant here. | 17:17 |
| promach_ | multiply.v:97: error: A reference to a wire or reg (`pp_index') is not allowed in a constant expression. | 17:17 |
| promach_ | multiply.v:97: error: Array index expressions must be constant here. | 17:17 |
| promach_ | finnb | 17:17 |
| promach_ | I guess a normal gmail account is suffice to use iverilog in edaplayground | 17:18 |
| promach_ | only commercial simulators need a corporate company or educational institute email account | 17:18 |
| promach_ | finnb: it is a bit late here. Shall we discuss later ? | 17:20 |
| promach_ | or you can leave message here. I will be back later | 17:20 |
| somlo | daveshah: ping | 17:22 |
| finnb | promach_, I have an idea | 17:23 |
| finnb | Just humour me and try this | 17:24 |
| finnb | reg [(NUM_OF_INTERMEDIATE_LAYERS-1):0] middle_layers [0:(SMALLER_WIDTH-1)] [(A_WIDTH+B_WIDTH-1):0]; | 17:24 |
| finnb | I'm actually just cooking | 17:24 |
| finnb | It isn't so late for me :P | 17:24 |
| finnb | Hmm actually I think your error is elsewhere tbh | 17:25 |
| finnb | I just get this: reg [(NUM_OF_INTERMEDIATE_LAYERS-1):0] middle_layers [0:(SMALLER_WIDTH-1)] [(A_WIDTH+B_WIDTH-1):0]; | 17:28 |
| finnb | oops | 17:28 |
| finnb | I just get some tomcat error | 17:28 |
| somlo | daveshah: I'm trying to modify the soc_versa5g pll.v example to give me 10MHz by changing s/CLKI_DIV(2)/CLKI_DIV(10)/ | 17:33 |
| somlo | daveshah: https://imgur.com/a/jSWmxRU | 17:33 |
| tpb | Title: Imgur: The magic of the Internet (at imgur.com) | 17:33 |
| somlo | daveshah: and wondering if I have to change any other parameters (not quite sure what the other *_DIV parameters are for), before I re-run synthesis, which takes several hours :) | 17:37 |
| daveshah | somlo: iirc there is a minimum input frequency after the divider, on phone rn so can't easily check but be careful with that | 17:38 |
| daveshah | Is synthesis really that slow? Where is it getting stuck? | 17:38 |
| somlo | daveshah: not getting stuck, just lots of work to do (rv64imadc rocket chip bare-metal demo -- inspired by soc_versa5g) | 17:42 |
| somlo | not enough room for "f", even on the 85k ECP5 :) but the f-less version fits on the 45k; nextpnr says it can go up to 10MHz | 17:43 |
| daveshah | Oh awesome | 17:43 |
| somlo | I wanted it to *actually* work before posting the code, but that rarely works out for me in real life :D | 17:44 |
| daveshah | https://github.com/YosysHQ/nextpnr/pull/219 should speed up placement by around an order of magnitude, but routing still needs a bit more work to speed up | 17:44 |
| tpb | Title: [EARLY WIP] HeAP-based analytical placer by daveshah1 · Pull Request #219 · YosysHQ/nextpnr · GitHub (at github.com) | 17:44 |
| somlo | so I think I might have screwed up the reset signal generator, and wanted to double-check the clock signal is OK before waiting another 4 hours to see if it worked | 17:45 |
| daveshah | The ecppll tool should give a working config | 17:46 |
| MoeIcenowy | somlo: how did you deal with rocketchip? | 17:47 |
| somlo | oh, cool, I'll see if I can figure out how to use it; Will also test-drive the pull request you referenced | 17:47 |
| MoeIcenowy | I'm afraid of the unreadable sources dumped by chisel | 17:48 |
| somlo | MoeIcenowy: I'll throw it up on github later today, either as a patch to prjtrellis (another demo folder in "examples") or as its own repo for the full details | 17:48 |
| somlo | but short version: I use sed to add uart and led signals to the top-level test harnes all the way through to the "external" mmio behav_sram module | 17:49 |
| somlo | it's mostly makefile magic :) | 17:49 |
| MoeIcenowy | BTW the VQM output functionality of Yosys seems to be broken when dealing with BRAM | 17:50 |
| somlo | and I replaced the mmio and RAM "behav_srams" with my own implementations: small(er) RAM initialized to "firmware.hex", and the MMIO one that twiddles the leds and uart | 17:50 |
| MoeIcenowy | smolo: BTW what's the LUT input number of ECP5? | 17:59 |
| MoeIcenowy | 4 or 6? | 17:59 |
| somlo | I *think* 4 | 18:00 |
| MoeIcenowy | oh I should read yosys techlib | 18:01 |
| MoeIcenowy | seems to be 4 with muxes inside cell | 18:01 |
| daveshah | Yeah, LUT4 with cascade muxes to build up to a LUT7 using an entire tile | 18:04 |
| MoeIcenowy | BTW is LUT4 better or LUT6? | 18:07 |
| MoeIcenowy | (seems a very newbie question) | 18:07 |
| MoeIcenowy | (my own think is that LUT4 is more space cheap but LUT6 has better timing | 18:07 |
| daveshah | I don't think it's a better or worse, but your thinking sounds reasonable | 18:09 |
| daveshah | The fact Xilinx uses LUT6 makes me think it's best for max performance | 18:10 |
| daveshah | I think I've seen somewhere that LUT4 has lower power | 18:10 |
| somlo | daveshah: ok, here's what I'm building right now: https://github.com/gsomlo/yoloRISC | 18:13 |
| tpb | Title: GitHub - gsomlo/yoloRISC: porting lowRISC to yosys/nextpnr/trellis on the Lattice ECP5 fpga (at github.com) | 18:13 |
| somlo | I'll probably nuke it and post a pull request as yet another demo for prjtrellis if/when I get it working :) | 18:14 |
| somlo | after which I'll dedicate myself to understanding "litedram" and finding an 85k board with adequate memory (or trying to bribe someone into redesigning one) :) | 18:16 |
| *** leviathanch has quit IRC | 18:18 | |
| daveshah | Awesome | 18:19 |
| *** X-Scale` has joined #yosys | 18:26 | |
| *** X-Scale has quit IRC | 18:26 | |
| *** X-Scale` is now known as X-Scale | 18:26 | |
| *** dys has joined #yosys | 18:29 | |
| *** m4ssi has quit IRC | 18:30 | |
| *** dys has quit IRC | 18:42 | |
| *** dys has joined #yosys | 18:58 | |
| *** xdeller_ has quit IRC | 18:59 | |
| *** xdeller_ has joined #yosys | 19:00 | |
| *** lutsabound has joined #yosys | 19:49 | |
| *** finnb has quit IRC | 20:44 | |
| *** finnb has joined #yosys | 21:16 | |
| finnb | promach_, I think I may have figured it out | 21:16 |
| finnb | Argh | 21:17 |
| finnb | Maybe not | 21:17 |
| finnb | I was going to say, have you checked you aren't initialising any arrays | 21:17 |
| finnb | nvm | 21:17 |
| *** danieljabailey has joined #yosys | 21:22 | |
| daveshah | somlo: https://usercontent.irccloud-cdn.com/file/HYTFDphU/MOV_0943.mp4 | 21:22 |
| daveshah | UART doesn't seem working and quite fast because I accidently left SIMULATION defined | 21:23 |
| daveshah | But this must be one of the most complex blinkies ever | 21:23 |
| daveshah | Thanks for your amazing work on this! | 21:23 |
| daveshah | Mind if I tweet it? | 21:23 |
| *** maikmerten has quit IRC | 21:30 | |
| *** lutsabound has quit IRC | 21:59 | |
| *** emeb has joined #yosys | 22:26 | |
| *** citypw has quit IRC | 22:40 | |
| *** citypw has joined #yosys | 22:52 | |
| *** finnb has quit IRC | 23:46 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!