thehurley3[m] has quit [Ping timeout: 250 seconds]
AlexDaniel-old[m has quit [Ping timeout: 250 seconds]
Wallbraker[m] has quit [Ping timeout: 252 seconds]
galv[m] has quit [Ping timeout: 264 seconds]
jfng has quit [Ping timeout: 276 seconds]
galv[m] has joined ##openfpga
jfng has joined ##openfpga
AlexDaniel-old[m has joined ##openfpga
nrossi has joined ##openfpga
pointfree[m] has joined ##openfpga
thehurley3[m] has joined ##openfpga
Wallbraker[m] has joined ##openfpga
indefini[m] has joined ##openfpga
edmund20[m] has joined ##openfpga
<tnt>
Can yosys infer RAM with write masks ?
Miyu has quit [Ping timeout: 252 seconds]
jfng has quit [Ping timeout: 250 seconds]
nrossi has quit [Ping timeout: 250 seconds]
edmund20[m] has quit [Ping timeout: 250 seconds]
Wallbraker[m] has quit [Ping timeout: 250 seconds]
thehurley3[m] has quit [Ping timeout: 250 seconds]
indefini[m] has quit [Ping timeout: 260 seconds]
galv[m] has quit [Ping timeout: 260 seconds]
AlexDaniel-old[m has quit [Ping timeout: 264 seconds]
pointfree[m] has quit [Ping timeout: 276 seconds]
Bike has quit [Quit: Lost terminal]
_whitelogger has joined ##openfpga
Wallbraker[m] has joined ##openfpga
thehurley3[m] has joined ##openfpga
edmund20[m] has joined ##openfpga
pointfree[m] has joined ##openfpga
AlexDaniel-old[m has joined ##openfpga
nrossi has joined ##openfpga
galv[m] has joined ##openfpga
indefini[m] has joined ##openfpga
jfng has joined ##openfpga
_whitelogger has joined ##openfpga
rohitksingh has joined ##openfpga
laintoo_ has quit [Read error: Connection reset by peer]
laintoo_ has joined ##openfpga
Maylay has quit [Ping timeout: 250 seconds]
rohitksingh has quit [Ping timeout: 240 seconds]
rohitksingh has joined ##openfpga
<Richard_Simmons>
seems like a lot of people are confused by the requirements of the risc-v contest
lovepon has joined ##openfpga
<sensille>
is risc-v anything more than "just" open? does it have some new ideas?
<whitequark>
sensille: not exactly, nothing radical i know of
<daveshah>
sensille: I believe it tends to avoid anything not documented less than 20 years ago for patent reasons
<azonenberg_work>
So intentionally conservative
<Richard_Simmons>
thought it had some fixes from other common riscs that were thought up in the 80s, nothing exactly new but hard to find in anything actually available
<SolraBizna>
based on my work with it so far, it's a nicely refined RISC, lacking features that turn out to be problems down the road
<SolraBizna>
like branch delay slots or predication or condition flags (this one is hard for me to get used to)
<daveshah>
Yeah I'm pretty sure all those things were avoided for good implementation reasons
<SolraBizna>
branch delay slots are only good if your microarchitecture has exactly the matching pipeline length, and even then the compiler will usually insert an explicit nop instead of the implicit pipeline bubble anyway
<azonenberg_work>
yeah branch delay slots basically make microarchitectural innovation impossible
<SolraBizna>
and predication and condition flags are more poisonous the more complex your pipeline is
<azonenberg_work>
as i found out when i tried to make a hyperthreaded mips :p
<azonenberg_work>
i had to do some nasty stuff to remember whether the instruction i context switched away from was in a delay slot or not
<SolraBizna>
it doesn't have register windows either
<SolraBizna>
I'm trying to read through that now, but my laptop is ten years old, it can't hold many Internets anymore
<daveshah>
Pretty sure there is nothing weird length in xbitmanip, although haven't looked recently
<daveshah>
Ah, some 64 bit instructions have been added
<daveshah>
Only available on rv64+
<daveshah>
Not 64 bit length AFAICS, just 64 bit operands
<SolraBizna>
it looks like if there ever was a weird-length instruction it's gone now
<SolraBizna>
I forgot one more weakness of RISC-V... no save/restore multiple instruction
m4ssi has joined ##openfpga
<SolraBizna>
whether that's a weakness or a strength depends on who you ask
GuzTech has joined ##openfpga
<Richard_Simmons>
I've watched too many videos of people working on BGAs. now I -want- to fuck with that.
m4ssi has quit [Ping timeout: 268 seconds]
m4ssi has joined ##openfpga
rohitksingh has quit [Ping timeout: 260 seconds]
wbraun has quit [Quit: wbraun]
lovepon has quit [Ping timeout: 252 seconds]
Miyu has joined ##openfpga
Miyu has quit [Ping timeout: 272 seconds]
_whitelogger has joined ##openfpga
gruetzko- has joined ##openfpga
gruetzkopf has quit [Read error: Connection reset by peer]
unixb0y has quit [Ping timeout: 272 seconds]
unixb0y has joined ##openfpga
gruetzko- is now known as gruetzkopf
kuldeep has quit [Quit: Its never too late!]
kuldeep has joined ##openfpga
<keesj>
but why can't I apt-get install a risc-v compatible compiler
<keesj>
(I want bare bones)
<sorear>
not sure; fedora 27 has gcc-riscv64-linux-gnu in the package repo
<jn__>
debian also has riscv64 compilers is unstable and testing
<keesj>
I see. (ubuntu also does have the 64 bits variant indeed) I want to start playing with picosoc on the TinyFPGA board
<sorear>
the riscv64 gcc will build riscv32 bare-metal code
<sorear>
it might not come with a riscv32 libgcc though
<keesj>
I will have to see
<daveshah>
Normally you have trouble as soon as you hit something that is done in library code
<daveshah>
Like multiply or divide on rv32i
unixb0y has quit [Read error: Connection reset by peer]
unixb0y has joined ##openfpga
<cr1901_modern>
the default linker script, even on rv32i, will "conveniently" link in libraries that assume hard floats exist.
<keesj>
for my purpose I think I will not need any math
rohitksingh has joined ##openfpga
emeb has joined ##openfpga
azonenberg_work has quit [Ping timeout: 244 seconds]
rohitksingh has quit [Ping timeout: 244 seconds]
GuzTech has quit [Quit: Leaving]
Miyu has joined ##openfpga
azonenberg_work has joined ##openfpga
azonenberg_work has quit [Ping timeout: 252 seconds]
wbraun_ has joined ##openfpga
rohitksingh has joined ##openfpga
m4ssi has quit [Remote host closed the connection]
azonenberg_work has joined ##openfpga
wbraun_ has quit [Quit: wbraun_]
rk[ghost] has quit [Ping timeout: 240 seconds]
mumptai has joined ##openfpga
rohitksingh has quit [Ping timeout: 272 seconds]
rohitksingh has joined ##openfpga
m4ssi has joined ##openfpga
rohitksingh has quit [Ping timeout: 268 seconds]
gruetzkopf is now known as gruetze
gruetze is now known as gruetzko-
gruetzko- is now known as gruetzkopf
rohitksingh has joined ##openfpga
rohitksingh has quit [Remote host closed the connection]
m4ssi has quit [Remote host closed the connection]
mumptai has quit [Read error: Connection reset by peer]
mumptai has joined ##openfpga
<Ultrasauce>
finally got around to actually trying yosys/icestorm/arachne and, wow
<Ultrasauce>
time-to-blinky was way low
<azonenberg_work>
Ultrasauce: yep
<azonenberg_work>
its fast
<azonenberg_work>
makes you not want to go back to vendor tools :p
<azonenberg_work>
only reason i still use them is that yosys/nextpnr/prjxray dont have working tools for 7 series or ultrascale yet
<Ultrasauce>
yeah I'm gonna need something with pcie soon but perhaps i'll be able to allocate some time to helping that happen
<sorear>
does yosys natively support your systemverilog subset yet?
<daveshah>
very experimental serdes support for ECP5 might be in nextpnr soon
<adamgreig>
daveshah: ooooh. yes please.
<Ultrasauce>
ooh nice
<sorear>
gruetzkopf has talked about working on a PCIe core once that happens
<gruetzkopf>
yes i have
<gruetzkopf>
the DLLP layer isn't that complicated
<daveshah>
I'm balancing working on the hardware side of things with the timing constraints side of things
<daveshah>
The latter are also needed for most fancy serdes designs
<sorear>
(( for prjxray, do we even have a rough idea what the hardware interface to the PCIe block looks like? is it AXI or something lower-level? ))
<daveshah>
I don't think anyone has really looked much at that stuff yet
mumptai has quit [Quit: Verlassend]
wbraun has joined ##openfpga
<azonenberg_work>
sorear: i dont think yosys can do structs
<azonenberg_work>
that's a pretty high priority feature for me
<azonenberg_work>
no enums either
<daveshah>
I think those both are on the list for 2019
<daveshah>
Someone did submit a PR for interfaces a few weeks ago which got merged
<azonenberg_work>
interfaces are nice but dont work well in vivado
<azonenberg_work>
in particular, you cannot make arrays of them
<azonenberg_work>
which is a must if you want to have any kind of a MP-SoC with networking between the cores
<azonenberg_work>
So i dont use them
<azonenberg_work>
i instead use structs, with one for output ports and one for input
<azonenberg_work>
its stupid but works with vivado :p
<sorear>
oh fun
<sorear>
unfortunately iverilog doesn't do structs
<azonenberg_work>
sorear: sounds like we have multiple tools to fix
<daveshah>
this is a really a general eda problem
<sorear>
(does verilator? I tried to get verilator working but it has a high boilerplate requirement and I didn't feel like writing a bunch of C code just to syntax check Verilog)
<daveshah>
FOSS and closed source
<daveshah>
I think VHDL 2008 is/was an even bigger mess than SV
<azonenberg_work>
daveshah: to start i want feature parity with the commercial fpga tools in terms of the subset of SV that is supported
<azonenberg_work>
additional features on top of that were nice
<azonenberg_work>
but for the moment my SV usage is the intersection of that supported by DC, VCS, and Vivado
<azonenberg_work>
so if yosys supports most/all SV features that work in all three of those, i'm good
<azonenberg_work>
(features that only work in one or another i dont use, thus are of no importance to me)
<daveshah>
I think the two big features in Yosys next year should be core SV support and DSP inference
<sorear>
i wonder how poorly a yosys->dc flow would work
<sorear>
via write_verilog presumably
<daveshah>
I'm also pushing for support for shared memory port inference (ie single port or true dual port)
<daveshah>
As the ecp5 has this and I know a few things I'd like to run need this
<daveshah>
sorear: no doubt its doable
<sorear>
daveshah: so I haven't personally encountered much of a use case for true dual port and I'm curious what you have in mind
<sorear>
does "pseudo dual port" just mean 1R1W?
<daveshah>
Things like small shared memory regions
<daveshah>
seen things like tlb implementations use them in various ways
<daveshah>
And a weird bidirectional FIFO type structure in a wishbone sdram controller
<daveshah>
For that I had to instantiate
<daveshah>
Yosys can support as many read and write ports as you want so long as they have their own address and control signals
<sorear>
how is yosys with byte and bit enables/
<daveshah>
Pretty good
<daveshah>
Should deal with all common cases fine
<daveshah>
It does have some sat magic to merge write ports too
<daveshah>
If none write to the same bit at the same time
<daveshah>
Don't understand the bram mapping fully
<daveshah>
Shared addresses would also be needed to infer ice40 ultraplus single port ram
emeb has quit [Ping timeout: 244 seconds]
emeb has joined ##openfpga
<azonenberg_work>
daveshah: that was something ISE sucked at
<azonenberg_work>
it would routinely infer extra read/write ports on memory because it wasnt smart enough to realize you never read X and Y in the same cycle
<daveshah>
Yosys certainly beats the Lattice ice40 tools on that
<azonenberg_work>
so i got used to putting my ram in a separate verilog module with explicit addr/data buses to it
<azonenberg_work>
i still infer within that module but now its easier on the tools
<azonenberg_work>
sorear: what about write_edif to dc?
<sorear>
azonenberg_work: that would require yosys to have a copy of the standard cell library
<sorear>
it's probably doable, but I suspect more moving parts
<azonenberg_work>
sorear: whats the point of using yosys if you arent compiling to the cell lib?
<azonenberg_work>
in fact why even use yosys -> dc at all? vs yosys -> par tool
<sorear>
parsing systemverilog and re-expressing it as behavioral verilog 1995
<azonenberg_work>
dc can read sv
<sorear>
so that you can use the same subset everywhere
<daveshah>
I'm also not convinced write_edif is tested with much other than Vivado
<azonenberg_work>
asic tools are way ahead of fpga tools in sv support
<daveshah>
I tried to get it to work with icecube and never succeeded
<azonenberg_work>
most of the fancy sv features were created for asic
<azonenberg_work>
my problem is mostly with vivado not accepting sv that worked fine when i simmed it in vcs or built in dc :p
<daveshah>
It's interesting because Vivado uses Verific's parser which is pretty good
<daveshah>
But not its elaborator
<daveshah>
Which I guess is where the problems are
<azonenberg_work>
yeah i wonder why they rolled their own elaborator?
<daveshah>
I think it's because they have horrible shit they need to do at elaboration
<daveshah>
Likely bram related
<sorear>
how much bram related horrible shit will we be doing
Maylay has joined ##openfpga
<daveshah>
Well we won't be doing it at elaboration
<daveshah>
Which does tend to improve the ability to recognise non standard patterns for bram use
wbraun has quit [Quit: wbraun]
<daveshah>
Vendor fpga tools tend to like pattern matching during elaboration too much from what I've heard
<azonenberg_work>
daveshah: all of my yosys-based inference work was working on the post "proc" netlist using RTLIL primitives
<azonenberg_work>
(for things like finding counters or shregs)
<daveshah>
That's a much better place imo
jevinskie has joined ##openfpga
Maylay has quit [Quit: Pipe Terminated]
<feuerrot>
wi 36
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]