cr1901_modern has quit [Ping timeout: 268 seconds]
emeb has quit [Quit: Leaving.]
cr1901_modern has joined ##openfpga
Miyu has quit [Ping timeout: 258 seconds]
cr1901_modern1 has joined ##openfpga
cr1901_modern has quit [Ping timeout: 244 seconds]
jevinskie has joined ##openfpga
gsi_ has joined ##openfpga
gsi__ has quit [Ping timeout: 246 seconds]
gsi_ has quit [Ping timeout: 246 seconds]
unixb0y has quit [Ping timeout: 255 seconds]
unixb0y has joined ##openfpga
cr1901_modern1 has quit [Quit: Leaving.]
cr1901_modern has joined ##openfpga
zem has quit [Ping timeout: 244 seconds]
zem has joined ##openfpga
GenTooMan has quit [Quit: Leaving]
rohitksingh_work has joined ##openfpga
pie__ has joined ##openfpga
pie_ has quit [Ping timeout: 255 seconds]
Patater has quit [Ping timeout: 268 seconds]
Patater has joined ##openfpga
Bike has quit [Quit: Lost terminal]
gsi_ has joined ##openfpga
futarisIRCcloud has joined ##openfpga
m_w has quit [Ping timeout: 246 seconds]
emeb_mac has quit [Quit: Leaving.]
Richard_Simmons has joined ##openfpga
Bob_Dole has quit [Ping timeout: 250 seconds]
cr1901_modern1 has joined ##openfpga
cr1901_modern has quit [Ping timeout: 272 seconds]
cr1901_modern1 has quit [Client Quit]
cr1901_modern has joined ##openfpga
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
s_frit has joined ##openfpga
scrts has quit [Ping timeout: 255 seconds]
scrts has joined ##openfpga
m4ssi has joined ##openfpga
pie_ has joined ##openfpga
pie__ has quit [Ping timeout: 250 seconds]
tmeissner has joined ##openfpga
m_t has joined ##openfpga
tmeissner has quit [Client Quit]
scrts has quit [Ping timeout: 246 seconds]
scrts has joined ##openfpga
Thorn has joined ##openfpga
futarisIRCcloud has joined ##openfpga
Thorn has quit [Read error: Connection reset by peer]
flaviusb has joined ##openfpga
Flux42 has quit [Quit: patch]
Flux42 has joined ##openfpga
Miyu has joined ##openfpga
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
Thorn has joined ##openfpga
rohitksingh_work has quit [Read error: Connection reset by peer]
Flea86 has quit [Quit: Goodbye and thanks for all the dirty sand ;-)]
m_t has quit [Read error: Connection reset by peer]
m_w has joined ##openfpga
Richard_Simmons has quit [Ping timeout: 250 seconds]
m_w has quit [Ping timeout: 250 seconds]
jevinskie has joined ##openfpga
tlwoerner has quit [Quit: Leaving]
rohitksingh has joined ##openfpga
Bob_Dole has joined ##openfpga
somlo has quit [Quit: Leaving]
tlwoerner has joined ##openfpga
<tnt>
mmm, as soon as you try for > 1st order, this whole delta sigma things becomes a whole lot less clear :/
<sxpert>
tnt: it's maths, it's supposed to be *complicated*
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
rohitksingh has quit [Ping timeout: 246 seconds]
rohitksingh has joined ##openfpga
somlo has joined ##openfpga
m4gul0_ has quit [Remote host closed the connection]
m4gul0_ has joined ##openfpga
<sensille>
s/complicated/beautiful
mumptai has joined ##openfpga
m4ssi has quit [Remote host closed the connection]
emeb has joined ##openfpga
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
unixb0y has quit [Ping timeout: 250 seconds]
m_w has joined ##openfpga
rohitksingh has quit [Remote host closed the connection]
RaYmAn has quit [Remote host closed the connection]
cpresser_ is now known as cpresser
RaYmAn has joined ##openfpga
<somlo>
daveshah: I was wondering if there's a reasonably easy way to find out if the ecp5 versa 5g board has PCB traces connecting balls T3, T7, and M7 of the DDR3 memory chip to the FPGA. Those would be A13-15, and, if connected, one could concievably have the "MT41K64M16TW-107:J" replaced with e.g., the otherwise pin-compatible 8Gb "MT41K512M16HA-107:A" chip.
<daveshah>
somlo: they aren't shown as connected on the schematic in the user manual
<azonenberg>
nothing a little magnet wire won't fix :P
<azonenberg>
(only half kidding)
<daveshah>
nope disconnected on gerbers too
<daveshah>
azonenberg: :D
<azonenberg>
you'd probably have to pull the FPGA too
<azonenberg>
and have fun matching the length
<daveshah>
nothing that clever use of delay blocks won't fix
<daveshah>
write leveling to the extreme
<somlo>
I'd have bought like 20 boards, and had a shop my uni is contracting with unglue both the DRAM and FPGA, and replaced them with 8Gb DRAMs and 85k 5g ECP5s -- if I got back 50% or even 20% working boards it'd have been awesome -- well, it was a nice thought before reality set in :D
<azonenberg>
somlo: at that point you might as well just design your own ecp5 board?
<daveshah>
If you have/buy an OrCAD license you could patch the Versa PCB
<somlo>
start with the ulx3s, and design a "yuge" DRAM chip... I was hoping not to have to go there -- still a bit of a mystery why Lattice is half-assing the dev boards they're selling...
<daveshah>
tbf the versa is very much designed as a "PCIe" peripheral board, for which 128MB is quite reasonable
<somlo>
daveshah: I'm pretty sure the ECE guys probably do, that's a good idea
<somlo>
(re. orcad)
<daveshah>
I'm working on a design for an ECP5 board with plenty of everything in my spare time, but no guarantee it will ever be working/done
<somlo>
apparently, at some point in the past, lattice had the "LFE5UM-85F-PB-EVN", with an 85k chip and 8GB of DDR3, but it's discontinued (reportedly they had "stability issues")
<daveshah>
also, looks like that was LPDDR3 (not to be confused with DDR3L); which litedram doesn't support
<somlo>
well, just to be pedantic, they write "8GB" in the docs, but on closer examination it's just "8Gb" (small-b, as in bits, not capital-B as in bytes). Annoying how that's a bit of misleading sloppiness that always works *against* me :)
<somlo>
daveshah: re. LPDDR3 -- the FPGA side of the KONDOR AX board also uses LPDDR, so that makes me a bit less sad that they've apparently stopped reading their email :)
<daveshah>
ah, that's annoying
SpaceCoaster has quit [Quit: ZNC 1.6.5+deb1+deb9u1 - http://znc.in]
SpaceCoaster has joined ##openfpga
deka` has joined ##openfpga
deka` has quit [Client Quit]
AndresNavarro has joined ##openfpga
<AndresNavarro>
Hi there.
<AndresNavarro>
This is mostly to Dave or Luke, but I think I managed to get the compression for bitstreams figured out now
<AndresNavarro>
I'm currently investigating the XO2 family and as all bitstreams are compressed I just started there
<daveshah>
sweet
<AndresNavarro>
It seems the compression is the same for both families (XO2/3 and ECP5) so maybe I can try to write some code and maybe do a pull request for Project trellis?
<daveshah>
that would be amazing
<AndresNavarro>
I'll write it here first so I get it out of my head, because I spent a whole day yesterday working on this and I need to get it out
<AndresNavarro>
Then I can probably do the docs first, and the implementation but it's fairly simple so it should be up tonight
<AndresNavarro>
It's a prefix code with just 4 (four) cases:
<AndresNavarro>
A single 0 bit stands for a byte made of all 0's
<AndresNavarro>
A 100xxx stands for a byte with a single bit set where the x says what bit is set
<AndresNavarro>
For example 100000 stands for 000001 (just the bit 0 set)
<AndresNavarro>
100010 stands for 00000100 (just the bit 2 set)
<AndresNavarro>
A 101xxx stands for a common byte, here xxx is an index into the array saved by the LSC_WRITE_COMP_DIC command
<AndresNavarro>
That command just sets the 8 most common bit patters (that have at least 2 bit sets)
<AndresNavarro>
A 11xxxxxxxx is just for all the remaining bit patters, they are just there in the next 8 bits
<AndresNavarro>
So it uses 1 bit for 0
<daveshah>
Very neat
<AndresNavarro>
6 bits for bytes that have only 1 bit set
<AndresNavarro>
6 bits for bytes in the 8 most common
<sorear>
so each codeword corresponds to a single byte of the uncompressed bitstream?
<AndresNavarro>
and 10 for the rest
<AndresNavarro>
exactly
<AndresNavarro>
There's also some bit padding but that's documented in the pdf about programming the ecp5
<AndresNavarro>
The code is pretty straight forwards I wrote a proof of concept in c and was able to convert a compressed bitstream for the xo2 to the uncompressed version perfectly
<sorear>
so you can actually generate uncompressed xo2 bitstreams using the vendor tools?
<daveshah>
yes
<daveshah>
you can use them with external flash
<daveshah>
or jtag/spi programming
<AndresNavarro>
yeah it's just a setting on the tool, but only for .bit files, the .jed files are always compressed...
<daveshah>
that makes sense, given the .jed files are for internal flash
<AndresNavarro>
I was stumbled by that one while trying to fuzz the lut inits... haha lost a good afternoon generating .jed files that turned out to be all compressed...
<AndresNavarro>
I eventually found out it even said so in the docs for the XO2 programming
<AndresNavarro>
The .jed file is pretty similar to the .bit file anyways although it misses some commands like the chip id (although that is somewhere else in the jedec file)
<AndresNavarro>
The one other thing I noticed is that bitstreams for the XO2 only had CRC after all the frames
<AndresNavarro>
(and the corresponding bit set in the program instruction)
<AndresNavarro>
Unlike the ones for ECP5 that have that bit cleared and CRC after every frame
<AndresNavarro>
I still haven't tested on larger XO2/3 parts to see if it's a matter of the size of the total bitstream or just a family of devices thing (i.e. all XO2/3 having just 1 CRC and all ECP5 having one after every frame)
<daveshah>
yeah, I think the setting bits after the LSC_PROG_INCR_RTI configure this behaviour
<AndresNavarro>
It says so in the docs (I'm going by the ECP5 docs here, the XO2/3 ones don't document the bitstream commands... fortunately they seem to be exactly the same)
<daveshah>
pinging cr1901_modern who is also interested in xo2
<AndresNavarro>
I'm going to work on them
<AndresNavarro>
But still I'm not sure if we should just try to fit project trellis because the architectures seem almost identical of if I should start a new "project" focusing on them
<daveshah>
I would get in touch with cr1901_modern, I think he started some work on them
<AndresNavarro>
After using the ice40 for a while I ordered a few tinyfpga series A (some of them are already at customs so I should have them next week or so)
<AndresNavarro>
And I'm looking forward to getting a full free software flow for them
mumptai has quit [Quit: Verlassend]
<AndresNavarro>
Thanks for the tip, I'll try to reach out
<daveshah>
AIUI a lot of Trellis should be usable with patches
<AndresNavarro>
Yeah, I think I'll write the compress/decompress docs & code tonight and make a pull request
<daveshah>
sounds good
<AndresNavarro>
After that I'll try to see how far I can get from inside the project
<AndresNavarro>
If it turns out to be much different and both families can't be sanely incorporated I can just spin out another project
<cr1901_modern>
AndresNavarro: privmsg
<daveshah>
I think the MachXO2 is almost identical to a lot of previous Lattice parts like the earlier ECPs
<daveshah>
certainly in terms of slice structure
<daveshah>
whereas the ECP5 is a tiny bit different
<AndresNavarro>
Yeah, I noticed a small difference in the slices, a couple of missing inputs if I recall correctly
<AndresNavarro>
And of course the xo2/3 are a lot simpler
<AndresNavarro>
So I think it should be doable to include them as a new family, but then again maybe there's something that warrants spinning something new to focus on them
<cr1901_modern>
daveshah: >I think he started some work on them
<cr1901_modern>
Think? :P C'mon I actually _did_ some work. At least it's better than usual where I just say I'm gonna do something and never start :).
<AndresNavarro>
Ok, guys I'm out for dinner now. I'll come back in a couple of hours to write some code.
<AndresNavarro>
you'll have to excuse my c++, I'm more a pure c guy myself but I'll try :)
<daveshah>
the whole of nextpnr is pretty much c with classes
<daveshah>
we don't tend to do "really c++" c++ - there's not too much inheritance or templating going on
<AndresNavarro>
I haven't looked at it yet, libtrellis I found very readable (even after about 10 years away from my uni c++ days)
<AndresNavarro>
(I did have to look up unique_ptr... we didn't have that in my days...)
<q3k>
nextpnr is indeed c with classes
<q3k>
its main 'sin' is that it uses duck typing for the architecture/core split
<q3k>
otherwise typical google style guide stuff: don't over do templates, don't overdo inheritance, etc
Bike has joined ##openfpga
Bob_Dole has quit [Ping timeout: 264 seconds]
Bob_Dole has joined ##openfpga
<whitequark>
same as solvespace :3
<whitequark>
except less legacy
<azonenberg>
whitequark: speaking of solvespace
<azonenberg>
how portable is the solvespace geometry kernel etc? and what license is it under again?
<azonenberg>
i'm wondering about the possibility (way down the road) of adding parametric cad capability to kicad for strange connector footprint generation
<azonenberg>
as well as things like board design or component placement
<azonenberg>
being able to say, for example, these two connectors have to be aligned in the X axis and exactly 40mm apart in Y
<whitequark>
azonenberg: gpl3/commercial
<whitequark>
do you want the solver or nurbs parts?
<azonenberg>
2d sketching only
<azonenberg>
kicad is gpl3+ so that matches nicely
<azonenberg>
no extrusion
<whitequark>
then that's ~trivial, the solver is a small C library
<azonenberg>
excellent
<azonenberg>
now the hard part is figuring out somebody who's got time to do the integration and write the UI code
<azonenberg>
:p
<azonenberg>
Because i don't, and i doubt you do
<whitequark>
you might need a few extensions as some of the newest features aren't exposed yet but that's doable