clifford changed the topic of #yosys to: Yosys Open SYnthesis Suite: http://www.clifford.at/yosys/ -- Channel Logs: https://irclog.whitequark.org/yosys
<awygle> So what is going on there is you're counting up a number of clock cycles equal to (500MHz / 2000 kHz /2) and every time you've seen that many cycles, toggling MCLJ
<awygle> *MCLK
<awygle> Which gives you a signal which toggles every 4000 kHz, or a 2000 kHz clock
<awygle> Does that make sense?
* shapr thinks about that
<shapr> ohh
<shapr> oh I get it!
<shapr> MCLK is a 'wire' so it's a binary signal
<shapr> and it needs to flip states to implement the protocol
<awygle> more or less, yes. MCLK is a binary signal, so ~MCLK is low if MCLK is high and vice versa, thus toggling
<shapr> ok, that makes sense
<awygle> This structure is called a clock divider
mwk has joined #yosys
<awygle> There are other ways to implement it, especially if you're doing power of 2 division, but that's what it is
<shapr> counter + check + invert wire and reset counter
<shapr> kinda surprised there's no way to set the kHz or MHz value for an outgoing signal, and then have the 'compiler' figure it out.
<awygle> yeah you'd think lol
<awygle> Actually you can do that with parameters but you have to specify the input speed too
<shapr> Would make sense to have one place to set the clock pin and its speed, and one place to set the outgoing speed
<shapr> if nothing else, I bet outgoing signals need a clock as well
<awygle> I think Migen does something like that, but verilog (and VHDL?) don't
<awygle> Mostly due to their historical roots as discrete event simulators
<shapr> yeah, they're not really designed for this
<shapr> it's an ugly hack
<awygle> There are things called clock constraints in most EDA toolchains which have some of that sort of functionality but not really in this context
<shapr> seems like you should be able to define the outgoing protocol and have the compiler handle some of it for you
<shapr> verilog is srsly low level
<awygle> I'm getting a bit out of my depth here, but there's a thing called reactive synthesis which does some of that kind of thing
<shapr> I'll go look that up one day
<awygle> Clifford referenced it on Twitter the other day, I don't know a ton about it
<shapr> for now, I just need to divide the count values by 5
<shapr> and ... change the names to match the beaglewire.pcf ?
<shapr> am I missing anything?
mwk has quit [Remote host closed the connection]
<shapr> awygle: is there a way to parameterize a verilog file so I could easily move a pmod from one header to the other and only have to change one value in the makefile?
azonenberg_work has quit [Ping timeout: 252 seconds]
<awygle> okay now i'm at a for real computer
<awygle> to do that i might try defining _all_ the pins in the PCF, then using `ifdef PMOD_1_I2S type constructs to assign the pins to semantically meaningful names
<awygle> does that make sense?
<awygle> then you'd just change some defines as passed in on the command line in your makefile
<awygle> something like this (i think i messed up the preprocessor syntax but you should get the idea) https://pastebin.com/NRJnMCmw
<awygle> specifically i think `end should be `endif but i'm not sure
<shapr> ok, so change values in the pcf?
<shapr> I guess that would be the easy way, alias whatever pins I'm using to i2s_something
<awygle> right, i would make the pins in the PCF _pmod-related_, because that's what they are, and then map them to _i2s related_ names in your code, because that's where the i2s-ness comes in
<awygle> but that's just me
<awygle> not everyone follows this style
<shapr> ok I think I understand that
<awygle> fair warning i know nothing about pmods or about i2s :p
<shapr> I don't know much, but I'm learning
<awygle> "I don't know everything, I just know what I know"
azonenberg_work has joined #yosys
seldridge has joined #yosys
azonenberg_work has quit [Ping timeout: 246 seconds]
rohitksingh_work has joined #yosys
seldridge has quit [Ping timeout: 246 seconds]
azonenberg_work has joined #yosys
mwk has joined #yosys
emeb_mac has quit [Quit: Leaving.]
bb has quit [Ping timeout: 246 seconds]
dys has quit [Ping timeout: 272 seconds]
AlexDaniel has joined #yosys
pie_ has quit [Ping timeout: 240 seconds]
m4ssi has joined #yosys
digshadow has quit [Ping timeout: 246 seconds]
GuzTech has joined #yosys
s_frit has quit [Remote host closed the connection]
s_frit has joined #yosys
xdeller_ has joined #yosys
xdeller has quit [Ping timeout: 252 seconds]
xdeller__ has joined #yosys
xdeller_ has quit [Ping timeout: 252 seconds]
rohitksingh_work has quit [Read error: Connection reset by peer]
rohitksingh_work has joined #yosys
rohitksingh_work has quit [Read error: Connection reset by peer]
rohitksingh_work has joined #yosys
rohitksingh_work has quit [Read error: Connection reset by peer]
rohitksingh_work has joined #yosys
rohitksingh_work has quit [Read error: Connection reset by peer]
rohitksingh_work has joined #yosys
seldridge has joined #yosys
m_t has joined #yosys
develonepi3 has joined #yosys
xdeller__ has quit [Ping timeout: 252 seconds]
xdeller has joined #yosys
AlexDaniel has quit [Ping timeout: 252 seconds]
rohitksingh_work has quit [Read error: Connection reset by peer]
indy has quit [Quit: ZNC - http://znc.sourceforge.net]
indy has joined #yosys
mattvenn_ has joined #yosys
s_frit has quit [Remote host closed the connection]
s_frit has joined #yosys
rohitksingh has joined #yosys
fsasm has joined #yosys
<mattvenn_> anyone with tinyfpga experience? I'm using arachne-pnr and it's failing with cm81 package
<mattvenn_> version: arachne-pnr 0.1+20151224git1a4fdf9 (git sha1 1a4fdf9, g++ 5.4.0-6ubuntu1~16.04.4 -O2 -fPIE -fstack-protector-strong)
<mattvenn_> and error:
<mattvenn_> fatal error: unknown package `cm81'
<mattvenn_> with command line:
<mattvenn_> arachne-pnr -d 8k -P cm81 -o tinyfpga.asc -p tinyfpga.pcf tinyfpga.blif
seldridge has quit [Ping timeout: 246 seconds]
<mattvenn_> hmm, seems my version is way out of date
<mattvenn_> have compiled new version and...
<mattvenn_> it works!
<mattvenn_> flashy flashy
emeb has joined #yosys
NB0X-Matt-CA has quit [Excess Flood]
NB0X-Matt-CA has joined #yosys
NB0X-Matt-CA has joined #yosys
<shapr> what's the idiomatic way of describing "convert one clock signal to a lower clock signal" ?
<jn__> i think the usual verb is "divide", if the frequency ratio is an integer ≥2
<shapr> so I'd say "clock division" or something?
<jn__> depends on the sentence structure, which i don't know in this case
NB0X-Matt-CA has quit [Excess Flood]
<jn__> (and, disclaimer: i probably don't know as much about fpgas as most people here)
<shapr> well I certainly don't
<shapr> but I'm still teaching FPGA class to my coworkers who know even less :-)
<jn__> the circuit that divides a clock is called a clock divider, but i haven't heard "clock division" as a term somehow
NB0X-Matt-CA has joined #yosys
maikmerten has joined #yosys
<develonepi3> hello all is anyone using the catboard?
rohitksingh has quit [Quit: Leaving.]
<shapr> develonepi3: what's that?
<shapr> jn__: noun : clock divider
<shapr> that helps thanks!
<jn__> cool :)
seldridge has joined #yosys
rohitksingh has joined #yosys
m_t has quit [Remote host closed the connection]
GuzTech has quit [Quit: Leaving]
<awygle> hmm so I can say "this method of doing (say) clock division takes O(n) size" but what's the equivalent to "O(n) speed"?
rohitksingh has quit [Quit: Leaving.]
<sorear> what do you mean by speed? fmax? latency?
<awygle> Oh maybe logic depth scales as O(n). That's more like what I'm trying to say
<awygle> sorear: I was thinking fmax
azonenberg_work has quit [Ping timeout: 252 seconds]
azonenberg_work has joined #yosys
azonenberg_work has quit [Ping timeout: 252 seconds]
azonenberg_work has joined #yosys
<develonepi3> shapr: The catboard was created by Dave Vanderbout from XESS (makes Xula2-lx9 & Xula2-lx25). It uses the HX8K and interfaces to RPi. Instead of sram which the icoboard uses, it has 4M X 4 banks X 16 bit sdram.
rohitksingh has joined #yosys
dys has joined #yosys
digshadow has joined #yosys
seldridge has quit [Ping timeout: 252 seconds]
seldridge has joined #yosys
fsasm has quit [Ping timeout: 244 seconds]
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined #yosys
digshadow has quit [Ping timeout: 250 seconds]
m4ssi has quit [Remote host closed the connection]
rohitksingh has quit [Quit: Leaving.]
<shapr> awygle: today's class attendees are excited about using https://github.com/kiran2s/FPGA-Synthesizer for our next goal!
<shapr> I described clock dividers and we went over the i2s specs a bit
<awygle> hooray!
<awygle> shapr: i found zipcpu's blog post on clock dividers btw http://zipcpu.com/blog/2017/06/02/generating-timing.html
<shapr> I also talked about PCF files and how we'd get to modify the pin descriptions to match the beaglewire.pcf
* shapr reads
<shapr> ZipCPU: thanks for writing blog posts!
<awygle> i think i'm also going to write one because zipcpu doesn't cover some of my favorite techniques
<awygle> or talk about performance tradeoffs etc
<awygle> (not a criticism, that just wasn't the point of the post)
<shapr> more info is better :-)
<shapr> Are there FPGA conferences that aren't vendor sponsored?
<shapr> something more yosys community style?
<awygle> there's ORConf which isn't strictly FPGAs but is definitely relevant
<awygle> unfortunately for me it's in poland
<shapr> not Oregon?
<awygle> although olof was talking about doing one in silicon valley area
<awygle> OR is OpenRisc (although that's mostly vestigial now as it's the FOSSi conference)
<shapr> I don't really have time to organize another conference
<shapr> but if I end up in Silicon Valley, I might do that anyway
<awygle> i could _probably_ make it to an ORConf Silicon Valley (NORConf as it's being called) but Gdansk was just too far for me to go this year
<shapr> haha NORconf ...
<shapr> gonna start one in the southeast called XORConf
<awygle> are you in the southeast? i thought you were in like Boston for some reason
<awygle> might have been thinking of someone else
<shapr> I live in Atlanta for the past three years, but I have lived in Boston in the past
<awygle> anyway stay safe! hurricane :/
<shapr> I've lived in a bunch of places.
<shapr> eh, Atlanta is mostly out of the path
<sorear> Hi, you’re thinking of me
* shapr thinks fondly of sorear
<shapr> sorear: when did you show up in #haskell ?
<sorear> I’m in Boston, cr1901_modern is Philadelphia, fseidel is Pittsburgh
<shapr> I'm in Atlanta! for the moment... but looking for work in DC
<sorear> 2006?
<shapr> GF just moved to DC
<shapr> awygle: you're in the Seattle area, right?
<awygle> yup
<awygle> redmond, for those who know the area a little better
<awygle> sorear: ah, that makes sense. my brain is lazy, "irc friend starting with s" had a hash collision i guess
<shapr> sorear: 2006 was a good time, after the drama of the failed coup had finally died down
<shapr> at least, I think that's the right timeline
<shapr> Lots of early #haskell people coming to ICFP this year
* awygle is suddenly much more curious about #haskell
<shapr> awygle: I started #haskell, tried to run it as a democracy, that failed miserably when one person tried to 1. be mean to newbies 2. say it was his academic right to be on #haskell
<shapr> so I became a mostly benevolent dictator, with the primary goal to create/maintain a friendly welcoming community
<shapr> I started a bunch of other irc channels, #concatenative #epigram and more
digshadow has joined #yosys
<shapr> #unicycling :-P
<shapr> I also tend to start groups wherever I'm living
<shapr> I started Boston Haskell, Atlanta Functional Programming, lots more
<shapr> I organized some conferences, EuroHaskell 2003 and AngloHaskell 2005
<shapr> AngloHaskell continued on for five years after
<shapr> I started The Monad Reader, a semi-academic journal
<awygle> dang, prolific
<shapr> I hosted the darcs website, admin'd the Haskell Wiki
<shapr> hosted lambdabot and wrote the plugin system
<shapr> Right now I teach FPGA on Monday lunch, Haskell Tuesday lunch, Haskell after work on Wednesday, organize a monthly hardware hack night and contribute to a monthly Haskathon
* awygle suddenly feels tired
<shapr> haha
<awygle> i can barely keep my dishes clean lol
<shapr> my apartment is a disaster, filled with half started projects and random offbeat hardware
<shapr> I need to replace the fan on my risc-v linux board so I can start porting the Haskell compiler to risc-v
<shapr> I really just need to add the calling convention to LLVM on risc-v
<shapr> awygle: I'm not so good at finishing projects, but I do fine if I'm going to give a talk or presentation
<jn__> just keep the clock a little lower :)
<shapr> so I give a whole bunch of talks and presentations
<jn__> the H5U originally didn't have a fan but then it didn't survive people compiling gcc, or something like that
<shapr> jn__: turns out the fan on the HiFive Unleashed has bearings that crap out if you twist the board while the fan is running
<shapr> oh really? tell me more!
<shapr> you have one? you're part of SiFive?
<jn__> i have a board, but i'm not part of SiFive. i just followed the announcements with interest
<shapr> jn__: I really wish the h5u had arrived with debian or something I could just use
<shapr> I also wish the sdcard driver weren't so slow
<shapr> what's the sane way to deal with that? NFS?
<shapr> I would have bought the expansion board if they had a yosys-friendly FPGA
<sorear> Yes, NFS
<jn__> oh yes, the SD card driver (stack) needs a good deal of tuning
<shapr> I've decided I will not fund FPGAs that don't support yosys, it's not worth my time and energy.
<awygle> does anybody know whether yosys is deterministic?
<sorear> It’s also possible to use the board with the vc707 as a (more expensive but maybe future yosys) option
<jn__> i wish someone will make an alternative chiplink "southbridge"
<awygle> if i feed it the same verilog will i always get the same blifs/jsons?
<shapr> sorear: what's that?
<shapr> awygle: afl time?
<sorear> Xilinx devboard
<awygle> shapr: lol. well there's vloghammer but idk really how to use it
<shapr> eek, that's pricey
<shapr> even for my hardware budget
<shapr> $3500 is a bit much
<shapr> If I have that much to burn, I'll buy a ThinkPad P52
<jn__> shapr: the usual solution for fast storage on the H5U is https://www.crowdsupply.com/microsemi/hifive-unleashed-expansion-board
<shapr> yeah, but that polaris FPGA makes me unhappy
<shapr> and it's not much cheaper than the vc707
<jn__> ^ yep, and it's pricey
<shapr> oh, polarfire
<shapr> the openfpga people said the bitstream is encrypted, so they wouldn't touch that for fear of DMCA problems
<shapr> if they'd had an ECP5 or something, I'd own it.
<awygle> oh is it really?
<awygle> that's a bummer
<shapr> that's what I heard
<shapr> doesn't mean it's true
<awygle> the polarfire has some appealing hardware features
<shapr> I can ask again
<jn__> the physical connector is https://en.wikipedia.org/wiki/FPGA_Mezzanine_Card and chiplink has public implementation(s), so it should be at least possible to get a southbridge running without a lot of silly research, i think
mwk has quit [Ping timeout: 272 seconds]
mwk has joined #yosys
<shapr> well that's interesting
<shapr> jn__: do you have the expansion board?
<jn__> nope
<jn__> too much $$$
<shapr> yeah, I know that feeling
<jn__> and for my projects i don't really need it
<shapr> jn__: are you compiling anything on the h5u?
<jn__> rarely
<jn__> because i mostly do coreboot stuff
<jn__> i will compile stuff on it if/when i decide to try porting alpine, though
<shapr> huh, sounds exciting
<shapr> ok so I asked on ##openfpga and it sounds like I was totally confused about the polarfire stuff
[X-Scale] has joined #yosys
X-Scale has quit [Ping timeout: 252 seconds]
[X-Scale] is now known as X-Scale
* shapr convinces another coworker to buy a BeagleWire
azonenberg_work has quit [Quit: Leaving.]
azonenberg_work has joined #yosys
pie_ has joined #yosys
seldridge has quit [Ping timeout: 246 seconds]
<shapr> on the good side, that polarfire questions turned into useful discussion
seldridge has joined #yosys
maikmerten has quit [Remote host closed the connection]
mwk has quit [Ping timeout: 272 seconds]
mwk has joined #yosys
<awygle> does yosys support functions?
<awygle> oh there we go, i managed to permute it into functionality
azonenberg_work has quit [Quit: Leaving.]
azonenberg_work has joined #yosys
<awygle> shapr: between my lunch hour and an hour before work I've written five clock dividers today
<shapr> w00
<shapr> awygle: this is useful info
<shapr> what other things do you write?
<shapr> cause I just don't know anything about FPGA dev
<awygle> well, without saying too much, i work at a company which programs memory chips. so i have a bit to do with some of that
<awygle> on my spare time i've been working on formally verifying a UART core
<awygle> which turns out to be quite difficult
<awygle> and a clock domain crossing fifo
<awygle> which isn't too bad
<awygle> the next thing is i want to do my own ILA/debugging suite, and then some Ethernet and PCIe stuff
<awygle> i might skip the debug stuff depending
<zkms> fifos / clock domain crossings are super intimidating, they're like the part of FPGA stuff that scares me the most ;-;
<awygle> zkms: have you read the sunburst papers on them?
<awygle> i sort of feel like it's similar to e.g. bga soldering, where it's got a reputation for being much more difficult than it actually is
<zkms> i haven't, can you link the relevant ones?
<zkms> all i recall hearing stuff about Grey code but i don't even know how exactly it gets used and if it's really necessary or superfluous ;;
<awygle> the other ones are just "this minus some bits"
<sorear> just read the Lamport papers and accept that doing this 100% reliable is impossible and you’re playing a mtbf game
<awygle> sorear: which lamport papers in particular?
<awygle> and yes, you're playing an mtbf game, but the mtbf can be brought arbitrarily low at the cost of some logic+latency
dys has quit [Ping timeout: 244 seconds]
<zkms> yeah speaking of MTBF are there good papers/textbooks about how to design high-reliability FPGA designs?
<sorear> Paper is 1976, ignore the url
<awygle> sorear: thanks
<awygle> zkms: high reliability in what sense? i probably don't have any good resources, i have a very narrow perspective on reliability due to my space background
<shapr> awygle: what's ILA?
<shapr> oh using gray code for clock domain crossing makes perfect sense
<awygle> shapr: internal logic analyzer
<shapr> ohh
mwk has quit [Ping timeout: 240 seconds]
<zkms> awygle: high reliability as in "you'd be happy to fly in an aircraft with that FPGA in the avionics"
<awygle> mm yeah i'm of limited use there. i sat next to some people while they wrote verilog that went to space, but i was more concerned with part selection and the pcb around the fpga than the hdl
<qu1j0t3> i'll take the one that has two fpgas in a failover config
<qu1j0t3> or three in voting
<awygle> need three for majority voting :p
<awygle> what we did was TMR in the fabric
<awygle> (triple modular redundancy)
<awygle> but not at the level of 3x physical chips
* qu1j0t3 nods
<qu1j0t3> you probably got almost all the same benefit, eh?
<zkms> how do you even do that kind of redundancy without having the voting circuit/gates not be a single point of failure?
<qu1j0t3> given the redundancy in all the utility wiring?
<awygle> we believed so based on our analysis, yes. and it was certainly much cheaper.
<qu1j0t3> zkms: There's a nice ACM Queue case study on the Space Shuttle computers but not sure it goes entirely into that level of detail
<qu1j0t3> zkms: some of the voting was mechanical
<qu1j0t3> zkms: which was i think one of their crucial inventions
<qu1j0t3> awygle: i like that solution. Filed for reference
<awygle> zkms: the voting circuit is an SPOF but assuming the failure isn't catastrophic, the voting glitches will be transient. much less bad than a long-term corrupted SRAM bit
<awygle> then you design in tolerance to bad inputs to the rest of your circuits
<awygle> so that they don't, say, fire explosive charges :p
<zkms> ohhh right yeah
<zkms> it's not stateful
<awygle> that combination of "protect persistent values" and "tolerate transient glitches" is a good one generally
<awygle> yup
mwk has joined #yosys
<zkms> and so SEUs don't break it
AlexDaniel has joined #yosys
<zkms> well, if they do the next clock cycle they get processed out or w/e
<awygle> exactly. although SEGRs still can :p
* zkms looks up what GR stands for in that acronym :)
<awygle> Gate Rupture! find some SEM pictures if you can
<zkms> have the feeling that if it shows up on SEM pictures it's catastrophic hardware damage
<awygle> yes it is
<awygle> it's when a high energy particle hits the gate oxide and ruptures it
<zkms> ouch
<awygle> yep. not much you can do at that point. it's rare though
<awygle> (well, it's rare in LEO)
<zkms> good thing i'm not making hardware that's going to space
<jer> where's the fun in making hardware that stays on the planet? =D
* shapr builds a bigger trebuchet
<zkms> heyyy in-atmosphere flight is fun
<awygle> true! and much harder to explain
<zeiris_> can't you just wrap it in enough layers of tinfoil
<awygle> that can actually make it worse, depending
<awygle> high energy particle (with small cross section because it's one particle) hits the tinfoil, spawns a bunch of medium-energy particles (which have a higher aggregate cross section)
<awygle> what you want is something called uhh "composite-Z shielding" i think? which has alternating, like, bismuth and boron
<awygle> (not actually those elements)
<awygle> graded-z, not composite z
<awygle> https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20140002469.pdf relevant paper much more authoritative than my half-rememberings
mwk has quit [Remote host closed the connection]
<awygle> huh, i just made a 40,000 element shift register and nextpnr placed it happily. that doesn't seem possible.
<awygle> maybe i suppressed errors?
<sorear> shift registers are ~the easiest thing to place
<awygle> oh i should have specified "on the hx8k"
<awygle> it shouldn't have room for 40k shift elements if i understand right. ice40 doesn't have distributed RAM
<awygle> yeah no, i just had errors suppressed. my b
mwk has joined #yosys
ZipCPU has quit [Ping timeout: 244 seconds]
ZipCPU has joined #yosys
<awygle> "why is GTK so slow at simulating this 4000 element shift register? ... oh."
<awygle> err, iverilog not GTKwave
mwk has quit [Ping timeout: 245 seconds]
mwk has joined #yosys
<awygle> is the nextpnr packer deterministic?
<ZipCPU> No.
<ZipCPU> Not by a long shot.
<awygle> ZipCPU: specifically the _packer_, not the placer
<awygle> turns out it's arch-specific
<awygle> and i don't see any randomness?
<ZipCPU> Ohh ... let me check
<ZipCPU> I misunderstood
<ZipCPU> Looks like the randomness is contained in the router and the placer.
<awygle> okay, cool
seldridge has quit [Ping timeout: 240 seconds]