Hail_Spacecake has quit [Ping timeout: 250 seconds]
seldridge has joined #yosys
s1dev has joined #yosys
emeb has quit [Ping timeout: 256 seconds]
emeb has joined #yosys
seldridge has quit [Ping timeout: 256 seconds]
emeb has quit [Quit: Leaving.]
develonepi3 has quit [Remote host closed the connection]
Hail_Spacecake has joined #yosys
s1dev has quit [Ping timeout: 268 seconds]
ravenexp has joined #yosys
seldridge has joined #yosys
_whitelogger has joined #yosys
develonepi3 has joined #yosys
seldridge has quit [Ping timeout: 240 seconds]
<cr1901_modern>
Okay, C++ question: in yosys, show.cc, line 822 we call run_command() with one argument. But in yosys.cc, run_command is defined on line 319 to take two parameters and does NOT provide a default value to the second parameter. Is this legal?
s1dev has joined #yosys
<sorear>
the default value is in yosys.h, not yosys.cc
edmoore has joined #yosys
s1dev has quit [Ping timeout: 272 seconds]
<TD-Linux>
is there a "standard" SPI programming header people are using yet?
<sorear>
cr1901_modern: ^reply
seldridge has joined #yosys
seldridge has quit [Ping timeout: 244 seconds]
cr1901_modern has quit [Read error: Connection reset by peer]
digshadow has quit [Ping timeout: 272 seconds]
X-Scale has quit [Ping timeout: 272 seconds]
Hail_Spacecake has quit [Remote host closed the connection]
<ZipCPU>
TD-Linux: None that I've seen. The 6-wire PMod might be as close as you'll get.
Hail_Spacecake has joined #yosys
dys has quit [Ping timeout: 272 seconds]
<edmoore>
oh, ZipCPU - I'm here because I saw your website. there is some really helpful stuff on it - thank you very much for all the effort you've put in
dys has joined #yosys
<ZipCPU>
edmoore: Why, thank you!
<ZipCPU>
That's encouraging.
<edmoore>
it has prompted me to dip my toes back into FPGAs, having taken a small swim in the shallow waters around xilinx about 4 years ago
<ZipCPU>
Swim, dipped toes, or dive?
<edmoore>
well a dive this time would be fun, now that there's a completely foss toolchain
<edmoore>
actually i think i read on your site that you had made a gps receiver at some point, which is the reason i was playing with them a few years ago
<edmoore>
i just made a pmod-connected frontend to a max2769 and a simple receiver that was mostly actually done on my computer, with the fpga not doing much, but i'd like to revisit that and make a decent inertial+gps unit
<ZipCPU>
That was a fun design. Although, it has yet to meet hardware. Others have had some more traditional success, that particular design needs a rather beefy FPGA, so ... it's still sitting in my rnd directory.
develonepi3 has quit [Remote host closed the connection]
<edmoore>
but yeah, i got a bit put off by trying to get a new license or something when i had to reinstall webpack ISE on an upgraded ubuntu ... blah blah I forget the details, but something like that... and totally unrelated work came along and I forgot about it all, but it was all a bit offputting then and it looks to be much better now
cr1901_modern has joined #yosys
<ZipCPU>
I'm just looking forward to the day when nextpnr supports series-7 devices ;)
<edmoore>
what is the biggest device that the icestorm toolchain currently supports?
<edmoore>
sorry lazy question, i will lookit up on the icestorm page
dys has quit [Ping timeout: 256 seconds]
<cr1901_modern>
sorear: Oops, thanks
<ZipCPU>
edmoore: The ecp5k
<ZipCPU>
IIRC
develonepi3 has joined #yosys
X-Scale has joined #yosys
digshadow has joined #yosys
dxld has quit [Quit: Bye]
dxld has joined #yosys
mjoldfield has quit []
pie_ has quit [Ping timeout: 244 seconds]
<awygle>
it would be the ECP5 family, specifically an 85k part
<awygle>
i think you merged ECP5 and UP5K :P
maikmerten has joined #yosys
<ZipCPU>
awygle: Ahh, thank you! I've never used either, so I'm not as familiar with them (yet)
<awygle>
no problem :) the ECP5s are really cool, they occupy a very attractive point on the price/performance curve
<daveshah>
Strictly speaking the biggest part supported by icestorm is either the 8k (by LCs only) or up5k (by features)
<daveshah>
ECP5 support is using the same tools but not part of icestorm itself (ECP5 is Project Trellis)
<daveshah>
Very early days though, but hopefully something will be useful well before the end of the year
<awygle>
yeah i didn't want to bother with that correction, but maybe i should have
<edmoore>
thanks all
<edmoore>
daveshah: is the difference between the two (lattice families) things like the dsp blocks?
digshadow has quit [Ping timeout: 256 seconds]
<daveshah>
Totally different
<daveshah>
ice40 is actually SiliconBlue and bought by Lattice
<daveshah>
ecp5 is actually Lattice, although a few things originate from Bell Labs/Lucent/AT&T/Xilinx
<edmoore>
oh well, i'll get an icestick and start playing and figure it out as i got along
<ZipCPU>
I'd go for at least an 8k device. I think the icestick is only 1k, right?
<edmoore>
is there a cheapo supported 8k device dev board to start with?
<ZipCPU>
Is the tinyFPGA BX for sale yet?
<TD-Linux>
I think it's still available on crowdsupply
<TD-Linux>
but yeah it's been for sale for a while, I'd recommend it for 8k
<ZipCPU>
Looks like $38 bucks plus shipping, is that cheep enough for you edmoore?
<edmoore>
well the icestick is $20 but it's still low-cost enough :)
<ZipCPU>
Doh!
<ZipCPU>
The stl files for a case can be found on my github page, in the tinyzip project--in case you want to 3d print a case ;)
<edmoore>
i might still get the icestick and use the pmod connector to stream data from my gps rf-samper pcb
<ZipCPU>
Of course... you can't use the pins if you do that, so take your pick
<edmoore>
it should be able to just blat 16Mbit/s from the 1bit adc over the usb right?
<edmoore>
do people still use fpgalink?
<ZipCPU>
It gets a raw USB speed of 16Mb/s, yes. I doubt you'd get that much net throughput tho.
<edmoore>
is it as low as that from the ftdi chip?
<ZipCPU>
No. To use the USB, you need to sacrifice some of the flash and about 1k LUTs
<ZipCPU>
That is a sizable portion of an 8k device, but it is what it is.
<edmoore>
given it only has 1k LUTs that could be a problem!
<edmoore>
oh i was taling about the icestick
<edmoore>
which has an ftdi chip on it
<ZipCPU>
The TinyFPGA has 8k LUTs, sorry, that's the one I was talking about
<ZipCPU>
I'm not familiar with the specs of the icestick
<edmoore>
ZipCPU: roger. so if i get the little 8k dev board you linked to above, that just connects d+ and d- to the fpga?
<edmoore>
and you have to implement the usb core in logic?
<ZipCPU>
Yes
<ZipCPU>
An example design is publicly available
<edmoore>
and that's the thing that's limited to 16Mb/s?
<ZipCPU>
That's what I was referencing. The serial channel is running at 16Mb/s simplex
<edmoore>
righto
<edmoore>
i think that's going to be a bit limiting for this
<edmoore>
so i will try the icestick to begin with and then if i like it I'll do my own pcb with an 8k device
<ZipCPU>
There are other available 8k devices
<ZipCPU>
There's the "BlackICE" board, and the ICOBoard. Those are the two I know of.
<ZipCPU>
I'm sure there are still others.
<ZipCPU>
Neither are quite as cheap as the icestick you mentioned, but ... you might want to look at them before designing your own.
<edmoore>
the ft2232h on the icestick at least claims it can do 30Mbit/s over the spi interface (which is the interface it's using according to the schematic)
<edmoore>
is there anything tricky about laying out a board for these parts?
digshadow has joined #yosys
<ZipCPU>
I wouldn't know ... I've never actually designed or built any PCBs myself
<ZipCPU>
Perhaps someone else on the channel can chime in here.
<edmoore>
$dayjob involves a lot of pcb design, for me
<edmoore>
in bursts anyway
<edmoore>
so i'm not too worried about that, though i try and avoid anything with more than 6 layers or dense BGAs
<edmoore>
blackice looks interesting though
<edmoore>
ZipCPU: just super approximately, and for my own interest, if one wanted to make a very rudimentary, not very good 8-bit cpu on an fpga (just for learning purposes), roughly how many LUTs would you need?
<edmoore>
i have really no intuition for how cpu building blocks map to LUTs
<ZipCPU>
Why don't you count them to find out? I know there's a nybbleforth CPU out there that fits in a 1k, I just don't know how much it can do or for that matter how well (if at all) it even works
<ZipCPU>
Hmm ... that one won't even build
<edmoore>
if you take all the bells and whistles (branching etc) out of the zipCPU, how small does it go?
<ZipCPU>
I might just barely fit into 4k.
<ZipCPU>
That would be without any debugging infrastructure either.
<ZipCPU>
So ... doable, but ... with limitations.
<edmoore>
sure
<edmoore>
ok, well you've convinced me i want the 8k part
<edmoore>
i will still see if i can use the icestick as a glorified way of streaming data from the gps front end, as that will be a cheap win and motivate me to get back into it
<ZipCPU>
Which GPS front end do you have?
<edmoore>
my own design
<ZipCPU>
Ahh ... okay. Ever tried getting the FPGA to lock onto it?
<edmoore>
really just a breakout for a max2769
<edmoore>
no, i just captured the iq data through my scope lasttime (which has a very deep memory) and took it back to the pc through that, then got a fix offline
<edmoore>
i've never tried to implement acquisition or tracking on an fpga
<ZipCPU>
Cool.
<ZipCPU>
Have you done the acquisition and tracking in S/W?
<edmoore>
it seems the obvious next step, but 'obvious' is a relative term from my position of complete fpga ignorance
<edmoore>
yes
<ZipCPU>
;)
<ZipCPU>
My own GPS processing design is highly memory intensive, so ... as I've built it-it doesn't fit on most FPGA's.
<edmoore>
that was no problem (in sw), but i have no idea how best to do it in hardware
<edmoore>
do you even do circular correlation in freq space on an fpga
<edmoore>
or do you just have lots of parallel correlators
<edmoore>
this is all a mystery to me
<ZipCPU>
I ported my software algorithm to an FPGA design. As a result, it requires many MB of block RAM
<edmoore>
i get the FPGAs lend themselves to FFTs, and in 1-bit land you can do some nasty things like mixing down the IF to baseband by xoring with a register of 'LO'
<edmoore>
ah right cool, so you do do the fft
<ZipCPU>
Yes. I haven't tried the XOR approach (yet). Not sure if I will or not.
<edmoore>
were you doing anything especially different with your implementation to make it more memory intensive?
<ZipCPU>
Perhaps
<edmoore>
this is very cryptic, I won't pry then :)
<edmoore>
i was doing it for rockets (just fun civilian ones) where the dynamics were above the cocom export limits for COTS GPS, and regardless where their dynamic assumptions in the internal kalman filters did more harm that good
<ZipCPU>
The result worked quite well in some unexpected environments. I just never managed to get it ported into a real-time application.
<edmoore>
so i wanted to make my own, and eventually do the inertial sensor fusion at a very deep level
<edmoore>
but then i got sidetracked into rocket engine work and have been there since
<ZipCPU>
Ahh ... no, I was more interested in pedestrian or ground-vehicle born GPS
<ZipCPU>
You should've seen the train test I did. That was fun.
<edmoore>
you strapped it to a train?
<ZipCPU>
Amtrak. When the GPS receiver was in the overhead bin, the traditional receiver didn't get any fixes, our processor got some very nice fixes *with velocity* estimates
<edmoore>
oh fun!
<edmoore>
how did you manage that? they're tin cans!
<ZipCPU>
Same thing when I took it on a grayhound bus--nothing in the overhead from the commercial receiver, my own algorithm worked.
<ZipCPU>
Not quite. The windows are pretty large.
<edmoore>
did you correlate over multiple chirps?
<ZipCPU>
;)
<edmoore>
best train ride of my life was the amtrak zephyr
<edmoore>
great country and lots of interesting fellow passengers
<ZipCPU>
Had one mbr of the team take it by pack into the grand canyon. It was fun to watch the Z axis of the fixes when that one came back for processing.
<edmoore>
i'm actually really interested in ultra high resolution relative positions
<ZipCPU>
Another fun one: a member of the team brought some collects back. I plotted them on google maps, and pointed out the speed limit didn't match his current speed.
<edmoore>
this might be a bit batty but i've just seen what tiny packages those 8k ice40 parts come in
<ZipCPU>
:D
<ZipCPU>
Ok, is that good or bad for you?
<edmoore>
so in a previous job i did parachute research for things landing in faraway places
<edmoore>
good for this idea
<ZipCPU>
Nice.
<edmoore>
by faraway i mean like mars rather than the middle east
<edmoore>
and testing parachutes is a nightmare, because it's very hard to match martian conditions in a wind tunnel on earth (specifically the combination of mach number and dynamic pressure, which governs the way a chute inflates, which is the important bit where the loads are highest)
<ZipCPU>
Ouch! GPS on Mars? Good luck with that one.
<edmoore>
lol nom though a fun idea
<edmoore>
so we can test by going high into earth's atmosphere where it's much thinner
<edmoore>
and use rockets, or just drop from a massive balloon, to hit the right mach/pressure combos
<edmoore>
however, you can't instrument that nearly as well as a windtunnel test with a million highspeed cams from all angles, 3d reconstruction etc etc
<edmoore>
so (i am getting to the punchline, thanks for your patience)
<edmoore>
what would be cool would be a series of very tiny gps loggers woven into different bits of the test chute - postage stamp sort of size - all on a coherent clock (somehow), all just logging the raw RF from the gps front ends for the 1s or so it takes to deploy
<ZipCPU>
Why use a coherent clock? You mean one clock for all of the loggers, rather than one clock per logger?
<edmoore>
then back on the ground, if you know their starting point was the same (in the mortar) and they all started logging at the same time, you can probably do carrier-wave level kinematics to figure out their relative positions from each other as they deploy
<ZipCPU>
One clock per logger should be all you need.
<edmoore>
and thus 3d reconstruct the way the parachute deployed
<edmoore>
yes, one per logger, but they all need to be very accurate and synced somehow
<edmoore>
probably a TCXO would do it, but with the syn still - maybe via radio, i'm not sure
<edmoore>
tiny bits of coax feeding time from a single clock woven into the chute canopy might be a bit fragile
<edmoore>
this is a bit silly, I know, but i mean all these chips are like 4mm x 4mm packages
<edmoore>
fpga, flash mem, max2769, tcxo. could fit it all on a dime
<edmoore>
it would be a bit like 'dorothy' in the twister film
* qu1j0t3
ponders that edmoore 's job is only 1e6 x more interesting than mine
<edmoore>
i don't do that anymore
<edmoore>
like many fun things, it becomes less fun when space agencies stick their tentacles in
<edmoore>
4 days of paperwork per minute of fun
<qu1j0t3>
i see
<edmoore>
i left to work for a much smaller company which is back to being fun
<qu1j0t3>
i'm glad to hear it
<edmoore>
hey look, my talking to doing ratio has been a bit off here today, but thank you all for all the pointers, i will stick around
<ZipCPU>
Cheer!
dys has joined #yosys
maikmerten has quit [Quit: Ex-Chat]
digshadow has quit [Ping timeout: 272 seconds]
<awygle>
edmoore: solidarity on the space agencies thing :/. PCBs for the ice40s aren't too hard as long as you pick a QFN or 0.8mm pitch BGA. you might be a bit stressed to break out _every single_ I/O on the BGAs but you rarely need them all
<awygle>
curious what your power target was on the GPS - i tended to hit my budget very quickly when whiteboarding designs for cubesat GPSes
<ZipCPU>
You mean ... how much power was received, or how much power the receiver used to capture the GPS? For the former, I never figured out how to properly measure it. For the latter, about 70mW as I recall.
<awygle>
the latter
<ZipCPU>
And when the hardware wasn't collecting GPS, it was using less than 30uW as I recall.
<awygle>
although the former sort of feeds into it in the sense that you can trade power for sensitivity most of the time
<awygle>
iirc i was getting killed on the processing end rather than AFE (GPS being fairly narrow)
<edmoore>
alright i'm back because gps chat
<edmoore>
so for a cubesat i'd take a different tac
<edmoore>
you don't really need real-time gps for a cubesat, you just need maybe 3 fixes in orbit to back our your keps
<edmoore>
so i figure you just record a second of iq data (2MB) and process it at your leisure on a cortex m3 or something
<edmoore>
don't ask me how you get ephemeris
<edmoore>
back out your keps*
<ZipCPU>
Ephemeris is published. It can also be downloaded from any other receiver or receiver set.
<edmoore>
well yes exactly, so i mean you could get it some other way that having the gps being on for 15 minutes
<edmoore>
and then just do the 1s of recording every 20 mins or so
<awygle>
that's true. i think i had memory bandwidth issues with that? but i bet i didn't pursue it very aggressively. it sounds like the knid of thing that would trigger my "even if this is the right solution it feels like a hack" alarm
<edmoore>
yes, doing it real-time would be more elegant
<ZipCPU>
;)
<awygle>
but yes your power budget is much happier at a 5% duty cycle :)
<edmoore>
i suspect reverse-engineering a ublox chipset would be the rightest way of doing it
<edmoore>
short of an asic
<ZipCPU>
That was part of the purpose of the design I had put together--doing it in real time on an FPGA, and getting all of the benefits from doing it off-line.
<awygle>
today i'd probably try to do it in, like, an igloo
<awygle>
also you almost certainly want an m4f for that sweet sweet DSP support :p
<ZipCPU>
I did the collection in an igloo before. Not terribly hard. Wrote to an SD card too.
<edmoore>
awygle: sure, though actually iirc there is not as much in gps decoding that lends itself to m4 dsp instructions as i thought
<edmoore>
at least not with 1-bit samples
<edmoore>
however i've not looked at this for 5 years and the chatting here today is about the first time i've thought about it. i might dig up my python implementation
<edmoore>
i guess all the stuff above correlation and tracking could take advantage of the fpu
<awygle>
i'd believe that. the dsp side of gps is not my strong suit, i'm more of an rf guy
<edmoore>
i don't like PLLs for tracking
<edmoore>
they got replaced by a kalman filter within about 5 minutes
<edmoore>
awygle: oh cool!
<edmoore>
have you ever done a gps front end from scratch? my rf is at the level where i wait for maxim to make an integrated chip and pretend i never saw the rf
<ZipCPU>
One of these days I need to play with Kalman filters. I've read the text too many times and still don't understand it. I figure I might understand them if I built one or two.
<edmoore>
yes i just used them in anger and it made sense
<awygle>
ZipCPU: i find kalman filters inscruitable but particle filters make intuitive sense to me *shrug*
<edmoore>
understanding them is a two-pronged approach (for me at least)
<edmoore>
1) understand them in a bayesian sense - predict, measure, predict, measure - one is multiplying two gaussians, the other is convolving two gaussians
<awygle>
edmoore: depends on what you mean by "from scratch". i used some RFICs, i haven't done one where i biased all the transistors myself yet
<edmoore>
i.e. the high level understanding of what the kalman filter is 'doing'
<awygle>
but i didn't use a fully integrated Maxim chip or anything like that - raw LNA, ADC, etc
<edmoore>
then for more than one dimension, it's understanding the linear algebra, being happy with the matrix inversion lemma, etc
<edmoore>
awygle: that's pretty cool, and the noise floor was low enough?
<awygle>
edmoore: seemed to be based on testing. i never flew it though :(
<edmoore>
i prefer particle filters to
<awygle>
my UHF LNB works great though, no real reason why the GPS version shouldn't
<edmoore>
but they're not going on a cortex m4
<edmoore>
too*
<edmoore>
u guess the unscented kalman filter is the middle ground between PF and KF
<awygle>
0.4 and 1.4 GHz aren't that different :p
<edmoore>
awygle: what do you use PFs for?
<awygle>
edmoore: i haven't used them since college actually, but i was just researching parallel FPGA placement algorithms and "population annealing" looks just like a particle filter
<edmoore>
nice
<edmoore>
my old research group was big into particle filters
digshadow has joined #yosys
<awygle>
they are fun, we did a SLAM project with them in college
<edmoore>
i've never done slam, i'd really like to
<edmoore>
it's one of those cool fields where the principles are easy enough but there's so much involved with making a good one
<edmoore>
kind of like rocket engines
digshadow has quit [Ping timeout: 260 seconds]
<awygle>
i'd really like to build a rocket engine
<awygle>
or a jet engine maybe
seldridge has joined #yosys
develonepi3 has quit [Remote host closed the connection]