lutsabound has quit [Quit: Connection closed for inactivity]
sgstair has joined ##openfpga
lutsabound has joined ##openfpga
<tpw_rules>
alright i can do 32x16 pixels at 11 bits per channel without obvious flicker
<tpw_rules>
i am maybe overshooting icetime by 8MHz but eh it works :D
freeemint has joined ##openfpga
freemint has quit [Read error: Connection reset by peer]
Bike has quit [Quit: Lost terminal]
<zignig>
and the crowd goes wild
* zignig
AAAAAAAAAAAAAAAAHHHHHH!
<zignig>
tpw_rules: what time zone are you in ? (utc+8) for me , we seem to be 180deg out of phase.
<tpw_rules>
utc-5 ;P
<tpw_rules>
so yes
<tpw_rules>
but we just switched daylight savings. it's 8:51 PM here
<zignig>
ah 10:52am. I'm at work so I shouldn't really be playing ....
<tpw_rules>
alright i think i'm done tonight. screen is still very slightly glitchy but the gamma correction works beautifully
<tpw_rules>
well i guess not still. icetime is telling me it's good for 36MHz and i'm running it at 40. also it turns out it was secretly 10 bits per channel because i was not displaying the 11th bit
<tpw_rules>
40 is also probably pretty close/past what the panel should really be handling
<tpw_rules>
also zignig i don't know if you saw/were aware, your PLL code clued me in the right direction but was broken as written
<tpw_rules>
the pll i made in my repo also can output the original clock signal which you were using a logic based divider to do
<tpw_rules>
but thanks for that code, it did help me
<tpw_rules>
oh wait, it might be memory contention... that's probably not fixable. i guess if i write to the same address i'm reading from, the read output is garbage?
lutsabound has quit [Quit: Connection closed for inactivity]
X-Scale` has joined ##openfpga
X-Scale has quit [Ping timeout: 240 seconds]
X-Scale` is now known as X-Scale
OmniMancer has joined ##openfpga
freeemint has quit [Ping timeout: 264 seconds]
OmniMancer has quit [Quit: Leaving.]
Jybz has joined ##openfpga
emeb_mac has quit [Quit: Leaving.]
X-Scale` has joined ##openfpga
X-Scale has quit [Ping timeout: 268 seconds]
X-Scale` is now known as X-Scale
Jybz has quit [Ping timeout: 240 seconds]
OmniMancer has joined ##openfpga
soylentyellow has quit [Quit: Leaving]
freeemint has joined ##openfpga
freeemint has quit [Ping timeout: 264 seconds]
freeemint has joined ##openfpga
freeemint has quit [Ping timeout: 250 seconds]
freeemint has joined ##openfpga
OmniMancer has quit [Quit: Leaving.]
oeuf has quit [Ping timeout: 240 seconds]
azonenberg_work has quit [Ping timeout: 250 seconds]
Asu has joined ##openfpga
azonenberg_work has joined ##openfpga
egg has joined ##openfpga
azonenberg_work has quit [Ping timeout: 252 seconds]
Bob_Dole has joined ##openfpga
emeb has joined ##openfpga
azonenberg_work has joined ##openfpga
freeemint has quit [Remote host closed the connection]
<goran-mahovlic>
Dublin workshop went really well!
pie_ has quit [Quit: pie_]
<blueCmd>
I want to make a Thunderbolt FPGA board but Intel seems to be the only ones making controllers, and I can't find a way to 1) buy the chips in less qty than 1000 and 2) the datasheets seems to be locked down :(
<GenTooMan>
goran-mahovlic good to hear.
<tnt>
blueCmd: yeah, welcome to thunderbolt world ...
<blueCmd>
tnt: :(
<GenTooMan>
bluecmd the data sheets are available likely. I was able to find them, just not within Intel search engine. Use google and find a outside line of getting them. I had do that for newer versions of cyclone parts.
<GenTooMan>
honestly it's insane to run a company that way, however a lot of other companies have been doing so as well. Micron is notorious for that.
<blueCmd>
ah right
<blueCmd>
I might try that. worst case I'll purchase some PCIe-thunderbolt adapters on ebay and reflow the chip :P
qu1j0t3 has left ##openfpga ["WeeChat 0.4.3"]
<daveshah>
Out of curiosity, why not just implement PCIe and use an off the shelf adapter?
<daveshah>
PCIe is fairly well documented in comparison
<daveshah>
and doesn't need any extra chips given an FPGA with transceivers
freeemint has quit [Ping timeout: 245 seconds]
rombik_su has joined ##openfpga
emeb_mac has joined ##openfpga
fsasm_ has joined ##openfpga
fsasm_ is now known as fsasm
freeemint has joined ##openfpga
fsasm has quit [Ping timeout: 265 seconds]
<whitequark>
there are no public datasheets for anything useful related to thunderbolt
<whitequark>
the best you get is patents
zkms has quit [Quit: zkms]
<blueCmd>
daveshah: I think it would be a pretty cool thing to have a compact, decently sized, box with something like an ECP5 in it with Thunderbolt
<blueCmd>
that would allow people to do FPGA development on the road etc, 15W should be plenty
<blueCmd>
But using an off the shelf adapter the footprint of that box would be quite substansial I'm thinking
<tpw_rules>
boneless idea: allow W to be a multiple of 4. then parameter passing would be easier and you could easily just add more registers for an inner loop or osmething
<blueCmd>
t
<tpw_rules>
he means like chip
<blueCmd>
The fact that you have to go to PCIe formfactor and back instead of just a couple of lanes, and the power stuff would be quite annoying
<blueCmd>
Not a bad idea, I thought about mini-PCIe / NVMe just now when looking for examples - that might work
<blueCmd>
I'll do that, why not
<blueCmd>
Thanks TD-Linux!
Asu` has joined ##openfpga
Asu has quit [Ping timeout: 268 seconds]
freeemint has quit [Ping timeout: 250 seconds]
freeemint has joined ##openfpga
freeemint has quit [Ping timeout: 245 seconds]
implr has quit [Ping timeout: 264 seconds]
<kc8apf>
I've started poking at the chip used in nearly every USB 3.1 -> NVMe SSD enclosure. It's an 8051.
<adamgreig>
of course
<blueCmd>
You can either do this USB style, 10 Gbit/s - it seems people are just emulating PCIe root port for mass storage in the chip in that case -- or Thunderbolt 3, 40 Gbit/s, which is "proper" PCIe
<blueCmd>
The former I have no doubt in my mind there are weird implementations of :-)
implr has joined ##openfpga
<blueCmd>
The latter seems to be only intel controllers, which I guess I expected something else than 8051 :P
<kc8apf>
JMedia JMS583 is just so cheap and prevalent. I hope they are hackable.
<whitequark>
tpw_rules: that adds an adder in the critical path
<whitequark>
so it probably slashes Fmax at least in half
<whitequark>
blueCmd: afaik TBT controllers use a 8051+ARC
Bike has joined ##openfpga
<whitequark>
looking at what cpu_rec sees in the firmware
<tpw_rules>
whitequark: very valid point
<tpw_rules>
speaking of critical paths, how do i decode the critical path report from nextpnr? none of the signal names make any sense and i'm not sure where to make an improvement
<tpw_rules>
also i figured out how to add extra clock constraints, but doing so makes my fmax go dow
<tpw_rules>
n
<whitequark>
tpw_rules: you can't. abc fucking sucks.
<whitequark>
i was working on flowmap that would not have this problem by design, but i've had other things take priority
<tpw_rules>
well alright then
<whitequark>
as for clock constraints, if you add a constraint, the pnr tool will only try as hard as it needs to satisfy it
<tpw_rules>
i understand that, but my fmax is like 20% under what it needs to be. with the constraint it's like 30%
<tpw_rules>
also does non transparent block ram imply that reading the same address as writing produces garbage?
<tpw_rules>
cause that's what seems to be happening. i expected it to return the old value but mayb enot
<whitequark>
no
<whitequark>
hm
<whitequark>
are the read and write ports in the same domain?
<tpw_rules>
no
<whitequark>
you know how you need a 2FF synchronizer sampling data from one domain in another?
<tpw_rules>
yeah
<whitequark>
using a BRAM instead of a single FF doesn't remove metastability
<whitequark>
or a requirement to synchronize multiple bit values
<TD-Linux>
8051 *and* ARC? I mean I'm not surprised, just disappointed as usual
<tpw_rules>
oh, blech
<whitequark>
TD-Linux: par for course for intel
<tpw_rules>
quartus says the block rams output the old value in that case on my altera fpgas
<whitequark>
tpw_rules: you literally cannot implement the behavior you want with asynchronous clocks
<TD-Linux>
waiting for the automotive grade part with an embedded 68hc11
<tpw_rules>
what was quartus doing then?
<whitequark>
there's no possible BRAM circuitry that will do it
<whitequark>
the behavior on read/write collision on asynchronous ports is always undefined
<whitequark>
it can be still undefined (if the vendor is lazy / keeps options open), read first, or write first for synchronous read/write port pair
<GenTooMan>
TD-Linux many automotive designs post 1997 used the HC12 core instead of the HC11
<whitequark>
consider how a BRAM would be implemented in fabric. you have a huge 2D array of FFs that are all in the write domain
<whitequark>
then you have a multiplexer and a set of FFs sampling its output in the read domain
<whitequark>
there's nothing magical about packing this into a hard macro
<tpw_rules>
ok, yeah the documentation for quartus had a really tiny asterisk that it only applies under synchronous conditions
<tpw_rules>
so uh does the collision only happen if the addresses are the same?
<whitequark>
yes
<tpw_rules>
ok. maybe i need to implement double buffering then
<adamgreig>
would adding 2FF to the read port output help anything?
<whitequark>
adamgreig: it would remove metastability
<whitequark>
but it would still return garbage
<whitequark>
because you're not sampling all of the data bits at the same time
<adamgreig>
i guess i assumed the hard bram's read output would already be synchronised to the read port clock
<TD-Linux>
GenTooMan, on a previous project we used a particularly cursed 68hc12 derivative
<tpw_rules>
that reminds me of my other boneless request, a way to stall the external bus
<whitequark>
adamgreig: it is
<adamgreig>
yea, understood that it will always be undefined, just didn't expect potential metastability
<adamgreig>
if the read port output is already synchronised to read clock domain, why would adding 2ff change anything?
<TD-Linux>
the MC9S12XDP512
<whitequark>
adamgreig: it's in the read domain, but it's just one FF
<whitequark>
you need to add a second FF layer
<whitequark>
in fact, if you investigate the Xilinx hard macro, they disallow the settings for async FIFO that would result in only having one FF layer
<TD-Linux>
they decided the 68hc12 core was too garbage so they added a second "xgate" core
<whitequark>
only if there can be an address collision
<adamgreig>
if address collision isn't otherwise averted*?
<adamgreig>
cool
<whitequark>
in an async FIFO there can't be an address collision if you use the read enable signal to avoid reading from an empty FIFO
<adamgreig>
so eg a fifo using 2ffs to forward the level would be ok because you won't read the output until the write side has already said it's safe
<whitequark>
which Migen/nMigen AsyncFIFO should do, but currently does not
<TD-Linux>
the way this was exposed in the IDE was particularly "interesting". you were supposed to have an .xc file corresponding to your .c files that ran the corresponding code on the xgate
<whitequark>
adamgreig: uhh, where do you have a level in an async FIFO
pie_ has joined ##openfpga
<tpw_rules>
ok so i guess i just need a fifo to do the clock crossing
<whitequark>
tpw_rules: yes, use lib.cdc.fifo.AsyncFIFOBuffered
<tpw_rules>
of course the overarching problem is when i have a perfect beautiful and stable led display, what do i show on it :P
Asu` has quit [Ping timeout: 240 seconds]
<whitequark>
tpw_rules: re boneless improvements: let me merge some PRs elsewhere and we can improve boneless a bit
Asu` has joined ##openfpga
<whitequark>
do you collect your requests re assembler somewhere?
<tpw_rules>
whitequark: ok. no i will and can give it to you later tonight
<whitequark>
great
rombik_su has quit [Read error: Connection reset by peer]
<whitequark>
feel free to open an issue
<adamgreig>
whitequark: sorry, I just mean "not empty" I guess
<tpw_rules>
yes that would probably be easier
<whitequark>
adamgreig: have you read cummings' FIFO paper?
<whitequark>
it explains this better than I ever could
<adamgreig>
thanks, have been meaning to read it but haven't yet
<tpw_rules>
(i do plan on stealing its wishbone components at some point)
<whitequark>
tpw_rules: take a look at nmigen-soc
<tpw_rules>
oh i didn't realize there was wishbone in there too. excellent, thanks
<GenTooMan>
TD-linux really... I nary touched the xgate series. I was migrating toward arm at that point. I regret ever touching anything saying C51 on it.
<whitequark>
that's where the actual upstream work is happening. heavyx gateware is just some ad-hoc hacks
<tpw_rules>
although it looks a bit sparse...
<whitequark>
tpw_rules: yes
<TD-Linux>
GenTooMan, we did too, but with a coldfire v1 in between :(
<tpw_rules>
that's what i'm in the mood for at the moment ;P
<TD-Linux>
with hc08 peripherals
<tpw_rules>
TD-Linux: are you doing cursed automotive stuff?
<whitequark>
tpw_rules: turns out making sure SoC infra has a good design is not a fast process
<tpw_rules>
absolutely
<TD-Linux>
and a usb controller so tacked on that for it to work you had to run the core at 48mhz. and if you ever executed the wfi instruction, the usb core crashed
<zignig>
derp.. remember that you have to init bram if you want have data in it.
<tpw_rules>
psh
<zignig>
did manage to covert my boneless across to a CSR multiplex though.
<TD-Linux>
tpw_rules, I don't do automotive stuff anymore but never cured my thirst for power electronics
<ZirconiumX>
wq: you reminded me of flowmap, so I decided to play about with it. Got a new assert that I am currently bugpointing
emeb has quit [Quit: Leaving.]
<zignig>
TD-Linux: mmm power.
<zignig>
tpw_rules: it might be possible to split the boneless memory space into [bram,spram] so you can have a bootloader in the bram that loads the rest of memory out of flash
<tpw_rules>
zignig: yeah that was my plan
<tpw_rules>
and/or have a bankswitch
<zignig>
on a upk5 you could then use the entire 64 Kwords
<tpw_rules>
well i don't know if bankswitch or decoding would be faster
<tpw_rules>
i gotta keep fmax over 12MHz and it's at like 17 right now
<whitequark>
tpw_rules: i'll add a way to preload the SPRAM with simple external logic
<whitequark>
it's really easy
<tpw_rules>
?
<whitequark>
you know how JTAG debugging usually works for CPUs?
<tpw_rules>
yeah
<whitequark>
so imagine like 30% of that with one command, "write to incrementing address"
<zignig>
whitequark: use the PC to increment acros ram and push it in from an external source ?
<tpw_rules>
i mean i was going to add an SPI flash engine and like 1 blockram of bootloader
<whitequark>
zignig: absolutely correct
<tpw_rules>
i'm not sure how to get stuff into the icebreaker. i could add a uart i guess?
<zignig>
tpw_rules: morse key ?
<tpw_rules>
but i figured load from flash. it would be nice to be able to reprogram the code brams without reprogramming the flash. i get worried i'm going to wear it out...
<zignig>
tpw_rules: flash lasts a while, just load externally via a uart during testing and then push it to flash.
<tpw_rules>
idk what power the icebreaker's usb port and ft232 or whatever have.
<tpw_rules>
according to the schematic it has a uart?
<tpw_rules>
so i guess i would just have a uart bootloader instead of spi flash?
<zignig>
I think there is a ftdi that has tx/rw it's in the platform.
<tpw_rules>
yeah i just found that bit
<tpw_rules>
ftdi has uart to the fpga and spi to the flash
<tpw_rules>
so i can write an spi engine and have the bootloader program that too
<zignig>
we will have to be carefull not to overwrite the FPGA images... Does the icebreaker have "user" flash ?
<zignig>
I mean a sector of flash that is not images.
<tpw_rules>
according to what it tells me when i program the thing, the first 128kB is the fpga bitstream
<tpw_rules>
whitequark: so what exactly is your bootloading plan?