<emeb_mac>
tnt: I'm trying to hook up the LED PWM driver also. When I do so I get this error in nextpnr: ERROR: No wire found for port LEDDRST on destination cell uut.uledpwm.PWMgen_inst.
<emeb_mac>
disconnecting that pin on the IP instance allows nextpnr to complete without errors, but I wonder why it's not recognized.
<emeb_mac>
some sort of error in the cell database?
emeb has quit [Quit: Leaving.]
<emeb_mac>
ok - looked into the ice40/cells.cc and see the note that this pin doesn't actually exist "for icecube compatibility only"
balrog has quit [Quit: Bye]
balrog has joined ##openfpga
GenTooMan has quit [Ping timeout: 250 seconds]
unixb0y has quit [Ping timeout: 250 seconds]
unixb0y has joined ##openfpga
lutsabound has quit [Quit: Connection closed for inactivity]
scrts has quit [Ping timeout: 250 seconds]
scrts has joined ##openfpga
scrts has quit [Ping timeout: 255 seconds]
<emeb_mac>
haha - 6502 controlling the LED PWM IP core.
gsi_ has joined ##openfpga
scrts has joined ##openfpga
gsi__ has quit [Ping timeout: 246 seconds]
rohitksingh_work has joined ##openfpga
OmniMancer has joined ##openfpga
<tnt>
emeb_mac: yeah, I had the same issue with rst
<emeb_mac>
Other than that it works fine
scrts has quit [Ping timeout: 246 seconds]
scrts has joined ##openfpga
emeb_mac has quit [Ping timeout: 246 seconds]
scrts has quit [Ping timeout: 250 seconds]
scrts has joined ##openfpga
ewen has joined ##openfpga
rohitksingh_work has quit [Ping timeout: 255 seconds]
m4ssi has joined ##openfpga
ewen has quit [Quit: leaving]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
rohitksingh_work has joined ##openfpga
scrts has quit [Ping timeout: 268 seconds]
Thorn has quit [Read error: Connection reset by peer]
Thorn has joined ##openfpga
scrts has joined ##openfpga
scrts has quit [Ping timeout: 246 seconds]
scrts has joined ##openfpga
genii has joined ##openfpga
rohitksingh_work has quit [Read error: Connection reset by peer]
hackkitten has quit [Read error: Connection reset by peer]
flea86 has quit [Quit: Goodbye and thanks for all the dirty sand ;-)]
<somlo>
^^ I wonder if/where we could see how many responses this got, and what (if anything) will be done with the collected data and the results, whatever they end up being
emeb has joined ##openfpga
sxpert has quit [Ping timeout: 272 seconds]
scrts has joined ##openfpga
msgctl is now known as loonquawl
<_whitenotifier-1>
[GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to master [+0/-0/±2] https://git.io/fjUJQ
<Cerpin>
Verilator's docs don't seem to list anything regarding getting line numbers in the testbench using --exe -- can you do that, or do you have to write your own makefile to get it?
<Cerpin>
I want to be able to use gdb on the output, basically
<Cerpin>
nvm, actually -- just going to write a makefile, easier than looking for anything
Bob_Dole has quit [Read error: No route to host]
scrts has joined ##openfpga
mumptai has joined ##openfpga
Bob_Dole has joined ##openfpga
<whitequark>
holy shit the HeAP placer is *fast*
<q3k>
it's stupid fast
cr1901_modern1 has joined ##openfpga
azonenberg_work has joined ##openfpga
cr1901_modern has quit [Ping timeout: 245 seconds]
rohitksingh has quit [Remote host closed the connection]
<TD-Linux>
whitequark, whoa did nextpnr get an analytical placer?
<whitequark>
yep
<whitequark>
like 3 hours ago
* TD-Linux
builds
scrts has joined ##openfpga
<daveshah>
It's the default for ECP5 already, for iCE40 we're letting it bed in a bit, you need `--placer heap` to use it
<daveshah>
You will also need to make sure the dev package for eigen3 is installed
cr1901_modern1 has quit [Quit: Leaving.]
cr1901_modern has joined ##openfpga
<TD-Linux>
wow only 16 iterations spent for annealing placer. nice
<TD-Linux>
it's not supposed to work so well for the initial commit :^)
<tnt>
TD-Linux: well, that has been available in a branch for a while. I've been using it for weeks (month even maybe) now.
<tnt>
It's a _really_ nice improvement.
<TD-Linux>
ecp5 feels almost as fast as ice40 now
<TD-Linux>
I should try openmp
<daveshah>
OpenMP doesn't make much difference for ECP5, it's more there for even bigger devices
<daveshah>
Analytic placer speed should be much less dependent on device size than SA
<daveshah>
A design of a given size should be similar regardless of how big the chip is
<whitequark>
ooooh
<whitequark>
so we wouldn't have a similar situation with s7 when it arrives
<daveshah>
I've been doing some tests with analytic placement with the 980k Virtex-7
<daveshah>
Using the Torc database
<daveshah>
Seems to scale pretty well, in fact the SA-based refinement after AP is the bottleneck
<daveshah>
Although I have some ideas as to how to fix that
<whitequark>
niice
<bubble_buster>
daveshah: ah the guy that abandoned the open source HLS tool to turn it into a proprietary for-profit tool :(
<daveshah>
Who?
<bubble_buster>
last I checked though, they're still using LLVM 3.5 :D
<bubble_buster>
Jason Anderson
<daveshah>
Ah, right
<bubble_buster>
I've upgraded LegUp to LLVM 7.0, planning to publish in the next two months or so
<daveshah>
Interesting
<bubble_buster>
want to play around with yosys/nextpnr as backends to legup
<whitequark>
legup?
<bubble_buster>
open source HLS
<bubble_buster>
using LLVM
<daveshah>
Would be great to see if Yosys integration works out
<daveshah>
If it's just Verilog, should work fine
<tnt>
Meh, I have enough trouble getting the low level synthesis to do what I want ...
<bubble_buster>
also want to replace the mips tiger softcore in their hw/sw flow with risc-v softcore
<daveshah>
Probably need to get DSP inference working better for many HLS apps
<daveshah>
I've personally found HLS very useful for some situations
<Finde>
what flow does legup target now?
<tnt>
daveshah: yeah "some situation"
<daveshah>
Not every situation, sure
<daveshah>
But saved an awful amount of time building the image processing pipeline for AR stuff
<bubble_buster>
the allocation/scheduling for legup takes in some architectural parameters so it kinda needs to be tuned to whatever fpga you're targeting, so I wouldn't say it's "just verilog" but yeah, I think if you're not using like... floating point IPs it might be just verilog for the most part
<bubble_buster>
I'm using legup for Stratix V with Quartus right now
<daveshah>
In terms of "just verilog" I was more concerned if it uses any SV stuff
<bubble_buster>
also supports Stratix IV, Cyclone II, maybe some other Cyclones I think
<bubble_buster>
and also some beta support for Xilinx
<bubble_buster>
oh yeah, just verilog not SV
<daveshah>
I guess it relies on DSP inference though?
<bubble_buster>
which I find annoying sometimes while debugging because the code it generates would be a lot cleaner if it could use some SV constructs
<bubble_buster>
not sure about DSP inference
<bubble_buster>
I know for floating point it explicitly instantiates altera IP modules
<daveshah>
Not sure what the open source floating point situation is
<bubble_buster>
I think there's a lot of interesting things you can do w/o floating point anyway. as long as the input code doesn't use it, doesn't matter if the backend supports it
<daveshah>
Yes, I had a lot of fun doing inverse perspective transforms in HLS using only fixed point
<bubble_buster>
there's soft fp implementations right? like for rv32im w/o f extension?
<daveshah>
Yes
<bubble_buster>
could possibly just offload to softcore
<TD-Linux>
virtually no video processing uses fp, so all the parts I care about could be used :)
<daveshah>
You can even have an M-mode stub that implements the FPU extensions
<bubble_buster>
that's what I want to do to implement a lot of the "unsupported" HLS features
<daveshah>
So you can run hard float code transparently
<daveshah>
But most people just use the compilers soft float
<bubble_buster>
what's the difference?
<Finde>
you can compile the former without the compiler having soft float
<Finde>
just leave it to the firmware
<bubble_buster>
I think on a long enough timeline I could get LegUp to support recursion, dynamic memory, file I/O, printf, etc
<bubble_buster>
oh you mean like the soft implementation is just built into the invalid opcode trap handler?
<Finde>
yeah you can do it that way
<Finde>
you could bootstrap OS boot with a relatively small implemented feature set by emulating a lot in M mode
<daveshah>
I did this recently to implement missing atomics for the userspace in the Linux kernel on VexRiscv
<daveshah>
Although that was actually in S mode rather than M mode
<Finde>
after you did that I was discussing how one could emulate atomics on multicore
<Finde>
which is one of those hacks that I find fascinating while also filling me with extreme dread
<bubble_buster>
ah, I am much more familiar with the user spec than the privileged spec, I was thinking M-extension when you said M-mode
<Finde>
does the LegUp licence restrict commercial use?
<bubble_buster>
yes I believe so
<bubble_buster>
I believe it also compels derivative works to make an effort to notify the original authors... I probably need to do that at some point
<whitequark>
uh, what?
<bubble_buster>
lol
<whitequark>
>Users agree to not redistribute the software, in source or binary form, to other persons or other institutions.
<whitequark>
well there goes any chance i'll look at it
<bubble_buster>
oh damn really?
<azonenberg>
That's pretty useless
<bubble_buster>
guess I'm not posting on GitHub?
<azonenberg>
you'd be better off reimplementing from scratch imo
<whitequark>
>The use of this software to assist in the development of new commercial FPGA architectures or commercial soft processor architectures is also prohibited without the written consent of the authors.
<bubble_buster>
I should email them, they abandoned it ~5 years ago to commercialize it
<whitequark>
wow, Stallman wept
<bubble_buster>
I wouldn't be surprised if they'd be willing to reconsider the license
<bubble_buster>
guess I wouldn't be surprised if they weren't willing though :/
<Finde>
you never know
<Finde>
then again you might need approval of A. Canis, J. Choi, R. Lian, Y.T. Chen, H. Hsiao, B. Fort, Q. Deng, B. Syrowik, N. Calagar, M. Hall, S. Hadjis, Q. Huang, M. Gort, V. Zhang, A. Kammoona, S. Brown, J. Anderson, and the University of Toronto.
<daveshah>
I can have a word with Jason at OSDA if you like
<Finde>
I'll get my groupmate to ask him too :D
<daveshah>
He's actually giving a talk there about LegUp and it's commercialisation
<Finde>
ohh
<Finde>
this sounds interesting
<azonenberg>
it sounds like they got bitten by the typical academic-to-profits bug
<azonenberg>
and are more interested in money than the work
<azonenberg>
Hmm, so glscopeclient falls flat on its face when it tries to draw <<1 sample per pixel
<azonenberg>
Zoomed in it's fine, zoomed out i get weird dots and degenerate stuff
<azonenberg>
I think the issue is that when it tesselates waveforms to polygons <1 pixel on a side they just disappear
<bubble_buster>
daveshah: that would be great if you don't mind
mumptai has quit [Quit: Verlassend]
<daveshah>
Sure, I'll see what I can do
<Finde>
looking forward to that 3rd bsd clause being in there
<hl>
whitequark: re: assemblers: randomly mentioning it in case you haven't encountered it, but djb made some weirdo customizable assembler called qhasm and then proceeded to write constant-time AES implementations in it. I don't remember much of the details though
<whitequark>
yeah, it's not quite what i mean
<whitequark>
*want
genii has quit [Read error: Connection reset by peer]