<whitequark>
for example, xilinx tells you to use specific hdl "templates" to get specific kinds of ram
<whitequark>
some of those aren't even behavioral
<Sprite_tm>
Well, this is Yosys/nextpnr, whic supposedly does things the right way.
<whitequark>
yosys' memory_bram is one of the buggier passes, it sorely needs a rewrite
<whitequark>
anyway
<Sprite_tm>
For some reason, it refuses to infer RAM, though... and I'm bonking my head against the wall by now.
<whitequark>
it tells you exactly why in the log, you can read it.
<whitequark>
(well, sometimes it tells you why it thinks it can't infer a RAM, not why it's actually happening, but that's still useful)
<whitequark>
Bram port A1 has incompatible enable structure.
<whitequark>
Failed to map write port #0.
<Sprite_tm>
Yeah, I get that indeed.
<whitequark>
actually, i think dual-port ram on ecp5 might just be broken in yosys
<whitequark>
or more like, unfinished
<whitequark>
i vaguely recall something like that
<Sprite_tm>
Omg :/
<Sprite_tm>
Well, back to Claris Designer to whip me up a primitive then :/
<Sprite_tm>
*Clarity
<whitequark>
there should be an attribute that makes failing to infer bram an error
<whitequark>
actually, this "incompatible enable structure" error is interesting
s_frit has quit [Remote host closed the connection]
s_frit has joined ##openfpga
<whitequark>
Sprite_tm: yes. indeed. it looks like ecp5 does not support true dual port rams with yosys
<Sprite_tm>
:/
<Sprite_tm>
Hm, would also be nice to have an attribute for 'Yes, this is a piss-ass small bit of memory, but I'm running out of LUTs, so please dump this in a BRAM anyway'.
<Sprite_tm>
At least, I assume Yosys isn't smart enough to adjust that threshold itself.
<whitequark>
it isn't
<whitequark>
it should be, really
<whitequark>
anyway
<cr1901_modern>
you can supply a bram rules txt file to override yosys' defaults
<whitequark>
there was an attribuet
<whitequark>
let me check
<azonenberg>
You want something akin to the xilinx RAM_STYLE attribute i think
<azonenberg>
(i would suggest being syntax compatible with that if possible, for compatibility of yosys w/ the vendor tooks - but i guess we could write some remapping passes to translate if needed)
<whitequark>
azonenberg: i don't think yosys should strive to be compatible with any speicfic vendor toolchain, other than wrt primitives
<whitequark>
certainly, it should not blindly copy xilinx's attributes on behavioral ram
<azonenberg>
whitequark: see, my thought is that you should be able to compile code written for ise/vivado on yosys unmodified
<azonenberg>
having better attribute models on top of that is fine
<azonenberg>
i dont care if its implemented as a compatibility layer to something else in RTLIL
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<whitequark>
yeah i'm not sure if yosys actually implements this
<whitequark>
which is a pity
<mwk>
AFAIK no xilinx attributes are implemented atm
<mwk>
there is a pass, attrmap, which is supposed to be useful for translating vendor-specific attributes to yosys ones, but no synth_* flow uses it for anything yet
<azonenberg>
Because I have a MemoryMacro module in antikernel-ipcores, for example
<mwk>
of course, first you would need something to translate it *into*
<azonenberg>
that allows you to use vendor indepndent attributes to describe the type of memory you want
<azonenberg>
and it will force inferring, say, a 2-port block ram with a double pipeline register
<whitequark>
mwk: no, i mean selection of memory style
<whitequark>
can't find it anywhere
<mwk>
ah yes, that too
<whitequark>
but it's easy to add that
<mwk>
yes
Bike has quit [Quit: Lost terminal]
<mwk>
*sigh* why can't xilinx decide on a single fucking endian for the bitstream
<azonenberg>
mwk: MSB-is-bit-zero needs to be taken out behind the barn and put down
<mwk>
*shrug* I could live with that
<mwk>
if they at least did they consistently
<azonenberg>
Lol
<mwk>
(although I do agree it's an abomination)
* azonenberg
spent most of last night chasing a bug where the ICAP wasn't working to read the IDCODE
<azonenberg>
turns out, you need to have a two-clock latency after sending the sync word before it processes any traffic
<azonenberg>
... but the behavioral sim model does not enforce this pipeline delay
<azonenberg>
so my code worked fine in sim :p
<mwk>
huh?
<azonenberg>
i was trying to make a "who am i?" module
<mwk>
series 7 bitstreams only have a single nop between the sync word and the first reg write
<azonenberg>
that would be compiled for any 7-series FPGA and give you the jedec idcode
<azonenberg>
maybe its only for reads
<azonenberg>
maybe 1 for writes and 2 for reads?
<azonenberg>
empirically, reads issued with a single nop between sync word and read are ignored
<mwk>
that would be crazy
<azonenberg>
there's no output
<mwk>
but *shrug*
<mwk>
could be
<azonenberg>
the icap may also have different pipeline latency than selectmap or the external interface
<azonenberg>
i'll poke more at it later ifi have time
<azonenberg>
right now, i have it working
<azonenberg>
and i never want to touch that cursed thing again :p
<mwk>
that doesn't make much sense either
<mwk>
but eh
<mwk>
the only way to find out is more blacbox RE
* mwk
currently staring at horrible bit position calculations in their own config frame parsing code written months ago and wondering if all of this is really necessary, or was just a horrible hack added at 3am to make this cursed shit work
<mwk>
I suppose the code could be significantly less horrible if python had some usable bitvector type
<azonenberg>
ah ok, see right now my code twiddling stuff for the icap is all in systemverilog
<azonenberg>
but i'm generating stuff
<azonenberg>
for parsing config frames in C++ i just use struct unions
<mwk>
what
<azonenberg>
But i didn't go into the FDRI/FDRO data at all
<azonenberg>
i just worked at the config state machine level
<mwk>
what what what
<mwk>
are you using C struct bitfields?
<azonenberg>
for the type 1 / type 2 read/write packet headers? yes
<mwk>
...
<mwk>
why
<azonenberg>
and for things like parsing the status register
<mwk>
did nobody tell you they are horribly broken?
<azonenberg>
I use __attribute__((packed))
<mwk>
that doesn't help at all
<azonenberg>
afaik that is fully supported and documented in gcc at least
<mwk>
no
<mwk>
bitfield packing order is *still* platform-dependent
<azonenberg>
whats wrong with them?
<mwk>
some platforms stuff them from the MSB, some from LSB
<azonenberg>
oh you mean if i was compiling on a big endian platform, yeah
<mwk>
correct
<whitequark>
it's kind of ridiculous to still be writing c code that only works "on gcc on little endian"
<azonenberg>
Well right now i am only targeting x86 and arm linux
<azonenberg>
whitequark: who still uses big endian platforms these days?
<azonenberg>
(and it's C++)
<whitequark>
azonenberg: wrong question
<azonenberg>
afaik big won on the network but all mainstream cpus are little
<azonenberg>
arm, riscv, x86, almost all mips
<whitequark>
the right question is "why make your code nonportable for no real improvement"
<whitequark>
ah well
<azonenberg>
whitequark: no, the question is why would i go through extra work to add support for obscure platforms i never expect to encounter?
<azonenberg>
I'm trying to make it compile on all mainstream architectures and work fine
<azonenberg>
and hopefully eventually improve windows/mac support
<whitequark>
i guess if it's just for your personal use it doesn't matter
<azonenberg>
if the debug code parsing the bitstreams breaks on big endian mips, i just have to add some ifdefs and change 2 functions to add a FlipBitArray() call before i do the parsing
<azonenberg>
whitequark: I do not have the time or motivation to make any of my f/oss projects work on all computers known to mankind
<azonenberg>
I care about portability, but it has a cost
<whitequark>
sure, neither do i, which is why i use languages that feature bitfields that aren't totally broken :p
<azonenberg>
Avoiding explicitly OS-dependent APIs when possible in favor of e.g. std::thread? Sure, i make a point of doing that
<azonenberg>
But the alternative to bitfields in C/C++ is to explicitly write all of the bit shifting and masking and have two cases for native endianness (assuming the end goal is just to spam a byte[] out to some jtag dongle etc)
<azonenberg>
bitfields produce code that is vastly easier to read
<azonenberg>
10-20 years ago i would say caring about endianness portability in such things would be a bigger deal
<whitequark>
mh, right, two cases make it more annoying
<azonenberg>
And like i said, since i only use them when packing/unpacking data it would be pretty trivial to htonl() all of the uint32_t packet data if i needed to
<mwk>
no.
<mwk>
that reverses bytes, not bitfields
<azonenberg>
but that makes the code longer and adds a performance hit to support architectures none of my actual or hypothetical users use
<azonenberg>
mwk: ok fine, FlipBitArray()
<mwk>
and how would you write that?
<mwk>
it depends on bitfield lengths and positions
<mwk>
you cannot know these because C++ has no introspection
<whitequark>
actually it'd be pretty easy to use C++ to make bitfields that don't suck
<whitequark>
and don't rely on compiler-specific platform-specific behavior just to avoid a few shifts
<whitequark>
bitfields should be ripped out from the standards
<mwk>
a bit of operator overloading should do it, yes
<mwk>
correct
<mwk>
the C bitfields have exactlty 0 sane uses
<whitequark>
you can't even use them for hardware registers
<whitequark>
because the access width isn't guaranteed or controllable
<whitequark>
even with compiler extensions
<azonenberg>
With gcc at least the bit ordering of bit fields is well defined wrt endianness
<azonenberg>
whitequark: well IMO if your hardware cares about access width for a SFR it's broken :
<azonenberg>
:) *
<whitequark>
azonenberg: ~all ARM hardware does
<whitequark>
that i've seen anyway
<whitequark>
but also, isn't C supposed to be y'know a low-level language?
<whitequark>
(rhetorical question)
Ekho has quit [Ping timeout: 258 seconds]
futarisIRCcloud has joined ##openfpga
Flea86 has joined ##openfpga
Thorn has quit [Read error: Connection reset by peer]
mumptai has joined ##openfpga
Thorn has joined ##openfpga
Ultrasauce has quit [Quit: Ultrasauce]
Ultrasauce has joined ##openfpga
mumptai has quit [Quit: Verlassend]
emeb_mac has quit [Ping timeout: 248 seconds]
Ekho has joined ##openfpga
edmoore_ has quit [Ping timeout: 248 seconds]
edmoore_ has joined ##openfpga
Asu has joined ##openfpga
unixb0y has quit [Ping timeout: 258 seconds]
AndrevS has joined ##openfpga
unixb0y has joined ##openfpga
marcan has quit [Quit: Now where's my screwdriver...]
marcan has joined ##openfpga
wpwrak has quit [Ping timeout: 248 seconds]
linzhi-sonia has quit [Quit: leaving]
linzhi-sonia has joined ##openfpga
linzhi-sonia has quit [Quit: leaving]
linzhi-sonia has joined ##openfpga
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
AndrevS has quit [Remote host closed the connection]
genii has joined ##openfpga
emeb has joined ##openfpga
Flea86 has quit [Quit: Leaving]
finsternis has quit [Remote host closed the connection]
<mwk>
hey, anybody here happened to use the DebugBitstream option with Xilinx ISE on Virtex 4/5/6 or Series 7? because I'm looking at it, and either the hardware is much weirder than I thought (with horrible layering violations), or bitgen is buggy and the generated bitstreams have no chance of working...
<ZirconiumX>
mwk: porqué no los dos?
<mwk>
eh.
<ZirconiumX>
I'm bored and on a train
wpwrak has joined ##openfpga
* mwk
bored, without a train
<ZirconiumX>
An hour and a half to burn
<mwk>
do you have some cursed piece of hardware with you to reverse?
<mwk>
I mean, a book would work too, but less fun
<ZirconiumX>
Unless my phone counts as cursed, no
<ZirconiumX>
At home I have a Corsair keyboard which is reasonably cursed
<mwk>
what's wrong with it?
<ZirconiumX>
And I've already done a fair amount of RE on it
<ZirconiumX>
It's a proprietary USB protocol that's inconsistent, frequently breaks, and sometimes crashes
<ZirconiumX>
(yes, you can crash your keyboard. That's a fun experience.)
<mwk>
oh
<mwk>
custom USB protocol? how does that work?
<mwk>
reminds me, my laptop keyboard is slowly becoming cursed recently
<ZirconiumX>
It's a proprietary get/set type protocol bolted onto the payload of Interrupt URBs
<ZirconiumX>
(originally Controls but then they changed that to interrupts)
<mwk>
sometimes it randomly goes into state where 8 i k , = ] keys don't work
<mwk>
but only when the laptop is on, if you suspend it, the keys work perfectly well to take it up, and cease working again when it's awake
<mwk>
*to wake it up
<mwk>
and then it fixes itself again randomly after some time
<ZirconiumX>
That sounds like it goes into numpad mode?
<ZirconiumX>
Ouch.
<ZirconiumX>
So, Corsair keyboards have three different modes
<mwk>
yeah, could be, but... only affects a single column
<mwk>
and the keys generate *no* events
<ZirconiumX>
Normal mode, which runs the proprietary Corsair protocol and standard USB HID *simultaneously*
<ZirconiumX>
So when you press a key, you get both the Corsair scancode and the USBHID scancode
<ZirconiumX>
BIOS mode, which is 6KRO instead of NKRO, activated either by the keyboard's (poor) autodetection, or holding a key combo
<ZirconiumX>
Which is indicated by your scroll lock blinking, which gets quite distracting
<ZirconiumX>
And demo mode, in which the keyboard times out waiting for enumeration and then displays an animation that you can't exit without factory resetting your keyboard
<mwk>
um wat
<ZirconiumX>
This was improved in firmware version 1/3/5 (depending on the mood of the manufacturer)
<ZirconiumX>
Sorry, 1/3/5/30
<ZirconiumX>
Which are all the same firmware version but the major number is all over the place
azonenberg_work has joined ##openfpga
<mwk>
improved how?
<ZirconiumX>
In version 1/2/4/10 it went into demo mode whenever it wasn't enumerated in 5 seconds; in 1/3/5/30 the delay is a lot longer (5 minutes?), but gets saved to flash.
<ZirconiumX>
Thus why you need to factory reset your keyboard to get it to act as a keyboard again.
<mwk>
so um
<mwk>
if you connect it to a computer in suspend....?
<mwk>
how do you even factory reset a keyboard
<ZirconiumX>
If the USB power is on, you're SOL.
<davidc__>
thats amazing. Plenty of laptops have charge-ports that stay alive when the machine is off
<mwk>
magnificent
<ZirconiumX>
You hold Esc while plugging it in
<ZirconiumX>
And that erases all the settings to factory default.
<ZirconiumX>
Could be worse!
<davidc__>
sure... it could spontaneously combust.
<ZirconiumX>
Corsair make certain mice (Glaive, Scimitar Pro) which have no BIOS compatibility mode.
<ZirconiumX>
So if your BIOS is incompatible with the USB Report system, your mouse will crash.
<ZirconiumX>
Repeatedly.
<ZirconiumX>
It's bad enough that Linux has USB quirks specific to Corsair devices
<ZirconiumX>
But the Linux usb-hid driver simply won't talk to a Glaive or Scimitar Pro.
<ZirconiumX>
Corsair don't give a shit about it.
<ZirconiumX>
They had to roll out an entirely new major firmware version simply because Apple won't tolerate their bugs on Mac OS X.
<ZirconiumX>
TL;DR if you're using a Corsair keyboard on Linux
<ZirconiumX>
A) what the hell is wrong with you
<ZirconiumX>
B) use ckb-next
<ZirconiumX>
C) cry in a corner
<ZirconiumX>
If you're not already
<Hoernchen>
how do you even get that far? it's a fucking keyboard, if it acts up, it gets sent back to amazon immediately
<ZirconiumX>
Wireshark, patience and a lot of coffee
<ZirconiumX>
Also if you spend £60 on a keyboard there's an incentive to get it to work.
<ZirconiumX>
Did you know recent keyboards come with a VFS?
<ZirconiumX>
An actual fucking virtual filesystem.
pie_ has joined ##openfpga
<Hoernchen>
uh...
<mwk>
.what vfs
<mwk>
as in, keyboard runs linux?
<ZirconiumX>
Their own custom one, of course
<ZirconiumX>
I don't think so; maybe an RTOS
<ZirconiumX>
It's a cortex-m so I don't think it could run Linux itself
* emeb
is a dinosaur and still uses PS/2 kbd + mouse.
<emeb>
because my KVM
<ZirconiumX>
I can understand that, honestly
pie_ has quit [Quit: pie_]
pie_ has joined ##openfpga
<azonenberg>
holy moley that is cursed
<azonenberg>
and yes i have no tolerance for malfunctioning keyboards/mice: they're input devices and should not do anything else
Jybz has joined ##openfpga
pie_ has quit [Ping timeout: 250 seconds]
pie_ has joined ##openfpga
pie_ has quit [Ping timeout: 272 seconds]
pie_ has joined ##openfpga
finsternis has joined ##openfpga
pie_ has quit [Ping timeout: 272 seconds]
pie_ has joined ##openfpga
<ZirconiumX>
azonenberg: all I wanted was adjustable backlighting for my keyboard ;~;
pie_ has quit [Ping timeout: 258 seconds]
mumptai has joined ##openfpga
<Hoernchen>
i should probably add the story of my razer huntsman elite, because ah, the volume wheel and optical switches: 6 windows services, 300mb application, "optional" mining of razercoins during idle time, just for a few colored leds -> back to amazon.
<azonenberg>
wait what
<Hoernchen>
yeah...
* mwk
curses Xilinx and their endianness once again
<mwk>
so the bitstream data is bit-swapped in 32-bit units before being stuffed into the AES decryptor
<mwk>
GOOD TO KNOW
<Hoernchen>
but that is not endiannness
<mwk>
yeah, that's just not giving a fuck about which bit goes where
<azonenberg>
so now its uniform 32 bit swapping 0:31 31:0?
<azonenberg>
rather than bytewise?
<mwk>
yes
<mwk>
and it's on Spartan 6, where bitstream isn't even 32-bit oriented in the first place
<mwk>
so... to make a proper encrypted bitstream, you have to bitswap32 the incoming data, the outgoing data, and the IV, but not the key
<mwk>
eh.
pie_ has joined ##openfpga
mumptai has quit [Quit: Verlassend]
dh73 has joined ##openfpga
<azonenberg>
...
<davidc__>
I'm pretty sure they just put all their IP blocks in a bucket and shake it up and see what sticks
<azonenberg>
davidc__: to be fair it doesnt look like other fpga vendors are any better
<davidc__>
yeah, some use a blender
<azonenberg>
Yeah but they all fill up from the same cesspit
<azonenberg>
So it doesnt really make a difference in the end
<davidc__>
Also, anyone familiar with the Xilinx hard PCIE block? (in terms of RE / low-level-details?)
<azonenberg>
no, i have several boards with pcie on them but have never used it
<azonenberg>
i've been all ethernet for years
emeb_mac has joined ##openfpga
<kc8apf>
mwk: I've looked at DebugBitstream from Vivado for 7 series
<davidc__>
azonenberg: if I'm understanding the xilinx stuff correctly; its a weird hard IP block that gets hooked up to the transceiver output that does lower-level protocol statemachines + some of the TLP layer
<davidc__>
azonenberg: anyhow, its weird, so I figured I'd ask if anyone else has messed with it
<tnt>
davidc__: I've used it only thorugh their wizard which hides all of that basically AFAIR.
<mwk>
kc8apf: "looked at"?
<mwk>
does it also send strange 00000000 words uncontained in any packet where dummy frames should be?
<mwk>
davidc__: specify which one, there are at least 6 different ones
<davidc__>
mwk: heh; I'm mostly interested in the Artix-7 at the moment. I don't know how much commonality there is to other versions
<kc8apf>
Yes
<davidc__>
Basically, it seems to do a lot of "magic" (ex: config space emulation, BAR filtering and decoding, and so on). I was wondering if there is some poorly documented way to just do raw TLP passthroughs
<mwk>
kc8apf: and these 00000000 words have to be counted as FDRI payload to get matching CRC, yes?
<kc8apf>
When the stream switches to a different frame row, there's a big pile of raw zeros
<mwk>
.. which in a non-debug bitstream is contained in FDRI packet
<mwk>
seems to me they messed up, and it should be inside FDRI as well, no?
<mwk>
anyway, the question here is, is there some hw magic that slurps them into FDRI anyway, or is the emitted framing just broken
<mwk>
hrm
<mwk>
I guess I should just pull out my virtex5 board and check if the thing configures