ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
ZipCPU has quit [Ping timeout: 264 seconds]
ZipCPU has joined ##openfpga
gsi__ has joined ##openfpga
gsi_ has quit [Ping timeout: 255 seconds]
futarisIRCcloud has joined ##openfpga
<sorear>
apparently #j-core has a build partially working for the upduino 2 (not using yosys obv)
unixb0y has quit [Ping timeout: 255 seconds]
unixb0y has joined ##openfpga
AndresNavarro has quit [Ping timeout: 246 seconds]
rohitksingh has joined ##openfpga
SpaceCoaster has quit [Ping timeout: 244 seconds]
SpaceCoaster has joined ##openfpga
photon70 has joined ##openfpga
photon70 has quit [Client Quit]
rohitksingh has quit [Remote host closed the connection]
lutsabound has quit [Quit: Connection closed for inactivity]
rohitksingh_work has joined ##openfpga
photon70 has joined ##openfpga
photon70 has quit [Client Quit]
<_whitenotifier>
[Boneless-CPU] whitequark commented on pull request #3: Text Assembler for boneless (WIP) - https://git.io/fhxOj
Bike has quit [Quit: Lost terminal]
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
Flea86 has joined ##openfpga
<TD-Linux>
how to I change targets/ulx3s.py in litex to target an 85F?
<TD-Linux>
I adjusted platforms/ulx3s.py to default to an 85F but I guess that wasn't enough
<TD-Linux>
ohhh I guess I need to reinstall litex for it to pick up that change
<_florent_>
TD-Linux: hi, if you use develop instead of install when running setup.py you shouldn't need to reinstall when doing changes
<_florent_>
TD-Linux: we could add a parameter to select the device
<TD-Linux>
oh okay cool. is there a way to do that for the other lite* packages as well?
ayjay_t has quit [Read error: Connection reset by peer]
<_florent_>
yes you can do the same
ayjay_t has joined ##openfpga
<TD-Linux>
nice I got into the lmbios!
<TD-Linux>
but yeah looks like one of the memory lines is bad :( time to reflow this bga
emeb_mac has quit [Ping timeout: 245 seconds]
<_whitenotifier>
[whitequark/Glasgow] whitequark pushed 3 commits to master [+0/-0/±6] https://git.io/fhxs9
<_whitenotifier>
[whitequark/Glasgow] whitequark aae0c31 - applet: fix a few typos. NFC.
<_whitenotifier>
[whitequark/Glasgow] whitequark 7bf0c55 - {target,gateware}.analyzer: use explicit flush.
<_whitenotifier>
[whitequark/Glasgow] whitequark 03f186a - applet..spi_master: release SS for at least one half period.
<keesj>
TD-Linux: or... python3 setup.py develop --user. This will install a .egg file in you ~/.local/something that points to the directory you did the checkout (e.g. wonderfull)
<q3k>
TD-Linux: did you try hitting it with an airgun yet?
<q3k>
(don't even reball it, just do the dumbest reflow)
<TD-Linux>
q3k, yeah. accidentally created a short while doing so, so I had to pull it off and replace it with a 2nd one. that one I installed with hot air + tons of flux
<TD-Linux>
behavior is identical
<q3k>
huh
<Flea86>
TD-Linux: You mention one of the memory lines was bad.. how do you know it's not the DRAM?
<Flea86>
soldering-wise I mean
<q3k>
TD-Linux: for bga, there is such a thing as too much flux :P
<TD-Linux>
I didn't. so I resoldered that and same behavior
<q3k>
also the sdram on the ulx3s is leaded
<q3k>
so you can easily inspect it
<TD-Linux>
yeah. but doubt I would solder 2 in a row where everything works, including hdmi, but ram doesn't
<q3k>
maybe the board are bad :V
<q3k>
where did you fab them?
<q3k>
*boards
<TD-Linux>
oshpark
<q3k>
someone mentioned that the ulx3s design is out of spec for oshpark
<Flea86>
q3k: Oh I know that, but TSSOP can still (and does) give problems
<TD-Linux>
that was me
<q3k>
if you have another board, measure for shorts there?
<TD-Linux>
yeah. or opens, the drill sizes/annular ring is where it is out of spec
<q3k>
like, pull up the pcb artwork and see where potential shorts could be
<q3k>
or that
<Flea86>
TD-Linux: Did you check said suspect mem line for open cct while the FPGA was removed?
<TD-Linux>
no cause I'm not that smart. also I don't know what line it is. all the mem tests fail
<TD-Linux>
lemme do some dumb tests and come back
<Flea86>
TD-Linux: No worries.
<TD-Linux>
oh
<TD-Linux>
was I supposed to populate all the RA/RB resistors? because I did
<zem>
yes, those are for power delivery
<_florent_>
TD-Linux: can you post your results? That's possible there are variations between boards that are not yet handled correctly
<_florent_>
TD-Linux: so it could be related to the design, not necessarily your board
<Flea86>
TD-Linux: Put your DRAM /CS = '1' and then go and exercise each and every single third line while all the DRAM pins are tristated. You will need a scope or DMM
<Flea86>
change pattern, then repeat.
<_florent_>
TD-Linux: ah sorry, i thought you were testing the ECP5 Versa, ULX3S should work correctly
<_florent_>
TD-Linux: this can help you finding the data lines that are not working
<TD-Linux>
_florent_, what will that do? will it constantly read write
<_florent_>
it will shorten the memory test and print the returned data vs expected data
<TD-Linux>
ah cool
<TD-Linux>
weird. ras/cas/we/cs/address lines are okay. but all 16 data lines are always 0. the test and scope both show this
<_florent_>
TD-Linux: memtest with debug is returning 0? is the clock ok?
<TD-Linux>
yes. the clock is 50mhz and seems ok. I don't see it write any data on those lines either
<TD-Linux>
going to pop the ram off and see if this changes
bemeurer has joined ##openfpga
<TD-Linux>
making q3k's blinky blink the dq lines with the sdram removed also yields nothing. so bad PCB, I'm thinking. or bad power to that IO bank, but CS is on the same bank so doubt. suspiciously, the data lines have to go through way more vias than the other lines
<TD-Linux>
aha there we go. using the right bit order, blinky now drives those lines. but litex doesn't. maybe a trellis bug?
<TD-Linux>
going to jump back to f32c demos and see if I can make them work
<q3k>
you're using an 85f, right?
<q3k>
if you give me your bitstream i can test it on my ulx3s
<q3k>
or just point me to the f32c demo you're using and that doesn't work
<TD-Linux>
it's in the ulx3s-bin one (the f32c demo doesn't really have any way to report failure so it's bad)
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<TD-Linux>
alright I don't know if it was the rework or what but now I see data on some of the lines. D15 is notably absent. I'm about to fall asleep so I'll work on this more tomorrow. interesting to know if that bitstream works for you though, q3k.
photon70 has joined ##openfpga
<q3k>
yeah i'll check once i'm done with $minimum_viable_dayjob_work
<TD-Linux>
no hurry :)
photon70 has quit [Client Quit]
<daveshah>
Looking into the ULX3S issue
<daveshah>
Indeed bitstreams with LiteX & Trellis are broken
<daveshah>
sdram_dq is declared as an input in the LiteX verilog though
<daveshah>
so bug appears to be in LiteX
<_florent_>
daveshah: ok thanks, i'll look at that
<daveshah>
Just fixed it I think :D
<_whitenotifier>
[whitequark/Glasgow] whitequark pushed 2 commits to master [+1/-0/±3] https://git.io/fhxc8
<cyrozap>
"Today, Intel announced that it contributed the Intel Thunderbolt protocol specification to the USB Promoter Group, enabling other chip makers to build Thunderbolt compatible silicon, royalty-free. In addition, the USB Promoter Group announced the pending release of the USB4 specification, based on the Thunderbolt protocol. The convergence of the underlying Thunderbolt and USB protocols will increase
<cyrozap>
compatibility among USB Type-C connector-based products, simplifying how people connect their devices."
<whitequark>
oh fuck this
<cyrozap>
?
<whitequark>
i mean, i hate it
<cyrozap>
I got that--but I'm confused as to what you hate. That USB 4 is going to be based on and compatible with Thunderbolt 3? That other manufacturers will be able to develop Thunderbolt 3/USB 4-compatible controllers? I thought the problems with Thunderbolt was that Intel had a monopoly on the controllers, and so the host controllers required an Intel CPU to function, an NDA was required to get docs for the
<cyrozap>
device controllers, and everything was slightly incompatible so the controllers needed constant firmware updates to work with newer devices?
<cyrozap>
Personally I'm cautiously optimistic about this.
<cyrozap>
...mostly because my Talos has tons of PCIe bandwidth but only 5 slots and PCIe switches are $$$-$$$$.
<whitequark>
cyrozap: no
<whitequark>
the problem with thunderbolt is that it is a festering pile of shit
<whitequark>
likewise with usb
<whitequark>
open thunderbolt means exactly 1 thing, we are about to have thunderbolt devices that work even worse
<whitequark>
because the only reason this pile of shit was remotely functional is intel mandating all tbt3 devices following one of their exact designs down to bom
<whitequark>
i am not optimistic about any development whatsoever from the group of people who think usb is a good idea
<whitequark>
the only good thing to do with usb is to throw it away and start over
<cyrozap>
But USB is widely available, with the fastest consumer-grade PHY on the market, inexpensive hubs/switches, and is backed by an organization that ensures certified devices will work together. I'm not sure how it could get much better than that?
<cyrozap>
Aside from the naming issues, of course, which are just dumb.
<whitequark>
you are very naive and that will change when you see how this stuff actually works
<whitequark>
or it mostly doesn't
<whitequark>
when anything with tbt3 actually does work it is a series of happy accidents
<whitequark>
or look at usb isochronous stuff, it is useless for anything except webcams
<whitequark>
completely braindead protocol
<TD-Linux>
cyrozap, I encourage you to read the usb audio spec
<whitequark>
yep
<whitequark>
the usb audio spec gave up on interoperability
<whitequark>
so many devices on market could not get descriptors right, so now the spec says "use this heuristic and ignore what the device says, it's probably wrong"
<TD-Linux>
would you say that usb audio or web audio is worse
<whitequark>
there are usb 3 audio cards that only work with specific XHCIs
<whitequark>
"an organization that ensures certified devices will work together" my ass
<balrog>
but will USB4 be compatible with thunderbolt 3?
<whitequark>
in your dreams maybe
<balrog>
or will they fix all the bugs, at the expense of backwards compatibility?
<whitequark>
you can't fix tbt3
<whitequark>
most of the bugs are by design
<TD-Linux>
ftdi should really lobby to make usb worse
<cyrozap>
I was talking about USB FS/HS/SS, not TB 3. I know TB 3 as it exists today isn't good, but now that more manufacturers will be able to make silicon for it, the compatibility will have to improve or it'll be a commercial flop.
<TD-Linux>
none of those are good either. really try implementing them :)
* cr1901_modern
likes FS, not that I'm known to have good taste
<TD-Linux>
I tried using USB on a car once (webcam for rear view)
<TD-Linux>
now that was a mistake
<cyrozap>
All the USB FS/HS/SS devices I own enumerate successfully on Linux and, so long as you're not using an ASMedia host controller (or really ASMedia anything), there're no problems. Sure, descriptors are often messed up, but that's more the fault of the manufacturers only caring about Windows compatibility.
<cyrozap>
Even my custom STM32-based usb devices using the libopencm3 USB stack work perfectly fine.
<TD-Linux>
I would argue that the biggest problems are the descriptors and the device classes, so sure if you disregard those then it's less bad :)
xobs has quit [Ping timeout: 264 seconds]
xobs has joined ##openfpga
<cyrozap>
Oh, lol, yeah, I always just ignore them when writing drivers since they're usually wrong unless the vendor driver uses them. I blame Windows's poor support for generic device class drivers--if that support was actually good, maybe we wouldn't be having as many issues as we are today. Though I suppose the standards are partly to blame for that--the design of how the descriptors work is weirdly complex,
<cyrozap>
and there really isn't any good tooling for generating/decoding/validating them.
<cyrozap>
The only major incompatibility problem I've had with USB is with my LimeSDR, since it doesn't seem to work with TI USB controllers (some packets get lost/are never sent), but I'm pretty sure that's more likely a problem with the LimeSDR's firmware+driver and not the controller hardware or the spec.
<TD-Linux>
again read the usb audio spec and then try writing a driver for that :)
<cyrozap>
But why would I do that? Linux already supports those devices.
<TD-Linux>
only a tiny subset
<cyrozap>
Of the standard? Or of devices?
<TD-Linux>
of the standard
<cyrozap>
Because if it hits 99.999% of devices but only uses a subset of the standard, that seems ok to me. After all, you can never trust standards 100%--you always have to look at real-world implementations to see how people interpreted the standard and what parts they do/don't use.
<TD-Linux>
no
<TD-Linux>
the part of usb audio spec that works is like 5%
<TD-Linux>
and you can in fact trust standards a lot. good ones
<ylamarre>
Now imagine if that was the case for ethernet.. like everyone implementing their own subset of it, changing fields positions...
<sxpert>
ylamarre: hi there
<ylamarre>
Hi
<sxpert>
I rewrote it all...
<sxpert>
applying the advice you all gave
<sxpert>
I am happy to report success on hardware !
<tnt>
sxpert: oh, nice.
<tnt>
what's the state ?
<sxpert>
getting a whole bunch of instructions to execute
<sxpert>
including jumps and stuff
<sxpert>
tnt: it compile successfully, and can be uploaded, and speaks through the serial port
<sxpert>
can't talk to it yet
<sxpert>
that can come later
<tnt>
sxpert: nice ! That was pretty quick.
<sxpert>
took me a day to get to actually work
<sxpert>
the last issues were "=" that should have been "<="
<sxpert>
lesson learned I guess
<tnt>
:)
<sxpert>
I managed to fit 1/2 the rom in the brams, and I can fit the whole ram too
<sxpert>
should be fine for a while
<tnt>
you're on an ecp5 right ?
<sxpert>
yeah
<sxpert>
(I know, this is the barbaric way to do things ;-)
tlwoerner has quit [Quit: Leaving]
<cyrozap>
TD-Linux: You mean "simple standards", not "good standards"--and even then you still have to test with real-world implementations or else you can't know for sure if it'll work properly or not. See, for example, DRAM compatibility lists--DDR is a well-known, relatively simple standard, and yet manufacturers still have to produce compatibility lists so people know what RAM is guaranteed to work with
<cyrozap>
their system (whether that's a PC motherboard, FPGA, SoC, etc.).
<TD-Linux>
the correct thing to do is use real world implementations while developing the standard
<TD-Linux>
TLS 1.3 is a complex standard but you can implement it 100% from the spec and it has excellent interop
<cyrozap>
ylamarre: All the USB device class stuff is application-layer, so not directly comparable to Ethernet. It's more like if everyone used their own proprietary protocols on top of TCP/UDP... which they do :P
<azonenberg>
TD-Linux: i do wish the RFCs would stop being 80 column text at some point thoguh
<azonenberg>
they're hard to read
<TD-Linux>
azonenberg, yeah they are fixing that! they are getting svg graphics even
<azonenberg>
o_O
<azonenberg>
because i often turn to wikipedia just because it's mroe readable than the actual spec lol
<TD-Linux>
they are also becoming reflowable and the pagination is being dropped
<cyrozap>
TD-Linux: I guess my point is we can have all the ideological purity in the world and still never produce a standard that people will actually use. The standard that exists and is in widespread use today is infinitely superior to the one that is ideologically pure but either doesn't exist or is not in use.
<sxpert>
tnt: I had to rewrite the whole thing about 4 times though ;-)
<cyrozap>
TD-Linux: And that's especially the case for hardware, where replacing the old thing with something new can get really expensive really fast.
<tnt>
sxpert: heh, I think I redisigned my cpu like 10 times at different stages before I was happy with it.
<gruetzkopf>
<sorear> let’s just use ePCIe
<gruetzkopf>
this, or let's implement channel io on the pcie link layer
<Ultrasauce>
token ring over pcie
Flea86 has joined ##openfpga
<shapr>
Ultrasauce: you WHAT?
* shapr
reads scrollback
<shapr>
Ultrasauce: btw, very cool hostname
<Ultrasauce>
best 180 rubles i ever spent
<shapr>
does fddi count as token ring?
Thorn has quit [Ping timeout: 245 seconds]
<TD-Linux>
daveshah, thanks for the fix!
<TD-Linux>
with the latest master I'm now getting this error though:
<TD-Linux>
ERROR: Conflicting init values for signal \main_sdram_trrdcon_ready (\main_sdram_trrdcon_ready = 1'1, \main_sdram_choose_req_want_activates = 1'0).
<daveshah>
Ideally migen wouldn't generate such stuff
<daveshah>
But in practice all kinds of initial statements exist in all kind of code
<daveshah>
And given strict synthesis rules should ignore initial altogether, a best effort approach with meaningful warnings seems fair enough
<TD-Linux>
cool that patch works. will test on my ulx3s when I get home
<TD-Linux>
don't a lot of synthesis tools use initial to control the initial ff value? (or invert the logic)
<daveshah>
Some do, some don't
<daveshah>
ASIC synthesis never does
<daveshah>
or very rarely
<daveshah>
Most FPGA tools do
<daveshah>
The iCE40 vendor tools don't, iirc
<daveshah>
The ECP5 ones do if there isn't a conflicting sync or async set/reset
<daveshah>
Even though the former case is trivially dealt with (as we do in Yosys) by converting sync set/reset back to logic if it is different to the init value
Asu has quit [Remote host closed the connection]
<tnt>
tip of the day: microcoded state machine work a whole lot better if you actually bother to load the microcode in the RAM :p
futarisIRCcloud has joined ##openfpga
<mithro>
mwk: Your working on s6 documentation process?
<tnt>
mithro: hey, while you're here, I was wondering what the fomu bootloader status was ?
<mithro>
tnt: See the #tomu IRC channel
<mithro>
tnt: I haven't had a chance to think about it with the whole moving and everything
<cr1901_modern>
mithro: You're moving?
<mithro>
cr1901_modern: Moved really...
<cr1901_modern>
back to AUS?
<mithro>
No to the US
<cr1901_modern>
seems like yesterday you moved to the U- oh...
<cr1901_modern>
I could've sworn you did that a year ago
<cr1901_modern>
maybe timelines are crossing over
<mithro>
someone did a port of netlistsvg to Python IIRC?
<mithro>
cr1901_modern: I think you linked me to it?
<cr1901_modern>
I don't recall a library like that :(