<cr1901_modern>
That would be my fault, though I don't understand the error
<cr1901_modern>
did I forget a header?
<cr1901_modern>
(and only more recent compilers bitch about it?)
<cr1901_modern>
whitequark: ^^
<whitequark>
cr1901_modern: you likely did
<whitequark>
and the problem is that libstdc++ has little header hygiene
<whitequark>
i.e. it includes <map> somewhere internally
<cr1901_modern>
I have absolutely no way to test this atm, but indeed there's no "#include <map>" in Tile.hpp, so I guess that'll fix it
<d1b2>
<DX-MON> GCC 10 did some neat albeit breaking changes to help fix some of the outstanding header hygiene issues of late which may explain why it now complains about that kind of thing where it didn't before
mwk has joined #nmigen
d0nker5 has joined #nmigen
<whitequark>
that's a clang build i linked
_whitelogger has joined #nmigen
proteusguy has quit [Ping timeout: 256 seconds]
<d1b2>
<DX-MON> I was saying that more for cr1901_modern's benefit that it'll break in GCC 10 too most likely
<whitequark>
oh!
<whitequark>
yeah
proteusguy has joined #nmigen
jaseg has quit [Ping timeout: 264 seconds]
jaseg has joined #nmigen
<tpw_rules>
whitequark: i think my mistake is trying to specify read/write behavior across ports
<whitequark>
tpw_rules: can you elaborate?
<whitequark>
(... well, evidently nmigen cannot elaborate your code...)
<tpw_rules>
so i have a simple dual port RAMB16 and i want if i assert WE on the write port with a given data to a given address, and RE on the read port to the same address on the same cycle, i get the written data the next cycle
<tpw_rules>
i'm reading xilinx's stuff and i'm not 100% sure if the bram can support that?
<tpw_rules>
i've made fabric logic to do that for me but i'm doing dumb stuff and am having timing problems
<tpw_rules>
which says the BRAM does not support what i want i don't think?
<whitequark>
i think usually non-transparent behavior is supported
<whitequark>
let's see though
<tpw_rules>
it says it invalidates the other port
<whitequark>
wit
<whitequark>
*wait
<whitequark>
there is a certain terminology confusion here
<whitequark>
nmigen calls the read half and the write half a "port" each, whereas xilinx calls both halves together a "port"
<tpw_rules>
in my design both halves have a different address usually
<tpw_rules>
i just want this behavior when they happen to coincide
<whitequark>
ohhh
<whitequark>
tpw_rules: take a look at fig 13
<tpw_rules>
so one port composes a data in, data out, RE, WE, CLK, and address?
<whitequark>
yeah
<tpw_rules>
so i am using dual port and the "data is invalidated" mode applies
<tpw_rules>
which is lame. how do i ensure whatever nmigen creates for transparent=False is READ_FIRST?
<whitequark>
er
<whitequark>
the point of transparent=False is exactly that it asks the synthesizer to use a READ_FIRST port
<whitequark>
so unless it's buggy (which it can be), you should just get that
<tpw_rules>
i assume it's not but i don't know how to check
PyroPeter_ has joined #nmigen
<tpw_rules>
i looked in ISE and it said one port is READ_FIRST and the other is WRITE_FIRST
<whitequark>
do you write from both ports?
<tpw_rules>
iirc the READ_FIRST is the one that is written to so that should be what i want
<tpw_rules>
no
<whitequark>
this setting only matters for ports that write
<whitequark>
so you should be fine
<tpw_rules>
is it possible to express true dual port in nmigen? there's not like a ReadWritePort
<whitequark>
it is, you use the same address for a read and a write port
<tpw_rules>
okay
<whitequark>
there are some tricky issues with that, and a ReadWritePort will eventually be necessary
<whitequark>
but it can't be added before Yosys learns about those
<whitequark>
so for now i'm doing the best i can
<tpw_rules>
i don't think i need it but good to file that away
<tpw_rules>
i wonder if it would be faster to set the write port to WRITE_FIRST and read from both ports. then if the address is the same i can read from the write port instead of the other port with the different address
PyroPeter has quit [Ping timeout: 260 seconds]
PyroPeter_ is now known as PyroPeter
<whitequark>
faster as in, higher fmax?
<tpw_rules>
yeah
<tpw_rules>
currently there's just a register that stores last cycle's written value and uses a mux to select if the address was the same
<tpw_rules>
i guess i can try it. this spartan 3 is almost insultingly slow
<whitequark>
well you don't need that register, do you?
<tpw_rules>
why wouldn't i need that register?
<whitequark>
since it's actually synthesizing a READ_FIRST port
<tpw_rules>
that doesn't have the behavior that i want
<whitequark>
okay, then i don't understand what you want
<tpw_rules>
"i want if i assert WE on the write port with a given data to a given address, and RE on the read port to the same address on the same cycle, i get the written data the next cycle"
<tpw_rules>
currently i get the written data the cycle after that
<whitequark>
ohh
<whitequark>
you want *cross-port WRITE_FIRST*, right?
<tpw_rules>
yes
<whitequark>
right
<whitequark>
yeah this would actually be solved with a ReadWritePort
<tpw_rules>
and the little register and mux does that but i need the fastest solution
<whitequark>
you probably have to instantiate the primitive
<tpw_rules>
why would it be? would the readwriteport have two different addresses?
<whitequark>
oh wait, you also have two different addresses
<whitequark>
sorry
<tpw_rules>
the table 9 in that PDF i linked seems to say what i want is impossible on spartan-3 bram
<whitequark>
yyeah
Degi has quit [Ping timeout: 240 seconds]
<whitequark>
not just on S3, i think no Xilinx BRAM supports what you want
<tpw_rules>
i would probably extend it to no BRAM at all
Degi has joined #nmigen
<whitequark>
i can see someone adding cross-port hard transparency
<whitequark>
haven't seen it yet
<tpw_rules>
hm my idea is probably slower than what i have
d0nker5_ has joined #nmigen
d0nker5 has quit [Ping timeout: 260 seconds]
djr has joined #nmigen
<d1b2>
<edbordin> oh, looks like my clang build of nextpnr for os x is hitting the same issue with missing #include <map>. presumably best to just wait until addressed upstream.
<lkcl__>
anyway - they all have the capability you're looking for. please note the LGPLv3 license.
<lkcl__>
whitequark: when we have time (or if we find someone willing to have a go) we'll have a go at implementing some of those (superb) multi-port regfile designs you linked to, last week.
<lkcl__>
tpw_rules: the "operand forwarding" mmmassively increases gate count. i honestly don't know if there's anything that can be done about it.
chipmuenk1 has joined #nmigen
chipmuenk has quit [Ping timeout: 260 seconds]
chipmuenk1 is now known as chipmuenk
awe00 has joined #nmigen
awe00 has quit [Read error: Connection reset by peer]
_whitelogger has joined #nmigen
BracketMaster has joined #nmigen
awe00 has joined #nmigen
BracketMaster has left #nmigen [#nmigen]
<tpw_rules>
lkcl__: thank you but i think those are all way super turbo too complicated for my use case
<tpw_rules>
i'm staying as far away from a real processor as possible :P
cr1901_modern1 has joined #nmigen
cr1901_modern has quit [Ping timeout: 258 seconds]
<lkcl__>
tpw_rules: :)
<lkcl__>
if you only needed the one "synchronised" port it would be a *lot* simpler.
<lkcl__>
the "complexity" - it's not, really, it's relatively very few lines of code - is down to the fact that we want synchronisation (read/write forwarding) across *ALL* of the read and write ports that quotes makes it look complicated quotes.
emeb has joined #nmigen
hitomi2507 has quit [Quit: Nettalk6 - www.ntalk.de]
chipmuenk1 has joined #nmigen
awe00 has quit [Ping timeout: 260 seconds]
awe00 has joined #nmigen
chipmuenk has quit [Ping timeout: 264 seconds]
chipmuenk1 is now known as chipmuenk
<lkcl__>
oh - that and i added a "combinatorial" option (same-cycle - when synced=False).
<lkcl__>
if you were to strip all that back from RegFileMem you'd actually end up with only about... mmm... 40 lines of code?...
<lkcl__>
that's hardly considered "complicated", is it? :)
awe001 has joined #nmigen
awe00 has quit [Ping timeout: 258 seconds]
cr1901_modern1 has quit [Quit: Leaving.]
cr1901_modern has joined #nmigen
<DaKnig>
what's `read_port().en`?
<whitequark>
enable input. if you set it low the output of the port won't change
<DaKnig>
and by default it's 1?
<whitequark>
yeah
<DaKnig>
well there's nothing about htat in the doc strings
<whitequark>
open an issue
<DaKnig>
ok
<_whitenotifier-f>
[nmigen] DaKnig opened issue #496: no doc string for `en` in `ReadPort` - https://git.io/JUC7x
awe002 has joined #nmigen
awe001 has quit [Ping timeout: 264 seconds]
SpaceCoaster has quit [Ping timeout: 272 seconds]
SpaceCoaster has joined #nmigen
jaseg has quit [Ping timeout: 272 seconds]
jaseg has joined #nmigen
chipmuenk has quit [Quit: chipmuenk]
electronic_eel has quit [Ping timeout: 240 seconds]
electronic_eel has joined #nmigen
electronic_eel has quit [Ping timeout: 260 seconds]
electronic_eel has joined #nmigen
electronic_eel_ has joined #nmigen
electronic_eel has quit [Ping timeout: 265 seconds]
electronic_eel_ is now known as electronic_eel
electronic_eel_ has joined #nmigen
electronic_eel has quit [Ping timeout: 256 seconds]