<whitequark>
the reason default_clk is a thing is because on most boards, (a) you virtually always want to use that specific clock for various reasons (no internal oscillator, poor quality internal oscillator, it's synchronized to some other device), and (b) the frequency of this clock is fixed
<whitequark>
but on TinyFPGA AX the frequency of the internal oscillator can only be chosen per design
<mtrbot-ml>
[mattermost] <hartytp> @sb10q on the new rev it’s 5pin with a gnd pin for cable screening
_whitelogger has joined #m-labs
rohitksingh has quit [Ping timeout: 276 seconds]
<Dar1us>
whitequark: you have a sensiron SCD30 right? ever had it produce obviously nonsensical values? (like 200ppm and I am not a tree)
<whitequark>
Dar1us: only NaN sometimes
<whitequark>
are you sure clock stretchig works correctly?
<Dar1us>
whitequark: hmm OK, mine has done stuff like start at ~200ppm then gone up to over 1000ppm then back to something believable
<Dar1us>
whitequark: weell.. I am being lazy and using a pyboard (STM32F4) so I believe it does
<Dar1us>
CRCs pass etc
<Dar1us>
currently it's running the calibration but that takes a week so zzzz
<whitequark>
ah at the start it might give nonsensical values due to warmup
<Dar1us>
whitequark: ah OK
<Dar1us>
whitequark: guess I'll wait another.. 6 days.. and see if it is more sensible :)
mauz555 has joined #m-labs
mauz555 has quit []
_whitelogger has joined #m-labs
_whitelogger has joined #m-labs
<_whitenotifier>
[m-labs/nmigen] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/JesZY
<_whitenotifier>
[m-labs/nmigen] whitequark 6414c80 - lib.fifo: add more compatibility shims.
<Dar1us>
ah just some dumb shit I missed that it picked up straight away
<Dar1us>
I'm still not in the habit of using it :(
kernlbob_ has quit [Remote host closed the connection]
sb0cn has joined #m-labs
_whitelogger has joined #m-labs
cedric has quit [Read error: Connection reset by peer]
cedric has joined #m-labs
cedric has quit [Changing host]
cedric has joined #m-labs
<ZirconiumX>
whitequark: Trying to test the SDR stuff by building Boneless, but I've got a small stumbling block: how do I specify top-level ports for build()?
<whitequark>
you don't
<whitequark>
you use platform.request("peripheral")
<whitequark>
i'm not sure if boneless would help much
<ZirconiumX>
I don't know of much in the way of nMigen code I can test with
<whitequark>
mhh, i'll see if i can buy an altera board.
<ZirconiumX>
The Terasic boards are pretty good
<whitequark>
mhm
<whitequark>
now if i can find one in ru...
<whitequark>
does de0nano work?
<whitequark>
de0cv?
<whitequark>
oh, de0nano has some ancient shit cyclone
<whitequark>
de10lite?
<whitequark>
that's max10
<ZirconiumX>
DE-10 Nano
<ZirconiumX>
DE0-CV is Cyclone V
<whitequark>
de10nano is 1.5x more expensive than ... what is reasonable
<whitequark>
also
<whitequark>
doesn't it also have some weird SoC with a hard CPU
<ZirconiumX>
Yep
<whitequark>
i don't like that crap
<whitequark>
always a headache
<ZirconiumX>
It's so far the only way I've gotten it to load bitstreams
<whitequark>
yeah no
<whitequark>
i am not going to bothre with booting an OS on it
<whitequark>
too much effort
<whitequark>
de0cv works too, right?
<whitequark>
i can get one
<ZirconiumX>
Yep
<whitequark>
okay, i'll hav one by 26th or around that
<ZirconiumX>
So, for reference
<ZirconiumX>
In the DE-10 Nano board you have a comment for investigating programming via USB Blaster II
<_whitenotifier>
[nmigen] whitequark commented on issue #220: Prune Yosys-internal attributes in emitted Verilog - https://git.io/JesCy
gnufan_home has joined #m-labs
lkcl has quit [Ping timeout: 246 seconds]
<cr1901_modern>
whitequark: I'm not quite sure I understand what you're getting at, but if I understand correctly: >>
<cr1901_modern>
I think my logic was: If other XO2 platforms are ever supported, I don't want to copy/paste the logic that switches between internal oscillator and external oscillator into each platform. Since MachXO2 is special in that regard, keep it in the backend.
<whitequark>
how is it special?
<whitequark>
ice40 has two internal oscillators
<cr1901_modern>
it does?
<whitequark>
ice40 ultra, ultralite and ultraplus yeah
<whitequark>
hfosc at 48 MHz and lfosc at 10 kHz
<whitequark>
ECP5 has OSCG
<cr1901_modern>
I didn't know that. Well then...
<cr1901_modern>
In omigen, I never really liked the hoops I had to jump through to get logic to switch between an internal an external oscillator working. But it was only one platform.
<whitequark>
what kind of hoops?
<cr1901_modern>
First off, I needed two additional class variable called osch_clk and osch_freq.
<whitequark>
why?
<whitequark>
why does that need to be in the platform in the first place?
<whitequark>
the reason default_clk exists is that on most boards, there is exactly 1 oscillator that will be used for most designs, and its frequency is well known
<cr1901_modern>
So you think there shouldn't be a default clk at all for this board?
<whitequark>
well, let's say you write a platform file for TinyFPGA AX
<whitequark>
it sets osch_freq to... any value.
<whitequark>
why is that value preferred over other values?
<whitequark>
if my board has a 100 MHz oscillator, that value is obviously preferred because I'm stuck with it, it's physically on the PCB.
<cr1901_modern>
it's not, it should be user settable
<cr1901_modern>
(with the caveat that there are a finite set of values supported internally for MachXO2- I have logic to detect whether that's in range that I'll copy over to nmigen)
<whitequark>
what's wrong with setting it by manually instantiating OSCH?
<whitequark>
sure, that means you have to, well, do it. but you already have to do *something* because you need to specify the frequency
<cr1901_modern>
You're also on your own wrt clock domains and creating the reset logic. I wanted to make it as seamless as possible for someone who just wanted a blinky back in omigen days
<cr1901_modern>
which is why I was willing to jump through hoops. But _I_ don't have a problem w/ instantiating OSCH
<whitequark>
yeah so
<whitequark>
hm
<cr1901_modern>
(No surprises, reset logic for MachXO2 is similar to ECP5.)
<whitequark>
ok, maybe it's fine
<whitequark>
i'll need to think about the best way to add OSCH support
* cr1901_modern
nods
<whitequark>
I guess we could add something like `default_clk = "OSCH"` and `osc_freq = 2.08` etc
<whitequark>
by the way all of your code selecting the closest frequency could be replaced with `min(osc_freqs, key=lambda osc_freq: abs(osc_freq - freq))` and a check if it's within 5%
<cr1901_modern>
Oh... lol
<cr1901_modern>
re: adding variables being "jumping through hoops", I handled four cases: osch_used = {True, False} * default_clk={"OSCH", any other string}. >>
<cr1901_modern>
I wanted to be as general as possible, even tho 100% of designs using TinyFPGA Ax in migen will only use OSCH (you could in theory feed another clk on a pin).
<whitequark>
osch_used?
<cr1901_modern>
internal variable for the platform that's set when the platform detects the OSCH was instantiated
<whitequark>
well that's certainly not the business of nmigen