Richard_Simmons has quit [Ping timeout: 244 seconds]
OmniMancer1 has joined ##openfpga
OmniMancer has quit [Ping timeout: 272 seconds]
Degi has quit [Ping timeout: 264 seconds]
Degi has joined ##openfpga
Bike has quit [Quit: leaving]
kristianpaul has quit [Read error: Connection reset by peer]
kristianpaul has joined ##openfpga
_whitelogger has joined ##openfpga
hitomi2509 has joined ##openfpga
hitomi2509 has quit [Read error: Connection reset by peer]
hitomi2509 has joined ##openfpga
emeb_mac has joined ##openfpga
mossmann has quit [Ping timeout: 260 seconds]
jeanthom has joined ##openfpga
mossmann has joined ##openfpga
emeb_mac has quit [Quit: Leaving.]
emeb has quit [Quit: Leaving.]
<omnitechnomancer>
Arithmetic in verilog wraps yes?
<tnt>
Post the actual code ... there are so many cases it's hard to answer that.
<omnitechnomancer>
Oh just the code from before, trying to comprehend why it might make yosys memory hungry
<omnitechnomancer>
cause verliator of course points out that bit_idx is not the same width as NUM_REQUESTERS and so it must always be < NUM_REQUESTERS...
<omnitechnomancer>
for loops feel like a troubling construct in an hdl
<omnitechnomancer>
at least their semantics are easier to grasp in something like migen or nmigen
Gracana has quit [Ping timeout: 256 seconds]
Asu has joined ##openfpga
cyrozap has quit [Ping timeout: 260 seconds]
cyrozap has joined ##openfpga
cyrozap is now known as Guest30462
Gracana has joined ##openfpga
jeanthom has quit [Ping timeout: 240 seconds]
peeps[zen] has joined ##openfpga
peepsalot has quit [Ping timeout: 264 seconds]
Sinclair2 has joined ##openfpga
<omnitechnomancer>
Can OpenRAM generate FIFOs or would I have to make a verilog FIFO wrapper for a two port SRAM?
<tnt>
it can't generate FIFOs.
<tnt>
OpenRAM generates a RAM, that's it, nothing fancy.
<tnt>
"it" is complex enough :p
<azonenberg>
Lol yes. Especially dual port sram is fun
<omnitechnomancer>
Indeed
<omnitechnomancer>
I assume the extra bits to make sram into a FIFO is reasonably synthesisable?
<whitequark>
it's two counters
<whitequark>
of course they're synthesizable. how do you think FIFOs work?
<whitequark>
oh wait, were you using vendor libraries for FIFOs before?
<omnitechnomancer>
I have not implemented one myself before, I figured it would be something like that
<omnitechnomancer>
does yosys synthesis typically consume > 8GB for something on the order of 70k altera logic elements?
<daveshah>
No, I would expect about 1GB max for that sort of thing
<tnt>
omnitechnomancer: do you need a sync one or async one ?
<tnt>
omnitechnomancer: if yosys ram usage explodes, most likely some ram failed to be inferred and is being implemented as a shitload of flipflops.
<tnt>
(in my experience)
<whitequark>
you can use (*ram_block*) to forcibly prevent that
<omnitechnomancer>
sync one but only 1 clock
<whitequark>
sync FIFOs always use 1 clock
<omnitechnomancer>
I should probably add a case for yosys ram
<whitequark>
only if you load techlibs from buttplug.io
<whitequark>
answering your question seriously: sync FIFO is 1 clock, async FIFO is 2 clocks
<whitequark>
i'm not aware of any other interpretation
<omnitechnomancer>
oh I accidentally left out the l, I was confused...
<omnitechnomancer>
I have been trying to cajole NyuziProcessor into a state that I can put it through yosys, tnt helped me with an issue I ran into before where it would have a ram explosion generating the RTLIL for the round robin arbiter
omnitechnomancer has quit [Quit: killed]
emily has quit [Quit: killed]
anu3jn has quit [Quit: killed]
jevinskie[m] has quit [Quit: killed]
promach3 has quit [Quit: killed]
eddyb has quit [Quit: killed]
indefini[m] has quit [Quit: killed]
wiizzard has quit [Quit: killed]
notafile has quit [Quit: killed]
henriknj has quit [Quit: killed]
xobs has quit [Quit: killed]
enick_8 has quit [Quit: killed]
lopsided98 has quit [Ping timeout: 260 seconds]
lopsided98 has joined ##openfpga
promach3 has joined ##openfpga
pepijndevos has quit [Ping timeout: 260 seconds]
pepijndevos has joined ##openfpga
pepijndevos has quit [Max SendQ exceeded]
pepijndevos has joined ##openfpga
_whitelogger has joined ##openfpga
jeanthom has joined ##openfpga
jeanthom has quit [Remote host closed the connection]
finsternis has joined ##openfpga
kmehall_ has joined ##openfpga
grantsmith has joined ##openfpga
keesj has joined ##openfpga
jeanthom has joined ##openfpga
simeonm has quit [Ping timeout: 258 seconds]
simeonm has joined ##openfpga
Bike has joined ##openfpga
<Gracana>
whitequark: re (* ram_block *): where can I learn about that and other attributes supported by yosys?
<Gracana>
ah brams_map.txt defines how that stuff is matched
jeanthom has joined ##openfpga
<Gracana>
tnt: I'm glad you pointed that out, though... I didn't even notice all that stuff in the readme.
<tnt>
I know there is a ram_style="block" "distributed"
<omnitechnomancer>
Isn't that somewhat FPGA specific and sort of one level up from is this a RAM vs a pile of FFs?
<Gracana>
yeah brams.txt says it supports syn_* attributes from lattice diamond, so you can also do syn_ramstyle=block_ram and whatnot
<tnt>
That is definitely fpga specific.
<Gracana>
but I think the advantage here is that you can hint to yosys how it should map your design to the hardware, without having to change your verilog to instantiate vendor-specific stuff directly.
Sinclair2 has quit [Read error: Connection reset by peer]
Sinclair2 has joined ##openfpga
Hoernchen has quit [Read error: Connection reset by peer]
Hoernchen has joined ##openfpga
jeanthom has quit [Ping timeout: 240 seconds]
emeb has joined ##openfpga
hitomi2509 has quit [Quit: Nettalk6 - www.ntalk.de]
kristianpaul has quit [Read error: Connection reset by peer]
<etrig>
they also provide some handy pkgbuilds if archlinux arm is your thing
<whitequark>
Gracana: this one is actually standard verilog
<kbeckmann>
nextpnr-ecp5 question: what's a good way to debug "Warning: Failed to find a route for arc 0 of net sys2x_clk" ? Trying to build a LiteX design with ethernet/etherbone and for some configurations it just fails, but works fine with others. sys2x_clk is a PLL output passed through an instance of ECLKSYNCB. This is with a recent build, 30 Sep 9aff6aa5.
<whitequark>
Gracana: see ieee 1364.1 §6.1
<daveshah>
kbeckmann: you might get a bit more info running with --debug --verbose
<kbeckmann>
thanks
<daveshah>
Otherwise, give me the json+lpf combo and I'll have a look
<daveshah>
lkcl mentioned hitting a similar issue once but I haven't triggered it myself to be able to debug what exactly happens
<kbeckmann>
ok! will do.
<Gracana>
thanks whitequark, I'd never seen this standard
<daveshah>
Its a bit of a strange standard as it is essentially deprecated, but was never properly replaced in SystemVerilog
<daveshah>
So really it is still the best reference as to what should be synthesizable
<whitequark>
systemverilog has always_sync and always_comb but it never actually says what constructs are permitted there nor does it allow making noncompliance with those directives an error. this always struck me as boneheaded
<whitequark>
i wonder if this was some odd compromise in the committee or something
<Gracana>
that seems likely :|
<daveshah>
Yeah, equally in SV there is no definitive guide as to whether you can use ?: for an async reset
<daveshah>
Whereas 1364.1 is clear that only if/else is legal
<whitequark>
it's especially bad because when i complain about verilog people are always "hey systemverilog fixed that" and well no it didn't
<whitequark>
also always_comb is broken by design still