<promach>
Why am I having error "SBY 20:33:19 [async_fifo] base: ERROR: No such command: read (type 'help' for a command overview)" for this line "read -formal async_fifo.sv" ?
<promach>
I am already using latest symbiyosys git
jwhitmore has quit [Remote host closed the connection]
<daveshah>
promach: you need the latest Yosys git for that too
<daveshah>
it was only added to Yosys a couple of weeks ago
<tpb>
Title: GitHub - YosysHQ/yosys: Yosys Open SYnthesis Suite (at github.com)
<promach>
I am using kernel 4.17.4
<promach>
./kernel/yosys.h:76:12: fatal error: tcl.h: No such file or directory
<daveshah>
promach: are you sure `tcl-dev` is properly installed?
<promach>
yes
<daveshah>
looking at the package contents it seemed /usr/include/tcl.h got moved to just /usr/include/tcl in newer ubuntus
<daveshah>
I don't use Ubuntu personally. Maybe ZipCPU is around, otherwise please open a GitHub issue (but removing the .h in the include directive should be a workaround for now)
<promach>
so, I will need to modify yosys.h then
* ZipCPU
starts reading backlog
<ZipCPU>
promach: Do you have verific installed?
<daveshah>
ZipCPU: tldr, Yosys seems not to build in Ubuntu 18.04 because of tcl.h
<promach>
no
<ZipCPU>
Then yosys can't process system verilog files.
<promach>
problem solved
<promach>
# include <tcl/tcl.h>
<ZipCPU>
That particular capabililty is part of the commercial version.
<promach>
daveshah: use # include <tcl/tcl.h>
<ZipCPU>
That would be why "read -formal async_fifo.sv" fails.
<promach>
ZipCPU: yup
<daveshah>
ZipCPU: read works with or without Verific
<daveshah>
it will autodetect and select the appropriate backend
<ZipCPU>
But SystemVerilog only works with Verific
<promach>
I got to go now. anyway, make is building now
<ZipCPU>
Sure, there are some supported non-verific pieces, but as a whole SystemVerilog requires Verific
<promach_>
make[1]: *** No rule to make target 'clean'. Stop.
<promach_>
seems like abc has some changes upstream
<daveshah>
promach_: I am building Yosys from source (not using AUR) on Arch fine
<promach_>
daveshah: you mean you "make && sudo make install" ?
<daveshah>
promach_: yeah, just trying with clean ABC now in case of ABC issues
<daveshah>
seems OK so far at least
<promach_>
ok, but to make things easier for future upgrade, I would email the AUR or ABC author about this. Do you think this would be a better idea ?
<promach_>
what do you mean by clean ABC ?
<promach_>
daveshah
<daveshah>
promach_: I deleted my ABC folder so Yosys cloned it again
<daveshah>
but it still built fine
<daveshah>
I'd flag this as an AUR issue tbh
<promach_>
ok
emeb has joined #yosys
emeb has quit [Ping timeout: 244 seconds]
seldridge has joined #yosys
luismarques has quit [Quit: luismarques]
emeb has joined #yosys
<promach_>
daveshah: solved the AUR issue. I used the wrong AUR
<promach_>
seems like yosys still does not fully support systemverilog
<promach_>
I have revert the coding style to verilog
luismarques has joined #yosys
mobius_ is now known as mobius
mobius has quit [Changing host]
mobius has joined #yosys
tmatth has joined #yosys
tmatth has left #yosys [#yosys]
luismarques has quit [Quit: luismarques]
pie_ has joined #yosys
jaafar has joined #yosys
<jaafar>
tinyfpga: are you around?
<tinyfpga>
jaafar: what’s up?
<jaafar>
tinyfpga: it's Jeff from the meetup :)
<jaafar>
tinyfpga: didn't know if you saw my email
<tinyfpga>
jaafar: i saw it, just hadn’t had a chance to reply yet :)
<jaafar>
I know you're busy shipping!
<jaafar>
OK good
<jaafar>
I was afraid you didn't read that address :)
<tinyfpga>
Should finish shipping today, then I’ll be catching up on everything else
<jaafar>
Take your time and good luck
<keesj>
good luck indeed!
<keesj>
I am going to give a presentation at work in a few days on the fpga work I have been doing. Being able to show them something like the floorplan https://knielsen.github.io/ice40_viewer/ice40_viewer.html really helps understanding. Thank you so much for the great work
<TD-Linux>
oh wow I didn't actually know about that tool. this is way better to explain fpgas than using the xilinx p&r tool. I like how it can show all the spans
<keesj>
on the blinky example (that is really quite simple) why don't I see a clock or similar going to the buffers? https://i.imgur.com/Lf7OdmY.png is this something implicit?
<knielsen>
keesj: the clock is using one of the global nets (I think), and those are not implemented yet
<knielsen>
you can see the clock entering in tile (0 8), from there it's routed to a global net and the rest is implicit in current code. The Icestorm docs has the details on how the global nets work
<knielsen>
would be nice to see those global nets, though - might be tricky to find a way to draw them without drowning everything else though
digshadow has joined #yosys
<keesj>
I don't see anything at (0 8) but I do see something at (0 16) called hwclk.
<knielsen>
right, that's the one
<keesj>
I think this is great enough to give a good start / idea on how things work. for myself I would like to understand a bit better but the presentation thursday so I don't have much time :P
<TD-Linux>
on the ice40 explorer I noticed there are massive true/false nets. what's up with that?
<knielsen>
TD-Linux: I think I remember seeing that - I suppose it's just using a single LUT to provide a constant "1" and then routing that everywhere (and similar for "0")
<ZipCPU>
There was an upgrade that was supposed to fix that. Did it ever make it downstream?
<knielsen>
though I can't now recall where it would need a constant 0/1 (it's been a while...)
<TD-Linux>
that looks like what it's doing. but... why?
<TD-Linux>
could just be that these are old bitstreams and a new yosys makes something better
<ZipCPU>
The issue was that "1" and "0" had to be created, so they were created once and then routed everywhere.
<knielsen>
the examples on ice40 viewer are definitely old bitstreams from a yosys probably several years old
<ZipCPU>
The upgrade as I recall was supposed to remove the dependency of these constants on the various LUTs.
<knielsen>
aha, so for example in a random place in the vga example I see a counter doing "trans_x + 1", and using a constant "1" net for an X+Y LUT function. That could just be done with a single-input X+1 LUT function, without needing the constant "1" input
<knielsen>
makes sense
digshadow has quit [Quit: Leaving.]
<keesj>
knielsen: what does
<keesj>
O meann in a LUT? is that OR?
<knielsen>
doesn't it just mean constant 0 output?
<keesj>
I don't know . sounds plausible
<keesj>
no I don't think so
<knielsen>
sometimes only the carry output from a cell is used, and the normal output is just make constant zero
<knielsen>
eg. see tile (23 19) in the vga example
<keesj>
(in the blinky example : counter[0] enters a block and (indeed possibly the carry goes to the next block)
<knielsen>
yes, the small wire vertically between the luts is the carry propagation
<knielsen>
for some reason, apparently counter[0] and counter[1] flip-flops were synthesised/placed separately from the others. I guess one might need to check the icebox_explain output in detail to get all details
<keesj>
I think I was looking at it the wrong way https://i.imgur.com/JNDWTPo.png (the a +b ) of counter 0 also acts as a flip flop). I will look at the js later
seldridge has quit [Ping timeout: 240 seconds]
seldridge has joined #yosys
seldridge has quit [Ping timeout: 265 seconds]
mjoldfield has quit []
seldridge has joined #yosys
seldridge has quit [Ping timeout: 264 seconds]
luismarques has joined #yosys
mjoldfield has joined #yosys
dxld has quit [Quit: Bye]
dxld has joined #yosys
digshadow has joined #yosys
dys has quit [Ping timeout: 240 seconds]
luismarques has quit [Quit: luismarques]
proteus-guy has quit [Remote host closed the connection]