leviathanch has quit [Remote host closed the connection]
emeb_mac has quit [Quit: Leaving.]
jevinski_ has joined #yosys
jevinskie has quit [Ping timeout: 250 seconds]
MoeIcenowy has quit [Changing host]
MoeIcenowy has joined #yosys
leviathanch has joined #yosys
fsasm_ has joined #yosys
fsasm_ has quit [Remote host closed the connection]
m4ssi has joined #yosys
MoeIcenowy has quit [Quit: ZNC 1.6.5+deb1+deb9u1 - http://znc.in]
MoeIcenowy has joined #yosys
promach_ has joined #yosys
rohitksingh_work has quit [Ping timeout: 244 seconds]
<promach_>
ZipCPU: Hmm... , I am really not sure why cover(in_valid); failed
<promach_>
I have played around those lines with reference to in_valid
promach_ has quit [Quit: WeeChat 2.3]
rohitksingh has joined #yosys
finnb has joined #yosys
rohitksingh_work has joined #yosys
rohitksingh has quit [Read error: Connection reset by peer]
<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?
rohitksingh_work has quit [Read error: Connection reset by peer]
rohitksingh has joined #yosys
rohitksingh_work has joined #yosys
rohitksingh has quit [Read error: Connection reset by peer]
<ZipCPU>
finnb: You mean ... how to organize your files?
<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.
<ZipCPU>
i.e. nothing changes without a "git pull" on the component repository. (See git submodules for how to do this)
<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
<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
<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
<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
<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
<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
<finnb>
adding a bit of CI to make sure master is always fine isn't my problem
<finnb>
My problem is more... dependency management
<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.
danieljabailey has quit [Ping timeout: 272 seconds]
<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.
<keesj>
if you work locally (and use git) you are always free to pull and attempt a git rebase master. if it works .. great
<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
<finnb>
I just wondered if there was anything like this out there alredy
<finnb>
s/I had a yml file which would have a cfg file/I had a cfg file
<finnb>
And it would generate the correct makefile for yosys / pnr / icestorm
<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
<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
rohitksingh_work has quit [Read error: Connection reset by peer]
<ZipCPU>
finnb: Are you familiar with FuseSoC?
<finnb>
nope
<ZipCPU>
FuseSoC was designed to be / intended to be a configuration manager for FPGA designs composed of multiple parts from multiple separate distributions
<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
<ZipCPU>
Very few tools support multidimensional arrays. This is probably due to the fact that few (if any) hardware implementations support it
<finnb>
iverilog + gtkwave does :)
<ZipCPU>
You might wish to check your implementation against the standard, though --- I'm not sure that's how to implement a 3D array
<finnb>
I need to get into verilator
<finnb>
I'm still a "let's look at the waveform" kinda guy
<ZipCPU>
Verilator will support the "let's look at a waveform" philosophy
<promach_>
ZipCPU: I know what went wrong
<promach_>
thanks
<ZipCPU>
Glad I could help. You might want to thank finnb for his help as well. ;)
<promach_>
thank finnb
<finnb>
no problem haha
<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
<promach_>
iverilog systemverilog support is still ongoing
<promach_>
the code also has no problem with vcs
<promach_>
finnb : same problem with yosys-smtbmc
<finnb>
hmm sorry you're hitting the limit of my knowledge here
<promach_>
a corporate company or educational institute email account will do
<finnb>
Can you paste in the error message instead? I'm neither corporate or in education
* 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;
<promach_>
multiply.v:96: error: A reference to a wire or reg (`pp_index') is not allowed in a constant expression.
<promach_>
multiply.v:96: error: Array index expressions must be constant here.
<promach_>
multiply.v:97: error: A reference to a wire or reg (`pp_index') is not allowed in a constant expression.
<promach_>
multiply.v:97: error: Array index expressions must be constant here.
<promach_>
finnb
<promach_>
I guess a normal gmail account is suffice to use iverilog in edaplayground
<promach_>
only commercial simulators need a corporate company or educational institute email account
<promach_>
finnb: it is a bit late here. Shall we discuss later ?
<promach_>
or you can leave message here. I will be back later
<tpb>
Title: Imgur: The magic of the Internet (at imgur.com)
<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 :)
<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
<daveshah>
Is synthesis really that slow? Where is it getting stuck?
<somlo>
daveshah: not getting stuck, just lots of work to do (rv64imadc rocket chip bare-metal demo -- inspired by soc_versa5g)
<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
<daveshah>
Oh awesome
<somlo>
I wanted it to *actually* work before posting the code, but that rarely works out for me in real life :D
<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
<daveshah>
The ecppll tool should give a working config
<MoeIcenowy>
somlo: how did you deal with rocketchip?
<somlo>
oh, cool, I'll see if I can figure out how to use it; Will also test-drive the pull request you referenced
<MoeIcenowy>
I'm afraid of the unreadable sources dumped by chisel
<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
<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
<somlo>
it's mostly makefile magic :)
<MoeIcenowy>
BTW the VQM output functionality of Yosys seems to be broken when dealing with BRAM
<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
<MoeIcenowy>
smolo: BTW what's the LUT input number of ECP5?
<MoeIcenowy>
4 or 6?
<somlo>
I *think* 4
<MoeIcenowy>
oh I should read yosys techlib
<MoeIcenowy>
seems to be 4 with muxes inside cell
<daveshah>
Yeah, LUT4 with cascade muxes to build up to a LUT7 using an entire tile
<MoeIcenowy>
BTW is LUT4 better or LUT6?
<MoeIcenowy>
(seems a very newbie question)
<MoeIcenowy>
(my own think is that LUT4 is more space cheap but LUT6 has better timing
<daveshah>
I don't think it's a better or worse, but your thinking sounds reasonable
<daveshah>
The fact Xilinx uses LUT6 makes me think it's best for max performance
<daveshah>
I think I've seen somewhere that LUT4 has lower power
<tpb>
Title: GitHub - gsomlo/yoloRISC: porting lowRISC to yosys/nextpnr/trellis on the Lattice ECP5 fpga (at github.com)
<somlo>
I'll probably nuke it and post a pull request as yet another demo for prjtrellis if/when I get it working :)
<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) :)
leviathanch has quit [Remote host closed the connection]
<daveshah>
Awesome
X-Scale` has joined #yosys
X-Scale has quit [Ping timeout: 250 seconds]
X-Scale` is now known as X-Scale
dys has joined #yosys
m4ssi has quit [Remote host closed the connection]
dys has quit [Ping timeout: 250 seconds]
dys has joined #yosys
xdeller_ has quit [Read error: Connection reset by peer]
xdeller_ has joined #yosys
lutsabound has joined #yosys
finnb has quit [Remote host closed the connection]
finnb has joined #yosys
<finnb>
promach_, I think I may have figured it out
<finnb>
Argh
<finnb>
Maybe not
<finnb>
I was going to say, have you checked you aren't initialising any arrays