<tnt>
Can someone remind me is yosys can do simple-dual-port RAM inference with R/W ports in different clock domain ?
<tnt>
(ecp5 target)
<mwk>
yes
<mwk>
one read-only port, one write-only port
<mwk>
should work
<GenTooMan>
I suppose I need to switch to the ECP5... for experimenting.
<whitequark>
it works just fine on ice40 too
<tnt>
Ok thanks for the confirmation !
<whitequark>
in fact ice40 only has SDP RAMs
<tnt>
And anyway to force BRAM rather than TRELLIS_DPR16X4 and a shitdload of mux ?
<tnt>
If I make it bigger, it eventually switches to BRAM ... but still I don't care about wasting the space, I don't want 500 LUTs to save 1 EBR ...
<tnt>
tried (* nomem2reg *) but no effect.
<whitequark>
both LUTRAM and BRAM are inferred using the memory_bram pass
<whitequark>
so nomem2reg doesn't do anything
<whitequark>
right now there is no way to control BRAM inference, which imo is a serious yosys deficiency
<tnt>
:/
<whitequark>
I keep wanting to fix it
<tnt>
Ok, well I guess I'm going back to instanciation.
lopsided98_ is now known as lopsided98
<whitequark>
pepijndevos: could you explain how U and X work in VHDL for me?
<whitequark>
s/for/to/
azonenberg has quit [Ping timeout: 250 seconds]
azonenberg has joined ##openfpga
<tpw_rules>
whitequark: is there some chance syncfifobuffered behavior could be different in simulation vs reality on ice40?
<whitequark>
tpw_rules: hmm
<whitequark>
do you use nmigen.build?
<tpw_rules>
i use whatever the platform.build() does
<whitequark>
do you use processes in simulation or is it just your HDL?
<tpw_rules>
just my nmigen HDL
<whitequark>
then it's unlikely
<whitequark>
there could be simulator bugs
<whitequark>
but apart from that i think it should be the same
<whitequark>
you could try simulating the verilog
<tpw_rules>
hm. my thing is working great in simulation but not IRL in a way that suggests some issue with the FIFO
<tpw_rules>
how should i best do that
<whitequark>
does it pass timing?
<tpw_rules>
yeah, it's like 20% under
<whitequark>
hmm
<whitequark>
strange
<whitequark>
as for simulating the verilog, grab top.debug.v and write a trivial testbench that just toggles the clock
<tpw_rules>
what is your favorite simulator? i don't have one installed
<whitequark>
iverilog should do
<tpw_rules>
does it just output a VCD?
<tpw_rules>
the program it makes. eh let me fiddle with it a bit
<whitequark>
you can make it do that, yes
<whitequark>
$dumpvars; $dumpfile("foo.vcd")
<whitequark>
er. the other way around iirc
<whitequark>
reg clk = 0; initial begin $dumpfile("foo.vcd"); $dumpvars; end always #10 clk = ~clk;
<whitequark>
initial #100000 $finish;
<tpw_rules>
excellent, thank you. was trying to dig through my memory for that syntax
<tpw_rules>
hm it will take some work to take out the ice40 specific modules
<whitequark>
you can use yosys sim cells
<whitequark>
share/something/ice40/cells_sim.v
<tpw_rules>
how does the syncfifobuffered output interface work exactly? is r_en a read enable or a read acknowledge? is the data ready on the cycle r_en is asserted or the next?
<tpw_rules>
ah, it's an acknowledge. simulation and reality must not quite agree on that point. i don't have time today to poke more
Bike has quit [Quit: Lost terminal]
Jybz has joined ##openfpga
Jybz has quit [Quit: Konversation terminated!]
OmniMancer has joined ##openfpga
OmniMancer has quit [Quit: Leaving.]
<whitequark>
tpw_rules: that doesn't sound possible
<whitequark>
SyncFIFOBuffered is defined using ordinary synchronous logic
nrossi has joined ##openfpga
emeb_mac has quit [Quit: Leaving.]
<pepijndevos>
whitequark, I think U is like verilog's X: undefined. X in VHDL is "conflicting drive". If two outputs drive the same net to a different value, you get X
<pepijndevos>
I think a std_logic has like 12 different values or something insane like that
<pepijndevos>
9 apparently. Tbh, I have no idea what the "weak" values are used for.
<azonenberg>
pepijndevos: i think weak is for pullup/pulldown
<azonenberg>
so if you drive a weak 1 and strong 0 it resolves to 0, but strong 1 and strong 0 resolves to undefined
<pepijndevos>
Sure, but when would you use that? Does it actually synthesize to IOB's with pull-up?
<azonenberg>
i think it's mostly a simulation feature for modeling chip to chip links with pullups
<azonenberg>
A lot of the more complicated features in most HDLs aren't synthesizeable
<pepijndevos>
Right
ym has quit [Ping timeout: 265 seconds]
ym has joined ##openfpga
<whitequark>
pepijndevos: oh
<daveshah>
tnt: how big is this RAM? The threshold is 2048 bits
<daveshah>
Which I think is about 192 LUTs
<daveshah>
Also notable that LUTRAM is faster then BRAM which makes mapping decisions even harder
<daveshah>
I think the solution is a ramstyle attribute. It's already on the list of wanted features for a future bram pass
<daveshah>
The only question is when someone will actually write that
<daveshah>
(it might be me next year if no-one else does)
OmniMancer has joined ##openfpga
OmniMancer1 has joined ##openfpga
<OmniMancer1>
Is a 504 gateway timeout expected from wq's irclog?
OmniMancer has quit [Ping timeout: 240 seconds]
<whitequark>
someone crashed it with a long query, i think
<whitequark>
postgres never worked very well on it
<whitequark>
for no good reason
<OmniMancer1>
awww
<OmniMancer1>
no multigigabyte queries? :P
<whitequark>
no. postgres for some cursed reason really likes doing full scans
<whitequark>
even when there's perfectly good indexes all around
<whitequark>
the postgres community is all like "our query planner is so perfect, we didn't expose a way to force it to use an index" but guess what, they're wrong
<gruetzkopf>
the postgres codebase is *extremely* weird
<gruetzkopf>
but it works after building it with a circa-2005 SGI MIPS compiler
<azonenberg>
lol
<azonenberg>
postgres on an origin 2k?
<gruetzkopf>
onyx2, but yes :D
<gruetzkopf>
(origin2k + graphics)
<azonenberg>
yes i know what an onyx is
<azonenberg>
the eclub at rpi had one we never managed to get fully debugged
<gruetzkopf>
(and not 2005-era postgres - we tried the dec-2018-current release
<gruetzkopf>
onyx1 and onyx2 are quite different
<azonenberg>
ours was an onyx2
<gruetzkopf>
ah
<gruetzkopf>
i've had great luck with mine (two 'deskside'-style units that were always rackmounted)
<gruetzkopf>
threw NumaLink2 routers in them (absolutely unsupported, but works)
<rvense>
... the wq irclog runs on an onyx?
<whitequark>
no
<whitequark>
it runs on digitalocean
<rvense>
good!
<OmniMancer1>
I think I have in the long long ago seen questions on the LLVM/Clang mailing list about non 8 bit char
<whitequark>
there's a lot of those threads
<sorear>
there's one this month that was started by someone trying to use llvm to target a 257-bit blockchain widget
<sorear>
personally I at some point hallucinated that this was the problem AAP was intended to solve
<whitequark>
AAP?
<azonenberg>
257-bit blockchain widget? wut?
<azonenberg>
like, someone is trying to compile LLVM to blockchain?
<azonenberg>
how does that even work
<daveshah>
I'm sure there's been Yosys to blockchain stuff in the past
<daveshah>
But arguably that's more sensible than llvm
<TD-Linux>
lol, that's horrible. (also the 256 bit vm thing actually comes from bitcoin, not ethereum)
OmniMancer1 has quit [Quit: Leaving.]
<tnt>
daveshah: it was 1536 bits. And it was mapped to 500 cells not LUTs. 199 LUT4 + 24 TRELLIS_DPR16X4 + 114 TRELLIS_FF and some L6MUX21/PFUMX.
<tnt>
And yup, smething like ramstyle would be the ideal solution.
freemint has joined ##openfpga
freemint has quit [Remote host closed the connection]
emeb has joined ##openfpga
genii has joined ##openfpga
mkru has joined ##openfpga
mkru has quit [Client Quit]
qu1j0t3 is now known as OK_b00m3r
mkru has joined ##openfpga
mkru has quit [Client Quit]
AndrevS has joined ##openfpga
<somlo>
ZirconiumX: I now have riscv64-unknown-elf-gcc v.9.2.0, and still no errors building LiteX with the Rocket Chip, so it wasn't the gcc version
<ZirconiumX>
That is...very odd.
<somlo>
not sure I'll be able to comprehend what's actually wrong, but I'd be curious to see what error you're getting, now that I'm sitting in front of my development rig at the office :)
<somlo>
do you have this file: litex/litex/soc/software/compiler_rt/lib/builtins/int_lib.h ? If not, did you initialize submodules recursively under litex (but I'd do it under all lite* project directories, just to be sure)?
<somlo>
ZirconiumX: ^^
<ZirconiumX>
somlo: I do, yes
<ZirconiumX>
(I do have that file)
<somlo>
actually, that's not where si_int comes from, it's probably one of the includes *it* references
<somlo>
trying to hunt down what dependency I had and didn't think of listing explicitly as part of my "prerequisites" :)
<ZirconiumX>
Something must have gone badly wrong in the clone.
<daveshah>
Could it be a symbolic link?
<ZirconiumX>
ls -l confirms it *is* a file, not a symbolic link
<somlo>
nope, just a regular file for me
<daveshah>
I know git symbolic links can be weird sometimes
<daveshah>
Never mind though
<somlo>
dumb question, is it possible you ran out of disk space during the clone ?
<ZirconiumX>
Given the huge amount of deleted files in `git status`
<ZirconiumX>
I think I might have.
<somlo>
I mean, grasping at straws here, I'm not a git guru, just a regular schlub user :)
<ZirconiumX>
Now that builds cleanly
<ZirconiumX>
Thanks anyway, I'm an idiot it seems.
<somlo>
good to hear it works, and happy to help troubleshoot -- it's *usually* the little things, in my painful personal experience ;)
<ZirconiumX>
Amen to that >.>
<davidc__>
Heh, I fought a similar problem a few days back (submodules not checked out right causing weird compiler errors)
<azonenberg>
i dont know why submodules aren't automatically cloned by default
<azonenberg>
like, under what circumstances would you ever want half the code for a project?
<davidc__>
(doesn't help that I have a truly horrific build setup at the moment)
<somlo>
as a self confessed git "dumb user", I have a love/hate relationship with submodules :D
<ZirconiumX>
somlo: Also this config just barely fits on a Versa, wow
<somlo>
yeah, it's usually placing 98% of the slices
<daveshah>
There are some packing inefficiencies on the nextpnr side that I hope to look at soon
<daveshah>
It's always a tradeoff between packing denser and risking routeability issues and packing loosely and wasting resources
<daveshah>
I think the solution is to increase packing density once the design is close to overutilised
<daveshah>
That way those designs will at least get to routing, even if they take a long time to route, without hurting smaller designs
<somlo>
daveshah: sweet, then we can have a 128bit native axi rocket <-> litedram link; right now, if I try that on the versa, I get 101% slice utilization. Strange that the wishbone converter + data-width adapter utilizes *fewer* LUTs :)