parataxis has quit [Read error: Connection reset by peer]
emily has quit [Remote host closed the connection]
emily has joined ##openfpga
_whitelogger has joined ##openfpga
OmniMancer has joined ##openfpga
<omnitechnomancer>
SpaceCoaster: I have not worked out how, you can always pipe its stdout somewhere else but I havent worked out how to get it not to make log files
Bike has quit [Quit: Lost terminal]
rohitksingh has joined ##openfpga
rohitksingh has quit [Remote host closed the connection]
rohitksingh has joined ##openfpga
rohitksingh has quit [Remote host closed the connection]
rohitksingh has joined ##openfpga
rohitksingh has quit [Ping timeout: 245 seconds]
rohitksingh has joined ##openfpga
_whitelogger has joined ##openfpga
Jybz has joined ##openfpga
sensille has joined ##openfpga
<sensille>
what do i need to program an ecp5? can i use a xilinx or altera programmer? or an avrispmkii?
<tnt>
anything that can play a svf file allows jtag programming.
<tnt>
alternatively, depending on the board, you might be able to just program the flash directly (using spi) and then let the ecp5 reconfigure itself on the next boot.
AndrevS has joined ##openfpga
_whitelogger has joined ##openfpga
ZombieChicken has joined ##openfpga
_whitelogger has joined ##openfpga
<sensille>
via jtag i mean. so i need to find out if there's an svf handler for xilinx or altera programmer
<sensille>
or the avrisp
<daveshah>
I think OpenOCD supports the Xilinx programmer and maybe the Altera one too
<sensille>
interesting, thanks
Kekskruemel has joined ##openfpga
Asu has joined ##openfpga
Asu has quit [Read error: Connection reset by peer]
<mwk>
whitequark: I pinged you because it involves a migen macro and I wanted to ask you whether this thing is intended to synth to BRAM or not
<mwk>
but the bug you linked answers this
<mwk>
thanks
<whitequark>
ack
<mwk>
so — the question now is what to do about the yosys pass doing this unsound transform
<mwk>
which is memory_dff
<mwk>
IMO the transform should be nuked, or at least stuffed with loads of checks that make it actually sound (ie. single clock for whole BRAM, no enables that could screw up semantics, ...)
<whitequark>
btw if you are looking into this...
<whitequark>
could you please fix transparent ports with RE?
<mwk>
you're welcome to chime in at JF, but if you don't want to bother, I'll handle this myself
<whitequark>
right now they're FUBAR
<mwk>
RE?
<whitequark>
read enable
<whitequark>
write_verilog emits invalid verilog for them
<mwk>
I don't know how they're even supposed to behave
<whitequark>
well, if the \EN input is low, the value does not change
<whitequark>
are there other possibilities?
<mwk>
I mean I'm not clear how transparent read ports are suppoed to behave
<mwk>
enable semantics are clear
<whitequark>
oh hm
<whitequark>
I mean I think the semantics is the same whether they're transparent or not but now I'm thinking about how the soft transparency logic should work
<whitequark>
the DFF is inside the BRAM, so you need a... latch after it
<mwk>
this never ends well
<whitequark>
I think I know how to do this
<mwk>
would a mux suffice?
<whitequark>
hmm
<Morn_>
is a transparent read port one that updates without clock cycle delay?
<whitequark>
yes
<mwk>
that sounds like async read port
<whitequark>
that's an easy and twice incorrect way to implement it
<mwk>
transparent is sync port that, if a value is written to the same address in the same clock cycle, reads the new value as opposed to the old value
<mwk>
(unelss I misremembered this badly)
<whitequark>
you're correct
<Morn_>
so still synchronous and with one cycle delay?
<mwk>
yes
<mwk>
the only difference is what happens when waddr == raddr
<whitequark>
basic soft transparency logic works like this: you add a mux between rdata and wdata, selecting on waddr == raddr
<Morn_>
i see, interesting
<whitequark>
this breaks down if you add enables
<whitequark>
read enable specifically
<Morn_>
how?
<whitequark>
because a disabled read port will still change state whenever waddr == raddr
<mwk>
hmm
<mwk>
have two extra registers
<Morn_>
could you do that check not before the waddr = raddr mux?
<mwk>
wdata, and waddr == raddr
<mwk>
have a mux after the registers
<mwk>
connect read enable as clock enable to both registers
<whitequark>
does that actually work?
<Morn_>
are you talking about a register-based memory or like an SRAM/BRAM?
<mwk>
I mean, we could do the same thing as memory_bram does in write_verilog and hope that whatever parses our code can figure out how to convert it back
<mwk>
but given how much BRAM inference sucks everywhere, I'm not hopeful about it
<mwk>
whitequark: this pattern doesn't have read enable though
<mwk>
which is because it's about a single port
<whitequark>
right
<whitequark>
it's about two ports
<whitequark>
read and write
<whitequark>
oh wait
<whitequark>
a single r/w port
<mwk>
yes
<whitequark>
right
<whitequark>
that's a pain
<mwk>
I wonder if Xilinx would even recognize it if you used different r/w addresses
<whitequark>
they have really weird handling of collisions
<whitequark>
I think I forgot to write down the exact details :/
<whitequark>
I've asked azonenberg to explain it before, I think?
<mwk>
you asked me about it
<mwk>
unless we're talking about different things
<mwk>
and my guess about the weirdness is that they're implementing WRITE_FIRST not by adding muxes but by manipulating relative timings of write strobe vs read strobe
<whitequark>
could have been you
<whitequark>
right, so, hm
<whitequark>
oh, I asked azonenberg about write-write collisions
<whitequark>
which are always undefined IIRC, which makes sense
<mwk>
yes, reasonable
<whitequark>
was there something weird about read-write collisions too?
<mwk>
I think so?
* mwk
opens documentation
<mwk>
alright, so for single clock, UG473 (series 7) says:
<mwk>
When one port performs a write operation, the write operation succeeds; the other port can reliably read data from the same location if the write port is in READ_FIRST mode. DATA_OUT on both ports then reflects the previously stored data.-
<mwk>
If the write port is in either WRITE_FIRST or in NO_CHANGE mode, then the DATA_OUT on the read port would become invalid (unreliable). The mode setting of the read-port does not affect this operation.
<mwk>
so the *read behavior* specified for the *write port* decides whether the read on the other port works right
<mwk>
which, incidentally, means you cannot really support transparent simple-dual-port memories, if I understand this correctly?
<whitequark>
so they're trying to play with timing of write strobe
<whitequark>
and as a side effect this completely defines their inter-port collision behavior
<whitequark>
right?
<mwk>
well
<whitequark>
the read strobe is fixed, and the timing of the write strobe is determined by the READ_FIRST/WRITE_FIRST setting
<mwk>
"then the DATA_OUT on the read port would become invalid (unreliable)"
<mwk>
the does not sound completely defined
<mwk>
but otherwise yes
<whitequark>
i meant defined in a colloquial sense
<whitequark>
"determines"
<mwk>
agreed
<mwk>
I wonder why, btw
<mwk>
so somehow the strobes on the two ports are slightly misaligned in such a way that it works fine for READ_FIRST mode, but not for WRITE_FIRST?
<ZirconiumX>
whitequark: idly browsing through prjbureau and noticed some typos in the NORx cells (output wire is QN, but assign goes to NQ)
<mwk>
hmm, Virtex 6 has the same weird async high address bits collision behavior as Spartan 6
<mwk>
I guess this translates to "don't use READ_FIRST when the two ports have different clocks, and don't use WRITE_FIRST if they have the same clock"
<mwk>
wonderful mess
<mwk>
why is everything horrible
<gruetzkopf>
aaaah
<gruetzkopf>
:xilinx_
<ZirconiumX>
I feel like I'm insufficiently educated on how Intel stuff works, and I appear to be the abyss domain expert here
<mwk>
Virtex 4 and Virtex 5 documentation says the same as Series 7 (ie. no weird high address bit behavior)
<mwk>
Spartan 3, on the other hand, says that using WRITE_FIRST or NO_CHANGE on a write port invalides the data read on the opposite port, but never mentions this only happens when they access the same cell
* mwk
wonders if that's an oversight, or if the hardware is *that* horrible
<mwk>
and Virtex 2 again matches Series 7
<mwk>
so probably an oversight
<omnitechnomancer>
oh my
<mwk>
alright
* mwk
has reached her quota for broken software, broken hardware, and broken languages today; goes to grab a coffee and forget all about blockrams
<whitequark>
heh
<whitequark>
weirdly enough, strange broken shit helps me recharge
<whitequark>
the stranger and brokener, the better. this is why i end up with so many 8051s i guess
Bike has joined ##openfpga
<gruetzkopf>
is the ti cc2531 in your collection yet? (usb FS, 2.4GHz radio, commonly used for 802.15.4 and zigbee)
<whitequark>
docs collection? or cursed shit collrection?
<gruetzkopf>
latter, docs are public
<gruetzkopf>
the radio controller is "interesting", you can pre-prepare command lists channel-controller style
<mwk>
whitequark: I don't mind strange broken shit, but this grew way too large for a quick fix and risks swapping out the stuff I'm working on now, for which I just managed to break a months-long procrastination streak
<gruetzkopf>
(all code i've ever seen for these radio 'hand-feeds' single commands though)
<gruetzkopf>
(radios from that family also exist as spi slaves) </otY>
<whitequark>
that actually sounds real neat
<whitequark>
I remember trying to use ti cc* chips as a little baby who couldn't RF
<whitequark>
unsurprisingly i never got any of them working because at the time i didn't have any pocket money and trying to do toner transfer for relatively fine pitch QFNs is hard
<whitequark>
and i think it was before the really cheap PCB fabs took off anyway
s_frit has joined ##openfpga
<gruetzkopf>
premade usb dongles with those are cheap, i can have the chinese drop-ship some if you want
<gruetzkopf>
ti cc1100 is _the_ classic sub-ghz radio, yeag
<gruetzkopf>
host clocked, data sampled at posedge
<whitequark>
yeah it's just two wire spi
<whitequark>
pretty uncursed if you ask me
<whitequark>
bit similar to microwire
<whitequark>
yeah, i should implement microwire for glasgow, and get this more or less for free
<whitequark>
i feel like i ought to write some sort of "universal serial core"
<whitequark>
with a SERDES-style pipelined interface and capability to do half/full-duplex single dual and quad transfers
<whitequark>
eSPI would work with it too
OmniMancer has quit [Quit: Leaving.]
rombik_su has joined ##openfpga
mumptai has joined ##openfpga
Hamilton has joined ##openfpga
<kc8apf>
That's the only simple part of eSPI
<whitequark>
indeed
<whitequark>
fun fact: when i talked about eSPI on twitter, its designer DM'd me
<kc8apf>
Nice
<kc8apf>
Speaking of 8051, I want to get back to playing with the JMedia JMS583 USB 3.1 to PCIe bridge
s_frit has quit [Remote host closed the connection]
s_frit has joined ##openfpga
<cr1901_modern>
I need to re-learn 8051 (after not having touched it for 8 years) for an upcoming project... whee...
<whitequark>
sdcc master now even has C2X features
<whitequark>
pretty impressive
<cr1901_modern>
Yea, that was my plan- checkout sdcc and use the upstream assembler
<whitequark>
hm, is there an issue with sdas8051?
<cr1901_modern>
No, tou just mentioned a while back that the upstream assembler got much better ergonomically, though that was months ago. sdcc may have released a version since then, making whether I use upstream or not irrelevant.
<whitequark>
ah interesting
Hamilton has quit [Quit: Leaving]
Jybz has quit [Excess Flood]
Jybz has joined ##openfpga
X-Scale` has joined ##openfpga
X-Scale has quit [Ping timeout: 240 seconds]
X-Scale` is now known as X-Scale
Kekskruemel has quit [Quit: Leaving]
Jybz has quit [Quit: Konversation terminated!]
Bob_Dole has quit [Read error: Connection reset by peer]
AndrevS has quit [Quit: umount /dev/irc]
cr1901_modern1 has joined ##openfpga
cr1901_modern has quit [Ping timeout: 240 seconds]
cr1901_modern1 has quit [Quit: Leaving.]
cr1901_modern has joined ##openfpga
Asu has joined ##openfpga
Asu` has quit [Ping timeout: 276 seconds]
rombik_su has quit [Read error: Connection reset by peer]